Штрих онлайн ( ФФД 1.05) округляет цену до рубля - как убрать?

[kkmspb]

Не могу победить округление именно цены товара:

например 1.22 посылаю через FNOperation() , а чеке упорно  1.00

Может кто знает, где с эта долбанная настройка?

Причем параметр PointPosition  : 1 , вроде бы копейки включены.

[kkmspb]

Пробовал Режим исчисления скидок 0 и 2 - все равно округляет.

Кстати после выключения/включения кассы Режим исчисления скидок восстанавливается в режим = 2.

Странно но , из драйвера если 100,12 х 1шт. пытаюсь пробить - нормально пробивается с копейками (если также сумму1 указать 100.12)

[DanShi]

В описании FNCloseCheckEx всё написано.

[kkmspb]

В описании FNCloseCheckEx всё написано.

FNCloseCheckEx - да по нему и пробиваю.  (Драйвер ККТ версия 5.17)
Штрих Онлайн
 ----------------------------------------
 Версия ПО                 : C.1
 Сборка ПО                 : 1800
 Дата ПО                   : 19.01.2023
 ----------------------------------------


Вот небольшой лог:
Password : 30 
CheckType : 1 
StringForPrinting : ttttttttttttttttt 
Price : 100.12 
Quantity : 10.123 
PaymentTypeSign : 4 
PaymentItemSign : 1 
TaxValueEnabled : 0 
Department : 1 
Tax1 : 4 
FNOperation() ok
TaxType : 1 
Summ1 : 1013.51 
Summ2 : 0 
Summ14 : 0 
Summ15 : 0
FNCloseCheckEx() ok Закрытие чека


драйвер 5.0.7942.30349 (32) или так DrvFR_516_877_x32

[DanShi]

RoundingSumm
CуммаОкругления
Тип: Integer / Целое
Сумма округления. Используется методом: FNCloseCheckEx 

[kkmspb]

RoundingSumm
CуммаОкругления
Тип: Integer / Целое
Сумма округления. Используется методом: FNCloseCheckEx 

Пробовал по разному (и перед FnOperation и перед FNCloseCheckEx  ):
"RoundingSumm" , 99
"RoundingSumm" , 0
"RoundingSumm" , 50
не помогает, точнее вообще пишет в чеке еще и округление какое-то

это точно не то, т.к. в драйвере Штриха без этого работает нормально

[DanShi]

Ну тогда , что мешает посмотреть лог драйвера и тупо повторить.

[kkmspb]

Ну тогда , что мешает посмотреть лог драйвера и тупо повторить.

Самое прикольное, что сделал передачу  один в один как в драйвере и все равно не помогает:

TaxValueEnabled : false 
Summ1Enabled : false 
CheckType : 1 
TaxValue : 0 
Tax1 : 4 
Summ1 : 1013.51 
PaymentTypeSign : 4 
PaymentItemSign : 1 
Department : 1 
Price : 100.12 
Quantity : 10.123 
StringForPrinting : ttttttttttttttttt 
MeasureUnit : 0 
DivisionalQuantity : false 
Numerator : 10 
Denominator : 123 
FNOperation() ok
RoundingSumm : 0 
Summ1 : 1013.51 
Summ2 : 0 
Summ3 : 0 
Summ4 : 0 
Summ5 : 0 
Summ6 : 0 
Summ7 : 0 
Summ8 : 0 
Summ9 : 0 
Summ10 : 0 
Summ11 : 0 
Summ12 : 0 
Summ13 : 0 
Summ14 : 0 
Summ15 : 0 
Summ16 : 0 
TaxValue1 : 0 
TaxValue2 : 0 
TaxValue3 : 0 
TaxValue4 : 0 
TaxValue5 : 0 
TaxValue6 : 0 
TaxType : 32 
FNCloseCheckEx() ok Закрытие чека
GetShortECRStatus() ok
DisConnect() ok
Успешное завершение.


Заметил также , что и при внесение суммы такое поведение , отрезает копейки (а в драйвере все норм.)

Пытался цену а\позиции как-то передать через FNSendTagOperation , но это не работает для цены.

В общем очень интересно... И хочется плюнуть на копейки, но дело принципа.

[M.Connor]

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

[pavel_net]

Если сумма 1013.51, то RoundingSumm = 51 округлит до 1013 по моему как то так, попробуйте.
Причем RoundingSumm идет уже после Sum1 даже в примере, что логично.

[kkmspb]

В общем пока не победить копейки.
Судя по примерам в протоколе разработчики Штриха на Дельфах писали библиотеку.
У меня С++ с Qt используется.
У Атола тоже С++ и тоже с Qt и я с Атолом нормально работаю, в.т.ч и с копейками (из этой же среды).

У Штриха везде и во внесении и в цене (в моем случае возникают проблемы).

Зацепился глаз - в протоколе Штриха упоминается фиксированная точка (4 знака после запятой)... Как это реализовать не догоняю.

Price Денежн. 0..99999999,99

Currency / Денежный – 64-битное число с 4 дробными разрядами; диапазон: от -922337203685477,5808 до 922337203685477,5807

[kkmspb]

Решил пойду-ка я на компромисс.

А и не надо пользователям пробивать копейки, запретил категорически в цене копейки и что вы думаете.

Начали вылезать автоматом какие-то округления в итоговой сумме чека . Облом полный. Спасибо прогерам Штриха, что не работает у меня ни шиша.

Но у них-то из драйвера работает и даже очень прекрасно.

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

ОЧЕНЬ БОЛЬШАЯ ПРОСЬБА ПРОГЕРАМ - У КОГО РАБОТАЮТ ДЕНЕЖНЫЕ СУММЫ С КОПЕЙКАМИ ?

НУЖНА ИНФОРМАЦИЯ - НА КАКОМ ЯЗЫКЕ ПРОГРАММИРОВАНИЯ И В КАКОЙ СРЕДЕ РАЗРАБОТКИ ЭТО ВСЕ ТАКИ РАБОТАЕТ?

[DanShi]

Задайте вопрос напрямую прогеру Штриха на github, я думаю он точно решит этот вопрос.

[kkmspb]

Задайте вопрос напрямую прогеру Штриха на github, я думаю он точно решит этот вопрос.

Спасибо, точно на гитхабе swex (вроде).

[M.Connor]

Решил пойду-ка я на компромисс.
А и не надо пользователям пробивать копейки, запретил категорически в цене копейки и что вы думаете.
Начали вылезать автоматом какие-то округления в итоговой сумме чека . Облом полный. Спасибо прогерам Штриха, что не работает у меня ни шиша.
Но у них-то из драйвера работает и даже очень прекрасно.
Мораль такая, надо реализовывать протокол на байтовом уровне. К счастью он известен, правда не документирован и возможны вариации от модели к модели ккт, но другого пути я не вижу.
ОЧЕНЬ БОЛЬШАЯ ПРОСЬБА ПРОГЕРАМ - У КОГО РАБОТАЮТ ДЕНЕЖНЫЕ СУММЫ С КОПЕЙКАМИ ?
НУЖНА ИНФОРМАЦИЯ - НА КАКОМ ЯЗЫКЕ ПРОГРАММИРОВАНИЯ И В КАКОЙ СРЕДЕ РАЗРАБОТКИ ЭТО ВСЕ ТАКИ РАБОТАЕТ?

Гораздо проще написать на support@shtrih-m.ru (support@poscenter.ru) и пользоваться библиотекой штриха, чем решать проблемы обмена на физическом уровне.
На .net никаких проблем с копейками не возникает

[kkmspb]

>На .net никаких проблем с копейками не возникает

На .net и суда нет.


Посмотрел на гитхабе у Штриха примеры и похоже облом у них там для С++:

Посмотрел объявление использования параметра Price в Qt
Q_PROPERTY(qint64 Price READ Get_Price WRITE Set_Price NOTIFY PriceChanged)
Как тут можно передавать дробное число , точнее копейки, примерно так 123.45.

Написал им там в гитхаб, жду ответки...

С другой стороны для количества имеем такое объявление:
Q_PROPERTY(double Quantity READ Get_Quantity WRITE Set_Quantity NOTIFY QuantityChanged)

Количество можно передавать дробное, все работает корректно.

Но как быть с Price?

У сумм тоже копейки не проходят:
Q_PROPERTY(qint64 Summ11 READ Get_Summ11 WRITE Set_Summ11 NOTIFY Summ11Changed)

[kkmspb]

Хотел спросить про байтовый протокол.

Все вроде понятно

1,99*1шт
"333"
приход
товар
полный расчет
шт. - 1.05 (только 1 вариант) другие не проходят,
без НДС
1 отдел

02
   23 FF    длина (со след байта и до конца, сключая CRC)
   46       код команды
   1E 00        длина пакета
   00 00      номер пакета
   01 приход
   40 42 0F 00 00 00      количество
   C7 00 00 00 00           цена 199
   FF FF FF FF FF
   FF FF FF FF FF       сумма налога
   08       ставка налога 1 - 20%, 2 - 10%, 4 - 0%, 8 - без НДС, 10 - 120% , 20 - 110%
   01    отдел
   04   полный расчет, аванс
   01   товар, услуга
   33 33 33   наименоваание предмета расчета
   70
   

Только CRC не догоняю как создавать, может кто знает?

[DanShi]

всё не так, есть же описание протокола в заголовке раздела, там всё расписано понятным языком и формат посылки и все команды по байтикам расписаны
 Формат сообщения:
Байт 0: признак начала сообщения STX;
Байт  1:  длина  сообщения  (N)  –  ДВОИЧНОЕ  число.  В  длину  сообщения  не
включаются байты 0, LRC и этот байт;
Байт 2: код команды или ответа – ДВОИЧНОЕ число;
Байты 3...(N+1): параметры, зависящие от команды (могут отсутствовать);
Байт  N+2  –  контрольная  сумма  сообщения  –  байт  LRC  –  вычисляется
поразрядным сложением (XOR) всех байтов сообщения (кроме байта 0).

[kkmspb]

С гитхаба Штрих подтвердил (спасибо им за оперативный ответ), что надо на С++ передавать цену как целое (8 байт), в копейках значение.

Устанавливаю цену 12345. Дошел отладчиком уже до диспатч интерфейса. В памяти все 8 байт как надо (39 30 00 00 00 00 00 00)

Код: [Выделить]

IDispatch *disp
hres = disp->Invoke(dispid, IID_NULL, LOCALE_USER_DEFAULT, DISPATCH_PROPERTYPUT, &params, 0, &excepinfo, &argerr);

Пробивает блин все-равно 12345.00.  Причем похоже это со всеми ценами,суммами такая фигня.

Посмотрел в программе TVD Online - там нормально все 123.45 пробивает.

В общем доже интересно становится...

[kkmspb]

С гитхаба Штрих подтвердил (спасибо им за оперативный ответ), что надо на С++ передавать цену как целое (8 байт), в копейках значение.

Устанавливаю цену 12345. Дошел отладчиком уже до диспатч интерфейса. В памяти все 8 байт как надо (39 30 00 00 00 00 00 00)

Код: [Выделить]

IDispatch *disp
hres = disp->Invoke(dispid, IID_NULL, LOCALE_USER_DEFAULT, DISPATCH_PROPERTYPUT, &params, 0, &excepinfo, &argerr);

Пробивает блин все-равно 12345.00.  Причем похоже это со всеми ценами,суммами такая фигня.

Посмотрел в программе TVD Online - там нормально все 123.45 пробивает.

В общем доже интересно становится...

всё не так, есть же описание протокола в заголовке раздела, там всё расписано понятным языком и формат посылки и все команды по байтикам расписаны
 Формат сообщения:
Байт 0: признак начала сообщения STX;
Байт  1:  длина  сообщения  (N)  –  ДВОИЧНОЕ  число.  В  длину  сообщения  не
включаются байты 0, LRC и этот байт;
Байт 2: код команды или ответа – ДВОИЧНОЕ число;
Байты 3...(N+1): параметры, зависящие от команды (могут отсутствовать);
Байт  N+2  –  контрольная  сумма  сообщения  –  байт  LRC  –  вычисляется
поразрядным сложением (XOR) всех байтов сообщения (кроме байта 0).

[kkmspb]

поразрядным сложением (XOR) всех байтов сообщения (кроме байта 0).

Спасибо, да точно, XOR используется. Почему-то тупанул, не сообразил. В 5.16, 5.17 , 5.18  уже об этом не упоминается.

[pavel_net]

Я тип Currency использую и проблем нет.

[kkmspb]

Регистрация операции (добавляем предмет расчета).

Похоже начинаю догадываться. Посмотрел в чем отличие моих передаваемых байтов (через USB протокол Device monitoring Studio) .
У меня:

02 22 46 1E 00 00 00 01 40 42 0F 00 00 00 C7 00 00 00 00 FF FF FF FF FF FF FF FF FF FF 08 01 04 01 33 33 33 8E

Из драйвера (при нормальном результате):

02 23 FF 46 1E 00 00 00 01 40 42 0F 00 00 00 C7 00 00 00 00 FF FF FF FF FF FF FF FF FF FF 08 01 04 01 33 33 33 70

У меня в поле длина однобайтовая 22, а у драйвера штрих 23 FF (2 байта).

[kkmspb]

Я тип Currency использую и проблем нет.

Это в Паскале похоже?

Дело в том, что в С++ есть только double. Аналога Currency встроенного в библиотеку Qt (4.8.1) вроде нет.

[pavel_net]

Это в Паскале похоже?

Да.
Я думаю должен быть какой то способ это обойти, не вы первый со штриховским драйвером работаите, ну или переходить на кросплатформенный драйвер.

[kkmspb]

Читаю еще раз протокол:
Стандартный нижний уровень

Код: [Выделить]

При обмене хост и ККТ оперируют сообщениями. Сообщение может содержать
команду (от хоста) или ответ на команду (от ККТ).
Формат сообщения:
Байт 0: признак начала сообщения STX;
Байт 1: длина сообщения (N) – ДВОИЧНОЕ число. В длину сообщения не
включаются байты 0, LRC и этот байт;
Байт 2: код команды или ответа – ДВОИЧНОЕ число;
Байты 3...(N+1): параметры, зависящие от команды (могут отсутствовать);
Байт N+2 – контрольная сумма сообщения – байт LRC – вычисляется
поразрядным сложением (XOR) всех байтов сообщения (кроме байта 0).

И чуть ниже Альтернативный нижний уровень:

Код: [Выделить]

[0] {STX} – стартовый символ, обозначает начало пакета. Значение 0x8F.
[1][2] {LEN16} – общая длина полей {NUM16, DATA[]} в байтах. Диапазон значений
LEN16 = 0, 2…65535.
Если LEN16 = 0 (тип I) – пустой пакет без номера; поля: {STX, LEN16, CRC16}; длина пакета 5
байт.
[LEN+3] [LEN+4] {CRC16} – контрольная сумма, которая включает в себя байты полей {LEN16,
NUM16, DATA[]} (если имеются).
Если LEN16 = 2 (тип II) – пустой пакет с номером; поля: {STX, LEN16, NUM16, CRC16}; длина
пакета 7 байт.
[3][4] {NUM16} – номер пакета. Диапазон значений NUM = 0…65535. Начальное значение 1.
Если LEN16 = 3…65535 (тип III) – информационный пакет; поля: {STX, LEN16, NUM16, DATA[],
CRC16}; длина пакета 8…65540 байт.
[5] {DATA[]} – информационное поле (блок) данных пакета. Длина блока данных LEN16 -
2 = 1...65533 байтов

[kkmspb]

ну или переходить на кросплатформенный драйвер.

Это о чем?

[kkmspb]

Идею подсказали на гитхабе у Штриха - надо заставить в COM объект передавать значение с типом VT_CY = 6 (VARIANT) . А у QT в QVariant такого нет (Qt4 во всяком случае).

[pavel_net]

Это о чем?

Это который на гитхабе, или там тоже Currency надо передавать ?

[DanShi]

Регистрация операции (добавляем предмет расчета).

Похоже начинаю догадываться. Посмотрел в чем отличие моих передаваемых байтов (через USB протокол Device monitoring Studio) .
У меня:

02 22 46 1E 00 00 00 01 40 42 0F 00 00 00 C7 00 00 00 00 FF FF FF FF FF FF FF FF FF FF 08 01 04 01 33 33 33 8E

Из драйвера (при нормальном результате):

02 23 FF 46 1E 00 00 00 01 40 42 0F 00 00 00 C7 00 00 00 00 FF FF FF FF FF FF FF FF FF FF 08 01 04 01 33 33 33 70

У меня в поле длина однобайтовая 22, а у драйвера штрих 23 FF (2 байта).

длинна в обоих случаях однобайтная, только через драйвер идет правильная команда FF46 , а   у вас просто 46, такой кстати вообще нет.

[kkmspb]

Итак проблема идентифицирована наконец.

Оказывается при установке свойства Com об'екта кроме самого значения надо передавать ещё и тип значения, а именно для Price тип VT_CY (денежный).
Так вот в С++ такого типа нет. В библиотеке Qt (у нас 4.8.1) тоже нет такого типа.
Смысл ситуации в том, что надо править исходники фреймворка Qt, реализовывать новый тип в QVariant, возможно править метаоб'ектную систему Qt, ,потом шлифовать/отлаживать классы QAxObject, пересобирать полностью Qt.
Конечно мы это сделаем, но надо понимать, что это будет уже форк и при обновлении на новую версию Qt все слетит к чертям собачьим.
Хочется добавить в итоге, что всего этого можно было избежать если использовать просто число с плавающей точкой (как в случае с количеством), которое поддерживается процессорами на аппаратном уровне и соответственно всеми языками программирования.
Ни и последнее - как вы думаете на чем написан драйвер Атола и почему у него таких проблем нет?

[pavel_net]

Ну вообще правильней использовать целые копейки чтобы вообще никаких проблем не было.
Атол полностью переписал свой драйвер после 6 версии и у них получился хороший современный продукт. Хотя мне у них много чего не нравится.
Вся беда Штриха, что у них драйвер как буханка, сразу получился заеб... идеально, но теперь он немножечко устарел.

[kkmspb]

В общем сделал развитие фреймворка Qt. Добавил новый тип данных, назвал QpCurrency. Qp это наш префикс для различия с исходниками самого Qt.
То есть надо интегрировать самопальный тип данных в QVariant, потом интегрировать его в метаобъектную систему Qt, потом не забыть настроить конвертации между базовыми типами данных. Потом пересобирать исходники Qt, да конечно ещё все отлаживать исправлять ошибки.

Но самое главное, что проблему решить возможно и без этого никакой ккт Штрих к проге, написанной на Qt С++, подключить нормально НЕВОЗМОЖНО будет.

То, что у Штриха выложен какой-то кроссплатформенный драйвер в виде объявлений методов на С++ это все полная ерунда, это не работает для копеек и получается тонкая подстава (да простят меня полосатые).

Всем спасибо, решение найдено.