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

[Murlin]

Есть некоторый функционал рекламных акций... собс-но просто какая то болванка, таблицы шапок, строк, мест проведения и периодов, которые не несут какой то особой смысловой нагрузки... данные таблицы просто попадает в кассовую программу которая уже сама по себе расчитывает какие то скидки... никаких проверок на пересечение рекламных акции - нет, хотя по процессу их и не должно быть в рамках одного типа скидочной карты, причем работать из этих двух, трех и тд пересекающихся акции будет только та у которой некоторой цифровое поле генерируемое аксаптой и нередактируемое будет меньше. У акции есть некоторый период её действия, ну поскольку пользовтели не особо задумываются и ленятся то включают и выключают редактируют(меняют например номенклатуру), включить могут как в прошлом так и в настоящем да и в будущем. Все бы ничего но от меня требуют получать какие то данные для выгрузок, для OLAP-кубов и тп... ну например сколько по каким то акциям было продано товара, какая цена у товара была по акции, оповещать пользователей о начале и конце рекламных акций(чтобы успели поменять ценники в магазинах)(продажи и цены попадают в аксапту из кассовых аппаратов)
Решил как то ограничить пользователей для того чтобы хотя бы как то и что то получать точно, а не "сферического коня в вакууме", т.е. отменять проведение/включение/разноску действующих рекламных акций только по письменному запросу, разработать какой то алгоритм действий сверки правильности рекламной акции до ее начала, а не после, запретить проведение/разноску/включение рекламных акции в прошлом(всем кроме администратора ибо синхронизация с кассовой программой идет вроде бы с каким то неочень большим промежутком времени), запретить включение/разноску/проведение пересекающихся акций(избавиться от непонятной и какой то "машинной" логики по цифровым полям), сделать как бы проводки по рекламным акциям(ну т.е. хранящие историю действия этих рекламных акций)... Не знаю насколько предложение рационально, но мне сказали что тут главное это то чтобы пользователи могли сами все исправлять... Акции могут быть большими, т.е. смсками тут тоже оповещение ну наверное никак не сделаешь
Внимание вопрос: правильно ли организован процесс на предприятии?

[mazzy]

Цитата:

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

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

Не очень рационально.
С людьми не стоит бороться. Такова их природа.

Лучше пусть делают что угодно. Но вести тщательные логи - похожие на проводки.
И отчеты строить по таким логам/проводкам. Похоже на финансовый учет в Аксапте.

Получится чуть сложнее, но железобетонно с точки зрения отчетов.

[Murlin]

Цитата:

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

Не очень рационально.
С людьми не стоит бороться. Такова их природа.

Лучше пусть делают что угодно. Но вести тщательные логи - похожие на проводки.
И отчеты строить по таким логам/проводкам. Похоже на финансовый учет в Аксапте.

Получится чуть сложнее, но железобетонно с точки зрения отчетов.

а какой смысл тогда в проводках если они будут содержать "сферического коня в вакууме"?

[S.Kuskov]

Цитата:

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

а какой смысл тогда в проводках если они будут содержать "сферического коня в вакууме"?

Проводки помогут разобраться как этот конь сформировался. Если пользователям всё-равно, то возможно руководству будет не всё равно.

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

Для начала Вам надо уточнить, должна ли в отчетах отображаться история или же все отчеты строятся по состоянию на "сейчас". Поясню

Допустим, у Вас действовала на 01 число некая акция. По этой акции был продан товар. Затем пользователь подумал и изменил период действия акции не с 01, а, скажем, с 10 числа.

Вопрос: Как в отчете надо отобразить товар, проданный 01 числа? Как проданный по акции, действовавшей на это число или же безо всякий акций, поскольку сейчас эта акция начинается с 10 числа.

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

PS: поскольку после закрытия склада товародвижение в закрытом периоде невозможно, то можно автоматом ограничить изменение задним числом по дате последнего закрытия склада.

[mazzy]

Цитата:

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

а какой смысл тогда в проводках если они будут содержать "сферического коня в вакууме"?

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

[Murlin]

Цитата:

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

Для начала Вам надо уточнить, должна ли в отчетах отображаться история или же все отчеты строятся по состоянию на "сейчас". Поясню

Допустим, у Вас действовала на 01 число некая акция. По этой акции был продан товар. Затем пользователь подумал и изменил период действия акции не с 01, а, скажем, с 10 числа.

"сферический конь в вакууме" :-) с 01 на 10. с на сейчас все и так понятно... проблема только в том что и на сейчас работает неочень понятно(про цифровое поле)
я когда сказал менеджеру что если даже акция и включена то не факт что она действует ее немного переклинило... да и соб-на я вообще не понимаю как можно акции проверять когда они уже запущены. Будущее не страшно я уже придумал что историю буду перетирать полностью которая в будущем. Но вот незадача акции большие по многим магазинам с периодичностью(только во вторник например с 2х до 3х)... будет а) тормозить б) акции которые на прошлые периоды будут просто засорять историю что за акция которая действовала 30 секунд?

[Murlin]

Цитата:

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

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

мне не просто история нужна а история для получения каких то данных, желательно фактических зачем мне чисто теоретические??? что с помощью теоретических данных они хотят увидеть?

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

Что-то какой-то "поток сознания". При чем здесь какие-то числовые поля?

Есть заказ на продажу. На момент проведения этого заказа действует акция. Действующая акция влияет на цену/сумму продажи? Если влияет, то Вы просто обязаны создать дополнительные поля, как минимум, в строках заказа (идеально - в логах), где и зафиксировать информацию, на основании которой такая цена получилась. Иначе как Вы потом будете объяснять руководству, почему товар продали за 5 руб, если его цена 10? Это даже не отчеты, это банальный "разбор полетов"

[Murlin]

Цитата:

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

Что-то какой-то "поток сознания". При чем здесь какие-то числовые поля?

Есть заказ на продажу. На момент проведения этого заказа действует акция. Действующая акция влияет на цену/сумму продажи? Если влияет, то Вы просто обязаны создать дополнительные поля, как минимум, в строках заказа (идеально - в логах), где и зафиксировать информацию, на основании которой такая цена получилась. Иначе как Вы потом будете объяснять руководству, почему товар продали за 5 руб, если его цена 10? Это даже не отчеты, это банальный "разбор полетов"

Есть пересекающиеся акции по одному и тому же товару одному и тому же магазину типу дисконтной карты в рамках сегодняшнего дня, так вот вычисление реальной активной акции делается по некоему цифровому полю там где это поле меньше та и является фактически активной. Такая вот еще проблема... т.е. по нормальному одну акцию надо откатить(обрезать до текущего момента), вторую провести(и только с текущего момента не важно чего там написано) уведомить пользователей...
а если вот эти откаты проведение будут по 100 раз в день делать? что будет с историей, пользователями?
Как фиксировать то? каким образом... они могут спокойно акцию провести завтрашним днем когда акция не действовала, не могу же я пойти и забрать товар у покупателя... просто я сделал вывод что для акции как бы закрытым периодом(в котором нельзя проводить задней датой) текущий момент времени-0.000000000000000001 милисекунды. а потом руководство спросит а вот почему? и что ответить? по истории запись есть а товар чего это продали по такой цене
я вот и спрашиваю правильно ли вообще устроен процесс? или лучше логировать и разбирать полеты или лучше сразу в чем то ограничить?

[Ivanhoe]

Как то делали похожий ОЛАП. В итоге пошли на упрощение - в одном кубе была несвязанная информация о продажах и об акциях, действовавших по товару / периоду. Не раскрывая аналитику "Акция" по товару можно было видеть Выручку и количество акций на момент времени, при желании - раскрываем аналитику "Акция", по пустому значению "Акция" видим факт продаж, отдельными строками - коды акций, но пустые продажи.

[S.Kuskov]

Действия пользователя в системе должны быть осмысленны. Когда пользователь для получения конечного результата сам вынужден определять и выполнять набор несвязных действий - это повышает требование к квалификации такого пользователя. Возможно нужно сгруппировать настройки и операции в какие-нибудь мастер-формы, визарды; реализовать вспомогательные операции при помощи журналов, разнося которые пользователь отражает изменения одновременно в нескольких таблицах.

Цитата:

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

мне сказали что тут главное это то чтобы пользователи могли сами все исправлять...

"ВСЕ - нехорошее слово. Как только появляется слово ВСЕ - жди логической ошибки." (c) mazzy


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

Цитата:

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

правильно ли организован процесс на предприятии?

Сдаётся мне, что он не организован

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

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

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

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

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

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

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

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

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

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

[Murlin]

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[Starling]

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

Цитата:

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

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

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

[mnt_dx]

Murlin, а почему эти акции пересекаются?
Мое мнение:
1) надо выяснить и сформулировать случаи, когда акции могут пересекаться
2) сделать в системе предупреждения менеджерам, создающим акции, что их новая акция пересекается с другой активной акцией.
3) при сохранении пересекающихся акций отправлять уведомление руководителю, например, директору магазина/директору по маркетингу.

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

Цитата:

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

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

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

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

[Murlin]

Цитата:

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

Murlin, а почему эти акции пересекаются?
Мое мнение:
1) надо выяснить и сформулировать случаи, когда акции могут пересекаться
2) сделать в системе предупреждения менеджерам, создающим акции, что их новая акция пересекается с другой активной акцией.
3) при сохранении пересекающихся акций отправлять уведомление руководителю, например, директору магазина/директору по маркетингу.

Оно как бы есть но ругается на товар и работает при сохранении !!!! СТРОКИ!!!! скидки с номенклатурой, простой warning. причем такие же длинные и непростые методы про которые я написал в другой теме(особенно радостно это все высчитывать в олапах и дисплей методах)

Пересекающиеся акции есть потому что они есть... реально есть в системе по данным...
Когда пересекаются выяснял сам у спеца по кассовой программе, ну скидочная система достаточно простая, ничего ни с чем пересекаться не должно... насколько я все это понял. или всмысле как пересекаются??? по коду номенклатуры, складу, типу дк и времени ест-но...

[Starling]

Цитата:

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

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

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

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

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

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