Website and POS stock: who owns synchronizationОстатки сайта и кассы: кто отвечает за обмен

Assign ownership to each valueНазначьте владельца каждого значения

Document which system owns physical stock, which confirms reservations and which submits orders. Define the permitted direction of change for every field. When website and POS independently overwrite quantities, the last write can erase a newer movement. Staff should know where to correct an item error and where they are viewing a published copy.Опишите, какая система хранит физический остаток, какая подтверждает резерв и какая передаёт заказ. Для каждого поля задайте разрешённое направление изменений. Если сайт и касса оба независимо перезаписывают количество, последняя запись может уничтожить более новое движение. Сотрудник должен понимать, где исправлять ошибку товара, а где только смотреть опубликованную копию.

Map item, variant, packaging and fulfillment-location identifiers. A shared barcode is insufficient when one channel interprets it as a carton and another as one unit. Catalog and availability changes are related but distinct. A new variant must not inherit a similar item’s stock merely because names match or a manager copied the product record.Сопоставьте идентификаторы товара, варианта, упаковки и места исполнения. Один штрихкод не решает задачу, если в одном канале он обозначает коробку, а в другом штуку. Каталог и наличие обновляются связанно, но это разные данные. Новый вариант не должен получать остаток похожего товара лишь потому, что названия совпали или менеджер скопировал карточку.

Also test a discontinued item and a changed product code. An older order must retain the item’s identity even when the listing is no longer customer-visible. An unknown channel code requires a mapping review, not a match to the first similar item. Assign catalog correction ownership, identify events awaiting resolution and verify that they are processed once after the correct cross-system relationship is restored.Проверьте также снятую с продажи позицию и изменение её кода. Старый заказ должен продолжать ссылаться на прежнюю идентичность товара, даже если карточка больше не показывается покупателям. Неизвестный код из канала требует разбора сопоставления; нельзя привязывать его к первой похожей позиции. Назначьте, кто исправит справочник, какие события ожидают решения и как проверить их однократную обработку после восстановления правильной связи между системами.

Distinguish movements from stock snapshotsРазделите событие и снимок остатка

Establish what the integration sends: a sale event, a reservation change or a calculated stock snapshot. “Seven available” cannot be processed as a receipt of seven units. When an order starts online and is fulfilled through POS, those records must refer to the same fulfillment or a single physical issue can be counted twice.Определите, что передаёт обмен: событие продажи, изменение резерва или готовое значение остатка на момент расчёта. Снимок «доступно семь» нельзя обработать как поступление семи единиц. Если один заказ пришёл с сайта, а затем был выдан через POS, эти записи должны ссылаться на одно исполнение, иначе одно физическое выбытие попадёт в учёт дважды.

Retries need a stable source-event reference and an identifiable processing result. Delayed messages may arrive out of order. An older value must not override a newer one merely because it arrives later. Agree duplicate and stale-update handling with the integrator and test it; the label “synchronization” does not establish those protections.Для повторов нужен устойчивый номер исходного события и понятный результат обработки. При задержке сообщения могут прийти не по порядку. Старое значение не должно отменять более новое только из-за позднего поступления. Способ распознавания повторов и устаревших обновлений согласуйте с интегратором и проверьте на примере; название «синхронизация» само по себе не описывает такую защиту.

Reconcile the history, not just the screensСверяйте историю, а не только экраны

Agree how to operate during an interruptionСогласуйте работу во время сбоя

Set acceptable data age according to item risk and selling method. When it is exceeded, alert the owner and apply agreed confirmation restrictions. Do not present the last known quantity as verified current stock. If a POS supports disconnected operation, separately test retained transactions, selling limits and later reconciliation; do not assume every configuration does.Назначьте предел допустимой давности данных по риску товара и способу продажи. При его превышении показывайте проблему ответственному и применяйте согласованное ограничение подтверждений. Не выдавайте последнее известное количество за проверенный текущий запас. Если касса допускает работу без связи, отдельно проверьте хранение операций, ограничения продаж и их последующее согласование; переносить это обещание на любую конфигурацию нельзя.

For recovery, identify the last confirmed processing result and unapplied events. Reconcile them to source orders, then repeat only the necessary actions while retaining references. Blind bulk replay can duplicate movements. After recovery, compare balances, reservations and open orders; a newly successful update does not establish that previous gaps have been repaired.Для восстановления сначала определите последнюю подтверждённую обработку и список неприменённых событий. Сверьте их с исходными заказами, затем повторяйте только необходимые действия с сохранением номеров. Массовая повторная загрузка без проверки может удвоить движения. После восстановления сравните остаток, резервы и незавершённые заказы; новый успешный обмен не доказывает, что прошлые пропуски уже устранены.

Accept the exchange through failure testsПримите обмен на повторе и задержке

Test a regular sale, online-order fulfillment through POS, cancellation, duplicate event, late older snapshot and connection interruption. Record expected physical stock and availability for each. The exchange owner should trace a difference to its source and demonstrate recovery without manually forcing the final total. Also verify that staff can see the problem, not only a technical service status.Проверьте обычную продажу, выдачу интернет-заказа через POS, отмену, повтор события, поздний старый снимок и перерыв связи. Для каждого случая запишите ожидаемые физический остаток и доступность. Ответственный за обмен должен найти источник разницы и показать восстановление без ручного подгона итоговой цифры. Отдельно убедитесь, что сотруднику видна проблема, а не только технический статус сервиса.

SABSUS links orders, POS and inventory; external exchange requires field ownership, direction, retry and error rules. Verify actual channels, update timing and recovery against the available integration. Start with one SKU at one location and a complete movement log. Acceptance means an explainable result after each failure, rather than an abstract promise of real-time operation.SABSUS связывает заказ, POS и склад; для внешнего обмена определяются владелец поля, направление, повтор события и ошибка. Конкретные каналы, срок обновления и восстановление требуют проверки доступной интеграции. Начните с одного SKU в одной точке и полного журнала операций. Критерий приёмки — объяснимый итог после каждого сбоя, а не обещанная абстрактная «работа в реальном времени».

Promises and reservationsОбещание и резерв · Online orderingОнлайн-заказы

Quick answersКороткие ответы