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

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

Слишком много "буков" Разбивай задачу на этапы.

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

Аксимома 2: Если заказа проведен по бухгалтерии, то изменить его невозможно! Нужно сторнирование и проведение заново, но уже как нового заказа (новые складские проводки, новые логи)

Т.е. выбирать/сохранять какие-либо реквизиты надо один раз в момент обработки заказа. Либо обработки счета-фактуры, либо накладной. Смотря по тому, в какой момент требуется окончательная цена в зависимости от бизнес-процессов. Ну, и необходимо блокировать возможность изменения реквизитов заказа, влияющих на цену после обработки

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

Соответсвенно, фиксируем только и исключительно то, что действовало на момент проведения заказа. И не важно, что там было "до" или стало "после". Еще менее важен интервал изменений. Хоть сутки, хоть год, хоть миллисекунды. Что "попало" в момент проведения, то и использовали.

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

Ну, а что именно надо зафиксировать - это уже другой вопрос.

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

[Murlin]

Цитата:

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

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

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

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

Цитата:

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

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

Так в 1С, насколько я в курсе, тоже перепроводят заказы в таких случаях. Правда, там это организовано без сторнирования (кажется, пункт меню "Распровести"), но все-равно делают то же самое.

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

[Starling]

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[Starling]

Цитата:

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

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

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

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

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

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