Корпоративные системы и интеграции
Синхронизация продаж, запасов и цен между POS и ERP
POS и ERP: продажи, запасы и цены в согласованном состоянии
Продажи и возвраты проводятся из каждого магазина, изменения запасов и цен отправляются обратно, а итоги дня сверяются.
Схема
Прокрутите вбок, чтобы увидеть весь чертёж.
От POS к ERP: каждая продажа проводится один раз
Продажи поступают с касс в ERP как события, а цены и запасы возвращаются обратно. Магазин, потерявший связь, продолжает продавать и затем догоняет. Неудачная проводка повторяется, а затем передаётся человеку.
- Основной поток
- Асинхронный
- Сценарий исключения
Поток из 8 шагов
Поток шаг за шагом
- От POS-терминалы к Магазин или облачный POS-сервер: Продажи, возвраты и аннулирования (основной поток).
- От Магазин или облачный POS-сервер к Интеграционный слой: События продаж и итоги дня через очередь событий, по REST/JSON (асинхронный).
- От Интеграционный слой к ERP: Проведённые продажи и движения запасов, по OData · REST/JSON (основной поток).
- От ERP к Интеграционный слой: Цены, акции и данные товаров через API или выгрузку файлов, по REST/JSON (основной поток).
- От Интеграционный слой к Магазин или облачный POS-сервер: Обновления цен и запасов, по REST/JSON (основной поток).
- От Интеграционный слой к Очередь повторов: Проводка не удалась (сценарий исключения).
- От Очередь повторов к Интеграционный слой: Повторено (сценарий исключения).
- От Очередь повторов к Операционная команда магазинов: Снова сбой: оповещение с подробностями (сценарий исключения).
Обзор
Это поток между кассами в ваших магазинах и ERP за ними. Продажи, возвраты и аннулирования идут вверх в ERP. Цены, акции, данные о товарах и запасы идут обратно вниз. Когда две стороны расходятся, магазины продают по неверной цене, цифрам остатков перестают доверять, а финансовая служба проводит конец месяца за сверкой.
Эталонная схема отправляет каждую транзакцию магазина как событие через интеграционный слой с очередью. Слой преобразует каждое событие в документы продаж и запасов ERP и проводит его ровно один раз. В обратном направлении изменения в ERP отправляются тем магазинам, которым они нужны, чтобы каждая касса работала с одинаковыми данными.
Магазины теряют связь, и схема это учитывает. Магазин или облачный POS-сервер продолжает продавать и догоняет, когда связь возвращается. Неудачная проводка повторяется, а та, что не проходит и после повторов, передаётся человеку с деталями, а не исчезает.
Как устроен поток
Продажа на кассе
Каждая продажа, возврат и аннулирование фиксируются на POS-терминале с уникальным идентификатором, магазином, кассой и временем.
Накопление в магазине
Магазин или облачный POS-сервер собирает транзакции и отправляет их дальше как события, надёжно сохраняя их, пока магазин работает офлайн.
Проводка в ERP
Интеграционный слой преобразует каждое событие в движения продаж и запасов и проводит его в ERP, проверяя идентификатор, чтобы ничего не провести дважды.
Отправка цен и товаров
Данные о товарах, цены и акции публикуются из ERP при их изменении — с датой и перечнем магазинов, к которым применяется изменение.
Обновление каждого магазина
Слой доставляет каждое изменение в соответствующие магазины и фиксирует, какие из них его подтвердили.
Когда что-то идёт не так
Проводка не удалась
Временные сбои повторяются с увеличивающимися задержками. Проводка, которая всё равно не проходит, попадает в очередь недоставленных сообщений, а команда операций магазина получает оповещение с транзакцией и ошибкой.
Магазин ушёл в офлайн
Магазин продолжает торговать на локальных данных. Транзакции сохраняются и отправляются по порядку, когда связь возвращается, а магазин, который молчит слишком долго, вызывает оповещение.
Транзакция приходит дважды
Каждая транзакция несёт уникальный идентификатор. Слой распознаёт повтор и игнорирует его, поэтому повторная отправка после сбоя никогда не удваивает продажу.
Итоги магазина и ERP различаются
Итоги каждого магазина на конец дня сравниваются с тем, что получила ERP. Расхождение открывает проверку со списком недостающих или лишних транзакций.
Стандарты и системы
- Данные и аналитика
- Apache Kafka
- ERP-системы
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Интеграция
- REST
- Webhooks
- RabbitMQ
Вопросы и ответы
Проводить продажи в реальном времени или пакетами?
Обычно как события, близкие к реальному времени, потому что тогда запасы и продажи актуальны в течение дня. Некоторые ERP или лицензии делают частые проводки дорогими, поэтому слой может также группировать события в сводки по магазину и периоду. Мы выбираем вместе с вами, исходя из того, каким решениям нужны актуальные данные и что хорошо выдерживает ERP.
Как сверяются итоги на конец дня?
Каждый магазин присылает свои итоги на конец дня по типам оплаты и отделам. Слой сравнивает их с транзакциями, которые ERP получила по этому магазину и дню. Если они совпадают, день закрывается. Если нет, проверка перечисляет недостающие или лишние транзакции, чтобы ваша команда устранила причину, а не проводила корректировку.
Можно ли планировать акции и изменения цен заранее?
Да. Каждое изменение цены или акции отправляется заранее с датой и перечнем магазинов, к которым оно применяется, чтобы кассы переключались в нужный момент без действий со стороны магазина. Слой фиксирует, какие магазины подтвердили изменение, и отмечает тех, кто этого не сделал.
Как вы разворачиваете это во многих магазинах?
Мы начинаем с пилота в нескольких магазинах и ежедневно сравниваем их итоги с текущим процессом. Когда итоги совпадают, мы разворачиваем решение группами в темпе, который выдержит ваша команда операций магазинов. Старый процесс остаётся доступным для каждого магазина, пока новый поток не подтвердит себя.
С какими системами POS и ERP это работает?
Схема работает с любой POS, которая может выгружать транзакции через API, события или файлы, и с ERP, такими как SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central и Odoo. Интерфейсы вашей конкретной POS и ERP мы подтверждаем в начале. Упоминание продукта не означает партнёрства с его поставщиком.
Кто занимается неудачными проводками после запуска?
Это согласуется до запуска. Обычно ваша команда операций магазинов или финансовая служба обрабатывает бизнес-ошибки, например неизвестный товар, из списка на проверку, а техническая команда — сбои самого потока. Мы можем обеспечить эту техническую поддержку в рамках действующего соглашения, передав вашей команде регламенты эксплуатации.
Начните с разговора, а не с договора.
Расскажите, что нужно создать, подключить или защитить. Архитектор разберёт это с вами и порекомендует, с чего начать.
Что происходит дальше
Согласование времени
Наша команда напишет вам, чтобы согласовать время сессии.
Предконсультационная сессия
бесплатная 30-минутная онлайн-сессия предварительного консультирования: мы разбираем ваши цели, системы и ограничения.
Оценка готовности
В рамках бесплатная 48-часовая оценка готовности ведущий архитектор проверяет ваш проект по шести критериям определения готовности и рекомендует подходящий трек.
Выбор трека
Проекты с готовым объёмом работ получают обязывающее предложение в течение 3–5 рабочих дней. Проекты на стадии концепции начинаются в Blueprint Studio. Действующая система, которая сбоит, не документирована или требует интеграции, начинается с диагностики 1–2 недели. У Blueprint Studio и диагностики фиксированная плата, указанная в предложении.