Двойные чеки.

26 октября 2013 5417 просмотров

Для начала начнем с определения «двойного» чека. Двойной чек, это чек который дублирует самого себя. Обычно это происходит при следующем развитии событий. При проведении чека через фискальный регистратор, на последнем происходит какой либо сбой, который препятствует проведению чека, соответственно выходит чек, у которого внизу отпечатана неполная информация, но фактически чек оказывается проведенным по фискальному регистратору .  Программное обеспечение рабочее место кассира (РМК) вовремя не получив ответа об успешном завершении операции, повторяет команду на проведение чека повторно. В этот момент и происходит проведение чека полностью повторяющий предыдущий чек. По РМК этот «двойной» чек проведен один раз, а по фискальному регистратору дважды. Если же снять контрольную ленту из ЭКЛЗ за эту смену, то мы увидим два абсолютно одинаковых чека следующими друг за другом с очень маленьким временным интервалом.

Вообще двойные чеки раньше были прерогативой ККМ Феликс РК, этому есть вполне реальное подтверждение. Из пяти ККМ установленных на рабочих местах при трех ККМ Штрих-ФР-К и двух Феликс –РК, при абсолютно одинаковых внешних параметрах и одинаковом ПО. Два ККМ Феликс РК беспрерывно выдавали двойные чеки, а три Штрих-ФР-К ни разу. Отсюда следует простой вывод проблема именно в ККМ Феликс РК, все мыслимые и немыслимые доработки лишь уменьшали количество двойных чеков, но не устраняли проблему в целом. Помимо заводских наработок, были и собственные, в результате которых количество двойных чеков уменьшалось до одного за период 3-6 месяцев, что в принципе клиент считал допустимым.

С появлением  FPrint 03K проблема не устранилась, это давало повод для размышлений, что старые болячки перешли на новые модели ККМ. 

С появлением восьмой версии 1С проблема приняла  несколько интересные очертания,  двойные чеки стали и ККМ производства Штрих, даже самые надежные представители в линейке – Штрих-ФР-К. Причем заявки шли  со всех сторон, с разных рабочих мест, от разных программистов, от разных клиентов.  При более детальном рассмотрении причины сбоев были разные, но всех их объединял один факт, все ККМ, которые сбоили, работали удаленно от сервера, то есть были не в локальной сети, а обращались к серверу посредством Internet ресурсов.

Если внимательно рассмотреть  алгоритм проведения чека по протоколу Штрих, то задача  выявления причин сбоя возможно уходит корнями в 1С. Упрощенно рассмотрим  алгоритм отработки распространенной ошибки для протокола Штрих и Атол – кратковременное отсутствие бумаги, то есть при наличии бумаги датчик бумаги ложно сработал.  Если Феликс РК – восстанавливает свою работоспособность сразу после ложного срабатывания, успев при этом ответить в РМК о том, что при проведении чека произошел сбой, то Штрих-ФР-К полностью блокирует работу ККМ до получения команды «Продолжить печать». То есть РМК должно сперва, дать команду отличную от команды закрытия чека, а только потом саму команду закрытия чека.  Тут алгоритм протокола Штрих работает идеально, это подтверждается его стабильной работой при работе с 1С.

В случае же работы с сервером 1С и удаленным рабочим местом, сбойная ситуация имеет несколько другие корни и как результат, ни надежность протокола Штрих, ни  хваленая надежность ККМ Штрих-ФР-К  не помогает стабильной работе ККМ и не устраняет проблему двойных чеков. 

Следует отметить, что в каждом протоколе заложен механизм отработки  подобных сбоев, но при работе с восьмой 1С эти механизмы не используются. При разговоре с программистами, которые делают РМК на основе Си, Delphi и других языков программирования, этот механизм всегда закладывается и поэтому на лицо полное отсутствие сбоев  при работе с ККМ с любым протоколом.