Вариант реализации второго плана счетов, для критики

[Torin]

Axapta 3.0 SP3
Итак, есть входные требования:
1) 2 Плана счетов. 1-й бухгалтерский, второй Управленческий (не черный, прошу заметить).
2) Холдинг с 15 юридическими компаниями. первый ПС ведеться в каждой из них, второй (Управленческий) ПС должен отражать смысл (содержание) операций в ссотвествии с учетной политикой Управленческого учета в общей ГК (скорее всего отдельная компания). При консолидации в Управленческий учет, никаких требований по инфляционным ожиданиям, валютным разницам и прочего нет, потому что общая вторичная валюта, и нас пока это не интересует.
3) Оригинальной методикой по руководству (помножить планы счетов и сделать общий) восспользоваться не получилось, так как первый ПС скорее по форме, а второй ПС по содержанию. Результат "умножения" ни понять ни использовать не представляется возможным.
4) С точки зрения момента признания доходов-расходов в обоих ПС свои принципы.
5) Пункт 2, так или иначе, дает целую серию требований, например, струтура затратных счетов несовпадает в принципе. Невозможно однозначно правильно интерпретировать проводку по ГК в бух. учете в Управленческий учет.
6) Про Налоговый ПС пока не говорим, он отдельно в каждой компании.
7) По затратным счетам пишеться отдельное приложение, немного похожее на РБП.
8) Считается, что относительно мало проводок создается напрямую по счетам ГК.
Да, и это бизнес дистрибуции, где позиции Аксапты типо "сильные"

Надо сказать, что мы нашли более 10 вариантов реализации все тщательно продумали.
Сейчас склоняемся к следующему (сильно упрощаю):
В любой компании ведеться нормальный Бух учет.
Берем проводку ГК и связанных с ней проводки модулей. Берем из оригинальной проводки объект, суммы, LedgerPostingType (которое Маззи назвал бесполезным), прогоняем через новые "профили разноски", получаем проводки по Управленческому учету.
"Новые профили разноски" - это, на основе оригинальных диалогов Профилей разноски всех модулей, сделаны для Управленческого учета и настроены.

Собственно, плюсы:
1) Отдельный функционал позволяет не беспокоится за качество работы стандарта.
2) Мы можем указать другую комбинацию счетов под "объект учета" и "тип разноски" - по разному интерпретировать объекты модулей в БУ и УУ.
3) Настройки разноски по БУ и УУ производятся в разных местах, это удобно для интерпретации (не создаем "кросс" таблиц)
4) Мы не занимается генерацией проводок модуля, а только пользуемся его результатом.

Но есть и опасения:
1) Если перечисление "LedgerPostingType" некорректно используется, то придеться править оригинальный код.
2) LedgerPostingType (просто нет документации внятной) - может и не соответствовать смыслу операции модуля с точки зрения "профилей разноски" - это частично проверено, вроде ОК.