[fed]

В общем - в первом приближении у вас есть два возможных пути развития. Первый - продолжать поддерживать совсестимость со старыми версиями и не заводить, грубо говоря, субконто к счетам затрат. В этом случае - согласен с EVGL. Не хватает гибкого и расширяемого механизма распределения затрат, причем такого, к которому я бы мог малой кровью дописывать новые базы распределения и новые объекты распределения. Ну скажем - можно было бы завести новый объект распределения - машина с грузом и новую базу - килгораммы на километр. А потом завести второй уровень объекта распределения - товары внутри машины, с новой базой - кубометры объема груза. Подчеркиваю, я не жду от вас модуля транспортировок, я жду механизма который позволит мне легко интегрировать мой собственный модуль транспортировок со стандартным распределением затрат.

Второй подход - в чем-то более системный, но полностью ломающий совместимость. Можно завести таблицу иерархии затрат, таблицу проводок по затратам и новый тип счета в журлале ГК -Затраты. Только схема эта чревата боком, потому что:
1. Необходимо будет динамически формировать иерархию затрат. То есть - грубо говоря, если у вас есть веточка "затраты на транспортировку", то как-то надо будет дать возможность относить затраты и на транспортировку вообще, и на конкретную закупку. Я пока не очень понимаю как это можно сделать системным способом.
2. Вам явно придется закладывать в систему некоторую предопределенную модель иерархии затрат (хотя бы для того чтобы затраты по каждому модулю прикрепить к определенному месту). Наличие предопределенной иерархии явно сделает систему менее гибкой и приведет к тому что она будет хуже ложиться на потребности клиентов. Учитывая традиционно похабную документацию, в которой пишут про галочки, а не про экономическую модель, уверен что партнеры не смогут разобраться с этой моделью и будут жостко и противоестественно насиловать ее на каждом внедрении. Ну то есть - хотите использовать предопределенные отраслевые модели - на здоровье. Только хорошо бы эти модели были бы хоть как-то документированы...
3. Ну и естественно - первое время вся переписанная функциональность будет жутко глючить (просто по другому быть не может). А учитывая качество поддержки и традиционную нелегкость регистрации в ней багов - процесс исправления ошибок (я говорю не об ошибках дизайна, а о тупых кодерских багах), может очень затянуться.

Собственно - я верю что вариант номер 2 возможен, но не советовал бы вам его рассматривать в отрыве от состояния канала продаж/поддержки/работы с партнерами/документирования. Надеюсь вы помните, дорога в какое место выстлана благими намерениями...