Guide

Как «ESLs» интегрируется с вашими платформами «POS», «ERP» и системами электронной коммерции

Технический обзор того, как «ESLs» интегрируются в ваш существующий стек — механизм синхронизации, с чем он взаимодействует, как происходит обмен данными и какой объем работы это на самом деле потребует от вашей команды.

Если именно вам предстоит принять решение о том, будут ли электронные ценники действительно работать с вашей системой, то экран на основе электронной бумаги — это наименьшая из ваших проблем. Настоящий вопрос заключается в том, сможет ли сеть ценников считывать данные из вашего «POS», «ERP» и вашего интернет-магазина без необходимости перехода на другую платформу — и какая часть этой работы ляжет на плечи вашей команды. В этой статье подробно рассказывается о том, как устроена интеграция, к каким системам она подключается, как происходит обмен данными, а также о том, какие факторы отличают удачный проект от проблемного.

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

Именно от интеграции зависит успех или провал проектов по внедрению системы «ESL», ведь точность данных на этикетке зависит исключительно от качества исходных данных. Проблема оборудования уже решена: выберите этикетку от проверенного производителя, и она будет отображать заданную информацию в течение многих лет. Что же значительно варьируется от проекта к проекту, так это то, доходят ли данные о цене, рекламных акциях и товаре до полки надежно, в нужном формате и без необходимости ручного обновления хрупких экспортных файлов. Пилотный проект с пятьюдесятью этикетками скрывает эту проблему; а парк из пятидесяти тысяч этикеток, распределенных по многим магазинам, сразу же её обнажает. Поэтому сначала оцените связь с вашими системами, а уже потом — экран.

Механизм синхронизации: как он взаимодействует между вашими системами и хранилищем

The piece that makes ESLs work is a sync engine — a service that sits between your systems of record and the label network. Your data flows in on one side; the engine resolves what changed, figures out which labels are affected, and pushes the new image to those labels through in-store access points on the other side. You never talk to individual labels, and your source systems never talk to the shelf. They only ever talk to the engine.

Именно этот промежуточный слой обеспечивает простоту интеграции. Вашему сервису POS не нужно знать, что такое точка доступа; вашему сервису ERP не требуется модель с отдельным плагином для каждой этикетки. Они передают цены и данные о товарах так же, как и при обычном экспорте данных, а механизм синхронизации Synchro занимается преобразованием, группировкой, повторными попытками и распределением данных по тысячам экранов. Эту структуру можно увидеть на нашей схеме интеграции: база данных, POS, ERP и система электронной коммерции подают данные в механизм синхронизации Synchro, который обновляет этикетки во всех магазинах.

С чем это связано — POS, ERP /SAP/Oracle/Dynamics, базы данных, электронная коммерция

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

  • Точка продаж. Кассовый аппарат зачастую является наиболее достоверным источником информации о цене продажи, поэтому синхронизация с POS обеспечивает идентичность цен на полках и на кассе по самой сути. Облачные платформы POS (например, Odoo или Hiboutik) обычно предоставляют доступ к этим данным через API; локальные кассовые аппараты обычно предоставляют их в виде представления базы данных или запланированного экспорта.
  • ERP — SAP, Oracle, Microsoft Dynamics and similar. When pricing, promotions and master data are governed in the ERP, the engine reads from there. These systems are built to integrate: SAP via IDocs/BAPIs or its OData and REST services, Oracle through its REST and integration layers, Dynamics 365 via its Web API and Dataverse. You expose the price and article entities you already report on; you do not build anything ESL-specific inside the ERP.
  • Базы данных и плоские файлы. Если реальным источником достоверных данных является база данных SQL или ежедневный ночной выгруз данных в формате CSV/XML, движок считывает их напрямую. Такой подход широко распространен и отличается высокой надёжностью — многие крупные автопарки работают на основе запланированной подачи данных из файлов.
  • Платформы электронной коммерции. Подключение вашего онлайн-каталога (Shopify, Magento/Adobe Commerce, WooCommerce, «бесголовая» платформа API) позволяет установить единую цену как на сайте, так и в розничных магазинах, что является основой ценового паритета между онлайн- и офлайн-продажами.

Дело не в длинном списке готовых интерфейсов. Дело в том, что движок работает с вашими данными в том виде, в каком они уже существуют — в формате «API», в базе данных или в файле — а не заставляет вас переходить на новую платформу.

Как на самом деле работает интеграция: API, промежуточное программное обеспечение, пакетная обработка и обработка в режиме, близком к реальному времени

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

  • Практически в режиме реального времени — через API или веб-хуки. Когда цена в вашей системе изменяется, она вызывает движок (или движок подписывается на канал обновлений), и соответствующие ярлыки обновляются в течение нескольких секунд. Это оптимальный подход для динамического ценообразования, краткосрочных акций и пересмотра цен с учетом конкурентов.
  • Пакетная / запланированная синхронизация. Механизм выполняет полный или дельта-экспорт по расписанию — каждую ночь, каждый час, каждые несколько минут. Такой подход проще в реализации, удобен для аудита и вполне подходит для ситуаций, когда цены меняются с предсказуемой периодичностью. Еженочное пакетное обновление синхронизирует весь автопарк до открытия касс.

Промежуточное ПО, расположенное между ними, компенсирует хаотичную реальность, лежащую между этими двумя идеализированными картинами: оно удаляет дубликаты изменений, повторяет неудавшиеся попытки отправки, ставит обновления в очередь при кратковременных сбоях в сети хранилища и выполняет синхронизацию, чтобы метка, пропустившая обновление, была исправлена при следующем проходе. Именно эта отказоустойчивость и является главной причиной, по которой вы не подключаете свой «ERP» напрямую к полке.

Разовое подключение против непрерывного потока данных: один раз против «никогда больше»

Интеграция осуществляется в ходе однократной настройки; после этого обмен данными происходит автоматически и не требует вмешательства со стороны пользователя. Это помогает чётко разграничить эти два этапа:

  • Все происходит так: вы предоставляете доступ к источнику данных (учетные данные службы «API», пользователь базы данных с правами только на чтение или папка для передачи данных) и согласовываете сопоставление полей. Мы осуществляем сопоставление ваших данных и создаем мост между вашей инфраструктурой и сетью этикеток — без миграции и без необходимости освоения вашей командой новых инструментов.
  • Никогда больше: с момента запуска изменения цен в вашей системе автоматически отражаются на полках. Никто не экспортирует файлы вручную, никто не ходит по рядам с этикетировочной пистолетом. Ваши сотрудники продолжают работать именно в тех системах, которыми они уже пользуются; этикетки генерируются автоматически.

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

Сопоставление данных: что требуется от вас для работы движка

Суть этой разовой работы заключается в сопоставлении данных — то есть в том, чтобы указать движку, какое из ваших полей что означает. Здесь нет ничего сложного, и именно эту часть стоит тщательно проработать на этапе определения объема работ. Как минимум, движку необходимо:

  • Стабильный идентификатор товара (SKU /EAN/GTIN). Это связующее звено, которое соотносит физическую этикетку со строкой в ваших данных, поэтому он должен быть уникальным и неизменным. Большинство проблем при интеграции связано именно с нестабильным или несогласованным идентификатором товара.
  • Поля цен. Обычная цена, а также любые другие цены, которые вы отображаете — цена для членов клуба, цена за единицу (за кг/л), цена с учетом НДС и без НДС — и какая из них является определяющей в случае расхождений между системами.
  • Данные об акции. Акционная цена, а также временные метки начала и окончания акции, чтобы сервис мог своевременно переключиться на акционный макет и автоматически вернуться к обычному виду по окончании акции.
  • Характеристики продукта, которые необходимо указать на этикетке: название, торговая марка, размер, страна происхождения, информация о пищевой ценности или нормативные указания, QR-коды и коды лояльности.
  • Поля запасов — если вы хотите, чтобы на краю полки отображалась информация о наличии товара или о его низком уровне запасов.

Более упорядоченные основные данные позволяют ускорить процесс интеграции. Если ваши SKU согласованы, а цены хранятся в едином контролируемом месте, сопоставление данных происходит быстро; если же цены разбросаны по таблицам и переопределениям, их стоит привести в порядок до начала проекта или в ходе его реализации.

Двунаправленный обмен данными: отправка информации о запасах и отборе товаров с полки

Интеграция не обязательно должна быть однонаправленной. Современные этикетки оснащены светодиодом и кнопкой, и движок может отправлять сигналы как обратно в ваши системы, так и на полку. Комплектовщик может нажать на этикетку, чтобы подтвердить отбор товара или отметить отсутствие товара на складе, и это событие передается обратно в вашу систему управления запасами или системами управления заказами; при заказе по схеме «закажи онлайн — забери в магазине» этикетки на товарах из списка могут мигать, чтобы персонал мог найти их за считанные секунды. Принцип такой же, как и при исходящем канале — ваши системы взаимодействуют с модулем, модуль взаимодействует с этикетками — только в обратном направлении. Рассматривайте двунаправленный обмен данными как функцию второго этапа: в большинстве случаев сначала внедряется синхронизация цен на исходящих данных, а сигналы обратной связи добавляются после того, как базовые функции налажены.

О чём следует спросить поставщика в отношении объёма работ по интеграции и коннекторов

Спросите у поставщиков, как они подключаются к вашим конкретным системам и кто выполняет эту работу — расплывчатые заявления о том, что их решение «интегрируется со всем», должны насторожить вас. Краткий и четкий контрольный список:

  • Как можно подключиться именно к нашим ресурсам POS / ERP — с помощью API, базы данных или файла — и существует ли готовый коннектор или требуется индивидуальная разработка?
  • Поддерживаете ли вы синхронизацию практически в реальном времени, пакетную синхронизацию по расписанию или и то, и другое? Какова типичная сквозная задержка от изменения цены до обновления метки?
  • Какие права доступа вам нужны от нас, и в чём разница между режимами «только для чтения» и «чтение-запись»?
  • Кто отвечает за интеграционную сборку и текущее обслуживание — вы, мы или третья сторона — и что произойдет при обновлении нашего сервиса «ERP»?
  • Как вы решаете вопрос с пропущенными обновлениями и сверкой данных, чтобы на этикетке никогда не отображалась устаревшая цена?
  • Как выглядит сопоставление полей и как обрабатываются акции с датами начала и окончания, а также с несколькими типами цен?
  • Каковы реалистичные сроки выполнения проекта и что от нашей команды ожидается в течение этого периода?

The quality of the answers — specific to your stack, honest about effort — tells you more about a vendor than any spec sheet. For the broader buying criteria beyond integration, the ROI framework and the ESL vs. paper comparison cover the cost and operational side, and the ESL guide covers the fundamentals.

Посмотрите, как это соотносится с вашими собственными системами

Самый быстрый способ снизить риски при оценке осуществимости проекта — это представить на рассмотрение ваш реальный стек технологий. В ходе демонстрации мы сопоставим ваши POS, ERP, базу данных и систему электронной коммерции с механизмом синхронизации, покажем, какая схема подключения подходит, и дадим вам четкое представление о том, какие работы потребуется выполнить однократно — чтобы вы могли одобрить проект, точно зная, что предстоит сделать вашей команде, а что ей больше никогда не придется повторять.