Аптека: остатки по трём точкам обновляются раз в сутки — как получить реальное время

MAATRIX

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

Откуда берётся суточная задержка

В типичной небольшой сети аптек (условно — три точки, но принцип тот же и для пяти, и для десяти) каждая точка обычно работает со своей локальной базой кассового и складского учёта. Раз в сутки, чаще ночью, запускается процедура выгрузки: с каждой кассы данные о продажах и остатках экспортируются в файл или через API уходят на центральный сервер, где хранится сводная база сети. Утром следующего дня сотрудники видят «вчерашнюю» картину.

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

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

Что именно мешает синхронизации работать быстрее

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

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

Итог: суточная задержка — не блажь и не лень, а прямое следствие того, что данные физически живут в нескольких разрозненных местах и сходятся редко.

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

Правильный способ убрать задержку — не «синхронизировать чаще», а перестать синхронизировать в привычном смысле вообще. Вместо того чтобы каждая точка вела свою локальную базу и раз в сутки отправляла снимок на центральный сервер, все точки работают с одной и той же базой остатков в реальном времени. Продажа на кассе в аптеке А сразу же — секунды, не часы — отражается в остатке, который видит сотрудник аптеки Б.

Практически это означает: у сети есть собственный сервер (обычно VPS или выделенный сервер, в зависимости от объёма сети и числа касс), на котором развёрнута центральная база данных товарных остатков. Кассовые терминалы на каждой точке подключаются к этой базе не раз в сутки пакетом, а постоянно — через защищённый канал, обычно VPN между точками и сервером или между точками напрямую по схеме site-to-site. Как устроено такое соединение между офисами и как выбрать между WireGuard и IKEv2, разобрано в статье про site-to-site VPN между офисами на WireGuard — принцип для сети аптек тот же: точки объединяются в одну защищённую сеть, и между ними нет ничего «внешнего», что нужно ждать раз в сутки.

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

1. Централизованная база с тонкими клиентами на точках. Каждая касса обращается напрямую к серверной базе данных при каждой операции — продаже, приёмке, инвентаризации. Остаток меняется в момент операции, без отдельного шага «выгрузка». Это самый честный вариант реального времени, но требует стабильного канала связи на каждой точке — если интернет на точке пропадёт, касса должна уметь либо работать в офлайн-буфере с последующей досинхронизацией, либо просто ждать связи.
2. Событийная репликация вместо пакетной выгрузки. Каждая точка по-прежнему имеет локальную базу для отказоустойчивости, но вместо ночной выгрузки файлом изменения (продажа, приход, списание) отправляются на центральный сервер сразу, как только происходят — событие за событием, а не раз в сутки пакетом. Это чуть сложнее в реализации, зато точки продолжают работать даже при кратковременном обрыве связи с центром, просто накопленные события досылаются, когда связь восстановится.

Для сети из нескольких точек второй вариант обычно практичнее: он даёт реальное время в подавляющем большинстве случаев и не превращает временный обрыв интернета в аптеке в полную остановку кассы.

Что нужно от сервера под такую задачу

Нагрузка от базы остатков сети из нескольких аптек — это, как правило, не про вычислительную мощность, а про стабильность, диск и сеть:

• Постоянная доступность. Сервер должен быть на связи 24/7 — если он недоступен даже на 20 минут в рабочее время, все точки либо встают в очередь на офлайн-буфер, либо (в худшем случае) продажи вообще нельзя провести. Отсюда требование к аптайму хостинга и к тому, чтобы сервер не делил ресурсы с чужими шумными соседями.
• SSD, а не HDD, под саму базу данных. Транзакционная нагрузка — много мелких операций записи (каждая продажа — это запись) — на вращающихся дисках упирается в задержки заметно раньше, чем кажется на бумаге.
• Резервное копирование базы, причём отдельно от точки, где она физически стоит. Если единственная копия остатков сети лежит на одном диске в одном месте, а диск умирает — сеть на какое-то время слепнет полностью, а не только теряет актуальность. Регулярный снапшот или дамп базы на отдельное хранилище — не опция, а часть архитектуры.
• Защищённый канал до каждой точки. Данные об остатках, ценах и, возможно, о движении рецептурных препаратов — не то, что стоит гонять по открытому интернету. VPN между точками и сервером закрывает и это, и заодно проблему «касса за NAT провайдера», из-за которой прямое подключение к серверу иногда просто не работает без туннеля.
• Разумный запас по ресурсам под рост. Сеть из трёх точек сегодня легко становится сетью из пяти через год — стоит закладывать сервер с запасом, а не впритык под текущую нагрузку, чтобы не переезжать посреди сезона гриппа.

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

Как выглядит переход на практике

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

1. Аудит текущей схемы. Что именно умеет ваша учётная система: есть ли у неё встроенный режим онлайн-синхронизации (некоторые продукты его поддерживают, просто по умолчанию сеть его не включала — не потому что не хотела, а потому что раньше не было куда подключить единый сервер), или интеграция с центральной базой потребует стороннего модуля.
2. Разворачивание центрального сервера. Отдельная машина — не общий сервер с сайтом или почтой сети, а именно выделенный под базу остатков ресурс, чтобы нагрузка и доступность одной задачи не зависели от другой.
3. Настройка защищённого канала до каждой точки. VPN между точками и сервером — сначала для одной точки в тестовом режиме, чтобы проверить, что канал стабилен и не «плавает» в часы пиковой загрузки интернет-провайдера точки.
4. Перевод синхронизации с пакетной на событийную (или прямую). Здесь важно не отключать старую ночную выгрузку сразу — какое-то время имеет смысл держать обе схемы параллельно, сверяя расхождения, пока не появится уверенность, что новая схема действительно не теряет и не задваивает операции.
5. Постепенное подключение остальных точек. По одной, с проверкой на каждом шаге — так проще найти точку, где что-то настроено не так, чем разбираться с проблемой сразу на всех кассах одновременно.
6. Отключение старой ночной выгрузки и переход на мониторинг. Когда новая схема отработала стабильно хотя бы пару недель — можно снимать страховку в виде параллельной пакетной синхронизации и оставлять только реальное время плюс регулярные бэкапы.

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

Что это меняет для сети из нескольких точек

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

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

Что касается персональных данных и сведений о движении рецептурных препаратов — вопрос, где и как их можно законно хранить, если учётная система арендована у стороннего облачного сервиса, разобран в статье про медцентр и 152-ФЗ: логика с местом хранения там пересекается с аптечной, хотя регулирование и профиль данных отличаются. Похожий переход от подписки на облачный сервис к собственной инфраструктуре с историей за несколько лет уже проходили в других отраслях — например, у автосервисов, которые переносили базу ремонтов по VIN на собственный сервер вместо того, чтобы зависеть от чужого облака и его расписания синхронизации. А если параллельно с остатками сеть ведёт бухгалтерию и товароучёт в 1С, конфигурацию сервера под такую нагрузку стоит смотреть отдельно — в статье про выделенный сервер для 1С и учётных систем.

Частые вопросы