Форум Сообщества Аналитиков
Обсуждения => Идеи и мозговой штурм => Тема начата: Стукалов от 28 Февраля 2017, 13:24:49
-
Коллеги приветствую!
Работаю в ритейле, в частности интеграции 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, это надо тоже учитывать. Вероятность не доставить пакет еще выше.
-
опишите в формате юзкейса, у вас тут ничего не понятно - ни входных условий, ни выходных, ни участников
а еще лучше - задайте прямо тот вопрос, который вы пытаетесь тут решить этой горой текста. Вы же не от недостатка общения сюда забрели, а с какой-то практической проблемой, надо полагать
-
Введём акцию водка+селедка+горбушка за 1/2 цены.
Кладём в чек три ВСГ-набора.
Удаляем одну водку (из первого набора). Имеем два ВСГ-набора за полцены + СГ за полную цену.
Удаляем одну селёдку (из второго набора). Имеем один ВСГ-набор за полцены + СГ + ВГ за полную цену.
Удаляем одну горбушку (из оставшегося набора). Имеем 2В+2С+2Г за полную цену.
-
Надеюсь, моя ремарка будет не слишком задержавшейся )
Коллеги здесь уже указывали верный подход.
Основной риск выбранного решения - это выделение отдельной систему для процессинга акций/скидок, и, таким образом, снижение надежности (а значит и повышение вероятности сбоя/отказа) системы вцелом при проведении расчетов. Но, догадываюсь, что архитектурное решение не подлежит обсуждению. Решение принималось не вами и без необходимой глубины (сам сейчас нахожусь в ритейле и решаю сходные задачи).
Так вот - в предложенном случае стоит с одинаковым успехом рассчитывать на выполнение расчета скидок смежной системой как при первом обращении, так и при изменении списка покупок. Лишние признаки расчета вряд ли идеологически защитят.