CashTAN logo
   
 
Главная
Новости
Продукты
  SM POS для Android
  Микродокстанция mDS1
  Терминал учета PIONER
  CashTAN P9
    Применение
    Сеть удаленных точек
    Работа с ЭККА
    Работа с весами
    Драйвера
    Техинфо
  CashTAN P9 Pro
  Рабочее место кассира
  mPOS
  XL100
  CashTAN M1
  Прайс-лист
Примеры решений
Информация
Партнеры
Сертификация
Поддержка
Download
Контрактная разработка
О компании

 Версия для печати
Общие принципы построения взаимодействия между учетным ПО и кассовым сервером CashTAN
Перед прочтением данной статьи необходимо ознакомиться со статьей «Секции, справочники товаров и протоколы». Далее в данной статье будет рассматриваться случай одной секции, однако нет никаких особенностей для экстраполяции рассмотренных примеров на случай нескольких секций.

Для начала рассмотрим самую простую и очевидную модель построения товарного учета с использованием кассового сервера.

В кассовый сервер мы выгружаем справочник товаров. Кассовый сервер ведет протокол работы кассы, на основании которого в нашей учетной программе мы сможем сформировать документ реализации. Кажется, все просто и легко. Но трудности в данной схеме начинаются как раз на этапе чтения протокола и формирования документа реализации. Представим себе ситуацию - нам нужно сформировать документ реализации. Мы читаем протокол и на его основании формируем этот документ. Но пока мы читали протокол и анализировали его, по кассам могли пройти еще продажи, которые нами при такой схеме учтены не будут, и мы получим неверные остатки. В таком случае, на время чтения протокола нам необходимо остановить работу кассового сервера и обслуживания им кассы и соответственно посетителей. Но, как известно из практики, формирование по протоколу документа реализации не является тривиальной процедурой, которая может быть проведена в автоматическом режиме. Почему? Хотя бы наличие в протоколе ошибок кассира, как-то пересортица - это требует уже вмешательства оператора в формирование документа реализации и приводит к задержкам по времени. А в это время магазин стоит.

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

Как это построено у нас: протокол не один, их много. Вообще, в нашем контексте, что такое протокол - это список операций по кассе за определенный промежуток времени. Какой должен быть этот промежуток времени? В принципе, любой. Но наша рекомендация такова - если магазин не круглосуточный, то наилучший вариант один протокол - один день, если же магазин круглосуточный - то один протокол за одну смену. Такой метод формирования протоколов позволяет сличать конечные суммы продаж по протоколу и в Z- отчете кассы, чтобы можно было сразу же провести некоторый контроль.

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

На что влияют открытые протоколы? Когда выгружается из учетной программы справочник товаров, программа анализирует продажи по всем открытым протоколам и соответствующим образом корректирует реальные остатки в кассовом сервере. Главная мысль такова - если протокол открыт, то учетная программа еще ничего не знает о продажах по нему и соответственно не учитывает эти продажи в остатках, которые выгружает в кассовый сервер. Как только протокол переводится в закрытое состояние - считается, что учетная программа учла продажи по нему и соответствующим образом изменила свои остатки.

Рассмотрим небольшой пример. В данном примере все движение рассматривается на примере одной позиции товара, однако, для более чем одной позиции, общая идея остается такой же.


На этом примере рассмотрим как реально происходит взаимодействие между учетной программой и кассовым сервером.

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

Остаток 10 штук. Выгружаем справочник товаров с остатком в 10 штук.

Идет продажа...
В результате за какое-то там время продалось 5 штук этого товара - т.е. реальный остаток у нас стал 5 штук. Учетная программа про это еще ничего не знает.

Приходит еще 10 штук этого товара в секцию
Учетная программа про продажу 5 штук еще ничего не знает. Она формирует остатки, получает остаток этого товара 20 и высылает их в кассовый сервер. Он знает, что 5 штук этого товара уже продалось и соответственно из 20 вычитает 5 и получает 15 - действительно реальный остаток.

И третий интересный этап - закрытие реализации - т.е. формирование по протоколу документа реализации.
Учетная программа читает протокол, анализирует продажи по нему. В результате всего этого в учетной программе остаток товара получается 15. Т.к. протокол прочитан и по нему уже сформирован документ реализации, то его в кассовом сервере необходимо закрыть. Закрываем его. Тут можно увидеть, что когда мы его закрываем, остаток в кассовом сервере становится 20. Это не есть неправильно, так и должно быть - протокол закрыт - значит, учетная программа уже учла продажи по нему и кассовый сервер уже эти продажи не учитывает. И остается единственное действие - выгрузить справочник товаров, где уже остаток товара 15.

0.017488 seconds