Чешката EET 2.0 от 1 януари 2027 г.: какво трябва да правят собствените POS системи и киоските

Електронното отчитане на продажбите в Чехия се завръща. Президентът Петр Павел подписа закона за EET 2.0 на 17 септември 2026 г., а съобщението на Финансовата администрация е ясно за датата: задължението за отчитане на продажбите започва на 1 януари 2027 г. То обхваща контактните плащания между търговеца и клиента, включително всички плащания в брой. В брой, с карта, с телефон или с QR код: ако клиентът плаща лично или във вашия търговски обект, продажбата се изпраща към данъчната администрация в момента, в който се случва.

За повечето малки търговци това означава обновление от доставчика или безплатно държавно уеб приложение. За веригите със собствен касов софтуер, киоски за самообслужване или платежно приложение, с което персоналът обикаля залата, това е интеграционен проект, за който остават около 90 дни. Тази статия е за тях.

Какво се промени от първата EET

Първоначалната EET беше премахната през 2022 г. EET 2.0 запазва основната идея (всяка подлежаща на отчитане продажба се изпраща онлайн и държавата потвърждава получаването ѝ) и сваля голяма част от тежестта:

• Минимални данни. Старата система разделяше всяка продажба по ставки на ДДС. EET 2.0 изпраща една обща сума с включен ДДС, независимо от ставките.
• Без задължение за касова бележка. Търговците вече не трябва да издават бележка за целите на EET, а кодът за потвърждение не е задължително да фигурира на нея.
• По-тесен обхват. Отчитат се само контактните плащания между клиент и търговец; старата система обхващаше по-широк кръг плащания.
• Безплатна държавна възможност. MOJE eet, уеб приложение за най-малките предприятия, както и възможност за отказ, наречена EET OFF, за някои еднолични търговци на паушален данък.

Техническата промяна е по-голяма, отколкото подсказва списъкът. Транспортът е познат: SOAP 1.1 през HTTPS с подписи по WS-Security, както преди. Съобщението обаче не е. Новият интерфейс е версия 4.1, старият беше 3.1, а спецификацията посочва, че промените от 2026 г. „са несъвместими с предишната система". В презентацията от семинара за разработчици като премахнати са посочени кодът за сигурност BKP, флагът за опростен режим и позициите по ДДС. Старият код за EET е ориентир за инфраструктурата и нищо повече.

Какво попада в обхвата

Официалната страница за това кой трябва да отчита продажби поставя три условия: плащането е контактно или е плащане в брой, то е приход от стопанска дейност и не се прилага изключение.

Контактно плащане е налице или при личен контакт с вас или с вашия персонал, или във вашия обект или превозно средство във връзка със стоката или услугата. Презентацията от семинара казва направо, че второто правило е насочено към касите за самообслужване и обектите на самообслужване. Киоск във вашия магазин попада в обхвата, дори ако никой служител не докосва транзакцията. Плащането в брой винаги се отчита, дори извън вашия обект, с изключение на наложения платеж, събран от пощенска услуга.

Начинът на плащане няма значение. В брой, с карта, с QR код, банков превод или директен дебит, направени на мястото на продажба, криптоактиви, подаръчни карти, ваучери за храна и предплатени карти: всички са изброени.

Плащанията от разстояние са извън обхвата: онлайн магазин, платен през платежен портал, или фактура, която клиентът плаща от офиса си. Значение има как реално са се движили парите, а не какво пише във фактурата. Ако клиентът плати 200 CZK с карта на гишето и останалите 800 CZK с превод от вкъщи на следващия ден, отчитат се само 200-те CZK.

Вендинг автоматите, които сами по себе си са обект (официалният пример е кафемашината), са изключени, както и щандовете на самообслужване извън вашите обекти, където отчитането би било неприложимо на практика. Списъкът с изключения обхваща също публичните органи, банките, хазарта и енергетиката, наред с други.

Кой може да пропусне повечето от това

Микропредприятията могат да използват MOJE eet, което стартира на 1 декември 2026 г. На юнския семинар за разработчици то беше представено като решение за предприятия с до две регистрационни единици и двама служители. Едноличните търговци на паушален данък в първата група с приходи до 1 милион CZK могат да се откажат чрез EET OFF.

Търговците, които използват масов POS продукт, трябва да получат обновление от доставчика си. Попитайте кога излиза и какво става при прекъсване на връзката, след това се регистрирайте в данъчния портал и инсталирайте сертификата.

Всички останали трябва да продължат да четат: собствен или персонализиран касов софтуер, киоски, които сте изградили сами, платежни приложения за персонала или група, в която едно плащане може да принадлежи на две дружества.

Какво трябва да се изгради

Всичко е на страницата с документи за разработчици: описанието на интерфейса (английската версия не е задължителна), XSD и WSDL, примерни подписани заявки и сертификати за тестовата среда. Английското издание вече е версия 1.2a от 2 октомври 2026 г.; тя поправя една грешна максимална дължина на porad_cis в раздел 3.3.3.10, така че проверете ограниченията на полетата си спрямо нея.

Регистрационни единици и идентификатори на устройства

Всяко съобщение съдържа идентификатор на регистрационна единица. Създавате единиците (магазин, мобилен щанд, превозно средство за доставки) в DIS+, данъчния портал, и системата присвоява номер на всяка от тях. Веригите могат да импортират единиците масово, а промените трябва да се съобщават в срок от 15 дни. Вашата POS система има нужда от поддържано съответствие между всеки обект и идентификатора на неговата единица, както и от идентификатор на устройството с дължина до 20 знака, който е уникален в рамките на единицата.

Сертификати

Тук собствените системи обикновено губят време. Процедурата за сертификати описва стъпките:

• Двойката ключове се генерира от удостоверяващия орган на EET, а не на вашето устройство. Изтегляте защитен с парола PKCS#12 файл, достъпен до потвърждаване на изтеглянето, но за не повече от 30 дни.
• Файлът използва остарялото криптиране 3DES заради по-старите каси. Документът предупреждава, че може да не се зареди в OpenSSL 3 без legacy provider, и препоръчва файлът да бъде преопакован или ключът да бъде преместен в трезор за тайни.
• Сертификатите са валидни една година. Един сертификат може да обслужва едно или няколко устройства; колко да издадете, решавате вие.
• Подновяването може да се автоматизира чрез REST API: краткотраен JWT, подписан със сертификата, който се подновява, след това проверка на статуса на заявката, изтегляне и потвърждение. Удостоверяващият орган препоръчва подновяване две до три седмици преди изтичането. След като сертификатът изтече, пътят през API е затворен и някой трябва да го поднови ръчно.
• Защитата на частния ключ е законово задължение на данъчно задълженото лице. Един файл с ключ, копиран на четиридесет каси, е отнемане на сертификат, което само чака да се случи.

Съобщението с данни

Заглавната част съдържа нов UUID за всеки опит, времето на изпращане, флаг за първи опит и незадължителен флаг за проверка. Частта с данни съдържа EIČ на данъчно задълженото лице, идентификатора на единицата, идентификатора на устройството, пореден номер (до 25 знака, уникален за единицата и устройството), времето на продажбата със съответното отместване на часовата зона и общата сума в CZK с точно два знака след десетичната запетая. Две незадължителни суми покриват зареждането и използването на предплатени средства; още две полета покриват отчитането от името на друго данъчно задължено лице.

Отчитайте това, което действително е получено: сметка в брой от 78,90, закръглена на 79, се вписва като 79,00, а същата сметка, платена с карта: като 78,90. Сметка, платена отчасти с ваучери за храна и отчасти с карта, е едно съобщение с общата сума.

Подписване и изпращане

Всяко съобщение се подписва с XML Signature в заглавната част WS-Security: изключителна канонизация, хеш SHA-256, RSA-SHA256, сертификатът е приложен като BinarySecurityToken и се подписва само тялото на SOAP съобщението. Не добавяйте допълнителни заглавни части като Timestamp или WS-Addressing: съобщенията над 12 kB се отхвърлят, а съобщение, което прилича на атака, може изобщо да не получи отговор. TLS 1.2 или по-нова версия е задължителна и клиентът трябва да проверява сертификата на сървъра. Продукционната среда използва балансиране чрез DNS, така че разрешавайте името на хоста при всяка връзка, вместо да фиксирате IP адрес.

От версия 1.2 крайната точка поддържа CORS, така че POS система в браузъра може да я извиква директно. Решете къде ще живее частният ключ, преди някой да е написал този JavaScript.

Отговори, прекъсвания и правилото за 48 часа

Валидното съобщение получава синхронен отговор с 39-знаков код за потвърждение (POK), подписан от данъчната администрация. Проверете този подпис и съхранете POK заедно с продажбата. Невалидното съобщение получава код за грешка; -1 означава временна неизправност, така че изпратете отново по-късно. По-малките проблеми се връщат като предупреждения, едно от които се появява, когато времето на продажбата изпреварва часовника на сървъра с повече от два часа. Часовниците на киоските се разминават. Синхронизирайте ги.

Времето за изчакване на отговора задавате сами, но не по-малко от две секунди. Ако POK не пристигне навреме, продажбата отива в опашка. Според презентацията от семинара повторният опит използва оригиналното тяло с нова заглавна част: нов UUID, флаг за първи опит със стойност false, ново време на изпращане и оригиналното време на продажбата. Изпраща се веднага щом връзката се възстанови и не по-късно от 48 часа след продажбата. Задължението не отпада и след 48-те часа: закъснялото съобщение пак се дължи.

Затова опашката трябва да оцелява след рестарт и да вдига тревога доста преди да изтекат 48-те часа. Още един капан: ако сертификатът изтече, докато продажби чакат в опашката, те трябва да бъдат подписани с валиден в момента сертификат.

Връщания, корекции и дубликати

Връщането или анулирането е ново съобщение с отрицателна сума, с текущата дата и без връзка с оригинала. Корекцията е или анулиране, последвано от правилното съобщение, или едно-единствено съобщение с разликата. Дубликатите се разпознават по шест полета (EIČ, единица, устройство, пореден номер, време на продажбата и обща сума), така че повторен опит със същото тяло е безопасен. Повторен опит, при който поредният номер се генерира наново, е втора продажба.

Касови бележки

По-малко работа, отколкото при първата EET: не се изисква бележка за целите на EET, а POK не е задължително да фигурира на нея. Премахнете кода, който задържа отпечатването, докато пристигне POK. Когато издавате бележки по силата на законодателството за защита на потребителите, поддържайте поредния номер за EET в съответствие с номера на бележката; спецификацията отбелязва, че на практика двата обикновено съвпадат.

Гранични случаи, на които се натъкват веригите

• Предплатени карти, гривни и портфейли: отчитат се зареждането и всяко плащане, с попълнени допълнителни полета за суми.
• Едно плащане, две данъчно задължени лица: примерът от презентацията с бензиностанцията (горивото се продава от името на друго дружество, кафето за ваша сметка) изисква две съобщения, всяко с данните на съответното данъчно задължено лице.

Графикът

• 5 юни 2026 г.: публикувана е техническата документация.
• 1 юли 2026 г.: отворена е тестовата среда (playground). Между 26 юли и 26 август тя е обработила 170 389 тестови транзакции от 624 клиентски IP адреса, като 94,6% от тях са обработени успешно.
• 1 ноември 2026 г.: EET в DIS+, регистрационни единици и продукционни сертификати.
• 1 декември 2026 г.: стартира MOJE eet.
• 1 януари 2027 г.: задължението започва за всички едновременно, без поетапно въвеждане.

Официалният график нарича януари пилотен месец, след което добавя, че това вече ще бъде стандартно отчитане. В по-ранно съобщение пилотният период беше описан като доброволен. Докато това не бъде изяснено, планирайте да изпращате реални съобщения от 1 януари.

Законът беше обнародван в Сборника със закони на 7 октомври 2026 г. като Закон № 180/2026 Sb. Той влиза в сила на 1 януари 2027 г.; седем от разпоредбите му влязоха в сила на следващия ден след обнародването.

План за 90 дни

Октомври: обхват и разработка.

1. Избройте всяко място, където парите сменят притежателя си: каси, киоски, преносими устройства, процеси за поръчка от масата, платени в обекта, вашите собствени шофьори, които събират пари в брой. Свържете всяко от тях с данъчно задължено лице и с бъдеща регистрационна единица.
2. Изберете архитектурата: подписване на всяко устройство или една услуга, която подписва и поддържа опашката за всички. Системата приема и двата варианта. За верига централизираният обикновено печели: едно хранилище за ключове, една опашка, едно място за наблюдение.
3. Изградете модула за съставяне на съобщения, модула за подписване и опашката спрямо тестовата среда със споделените тестови сертификати. Валидирайте всяко съобщение спрямо XSD в CI.

Ноември: продукционни идентификационни данни.

4. От 1 ноември активирайте EET в DIS+, създайте единиците (с масов импорт, ако са много) и издайте продукционните сертификати. Сложете ги в трезор за тайни, а не на USB флашки.
5. Спецификацията определя 1 ноември 2026 г. като най-ранната валидна дата на продажба в продукционната среда. Изпращайте съобщения в режим на проверка с реалния сертификат: те тестват цялата верига, без да отчитат продажба.
6. Завършете връщанията, процесите с предплатени средства, подновяването на сертификатите и известията за възрастта на опашката.

Декември: репетиция.

7. Внедрете в един обект. Извадете мрежовия кабел в обедния пик и наблюдавайте как опашката се изпразва след това.
8. Направете тест под натоварване на най-натоварения си час през модула за подписване.
9. Замразете промените преди коледния пик. Обяснете на персонала как изглежда прекъсването; ако опашката работи, те не правят нищо.

Януари: пилотният месец.

10. Правете равнение всеки ден. Сравнявайте сумите от POS системата с агрегираните суми в DIS+, където можете да поискате и подробен CSV експорт, съдържащ всеки POK.

Къде да намерите помощ

Изграждаме и променяме POS интеграции: модула за съставяне на съобщения и модула за подписване, опашката при прекъсвания, съхранението и подновяването на сертификатите, съответствието с единиците и равнението спрямо DIS+. Когато касовият софтуер е стар, а авторите му отдавна са продължили напред, работата започва от нашата услуга за поддръжка на наследени системи. Ако вашият екип познава системата, но не му достигат ръце преди януари, можем да добавим разработчици към него.

Ако управлявате собствени каси или киоски в Чехия и все още не сте изпратили съобщение до тестовата среда, пишете ни на office@c9group.dev.