Ръчният касов бон е отделен процес, който системата вече може да знае
Поръчката влиза в онлайн магазина, плащането е успешно, а след това служител отваря друга програма или устройство и въвежда същата информация още веднъж. При малък обем това е неудобство. При десетки или стотици операции дневно вече е системен проблем: време, двойно въвеждане, риск от грешка и липса на ясен статус кое е фискализирано.
В web-design.bg изграждаме интеграции между онлайн магазини, ERP, CRM, POS и custom бизнес системи и касови апарати или фискални принтери. Целта не е просто да „натиснем Print“, а продажбата, фискалната операция и резултатът да бъдат един проследим flow.
Касов апарат и фискален принтер не са едно и също
НАП посочва електронните касови апарати с фискална памет и фискалните принтери като видове фискални устройства. От техническа гледна точка обаче начинът на интеграция зависи от конкретния модел, производителя, наличния protocol, driver или SDK и средата, в която устройството работи.
Затова не обещаваме универсална интеграция по марка. Първо проверяваме точния модел и документацията му. Фискалният принтер често е естествен избор, когато продажбата вече се управлява от софтуер, но и касов апарат може да участва в автоматизиран flow, ако устройството и производителят предоставят подходящ интерфейс.
Как изглежда една реална интеграция
Системата вече знае артикулите, количествата, цените, ДДС групите, отстъпките, доставката, начина на плащане и номера на поръчката. Вместо оператор да преписва тези данни, integration layer-ът може да ги map-не към командите на конкретното фискално устройство, да получи отговор и да запише резултата обратно към поръчката.
При по-зряла архитектура пазим и operational state: издаден ли е документът, кога, от кое устройство, успешна ли е операцията, има ли грешка, трябва ли retry, имало ли е сторно и кой процес е задействал действието. Това позволява audit trail и защита срещу двойно изпълнение.
Cloud система и физическо устройство: local bridge
Често онлайн магазинът или ERP системата е в cloud, а фискалният принтер е физически в магазин, офис, ресторант или хотел. Ако устройството комуникира локално през USB, serial или LAN, не е разумно публичният сървър директно да управлява локалния порт.
В такива случаи можем да изградим защитен local bridge/service. Той работи в обекта, получава разрешени операции през контролиран API или queue, комуникира с устройството през неговия driver/protocol и връща резултата към cloud системата. Така физическото устройство остава локално, а бизнес логиката остава централизирана.
Какво става, ако устройството е изключено
Това е архитектурен въпрос, а не edge case. Лошата интеграция изпраща команда и се надява. Добрата интеграция знае статуса. Ако устройството не отговори, операцията може да бъде маркирана като pending или failed, да се предотврати дублиране, да се изпрати известие и да се позволи контролиран retry.
При системи с повече от един обект може да се добави routing към конкретно устройство, health status и централен журнал. Това е особено важно, когато фискалният процес е част от ERP или custom система и трябва да остава видим за екипа.
Сторно, връщане и анулиране трябва да бъдат част от дизайна
Фискализацията не приключва при успешната продажба. В eCommerce има отказани поръчки, частични и пълни връщания, корекции, неуспешни плащания и замени. Ако автоматизираме само първоначалната продажба, а всички изключения остават ръчни, системата бързо създава нов operational debt.
Затова още при discovery определяме кои order statuses и бизнес събития изискват фискално действие и как резултатът се записва обратно в ERP, CRM или поръчката.
При онлайн магазин режимът зависи и от начина на плащане
Не е коректно да се твърди, че всяка онлайн поръчка задължително изисква една и съща фискална операция. НАП описва различни режими според начина на плащане и организацията на продажбата. При електронен магазин при приложимите условия фискален или системен бон може да бъде генериран и в електронен вид, а за определени неприсъствени картови плащания съществува и алтернативен режим при изпълнение на нормативните изисквания.
Затова започваме от реалния payment flow, а не от кабела към принтера. При необходимост счетоводителят или данъчният консултант на клиента потвърждава приложимия режим, а ние реализираме техническата архитектура.
Как протича проектът при нас
Първо проверяваме точния модел устройство, къде се намира, как е свързано и каква система трябва да го управлява. След това описваме sales и return flow-а и определяме mapping-а между бизнес събитията и командите към устройството.
При нужда изграждаме middleware/local bridge, queue, retries, logging, permissions и audit trail. Накрая тестваме не само успешен бон, а продажба, offline устройство, грешка, повторен опит, сторно и връщане. След launch интеграцията може да остане под техническа поддръжка, защото драйвери, firmware, eCommerce платформа и бизнес процеси се променят.
Какво ни изпращате, за да преценим интеграцията
Най-полезната начална информация е точният модел и производител на касовия апарат или фискалния принтер, системата, която трябва да бъде свързана, физическото местоположение на устройството, начинът на връзка, начините на плащане и какво събитие трябва да задейства фискалната операция.
Ако имате повече от един обект, няколко устройства, сторно/връщания, ERP/CRM sync или налична SDK/protocol документация, включете и това. С този контекст можем да предложим конкретна архитектура вместо универсален plugin, който предполага, че всеки бизнес работи еднакво.
Нашият подход: системата трябва да знае дали операцията е приключила
Не продаваме „plugin за касов апарат“. Изграждаме връзката между реалния продажбен процес и конкретното устройство. Това може да е проста връзка към един фискален принтер или инфраструктура с множество обекти, централен ERP, локални bridge услуги и пълна проследимост.
Добрата интеграция премахва въпроса „Издадохме ли бона?“. Системата трябва да знае отговора. Ако искате да проверим вашия случай, изпратете модела на устройството и кратко описание на процеса през страницата за интеграция или проектния съветник.