Нужна помощь в проектировании системного процесса offline расчета скидок(Прочитано 7691 раз)
Коллеги приветствую!
Работаю в ритейле, в частности интеграции CRM и POS систем, столкнулся с необходимостью создания процесса расчета скидок в offline режиме, примерное понимание будущего процесса уже имеется, но я хотел бы всесторонне его оценить, в том числе и с вашей помощью.
Итак, начну.
Процесс as is выглядит следующим образом:
 1. Pos система передаёт запрос в CRM на расчет скидок\акций по чеку. (В этом шаге мы предполагаем что связь между системами есть всегда)
 2. CRM рассчитывает скидки\акции и присылает ответ с изменённой стоимостью товаров.
 3. Pos система формирует чек и сумму к оплате
 4. Связь между системами обрывается и клиент просит удалить 1 из товаров из чека.
На последнем шаге Pos удаляет позицию и отправляет оставшиеся на перерасчет (это фундаментальная логика и изменению не подлежит), но так как связь с CRM отсутствует, мы сталкиваемся со следующими сценариями:
 * Оставшиеся позиции перерасчитываются по номинальной стоимости (эти данные загружены в Pos) - текущий сценарий нас не удовлетворяет, т.к. мы не выполняем перед клиентом Оферту;
 * Позиции не перерасчитываются - Теущий сценарий нам так же не подходит т.к. приводит к потенциальным убыткам (Акция "Купи колбасу, хлеб в подарок". Покупая колбасу и затем удаляя её из чека, хлеб продаётся по нулевой стоимости).

Процесс to be:
 1. Pos система передаёт запрос в CRM на расчет скидок\акций по чеку. (В этом шаге мы предполагаем что связь между системами есть всегда)
 2. CRM рассчитывает скидки\акции, присваивает товарам признак набора акции и привязывает его к количеству и присылает ответ с изменённой стоимостью товаров.
 3. Pos система формирует чек и сумму к оплате
 4. Связь между системами обрывается и клиент просит удалить 1 из товаров из чека.

В данном процессе, во 2 шаге я добавил присвоение признака набора акции и его отношения к количеству, в таком случае, используя сценарий перерасчета чека в момент отсутствия связи с CRM, POS система, видя изменение кол-ва у товаров с одинаковым признаком набора акций, перерасчитывает по номинальной стоимости только только товары, входящие в набор акции, пример ниже:
 * Имеем в чеке 4 товара по акциям ("Купи колбасу, хлеб в подарок"(признак 1 к кол-ву 2) и "Купи торт, кофе в подарок"( признак 2 к кол-ву 2).
 * Удаляем из чека колбасу
 * POS перерасчитывает чек и видя изменения кол-ва у 1 признака, присваивает "хлебу" номинальную стоимость, а стоимость "Торта и кофе" не изменяет, т.к. для признака 2 не было изменения кол-ва.

Прошу прощения за объёмный текст, осталось ещё немного :)

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



1. Почему на шаге 4 связь рвется, а на первом нет?
2. ИМХО все акции всегда зашиты в ПОС терминал по всем товарам ПОСа и синхронизируются с СРМ по расписанию или по изменениям на стороне СРМ.
3. Пакеты по обмену вырастут на шаге 2, это надо тоже учитывать. Вероятность не доставить пакет еще выше.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



опишите в формате юзкейса, у вас тут ничего не понятно - ни входных условий, ни выходных, ни участников
а еще лучше  - задайте прямо тот вопрос, который вы пытаетесь тут решить этой горой текста. Вы же не от недостатка общения сюда забрели, а с какой-то практической проблемой, надо полагать
« Последнее редактирование: 11 Марта 2017, 13:54:40 от ida - брэнд с 14-летней историей »



Введём акцию водка+селедка+горбушка за 1/2 цены.
Кладём в чек три ВСГ-набора.
Удаляем одну водку (из первого набора). Имеем два ВСГ-набора за полцены + СГ за полную цену.
Удаляем одну селёдку (из второго набора). Имеем один ВСГ-набор за полцены + СГ + ВГ за полную цену.
Удаляем одну горбушку (из оставшегося набора). Имеем 2В+2С+2Г за полную цену.
[...и улетело НЛО.]



Надеюсь, моя ремарка будет не слишком задержавшейся )

Коллеги здесь уже указывали верный подход.
Основной риск выбранного решения - это выделение отдельной  систему для процессинга акций/скидок, и, таким образом, снижение надежности (а значит и повышение вероятности сбоя/отказа) системы вцелом при проведении расчетов. Но, догадываюсь, что архитектурное решение не подлежит обсуждению. Решение принималось не вами и без необходимой глубины (сам сейчас нахожусь в ритейле и решаю сходные задачи).
Так вот - в предложенном случае стоит с одинаковым успехом рассчитывать на выполнение расчета скидок смежной системой как при первом обращении, так и при изменении списка покупок. Лишние признаки расчета вряд ли идеологически защитят.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19