Перейти до вмісту
XSIS
Покупець платить на касі самообслуговування

Галузі

Рітейл і омніканальна торгівля

Магазини, онлайн-вітрини й ERP згодні щодо кожного продажу й кожної позиції, у реальному часі.

Чому магазини, онлайн-канали й ERP розходяться

Рітейлери працюють на багатьох системах, які мають бути згодні: каси, інтернет-магазини, склади, платіжні провайдери й ERP. Коли вони розходяться, запаси неправильні, ціни різняться між каналами, а фінанси витрачають дні на звіряння.

  • Нічні пакетні синхронізації

    Каси, інтернет-магазини й ERP обмінюються даними із запізненням на години, тож у пік запаси продаються понад наявність.

  • Повільні розрахунки

    Карткові розрахунки між еквайрами звіряються пізно, а розбіжності коштують грошей.

  • Піки, що ламають оформлення замовлення

    Акції та свята приносять трафік, якого повільні системи не витримують.

Що змінюється

  1. Одна версія кожного продажу

    Магазинні термінали, онлайн-оформлення й головна книга ERP згодні в реальному часі.

  2. Запаси, яким можна довіряти

    Рівні позицій синхронізуються між магазинами й вітринами в міру змін.

  3. Розрахунки звірені

    Файли розрахунків обробляються, а комісії проходять аудит автоматично.

Де ми працюємо

Що ми створюємо

  • Розширення POS, бек-офісні застосунки й панелі магазинів
  • Безпечна для офлайну синхронізація між серверами магазинів і головним офісом

Що ми створюємо

  • Фронтенди електронної комерції й сервіси замовлень
  • Самовивіз, повернення й відстеження замовлень

Типові інтеграції

  • Платформи електронної комерції, маркетплейси, перевізники й ERP

Що ми будуємо, зʼєднуємо й захищаємо

  • Інтеграція POS і ERP

    Продажі, повернення й підсумки дня проводяться в ERP, а ціни, акції й товари надсилаються назад у кожен магазин.

  • Видимість запасів

    Єдиний огляд запасів у магазинах, на складах і онлайн, оновлюваний у міру продажів і постачань.

  • Онлайн- і мобільна торгівля

    Інтернет-магазини й застосунки, що мають спільні товари, ціни й запаси з магазинами.

  • Лояльність і акції

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

  • Інструменти операцій магазину

    Застосунки для переобліку запасів, переміщень, постачань і завдань персоналу, створені для роботи в торговельному залі.

  • Суперзастосунки й уніфікована торгівля

    Один високонавантажений застосунок для покупок, платежів і лояльності між брендами.

  • Платформи POS

    Каси й хмарні сервіси POS через їхні API, файли експорту чи сервери магазинів.

  • Карткові платежі

    Термінали, шлюзи й еквайри з файлами розрахунків, зіставленими з продажами.

  • ERP

    SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuite, Odoo та інші для товарів, запасів і фінансів.

  • Склади й перевізники

    Складські системи й API перевізників для виконання замовлень, доставок і повернень.

  • Карткові дані поза межами

    Ми залишаємо карткові дані в платіжного провайдера через токенізацію й термінали з наскрізним шифруванням, де вони доступні, що зменшує межі PCI DSS.

  • Дані клієнтів

    Дані лояльності й замовлень збираються за згодою, зберігаються лише стільки, скільки потрібно, і обробляються за GDPR та застосовними місцевими законами.

  • Фіскальні й податкові правила

    Де країна вимагає фіскальних чеків чи електронного фактурування, ми підключаємо сертифіковані пристрої чи платформи, які вона вимагає, і зберігаємо потрібні їй записи.

Рука тримає бездротовий банківський платіжний термінал, зблизька

Як ми працюємо

Ми зʼєднуємо ці системи, щоб продажі, запаси, ціни й платежі надійно переходили між ними, і створюємо навколо них клієнтські застосунки й бек-офісні інструменти. Магазини продовжують продавати, коли звʼязок зникає, і наздоганяють, коли він повертається.

  1. Закартуйте потоки

    Продажі, повернення, ціни, запаси й платежі між кожною системою.

  2. Замініть пакети

    Події потоком ідуть між POS, вітринами й ERP із чергою недоставлених повідомлень для збоїв.

  3. Доведіть це в пік

    Навантажувальні тести на святковому трафіку до запуску.

POS до ERP: кожен продаж проведено один разПродажі йдуть від кас до ERP як події, а ціни та запаси повертаються назад. Магазин, що втратив звʼязок, продовжує продавати й надолужує. Невдале проведення повторюється, а потім передається людині.POSPOS-терміналиКожна каса в кожномумагазиніСховище данихМагазинний абохмарнийPOS-серверПродовжує продаватибез звʼязкуXSISШар інтеграціїЧерга подій,зіставлення, захиствід дублікатівERPERPПродажі, запаси йфінансиСервісЧерга повторнихспробПовторні спроби знаростаннямзатримки, далі черганедоставленихЛюдиОпераційнакоманда магазину12REST/JSON3OData · REST/JSON4REST/JSON5REST/JSON678

POS до ERP: кожен продаж проведено один раз

Продажі йдуть від кас до ERP як події, а ціни та запаси повертаються назад. Магазин, що втратив звʼязок, продовжує продавати й надолужує. Невдале проведення повторюється, а потім передається людині.

  • Основний потік
  • Асинхронний
  • Шлях винятків
Потік у 8 кроках

Потік крок за кроком

  1. Від POS-термінали до Магазинний або хмарний POS-сервер: Продажі, повернення й скасування (основний потік).
  2. Від Магазинний або хмарний POS-сервер до Шар інтеграції: Події продажів і підсумки дня через чергу подій, через REST/JSON (асинхронний).
  3. Від Шар інтеграції до ERP: Продажі та рухи запасів проведено, через OData · REST/JSON (основний потік).
  4. Від ERP до Шар інтеграції: Ціни, акції та дані товарів через API або експорт файлів, через REST/JSON (основний потік).
  5. Від Шар інтеграції до Магазинний або хмарний POS-сервер: Оновлення цін і запасів, через REST/JSON (основний потік).
  6. Від Шар інтеграції до Черга повторних спроб: Проведення не вдалося (шлях винятків).
  7. Від Черга повторних спроб до Шар інтеграції: Повторено (шлях винятків).
  8. Від Черга повторних спроб до Операційна команда магазину: Досі збоїть: оповіщення з подробицями (шлях винятків).
Карткові платежі: авторизація на касі, розрахунки пізніше, звіряння в ERPТермінал або оформлення замовлення звертається до шлюзу, шлюз до еквайра, а еквайр маршрутизує до карткової мережі та емітента. Файли розрахунків надходять пізніше й зіставляються з продажами та комісіями в ERP. Тайм-аут запускає скасування, щоб із клієнта ніколи не стягнули двічі.POSТермінал EMV абоонлайн-оформленняЧип, безконтактніплатежі таелектронна комерціяШлюзПлатіжний шлюзТокенізація тамаршрутизаціяБанкЕквайрАвторизація тарозрахункиТретя сторонаКарткова мережа йемітентСхвалює абовідхиляєERPERPПродажі, комісії тавиплатиXSISШар інтеграціїРозбір ізіставленнярозрахунківЛюдиОпераційнакоманда платежівРозбіжності, спорита чарджбеки1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

Карткові платежі: авторизація на касі, розрахунки пізніше, звіряння в ERP

Термінал або оформлення замовлення звертається до шлюзу, шлюз до еквайра, а еквайр маршрутизує до карткової мережі та емітента. Файли розрахунків надходять пізніше й зіставляються з продажами та комісіями в ERP. Тайм-аут запускає скасування, щоб із клієнта ніколи не стягнули двічі.

  • Основний потік
  • Асинхронний
  • Шлях винятків
Потік у 8 кроках

Потік крок за кроком

  1. Від Термінал EMV або онлайн-оформлення до Платіжний шлюз: Запит авторизації, через EMV · REST/JSON (основний потік).
  2. Від Платіжний шлюз до Еквайр: Авторизація, через ISO 8583 (основний потік).
  3. Від Еквайр до Карткова мережа й емітент: Маршрутизовано до емітента, через ISO 8583 (основний потік).
  4. Від Еквайр до Платіжний шлюз: Схвалено або відхилено, через ISO 8583 (асинхронний).
  5. Від Еквайр до Шар інтеграції: Файли розрахунків і комісій, через SFTP (асинхронний).
  6. Від Шар інтеграції до ERP: Розраховані продажі, комісії та виплати, через REST/JSON (основний потік).
  7. Від Платіжний шлюз до Термінал EMV або онлайн-оформлення: Немає відповіді вчасно: автоматичне скасування, через ISO 8583 0400 (шлях винятків).
  8. Від Шар інтеграції до Операційна команда платежів: Розбіжність розрахунків або чарджбек (шлях винятків).

Досвід

  • Логотип Landmark Group (UAE)
  • Логотип Nike
  • Логотип Victoria’s Secret
  • Логотип M·A·C Cosmetics

Вибрані корпоративні бренди представляють історичні й поточні системи, платформи та цифрові продукти, спроєктовані чи постачені XSIS, KONG GROUP, нашим генеральним директором і нашими головними інженерами-керівниками протягом їхніх карʼєр. Усі сторонні торговельні марки належать їхнім власникам і названі виключно для фактичної ідентифікації портфеля.

Як почати

Що буде далі

  1. Узгодження часу

    Наша команда напише вам, щоб узгодити час сесії.

  2. Попередня консультація

    Формат: безкоштовна 30-хвилинна онлайн-консультація перед співпрацею. Ми разом розбираємо ваші цілі, системи й обмеження.

  3. Оцінка готовності

    На кроці «безкоштовна 48-годинна оцінка готовності» головний архітектор перевіряє ваш проєкт за 6 пунктами Definition of Ready і рекомендує відповідний трек.

  4. Вибір треку

    Проєкти з готовим обсягом отримують обовʼязкову пропозицію протягом від 3 до 5 робочих днів. Проєкти на стадії концепції починаються в Blueprint Studio. Робоча система, яка дає збої, не має документації або потребує інтеграції, починається з діагностики тривалістю від 1 до 2 тижнів. Blueprint Studio і діагностика мають фіксовану плату, зазначену в пропозиції.

Найшвидший спосіб почати: пакет Спринт готовності до електронного фактурування й ERP, один із наших пакетів швидкої співпраці.

З чого почати

Запитання й відповіді

Що відбувається, коли магазин втрачає звʼязок?

Магазин продовжує продавати. Продажі зберігаються локально й надсилаються, коли звʼязок повертається, кожен з унікальним ідентифікатором, щоб нічого не було проведено двічі. Оновлення цін і запасів стають у чергу так само. Операції бачать, які магазини відстають і наскільки, тож тривалий збій помічають одразу, а не виявляють у кінці місяця.

З якими системами POS ви можете інтегруватися?

Ми інтегруємо платформи POS через те, що вони пропонують: хмарні API, сервери магазинів, експорт баз даних чи файли. Перш ніж оцінювати, ми переглядаємо документацію POS і вибірку його даних, бо це визначає підхід. Згадка платформи POS чи ERP на цьому сайті не означає партнерства з її постачальником.

Чому запаси ніколи не збігаються між ERP і магазинами?

Зазвичай тому, що системи розходяться щодо часу, одиниць чи того, що вважати рухом товару. Поширені причини: повернення, переміщення, пошкоджений товар і продажі під час інвентаризації. Ми простежуємо розбіжності, узгоджуємо одне правило для кожного виду руху й будуємо синхронізацію так, щоб вона записувала кожну зміну з її джерелом. Решта розбіжностей потрапляє до списку на перегляд, а не накопичується.

Що формує вартість інтеграції для рітейлу?

Кількість систем, магазинів і каналів, наскільки добре POS і ERP відкривають свої дані й скільки винятків потребують правил, як-от повернення між каналами чи розділені платежі. Розгортання магазин за магазином також додає тестування. Ми оцінюємо після перегляду систем і вибірки реальних транзакцій.

Чи можете ви розгорнути це, не закриваючи магазини?

Так. Ми запускаємо поетапно, починаючи з пілотного магазину, і ведемо нову інтеграцію паралельно з поточним процесом, доки підсумки не зійдуться. Зміни в магазинах плануються поза торговельними годинами, де можливо, і кожен етап має шлях назад, якщо щось піде не за планом.

Хто підтримує інтеграцію після запуску?

Ми можемо стежити й підтримувати її за угодою про підтримку або передати вашій команді з документацією, оповіщеннями та інструкцією з експлуатації. У будь-якому разі невдале повідомлення потрапляє в чергу з причиною, щоб його можна було виправити й повторити, а не втратити.

Почніть із розмови, а не з договору.

Розкажіть, що вам треба побудувати, зʼєднати чи захистити. Архітектор пройде це з вами, а потім порадить, з чого почати.