1506Для того чтобы продать товар своей фирме надо ввести два документа: реализация и поступление , причем эти документы никак не связаны,т.е исправление в док. реализация не окажет никаго влияния на учет фирмы покупателя. - о какой консолидации можно вести речь, если при такой схеме даже получение "нормальных" взаимрасчетов между фирмами входящими в холдинг проблематично.

Вообщем то подход правильный. Ситуация: отгрузили 10 матрешек на 10'000руб, а доехали только 8 на 8'000 руб. Где разница зависла?

Также возможна ситуация при котрой на один документ реализация необходимо ввести несколько документов приход, например для распределения поступления на несколько складов (в 1С как правило один документ - один склад, хотя возможна реализация указания склада в строках табличной части и формирование аналитики проводок по складу указанному в строке).

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

Поскольку как правило холдинговый учет реализуется для управленческих целей очень разумно использовать типовые документы приворачивая к ним дополнительные управленческие навороты, без серьезного вмешательства в типовой функционал. На самом деле при "вдумчивом" проектировании можно многие моменты реализовать более четко и просто.

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

Для контроля взаиморасчетов все ли принято из того что отгружено используют специальный транзитные счета или регистры, аналитикой могут быть например - организации, склады, номенклатура. Простым отчетом или даже в обычной оборотно-сальдовой ведомости (если счета организуются через регистры бухгалтерии) можно увидеть какие именно разницы суммовые так и в разрезе номенклатуры "зависли". Наличие на таком счете в разрезе аналитики организация 1 - организация 2 не закрутых сальдо говорит о том что учет разъехался и необходимо принять меры "по консолидации".

GorOlegКлючевым словом является ЕДИНАЯ БАЗА по всем предприятиям, всем юридическим лицам а также ВРЕМЕННЫМ интервалам!
В 1С это будет куча баз и каждый год они делают "чистку базы" переводят "старые данные" в "архивные базы". Зарплатчикам может и пофиг, а вот Аналитикам это головная боль которую приходится через задницу решать.
Эта "задница" называется OLAP. Для целей управления очень большое значение имеет информация "сдесь и сейчас" поскольку именно на основании её принимаются решения.
В проекте в котором в настоящий момент принимаю участие (внедрение Axapt'ы) принято решение все отчеты разделены на "оперативные" и "аналитические". Оперативные нужно с точностью день в день плюс 2-3 дня. Все остальные - "аналитические" берутся из OLAP. К оперативным можно отнести остатки ТМЦ по складам (адресное хранение), остатки в разрезе партий (для уконтроля сроков хранения и реализации), оборотно сальдовые ведомости, взаиморасчеты с контрагентами и т.п. К аналитическим - анализ продаж (ABC, XYZ), расчет прибыльности, расчет стоимости услуг по транспортировке и т.п.

Временной интервал хранения данных в базе не может быть бесконенчным, как бы хорошо не была спроектирована база данных и какая бы идеальная среда разработки БД не использовалась. Возможности систем имеют ограничения.
Информация обладает очень важным свойством как объем. И какая бы платформа не была уменьшить в разы объемы хранения необходимой информации - невозможно.
Имение выделить в исторической информации ключевую и поддерживать на плаву именно её это искусство. Как правило в базе данных хранится очень большое количество разнообразной информации большая часть которой (оцениваю по принципу Паретто в 80%) с течением довольно незначительного времени становится просто не нужна - прибыль получена, период закрыт.