AUT-0057· Електронна комерція
Приймання товарного замовлення з сайту
Менеджер отримує одне замовлення з перевіреним складом товарів і знімком ціни.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Менеджер переносить замовлення із сайту вручну, губить товарні позиції або двічі обробляє повторну подію.
02 / Результат
Кожне замовлення має стабільний ID, клієнта, товарні рядки та зафіксовану суму для опрацювання.
03 / Процес
ТригерСайт передав підтверджену подію нового товарного замовлення.
Перевірити походження події, ID замовлення, версію, валюту й обов’язкові контактні дані.
Зіставити SKU та кількість кожного рядка; невідомі товари й суперечливі суми передати на перевірку.
Перевірити вже оброблений ID; повторна доставка тієї самої події не створює нового замовлення.
Створити або оновити пов’язаний запис із товарними рядками та знімком ціни; зберегти зовнішній ID.
Призначити відповідального й перевірити результат запису; невизначений збій не повторювати без звірки.
04 / Реалізація2 варіанти
Приклад · Подія одного магазину
Покупець замовив дві лампи й один кабель; менеджер бачить три одиниці у двох рядках та суму на момент оформлення.
Спосіб реалізації
- Вхідний вебхук або серверний адаптер PlanFix із товарними рядками; спосіб захисту від повторів перевіряють перед впровадженням.
Що потрібно для реалізації
- Є підтверджене джерело подій і стабільний ID замовлення.
- Погоджено зіставлення SKU, валюти, знижок, доставки, контактів і версій події.
Обмеження
- Створення замовлення не підтверджує оплату, резервування або наявність товару.
- Офіційний приклад PlanFix підтверджує приймання даних, але не атомарну дедуплікацію та втратобезпечне оновлення.
- Неоднозначні контакти й невідомі SKU не можна мовчки замінювати випадковими значеннями.
Що потрібно уточнити (2)
- Чи надходять замовлення з кількох магазинів?
Уточніть ключ джерела та правила ID і SKU між магазинами.
- Чи змінюють склад замовлення після оформлення?
Визначте версії, пізні події та правило збереження попередніх цін.