Учет по нескольким предприятиям в одной базе данных

[Maxim]

Syte
Вы предложили очень интересный метод ведения нескольких ЮрЛиц!!!
Сразу все в голове не укладывается, но такое впечатление что это реализуемо.
Если можно, несколько вопросов, как реализовали:
1) Проводки и планы счетов?
2) Такие специфичные модули как ОС, НМА и т.д.
3) Использовали ли доступ к таблицам по условиям?

ddim
Бюджет (тоже могу ошибаться) можно собирать через ЦО, т.е. консолидировать.

[Syte]

постараюсь объяснить на примере двух организаций - так проще, а количество организаций в реальности можно увеличить по аналогии.
так вот, существуют 2 организации - ЗАО Тест - г. Нью Йорк и ООО Тест г. Урюпинск. Берем для примера четверых пользователей - два в NY и два в Урюпинске. Причем босс в NY должен иметь доступ к полной информации - т.е. в режиме реального времени отслеживать ситуацию и там, и там. пользователи для NY - Вася Пупкин (Босс) и Лена Пупкина - Главбух. Для Урюпинска - Коля Сидоров - грузчик/кладовщик/директор, Ляля Сидорова - главбух.
Для наглядности возьмем первые 6 символов фамилии и один - имени для формирования логинов. Итого для NY: PupkinV и PupkinE. Для Урюпинска: SidoroN и SidoroL
Первостепенной задачей является заполнение поля DESGR во всех таблицах, где оное существует. Список таблиц получается вот таким запросом:
select X$FIles.XF$NAME from X$FIles, X$Fields where (('DESGR'==X$Fields.XE$NAME and X$Fields.XE$FILECODE==X$FILES.XF$CODE));
Для NY ставим значение DESGR равным NYC, для Урюпинска - URU.
Если задача в том, чтобы разделить одну базу на две части, принадлежащими отдельным организациям, по раздел документов можно произвести отталкиваясь от поля DESCR - дескриптор пользователя. Проводки, сальдо и пр - от плана счетов. Планов счетов, кстати, можно вести сколько угодно. У нас используется 6 - по три на организацию - план счетов 2001, Налоговый учет и GAAP. Для тех бухгалтеров, которым мешают "лишние" записи в плане счетов поставлен фильтр по условию, чтоб не путались. В ОС, НМА и пр. тоже есть поле DESGR, но в 7.10 фильтр по группе не работает (и не заполняется из интерфейсов Галактики) Можно обойтись фильтром по условию по DESGR, а можно использовать различия в нумерации, добавляя букву в номер, например. Таким же образом обходится проблема нумерации документов - она ведется в разрезе центров ответственности.
После заполнения поля DESGR необходимо изменить тип настроек:
Организация, Руководитель, Главный бухгалтер, банковские настройки, код инспекции, КПП и т.д. - по необходимости. Как это сделать, я писал ранее. После этого на каждого пользователя заполняются значения измененных настроек. Каждому своё.
Создаём группы пользователей (NYC и URU).
Затем каждому пользователю необходимо присвоить свою группу. (Настройка/Пользователь/Группа дескрипторов).
Далее ограничиваем пользователям доступ к документам по группе дескрипторов (Настройка/Документы/Доступ к документам - все права в рамках группы), а для PupkinV - все права.
Таким образом все пользователи, кроме PupkinV будут видеть (и создавать) документы (проводки - при правильной настройке ТХО)только своей организации.
Если PupkinV требует возможности создавать документы от имени Урюпинской организации, то ему можно создать отдельный логин, например - PupkinV_URU, оставив "домашний" логин без изменений, а в "чужом" настроив соответствующую группу пользователей, либо разрешив выбор группы при создании документов.
Теперь о том, как ведет себя система при, например, печати документов.
Печатаем накладную на продажу (расходную). Как тут уже упоминалось, поля "своя организация" в Галактике не существует.
Однако, своя организация указана в настройках (в нашем случае - в измененных). Интерфейс редактирования накладной формирует несколько переменных - MyOrg, Директор, Главбух и т.д, получая их значения из настроек. Таким образом для группы NYC они получатся: ЗАО Тест, Василий Пупкин, Елена Пупкина (мы назначали пользователям эти значения в настройках). А для Урюпинска - ООО Тест, Николай Сидоров, Ляля Сидорова (аналогично). И т.д. в ДО (счетах на оплату), ордерах, счетах-фактурах и пр. и др. Сальдовые остатки МЦ на складах фильтруются аналогично. Те МЦ, движение которых производилось только в одной из организаций, в другой организации даже жирным не подсвечены.
Для ARD-отчетов мы придумали простой интерфейс-переключатель с выбором группы, который возвращает определенное нами значение. А в отчетах достаточно добавить в блок where (( ..... ... and 'NYC'==TABLE1.DESGR)) или соответствующую переменную вместо значения.
Если что-то пропустил, пишите.

Best regards,
Alexei Vishnevsky,
CMSA CIS.
___________________________
Aut viam inveniam, aut faciam

[ddim]

Система учета бизнеса она вообще-то довольно шаблонная и мало зависит от предприятия и того, что на нем выпускают и в какой отрасли оно работает. Если говорить о бухгалтерии и логистике, то там вообще штатного функционала никому не удавалось освоить более 20% того, что есть в Галактике. Главным образом мы автоматизировали именно эту сферу.

С этим не соглашусь. Если брать накладные, бухгалтерию - то да. А если глубже, то каждая фирма развивается своим путем и у многих есть сложности ...
Например, бюджетирование видел очень разное у всех ...
Управленческий учет у многих разный!

Хотя по оперативному учету можно внедрение галактики довести до 80% и выше: валюты, разные прайсы, сложные остатки по складам, резервирование и т.д.

Вы поймите правильно, что сама доработка для нас не представляет никакого труда, т.к. я программирую на ВИПе уже более 10 лет и из них 4 года был начальником отдела разработки самой Галактики, когда работал в корпорации.

Ой ... тогда я знаю кто скрывается под ником "ecasoft" ...
Это Игорь Косякин

У меня есть люди, котрые имеют большой опыт в разработке. Никаких проблем, чтобы что-то там доработать или переписать - нет. И казалось бы наоборот я должен бы агитировать всех все переписать. НО...самое сложное в переписывание (и вообще в программировании) - это тестирование и сопровождение кода, а не само по себе программирование.
Это написано в любой книжке.

Кстати, галактика долгое время писалась, сопровождалась (да и зародилась!) и тестировалась программистами!
Так что и галактика зародилась не правильно!

В итоге, получается, что все что Вы (или мы) разработаем является поделками, несоответсвующими технологии программирования, непонятно кем сопровождаемое (т.к. у Вас у функциональных обязанностях формально сопровождение наверняка не закреплено, да и нет никакой гарантии, что завтра Вы не уйдете с предпрятия и это все не выкинут). Это низкосортные программки, с неопредленным сроком жизни.

Я не согласен! Можно написать небольшую систему достаточно быстро и она будет работать и будет ОЧЕНЬ хорошо удовлетворять нужды конкретного заказчика. Это называется "экстримальное программирование".
В этом случае ПОСЛЕ написания системы:
1. она должна быть с открытым кодом и должен быть доступным человек, который понимает этот код (именно по этому при заказных разработках лучше связываться с фирмами, а не персоналиями!).
2. все в системе нужно задокументировать и поддерживать далее эту документацию в актуальном состоянии.
3. так и рождается галактика

А про суммы ... за сопровождение: 20 часов (на визиты) в месяц я беру 500 у.е. - это разве много? заказчику хватает этих часов. Даже иногда у меня часов меньше, а сумма фиксированная.

Поэтому с клиентами мы стараемся (это не всегда выходит правда) придерживаться следующих правил при работе на Галактике:

1. Работа на штатном функционале

Таких клиентов видимо будет все меньше и меньше! Могу утверждать что управленческий учет у многих разный!

2. Отказ от сотрудников АСУ поддерживающих Галактику внутри или минимизация количества (вообщем-то 1-го человека можно иметь, хотя он может выполять эту работу совмещая еще с чем-то) - это чаще всего не нужно,т.к. это огромные затраты предприятия - чаще больше, чем закупка и сопровождение Галактики . В Москве это до 15 тыс $ в год на 1 чел.

Ну это очень спорно ... не буду уточнять почему

3. Любая доработка, ее необходимость, должна быть обоснована сотрудниками, которым она нужна, цифрами перед руководством своего предприятия, в которых показано, сколько, когда, как часто и за счет чего теряет предприятия экономически (упускает прибыль), если не будет сделана такая доработка. Если, к примеру, предприятие теряет 10 тыс. долларов в год за счет отсутствия доработки, то понятно, что можно 5 тыс в год тратить постоянно, чтобы ее закрывать. В любом другом случае доработка не делается,т.к. это прихоть каких-то сотрудников.

Золотые слова!

[ddim]

Syte
Вы предложили очень интересный метод ведения нескольких ЮрЛиц!!!
Сразу все в голове не укладывается, но такое впечатление что это реализуемо.
Если можно, несколько вопросов, как реализовали:
1) Проводки и планы счетов?
2) Такие специфичные модули как ОС, НМА и т.д.
3) Использовали ли доступ к таблицам по условиям?

ddim
Бюджет (тоже могу ошибаться) можно собирать через ЦО, т.е. консолидировать.

ЕЩЕ раз хочу уточнить: судя по описанию, это всего лишь использование галактики с разграничением по дескрипторам!
В таком случае, очень спорно считать что это разграничение по юр.лицам!
Ведь не известно куда дальше двинется галактика и дескрипторы

Говорю вам, раньше была внутренняя организация в документах и основных таблицах и от этого ушли посчитав что корпорация на этом теряет деньги!!!

[Max_Fin]

Открыт секрет полишинеля

Ой ... тогда я знаю кто скрывается под ником "ecasoft" ...
Это Игорь Косякин

[oiko]

А ddim - Дима Сидоров

[ddim]

Открыт секрет полишинеля

Ой ... тогда я знаю кто скрывается под ником "ecasoft" ...
Это Игорь Косякин

Ой ... а я думал что эту длинную ветку сейчас читают только те, кто в ней пишут

[ddim]

А ddim - Дима Сидоров

Точно!

[ecasoft]

Вообще-то, в старом форуме, в котором я регистрировался, мой ник и был моим реальным ФИО, а в новом, господа из Тюмбита сами его заменили на название фирмы. Мне вообщем-то все равно, даже с фирмой удобнее наверное. Так что никто и не скрывался под никами

На счет доработок - вообще-то дело хозяйское, каждый сам должен решить, тем более интерересы у всех разные и однозначного ответа и получиться не могло. Мы раньше даже здесь предлагали свои доработки, но потом поняли, что кроме проблем с ними ничего хорошего не получится. Корпорация скорее против доработок, чем за...во всяком случае стратегии такой нет. Судя по своим клиентам - это тоже чаще всего не нужно предприятию, а чаще это прихоть сотрудников АСУ, которые решение всех вопросов видят лишь через программирование, дописывание, докручивание....не видя (и не желая видить) никакой экономической пользы для предприятия. Их можно понять - ну любят люди программировать..скучают по этому делу...и надо им приложить куда-то свои способности - вот и придумывают, а если дексрипторы назвать организациями?

Помню был случай, когда в одной фирме один программист сказал, что не надо им кадры,т.к. склад можно легко использовать как управление персоналом и показывал, что сотрудников надо вводить как МЦ, принимать, как оприходывать, увольнять, как списывать, переводить, как внутреннее перемещение...вообщем кое-что там подправил в отчетах и можно было вести и кадры на складе Ну есть у человека фантазия и хочется приложить ее, а главное время на работе есть оплачиваемое. Пусть делает - получит удовольствие.

Мне тут фраза понравилать - ХОРОШАЯ ИДЕЯ. Вообще, работа по внедрению не очень уж творческая на самом деле, если знаешь системы, а скорее рутинная. Когда не знаешь и не хочешь ничего читать в документации - то рождаются идеи