Правильно ли сделан функционал и организован процесс?

[Starling]

To Владимир Максимов
Вообще конечно со всем согласен, но вот этот пункт

Цитата:

Сообщение от Владимир Максимов

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

В стандарте реализован не самым лучшим образом. Причина в том, что к одной строке заказа на продажу может быть применено несколько скидок. Как пример несколько скидок по строке - одна настроена на уровне клиента, другая на уровне группы клиентов. Эти скидки суммируются и разобрать потом, как они получились уже очень проблематично. А если коммерческие соглашения менялись, то почти невозможно.
Я не нашел ни какого универсального решения этой проблемы. На конкретном проекте пришлось вводить ряд ограничений:
1. Использовать многострочные скидки, хотя по свой природе это были скидки по строке, чтобы отдельно выделять их.
2. Запретить административно использовать более чем одну скиду по строке к одному заказу на продажу.
3. Ряд скидок вынести на накладные расходы.
В целом хранить историю цены получилось, но решение далеко не универсальное.
Стояла ли перед вами такая задача, если да, то как вы ее решали.

[Владимир Максимов]

Цитата:

Сообщение от Starling

Стояла ли перед вами такая задача, если да, то как вы ее решали.

Ну, у нас несколько попроще. Изменение задним числом, конечно, возможно, но это целая история с вовлечением в процесс кучи народа. Так что, нет особой необходимости хранить историю изменений именно в заказе. Сами справочники не меняются задним числом. Поэтому вполне досточно хранить лог изменения таблицы скидок через стандартный SysDataBaseLog

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

[Starling]

Цитата:

Сообщение от Владимир Максимов

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

Вообще наверно задачу нужно разбить на две части:
1. Хранить историю изменения коммерческих соглашений, для этих целей подходит журнал коммерческих соглашений. И на его основании можно было бы формировать отчеты. В 2012 все коммерческие соглашения можно менять только через эти журналы. И автору я бы советовал посмотреть в эту сторону.

2. Хранить историю ценообразования для конкретной продажи. У меня были сложности именно с этим.

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

Но так как удалось "запихнуть" историю почти в стандарт с учетом описанных выше ограничений, то от этой идеи отказались.
Как по мне такое решение было более универсальным.