Страница 13 из 46

Взять кассу

Добавлено: 05 Ноябрь 2018, 18:30
Игорь Столяров
finsoftrz писал(а): 05 Ноябрь 2018, 17:52По логу у Штрихов возврат ошибки "нет связи".
1. Поговорите на эту тему с любым мастером сервисного центра. После того, как он выматерится, Вы узнаете,
что у Штрихов "больное" место - это кабели. Точнее их качество. Первым делом при ошибке "нет связи" меняется кабель.
Как правило - это решает проблему. Как мне объясняли - там какая-то беда с качеством контактной группы (Китай ?).

2. Архитектура Штриха изначально (очень давно) строилась под медленный COM порт и особо не изменилась (в отличии от АТОЛ).
Поэтому желательно не перегружать буфер печати, т.е. не гнать в него данные потоком, пока есть ещё не распечатанные.
В общем-то это описано в документации, просто обычно это место пропускают и упрощают код … ;)
Реализовать сказанное выше можно по разному, например вставляем после КАЖДОЙ команды печати вызов:

Код: Выделить всё

ShtrihM_WaitPrint    PROCEDURE  (Object_)                  ! Declare Procedure
Loc:RetValue         BYTE(False)
  CODE
  
  Loop
     Case Int(Object_{'WaitForPrinting'})
     Of 0
        Break
     Of -34
        If Message(' В ККМ закончилась кассовая лента !| Вставьте новый ролик с лентой.|| Продолжить печать ?','У нас проблема !',Icon:Question,Button:Yes+Button:No,Button:Yes) <> 2
           Display
           Loc:RetValue = True    ! Выход с ошибкой
           Break
        else           
           Object_{'ContinuePrint'}           
        end
     Of -1
        Object_{'GetShortECRStatus'}
     else
        If Int(Object_{'ResultCode'})
           Message(' Ошибка: ' & Clip(Left(Object_{'ResultCodeDescription'})),'Сообщение',Icon:Exclamation,'&1. Закрыть')           
           Loc:RetValue = True    ! Выход с ошибкой
        end
        Break
     end
  end

  Return(Loc:RetValue)

Взять кассу

Добавлено: 05 Ноябрь 2018, 18:53
finsoftrz
Насчет китайских кабелей я в курсе, про это и писал. Возможно, потеря связи и вход в режим необходимости продолжения печати - разные ситуации. Пишут, что для продолжения печати на штрихах можно просто нажать кнопку протяжки ленты на ккм...

Взять кассу

Добавлено: 05 Ноябрь 2018, 18:58
deesoft
Коллеги со Штрихом под ФЗ-54 ФДД 1,05 кто нибудь разобрался как агенские тэги передавать ?
в официальной документации тишина.

Взять кассу

Добавлено: 05 Ноябрь 2018, 18:58
Игорь Столяров
finsoftrz писал(а): 05 Ноябрь 2018, 18:53Пишут, что для продолжения печати на штрихах можно просто нажать кнопку протяжки ленты на ккм
Это как решить проблему. Но ведь мы хотим предотвратить её появление ? ;)

Взять кассу

Добавлено: 05 Ноябрь 2018, 19:07
gopstop2007
Бывает, что достаточно снизить скорость передачи данных по com порту, в настройках. Кабель больше играет качество - экранирование кабеля и ферриты на концах.

Взять кассу

Добавлено: 05 Ноябрь 2018, 19:18
finsoftrz
На штрихах чек вначале регистрируется в фн и отправляется в офд (при наличии связи), а потом печатается. Если при печати сбой (кончилась или зажевалась бумага), то получаем нашу ситуацию. Чек уже зафиксирован в ккм, но не напечатан. И, как я понимаю, в программу нам вернулось, что все ок. А при попытке печати следующего чека драйвер нам возвращает ошибку, что ожидается команда продолжения печати. Вариант с WaitForPrinting выглядит правильным в этом случае. Попробую, спасибо за наводку.

Взять кассу

Добавлено: 08 Ноябрь 2018, 10:05
Игорь Столяров
finsoftrz писал(а): 05 Ноябрь 2018, 19:18И, как я понимаю, в программу нам вернулось, что все ок.
Вот это очень неприятное место в работе с Штрих-ом при проблемах с лентой. :(
Вопрос в том, как отсекать ошибку: по закрытию чека или по его печати.

- Если по закрытию чека - то будет как Вы написали, в программу вернётся, что всё OK, но чек не напечатан.

- Если по печати чека - то вернётся ошибка, но ведь чек по факту "закрыт" и передан в ОФД.
Попытка второй раз печати чека - приведёт к его дублированию в фискальном реестре и ОФД.

Взять кассу

Добавлено: 08 Ноябрь 2018, 14:09
finsoftrz
Наблюдаю иногда еще такую проблему на Штрихах. Чек пробился, ушел в офд, но драйвер вернул ошибку потери связи. Программа в этом случае продажу откатывает, товар остается на экране и кассир проводит продажу повторно. Получается лишний чек в фн и офд. При закрытии смены программа делает сверку чеков в своей базе данных и фн, при обнаружении расхождения пишет в лог.

Взять кассу

Добавлено: 13 Ноябрь 2018, 15:57
finsoftrz
Сегодня еще одну проблемную ситуацию зарегистрировали на Штрихах. Чек из 2 строк. Почему-то вторая строка не зарегистрировалась, драйвер ошибку не вернул. Ее сумму в чеке вывел как сдачу. Деньги с покупателя взяли правильно, по кассовой программе все тоже прошло правильно. А в ОФД и на печати чек на сто рублей меньше. Произошло один раз на несколько тысяч чеков. Похоже, надо еще итоговую сумму по чеку перед фиксацией платежа сверять. Хотя не понятно, почему не вернулась ошибка, впечатление, что команда регистрации не дошла до драйвера.

Взять кассу

Добавлено: 30 Ноябрь 2018, 17:03
finsoftrz
Еще одна байка из склепа про Штрихи. У них относительно часто отрезчик ленты выходит из строя. Пока приедет инженер из ЦТО, проходит время, и чтобы магазин не простаивал, можно этот отрезчик просто отключить. В настройках драйвера Штриха такое есть. Только разработчики драйвера почему-то решили, что данную настройку должно проверять верхнее ПО, вместо просто отключить отрез. Иными словами, если при выключенной настройке мы пошлем команду отреза драйверу, то ККМ спокойно уходит в аварийный режим. Те, кто делает верхнее ПО, разумеется, читать эти настройки не хотят, а просто вводят свою. Это работает, но выглядит как откровенная заплатка...

Взять кассу

Добавлено: 30 Ноябрь 2018, 17:18
finsoftrz
Сегодня запустили в одном из магазинов в тестовом режиме первую СП-ку. Для поддержки формата ФФД 1.05 Сервис-Плюс сильно переработал команды обмена. Соответственно, пришлось перелопатить весь интерфейсный класс. В отличии от них в Штрихах и Атолах изменения носят точечный характер. В основном, это касается команд регистрации чеков.

Например, в Штрихе вместо старой команды SELF.Contr{'Sale'} надо использовать такое:
SELF.Contr{'PaymentTypeSign'} = 4
SELF.Contr{'PaymentItemSign'} = SELF.QueueSale.SaleType
SELF.Contr{'CheckType'} = 1
SELF.Contr{'FNOperation'}

Практически никаких изменений для 1.05 не требуется в Пиритах. Как у самых молодых и без наследия. По большому счету в последних прошивках добавили возможность передачи ИНН кассира вместе с наименованием <ИНН>&<ФИО>. И в качестве общей тенденции, теперь в ответ на печать чека возвращают все реквизиты, которые использовались при печати, включая рег.номер ккм и т.п.

С нового года формат 1.0 упраздняется и будет только 1.05. Соответственно, пора проверять программы на его поддержку...

Взять кассу

Добавлено: 30 Ноябрь 2018, 17:28
Игорь Столяров
finsoftrz писал(а): 30 Ноябрь 2018, 17:18Соответственно, пора проверять программы на его поддержку...
Собственно говоря, год уж как всё работает …
Тут надо заметить, что FNOperation никакого отношения к ФФД 1.05 не имеет и использовалась ранее для того,
что бы указывать (изменять установленную по умолчанию в драйвере) СНО - систему налогообложения чека.
Также нужно обратить внимание, что теперь (именно в ФФД 1.05) жёстко фиксированы номера ячеек фискальной
памяти для видов оплаты, особенно если используется оплата в счёт аванса или кредитом … Для алкашки - не актуально. :idied:

Взять кассу

Добавлено: 30 Ноябрь 2018, 17:32
finsoftrz
У Атолов обратил внимание на такое. В таблице видов оплат в тесте драйвера одно прописано, а фактически используется другое. Это другое есть в документации.

Взять кассу

Добавлено: 30 Ноябрь 2018, 17:39
finsoftrz
Игорь Столяров писал(а): 30 Ноябрь 2018, 17:28 Тут надо заметить, что FNOperation никакого отношения к ФФД 1.05 не имеет и использовалась ранее для того,
что бы указывать (изменять установленную по умолчанию в драйвере) СНО - систему налогообложения чека.
Нужные для 1.05 можно передать только через FNOperation, а для 1.0 работала и старая команда Sale. Поэтому наличие отношения вопрос скорее терминологии... Точнее, это если мы пользуемся этими командами. Некоторые на них кладут и работают напрямую, используя протокол обмена с ККМ. Я даже таких разработчиков знаю, можно сказать лично... :-)

Взять кассу

Добавлено: 30 Ноябрь 2018, 17:40
Игорь Столяров
finsoftrz писал(а): 30 Ноябрь 2018, 17:32В таблице видов оплат в тесте драйвера одно прописано, а фактически используется другое
Это тоже было где-то года назад ... там лихорадило эти таблицы оплаты по чёрному. :(
Они имели различия и от прошивки, и протокола обмена (!!!). Сейчас вроде стабилизировалось.
Четыре первых вида оплаты фиксированы, остальные можно менять, но в ОФД это всё будет как "оплата электронно".