Защо онлайн магазинът ви продава свръх наличността: правилна синхронизация на ERP склад

Всеки търговец, с когото се срещаме, има една и съща история: онлайн магазинът е продал три бройки от нещо, от което складът е имал нула наличност, последвал е гневен имейл от клиент, и някой е обявил интеграцията за „повредена“. Обикновено не е. Тя прави точно това, за което е проектирана - синхронизира наличността на всеки 15 минути - и проблемът е в дизайна.

Продажбата над наличността е въпрос на консистентност

Синхронизацията на наличности се намира в спектър между два вида разходи:

• Синхронизирате твърде рядко и продавате това, което нямате.
• Резервирате в реално време и плащате за това - в натоварване на ERP API, в закъснение при плащане и в инженерна сложност.

Грешката е да изберете една единствена точка от този спектър за целия каталог. Търговец с 40 000 SKU може да има само 200, които някога се доближават до продажба над наличността - бързооборотни артикули, промоционални продукти, разпродажба на последни бройки. Те заслужават резервация в реално време при плащане. Останалите 39 800 се обслужват отлично от партиден фийд на всеки 15 минути.

Моделът с три нива, който доставяме

1. Партидно ниво - по подразбиране. Нивата на наличност преминават от ERP → онлайн магазин по разписание. Евтино, стабилно, подходящо за всичко с достатъчна дълбочина на наличността.
2. Прагово ниво - когато наличното количество падне под конфигурируем праг, SKU автоматично се повишава до обновявания, задействани от събития.
3. Резервационно ниво - плащането прави твърда резервация в ERP системата преди потвърждаване на поръчката. Запазено за малкия брой SKU, при които продажбата над наличността струва повече от API извикванията.

Преминаването между нивата е автоматично и базирано на данни - интеграцията следи собствения си процент пропуски и се коригира. Шест месеца след внедряването за балтийска търговска група, продажбите над наличността намаляха от седмичен канал за инциденти до два случая на тримесечие, като и двата се оказаха наличности, коригирани на ръка в склада - грешка при въвеждането на данните в източника, а не дефект в синхронизацията.

Проектирайте интеграцията около цената на грешката и архитектурата ще се получи сама.