Куда деваются продажи в ONLINE-сервере?

А Вы можете и мне тоже ответить на этот вопрос?

У меня точно такаяже ситуация.

С уважением, Артур Усманов.

Такая ситуация скорее всего у всех.
Я находил продажи в сброшенных чеках и кассовые отчеты тогда сходятся.
Такое ощущение что вместо команды "закрытие чека" до ПК доходит команда "Сброс"
Это списках чеков, а как обстоит дело в суммах продаж и количествах товара не знаю, подскажите.

На самом деле ситуация нам давно известна. Сервер получает ложный сброс чека (вместо реально закрытия) в том случае, если во время печати этого чека нажимать клавиши на клавиатуре ККМ или считывать сканером ШК (во всяком случае других причин нам неизвестно). Эта ситуация описана в Readme - файле OnlineServer'a 1.46. В самых последних релизах 1.46 эта проблема решена, но не до конца. Все же существуют периоды во время печати чека, при которых нажатие клвиш может привести к ложному сбросу.
Кардинально эта проблема решена в OLS Prof. Если сервер получает событие сброса чека, то подтверждение, что оно не ложно сервер получает из ЭЖ ККМ. К сожалению, ввиду того, что в ККМ ЭЖ организован на Flash с последовательным доступом, это несколько замедляет работу сервера с ККМ, по сравнению с OLS 1.46.

P.S. Речь конечно же здесь идет о нормально работающем аппарате, т.е. если на кассе имеют место аппаратные сбои и ошибки типа E-13, то ни о какой корректности работы сервера с такой кассой речи идти не может.

Цитата
Владимир Дмитриев писал(а): Сканирование ЭЖ ККМ это интересное решение, но представьте: вместо постоянного прослушивания "линии" кассовым сервером (нет ли запроса от кассы?) кассовый сервер сам занимает "линию"...

Кассовый сервер и занимается опросом состояния ККМ, просто при опросе состояния выделяется квант времени для чтения дополнительной информации, необходимой для контроля по ЭЖ при закрытии чека.

Цитата
Владимир Дмитриев писал(а): Правда есть одно "НО". При работе с несколькими секциями второй файл нужно получать с сортировкой внутри чека по секциям.

Это "НО" на самом деле не одно. Например, если пробить несколько чеков со свободными суммами при отключенном сервере (потеря интерфейса, зависание ПК и т.п.), сервер эти свободные суммы учтет (правда одним чеком, поскольку понятия номера чека в АМС-100Ф отсутствует и в ЭЖ храняться только покупки), но очередность покупок в списке полученном из ЭЖ будет отличаться от очередности покупок в списке полученной из сервера, поскольку в ЭЖ была произведена сортировка по отделам внутри нескольких чеков, а сортировка по отделам при получении данных с сервера будет произведена внутри одного чека созданного на основании данных ЭЖ. То есть отложенный контроль не может дать 100% гарантии корректности данных без реализации достаточно сложного алгоритма анализа данных в случае несовпадения списка покупок в ЭЖ и сервере.
Алгоритм, реализованный в программе на данный момент, на наш взгляд, является самым оптимальным.

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

Кроме того, мне до сих пор непонятно, почему в ККМ не доработают интерфейс RS-232 до полной совместимости со стандартом, а именно размах напряжения +12 -12 вольт, и чувствительность за зоной +5 -5 вольт?
А также почему ККМ просто выключает порт при печати чека ?

Извиняюсь за задержку с ответом...

Цитата
Владимир Дмитриев писал(а): После пробития свободных сумм подключили кассу АМС-100Ф к серверу OLS Prof. Востановления чеков ждали долго ... Или работа по кассе пробитием чеков является необходимым условием востановления чеков из ЭЖ?

При опросе ККМ сервер отслеживает номер последней покупки в ЭЖ. Если на следующем проходе обнаруживаются расхождения между номерами покупок, учтенных сервером, и номером последней покупки в ЭЖ, то присходит сверка с покупками, сохраненными в ЭЖ. В предыдущем сообщении я неверно сформулировал фразу: "при отключенном сервере" следует читать как "при отсутствии физической связи с сервером". Коррекция будет произведена в случае сбоев произошедших в период работы кассового сервера, даже при временном отключении кабеля (но не при отключении сервера). Если остановить сервер, затем пробить несколько чеков, то при запуске сервера будет произведена инициализация ККМ, вычитан номер последней покупки, хранящейся в ЭЖ и сервер начнет работать в штатном режиме.

Цитата
Torquader писал(а): Не знаю, как там оно реализовано, но мне кажется наиболее логичным проверять соотвествие чеков именно при запросе очередной суммы с ККМ, так как именно в этом случае надо заносить данные о следующем чеке в базу сервера, а также выставлять данные обратно на ККМ.

На данный момент предварительная проверка расхождения производится при опросе статуса ККМ.

Цитата
Torquader писал(а): Кроме того, мне до сих пор непонятно, почему в ККМ не доработают интерфейс RS-232 до полной совместимости со стандартом, а именно размах напряжения +12 -12 вольт, и чувствительность за зоной +5 -5 вольт? А также почему ККМ просто выключает порт при печати чека ?

По поводу размаха RS232 - так сложилось исторически. Вообще Online сети лучше строить на RS485 (и работают надежнее и с расстояниями проблем нет). В новой АМС-100Ф на плате БУ имеется панелька под ADM485 (как в АМС-200Ф). Как следствие отпадает необходимость установки преобразователей RS232<->RS485 на каждую ККМ.
Отключение RS232 при печати чека на АМС-100Ф производится, поскольку прерывание по RS в момент работы ТПУ может привести к выходу ТПУ из строя.

Цитата
ping писал(а): А мы хотим процедуру закрытия кассовой смены со сверкой Z-отчета с данными в компьютере, и отчетом о расхождениях и другими вешами облегчающими нелегкую и опасную работу кассиров )

Как я уже писал ранее - нам пока не удалось создать алгоритм, который однозначно бы восстанавливал картину продаж на АМС-100Ф при любых сбоях ККС . Например, при ситуации, описанной в моем предыдущем сообщении.