BG Development


Страници: (14) « първа ... 12 13 [14]   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Delphi и фискален принтер
wqw
Публикувано на: 20-02-2020, 15:20
Quote Post


Group Icon
Име: Владимир Висулчев
Група: VIP
Ранг: Почетен член

Мнения: 6218
Регистриран на: 10.06.04



QUOTE (Dido @ 20-02-2020, 13:52)
Има някои случай, в които допуска втора връзка, докато първата е отворена и не е приключил печата на ФБ.

И какъв е резултатът? Двата бона се interleave-ват?

Това би било доста бизарно и съм сигурен че и Датекс искат да видят такъв микс отпечатан.

cheers,
</wqw>


--------------------
PMEmail PosterUsers Website
Top
Dido
Публикувано на: 20-02-2020, 16:05
Quote Post



Име:
Група: Потребител
Ранг: Посетител

Мнения: 52
Регистриран на: 17.11.10



QUOTE (wqw @ 20-02-2020, 15:20)
QUOTE (Dido @ 20-02-2020, 13:52)
Има някои случай, в които допуска втора връзка, докато първата е отворена и не е приключил печата на ФБ.

И какъв е резултатът? Двата бона се interleave-ват?

Това би било доста бизарно и съм сигурен че и Датекс искат да видят такъв микс отпечатан.

cheers,
</wqw>

Не, боновете не се смесват. Излизат си правилно. Просто ФП докато печата допуска втора конекция по TCP/IP, преди да е завършила първата конекция.
PMEmail Poster
Top
wqw
Публикувано на: 20-02-2020, 22:44
Quote Post


Group Icon
Име: Владимир Висулчев
Група: VIP
Ранг: Почетен член

Мнения: 6218
Регистриран на: 10.06.04



QUOTE (Dido @ 20-02-2020, 16:05)
QUOTE (wqw @ 20-02-2020, 15:20)
QUOTE (Dido @ 20-02-2020, 13:52)
Има някои случай, в които допуска втора връзка, докато първата е отворена и не е приключил печата на ФБ.

И какъв е резултатът? Двата бона се interleave-ват?

Това би било доста бизарно и съм сигурен че и Датекс искат да видят такъв микс отпечатан.

cheers,
</wqw>

Не, боновете не се смесват. Излизат си правилно. Просто ФП докато печата допуска втора конекция по TCP/IP, преди да е завършила първата конекция.

И? Има ли някакви фатални последствия това?

При мен имам само един FP-650 а той няма LAN порт и не съм ги тествал мрежово въобще моделите от група А на Датекс. Имам една DP-25X каса, която достъпвам през tcp, но не съм я напъвал с по няколко conn едновременно да забележа че ми прави мизерии.

Малко странно ми изглежда, това е все едно да отвориш COM1 с hComm = CreateFile("\\.\COM1") примерно и някакси да успееш да си вземеш втори handle.

Аз съм на втора версия на проекта с драйверите: https://github.com/wqweto/UcsFiscalPrinters...ontrib/UcsFPHub

Вече върху COM базата е развито към JSON базирани протоколи, има REST сървис през едно hub-че и дори може да се ползва през message queue endpoint-и като Service Broker на MSSQL.

cheers,
</wqw>


--------------------
PMEmail PosterUsers Website
Top
Dido
Публикувано на: 21-02-2020, 12:09
Quote Post



Име:
Група: Потребител
Ранг: Посетител

Мнения: 52
Регистриран на: 17.11.10



QUOTE (wqw @ 20-02-2020, 22:44)
И? Има ли някакви фатални последствия това?


Няма фатални последствия. Анализирах го и го тествах основно и се оказа следното:

1. Ако се пуснат от две работни места едновременно фискални бонове,
принтера приема и двете конекции и ги отпечатва правилно, явно си прави опашка.
Всичко което е между команди 48 (отваряне на ФБ) и 56 (затваряне на ФБ) работи
коректно.

2. При едновременно пускане на бонове от две работни места към един принтер:
- Ако се пусне поредност 48-49-53-113-62-56 - работи коректно.
- Ако се пусне поредност 48-49-53-56-113-62 - почти винаги команди 113 и 62
вместо да върнат глоб. номер на последен документ и дата и час на ФП, връщат
нещо от сорта на 'D000....', или единият фискален бон остава наполовина и после трябва да се анулира.

3. Явно когато има опашка и има команди извън фискална транзакция, те не сработват
правилно. Когато командите са във фискалната транзакция (между 48 и 56),
всичко си работи коректно. Преместих ги (113 и 62) преди 56 и увеличавам номера с 1 и така получавам глобалния номер на текущия ФБ и времето му с 2 сек. разлика
и за сега мисля, че проблема се разреши.
PMEmail Poster
Top
wqw
Публикувано на: 21-02-2020, 19:32
Quote Post


Group Icon
Име: Владимир Висулчев
Група: VIP
Ранг: Почетен член

Мнения: 6218
Регистриран на: 10.06.04



Да, това което си направил е много мъдро, и при мене е точно така. Преди да затворя ФБ взимам GetLastReceiptNo и го увеличавам с 1 само ако не печатам на ФУ на Елтрейд, които се оказва са решили да инкрементират брояча на ФБ на *отваряне* на бон, не на commit.

И при мен ползвам GetClock за дата/час на ФБ а не инфо от QR кода (където часът е точен до секунда), защото QR код все още не е отпечатан. Аз лично не си играя да увеличавам времето с 2 секунди обаче, защото и това може да е неточно -- зависи на какъв модел се печата ФБ.

Друго което collect-вам е ReceiptAmount -- обща стойност на ФБ така както го връща команда 76, за да мога да си популирам таблица с данни за отпечатани ФБ -- номер, дата/час, обща стойност, сериен номер на ФУ и номер на ФП, като в отделна таблица имам разбивка на сумите по видове плащания с номер и име на вид плащане от номенклатурата на НАП с 11-те вида плащания (SCash, SChecks, ST, SOT, etc. XML тагове) ако се плаща смесено дадена продажба.

Но истинската причина при мен за събиране на пълните данни за ФБ преди commit на фискалната транзакция са устройствата на Тремол в т.нар. buffered/postponed печат на ФБ. При този режим на работа тремолските ФУ спулират много бързо всичките PLU редове и суми на плащания и едва на commit започват да печатат физически, което е доста по-бавната операция в сравнение със спулирането.

При протокола на Тремол идеята е, че ако commit се изпълни успешно самото ФУ гарантира, че сумите по ФБ са фискализирани и ако например свърши хартията преди напълно да е отпечатал ФБ, то самото си започва отначало печата на конкретната ФБ като се смени ролката -- не е нужно клиентското приложение да се грижи за retry и пр. неприятности с разминаване на суми по ФУ и по ПОС.

За операторите на нашия ПОС този режим на работа означава, че при печат на ФБ самото ПОС приложението става responsive преди ФБ да е отпечатан на 100% и затова могат да поемат следващия клиент на опашката в магазина докато ФУ отпечатва ФБ за предходната продажба и ФУ с ПОС работят в синхрон много по-надеждно отколкото с ФУ на Датекс.

cheers,
</wqw>

Това мнение е било редактирано от wqw на 21-02-2020, 19:35


--------------------
PMEmail PosterUsers Website
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (14) « първа ... 12 13 [14]  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0