Lucius1 Вести и учитывать не есть одно и тоже
Вести, это когда в 2-х БД могут создаваться уникальные записи, и их нужно "взаимореплицировать" (Обычно решается разведением по ключу учетных записей). Я хочу, чтобы уникальные записи по одному бизнес процессу создавались только в одном месте, а в Центр передавались без возможности изменить или добавить. (отсутсвие документов в Центре будет ограничением для реализации DrillDown при надстройке аналитической системы)

Я Вас немного непонял. Что значит вот этот момент - Обычно решается разведением по ключу учетных записей. Пожалуйста поподробнее.
Просто действительно интересно чем ведение отличается от учета.

LuciusПробую еще раз
В терминах, которыми я оперирую:
Вести данные - это создавать учетные записи (например приход на склад).
Если эти приходы создавать только в БД склада, а в центральную БД только собирать как факт, без возможности изменения - это учитывыать факты.

Есть вариант, когда пользователи одновременно из разных точек создают документы по одному бизнес процессу.
Например приход на склад может создать и кладовщик и менеджер ЦО, каждый в своей базе с последующим обменом данными.
В таком случае есть вероятность, что в обеих БД появятся разные записи с одинаковым идентификатором (первичным ключом), это может быть номер докмент, простой сиквенс, и пр... и непонятно, какую запись оставить а какую заменить
Для того, чтобы этого не произошло проше всего развести первичный ключ на большие значения
например на складе нумеровать записи с 1 а в ЦО с 1000000
Поскольку вероятность ввода миллиона (миллиарда и тд.) документов отсутсвует, то и вероятность появления 2-х записей с одинаковым первичным ключем исчезает

Вроде понял Вашу терминологию. Списибо за объяснение.

Обычно под учетом - я понимаю регистрацию какого-либо события.
Поэтому соединяю учет и ведение как синонимы.

Есть жизненное правило - где информация создается, там должна и изменяться. Согласитесь было бы странно если бы в ЦО правили доки филиалов.

Распределение дапазов учетных номеров в СБО есть в настройках.

LuciusТогда еще вопросы, если позволите.
Как я уже говорил будет 4 подразделения (бизнес единицы), и у каждого свое юр лицо.
Я хочу узнать:
1) можно ли сохранять историю смены юр.лиц
2) Есть ли такое понятие как центр прибыли\убытков
3) К центрам прибыли убытков относятся юр лица или подразделения
4) Расчетные счета привязаны к Юр.Лицу или к подразделению
5) Есть ли возможность ввести касы с привязкой к сотруднику (чтоб не оформлять выдачу под отчет)

Пп. 1. Неясен.
В СБО одна фирма - 1 база. (БД в SQL Server).
Пп. 2.
Есть центры учета.
Пп. 3. подразделения

Пп.4 Юр.Лицу (В СБО они называются Бизнес-Партнер)

Пп.5 Не знаю.

Shuhard[quot steplton В СБО одна фирма - 1 база. (БД в SQL Server).

шютка - множественность юр.лиц в одной базе осуществляется разными способами[/quot]

Нет не шутка, правда. Одна фирма - одна база. Это 100% процентов.

Shuhard stepltonНет не шутка, правда. Одна фирма - одна база. Это 100% процентов.
1 Запросите у старших товарищей толкование термина множественность юр.лиц.
2 не пужайте публику , в SBO ведется не только(не столько ?) белый учет , счет-фактурки и книги продаж по ПБУ.

Ну хватит прикалываться, гды Вы такое понятие взяли множественность юр лиц.
Первый раз такое слышу. Объясняйте, вместе посмеемся? :)
П 2 это к чему ?

LuciusОбъясняю
Мой склад и мой магазин - суть два подразделения 1-ой сети
но по бух учету это 2 разных юр лица, и одно другому товар продает (или выдает на комиссию)
Потом, по причине неважно какой я хочу, что б мой скалд поменял юр. лицо (например я решил его оформить малым предприятием или еще чего), ну не собираюсь я заводить еще одну фирму и продавать весь товар с одной на другую в управленческом учете, по бухгалтерии - да.
Так что Юр.лицо - это периодический (зависит от времени) атрибут подразделения.

to Shuhard:
множественность юр.лиц в одной базе осуществляется разными способами

можно примеры или намеки. Какие порблемы меня ожидают

Что Shuhard думает по этим вопросам ?