Главная категория > ЭЛВЕС-МФ БЕЗ УМ

Элвес-МФ - ФН помер на 2-ой смене

<< < (8/8)

engineer:

--- Цитата: Mechanik от 10/04/2017 21:02:10 ---И касса "отрыгнула" все чеки в ОФД...
--- Конец цитаты ---
Похоже, что это просто ребята из Атласа оперативно сработали по результатам разбора контейнера... Наверняка, косяк был на стороне ПО ПКЗ... Поправили - и все полетело!

GeorgSerg:
to engineer - Опередили чуток... На втором завтра только можно будет проверить -
отпишу сразу же ..

Mechanik:
А что тут думать сумма без ндс была одна - чек НЕ ПРИНИМАЛСЯ, стала как положено - принялся!!! Вот и угадай почему - ЗАПИСЬ В ФН - не может менятся, т.е. глюк на уровне ОФД? Жаль что я не подключил к компу ФН. Кто-то что-то поправил и всё принялось как положено.

Чек который пришёл и переварился:
ЧЕК / Приход
ИП Черных Ольга Витальевна г.Челябинск ул.Яблочкина д.19
ФИСКАЛЬНЫЙ ДОКУМЕНТ
#29
ДАТА ВЫДАЧИ
04.04.17 14:04
Кассир 1 Горина Н.В.
ИНН 743800031985
РН ККТ 0000261472001577
ФН 8710000100316664
Фискальный признак
2612832792
НОМЕР СМЕНЫ
#2
ПОРЯДКОВЫЙ НОМЕР ЗА СМЕНУ
#21
ОФД
ООО ПС СТ
Сайт ОФД
ofd.ru
Продукты
1 X 469.00
в т.ч. СУММА БЕЗ НДС = 469.00
 = 469.00
ИТОГ
469.00
Наличными
0.00
Электронными
469.00
  в т.ч. налоги
  СУММА БЕЗ НДС
469.00
Система налогообложения
ЕНВД

Кто хочет может сравнить с контейнером

engineer:

--- Цитата: Mechanik от 10/04/2017 22:10:44 ---то хочет может сравнить с контейнером
--- Конец цитаты ---
Не поленился, сравнил...
В контейнере для предмета расчета вместо B734h записано 6E34h. Однако на таком уровне (уровне подсчета и контроля сумм) ФЛК (форматно-логический контроль) в ОФД (и тем более в ПКЗ) не осуществляется.
Если внимательно посмотреть, то увидим, что 6Eh (01101110) - это B7h (10110111), сдвинутое влево. Поскольку теперь все вдруг улетело, то предположение о том, что это искажение не в ФН, абсолютно верно. Это подтверждает и подсчет CRC-16 контейнера. Со значением 6Eh подсчет дает значение 6ADEh, что не соответствует значению CRC-16, указанному в контейнере (ее значение в контейнере равно 6C25h). А вот подсчет CRC-16 с правильным байтом B7h дает и правильное значение CRC-16. Становится ясно, что не принималось из-за несовпадения CRC-16. Осталось понять, где этот сдвиг произошел?..
Сдается мне, что все-таки в ККТ... Согласно протоколу вычитывание сообщения из ФН касса может осуществлять блоками, длину которых определяет сама. При этом CRC-16 этих блоков ФН не формирует. Поэтому сбой при чтении этих блоков может быть обнаружен только после вычитки всего контейнера по CRC-16 этого контейнера. А все ли кассы это делают?
Скорее всего, Mechanikу просто повезло, что сбой в ККТ при вычитывании сообщения из ФН каким-то чудесным образом самоустранился.

Навигация

[0] Главная страница сообщений

[*] Предыдущая страница