Означает ли офлайн-ориентированный POS, что мой магазин никогда не нуждается в интернете?

Нет. Офлайн-ориентированный подход означает, что основные функции, такие как оформление покупки, печать чека и логирование товаров, могут продолжать работать без активного соединения, но большинство систем всё равно нуждаются в периодическом подключении для синхронизации данных между устройствами, резервного копирования записей и во многих случаях для авторизации карточных или мобильных платежей.

Что происходит, если две кассы продают последнюю единицу товара, находясь обе в офлайне?

Обе продажи обычно будут выглядеть действительными на своём собственном устройстве, так как ни одно не имеет видимости в реальном времени в деятельность другого. Когда устройства переподключаются, система должна применить какое-то правило конфликта — пометить для проверки, позволить обеим пройти и сделать запас отрицательным, или дать приоритет по временной метке. Спросите любого поставщика конкретно, как это обрабатывается, перед тем как предполагать, что это автоматическое и правильное.

Является ли архитектура «офлайн-ориентированный» действительно новой?

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

Охватывает ли режим офлайн карточные платежи тоже?

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

Как двухвалютное ценообразование усложняет синхронизацию в офлайне?

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

Что происходит, когда два кассира продают последний товар в режиме офлайн?

КороткоОдна широко распространённая статья об архитектуре офлайн-ориентированных POS-систем описывает локальное хранилище, синхронизацию в очереди и разрешение конфликтов как стандартную архитектуру, а не аварийный резерв. Это полезное объяснение, но не доказательство волны по всей индустрии — поэтому мы рассматриваем его как отправную точку, а не как исследование. Мы используем его, чтобы разобраться с реальным вопросом, который задают нам владельцы небольших магазинов: что действительно происходит, когда два устройства продают один товар или фиксируют разные цены во время отсутствия интернета?

Мы разрабатываем Pultrack, приложение для кассовых аппаратов и управления товарами для небольших розничных торговцев, которые сталкиваются с ненадёжным интернетом и, часто, двумя валютами в одной кассе. Поэтому когда публикация об архитектуре офлайн-ориентированных POS-систем получает распространение и воспринимается как «индустрия изменилась», мы хотим остановиться и разобраться, что действительно утверждается, а что домысливается.

Честно говоря, исходной точкой является одна статья в стиле сообщества об офлайн-ориентированных POS-системах [1]. Это разумный и правдоподобный рассказ о том, как локальное хранилище, синхронизация в очереди и разрешение конфликтов могут работать в POS. Это не исследование рынка, не рецензируемый тест и не доказательство того, что каждый поставщик переделал свою архитектуру таким образом. Мы цитируем его как одну информированную точку зрения, с которой стоит разобраться, а не как доказательство масштабного тренда. Когда мы углубляемся в конкретные детали — например, что действительно происходит, когда два кассовых аппарата пытаются продать один товар одновременно — это наше собственное операционное понимание, основанное на наблюдении за работой небольших магазинов день за днём, а не то, что мы приписываем какому-либо источнику.

Что на самом деле означает «офлайн-ориентированный»?

Основная идея источника проста: вместо того чтобы рассматривать «отсутствие интернета» как состояние ошибки, система рассматривает локальное устройство как основное место, где происходит продажа, а синхронизацию с центральным сервером — как что-то, что произойдёт позже, когда соединение будет доступно [1]. Оформление покупки, печать чека и уменьшение товарного запаса происходят сначала на основе локальных данных. Утверждается, что это устраняет главный сбой, который сообщают владельцы небольших магазинов — кассовый аппарат, который просто перестаёт работать, потому что сетевой вызов не вернул результат.

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

Так что действительно происходит, когда два человека продают последний товар?

Это сценарий, который чаще всего задают владельцы магазинов с более чем одним кассовым аппаратом или устройством, и стоит быть точным в том, что обещает и не обещает «офлайн-ориентированный» подход в этом случае.

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

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

Это действительно новое, или просто по-новому продаётся?

Мы были бы осторожны в том, чтобы назвать это свежим сдвигом. Небольшие магазины в районах с нестабильным соединением долгое время нуждались в какой-то версии «касса работает, разберёмся позже» столько же времени, сколько существует POS-программное обеспечение. Что может изменяться — это то, как явно поставщики описывают это как основную архитектуру, а не как обходной путь — источник рассматривает локальное хранилище и синхронизацию в очереди как «модель по умолчанию, а не режим скорой помощи» [1]. Отражает ли это подлинный сдвиг в том, как системы строятся, или сдвиг в том, как они описываются покупателям, не может решить одна статья.

Что должен спросить владелец магазина перед тем, как доверять «режиму офлайн»?

Что происходит, если один товар продаётся на двух устройствах перед синхронизацией одного из них — есть ли правило конфликта и могу я увидеть его простым языком?
Охватывает ли режим офлайн авторизацию карточных или мобильных платежей, или только захват заказа и логирование товаров? Это часто разные вещи, и расчёты обычно всё равно зависят от процессора платежей и последующего соединения.
Если мой магазин использует несколько валют, какой обменный курс фиксируется в момент офлайн-продажи и заблокирован ли он, или может быть тихо обновлён позже во время синхронизации?
Когда обнаруживается конфликт, получает ли персонал чёткий сигнал для проверки, или система просто молча выбирает победителя?
Могу ли я видеть журнал того, что изменилось во время синхронизации, чтобы передача смены или подсчёт не был перезаписан без следа?

Куда это оставляет владельцев небольших магазинов?

Мы думаем, что полезный вывод не в том, что «офлайн-ориентированный подход теперь стандарт» — это то, что интересная инженерия и интересный риск переместились с «работает ли это без интернета» на «что происходит, когда две офлайн-реальности должны быть объединены в одну». Это то, о чём стоит спросить напрямую, потому что это то, что действительно определяет, можно ли доверять подсчёту товара или итоговой сумме кассы за день после сложного дня с подключением. Мы разрабатываем Pultrack вокруг такого рода многоустройственного, двухвалютного согласования, потому что мы видели достаточно реальных подсчётов в конце дня, которые пошли неправильно, чтобы знать, что «это синхронизируется в конце концов» — не полный ответ — но это наш выбор дизайна, а не утверждение, что какой-либо конкретный конкурент это получает неправильно.