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

[Starling]

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

Цитата:

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

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

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