Въпроси и отговори касови апарати – НАП

Обучение за работа с Ками

Въпрос

Подаването на обобщен оборот от ръчните касови бележки от кочан няма ли да дублира оборота на задълженото лице? Очаква се да се подава натрупаният с РКБ оборот при възстановяване работата на ФУ, но лицето по чл. 3 вече е регистрирало този оборот посредством ръчните касови бележки; новият тотален бон с общия оборот от РКБ ще му дублира оборота и съответно задълженията пред фиска.

Регламентираният с чл. 40, ал. 5-7 ред е за подаване чрез ФУ към НАП на отчетения с касови бележки от кочан оборот и не следва да води до дублиране на оборота на задълженото лице. Чрез издаване на фискален бон със сумарния оборот, отчетен при работа с касови бележки от кочан, регистрираните суми от продажби само се предават по дистанционната връзка към НАП. Не следва да се получи дублиране на оборота на лицето.

Въпрос

XML описанието на бона не допуска ID номер на чужденец (има избор само между БУЛСТАТ, ЕГН, ЛНЧ и служебен номер). Какво се прави в такива случаи? Това е честа практика в много от ритейлърите – издаване на фактура на чужденец/чужда компания; техните номера не попадат в нито една от 4те категории, предвидени за предаване на този номер към сървъра на НАП.

При издаване на разширен фискален бон – фактура на чужденец, в елемента за тип на ЕИК следва да се вписва стойност „2“.

Въпрос

Как се излиза от положението, зададено в отговора на НАП сървъра на FBDATA xml (данни от фискален или сторно бон)? НАП сървърът може да върне таг <Status>2</Status>, т.е. грешка номер 2, която е „Грешен БУЛСТАТ/ТИП“. Т.е., ако СУПТО е подало на ФУ валиден (по формалната проверка) БУЛСТАТ, но лицето не е регистрирано в Търговския регистър, или пък СУПТО подава грешен тип (подава ЕГН, а подава като тип БУЛСТАТ)? Ако се върне такава грешка към ФУ, той не може да направи нищо – няма как да се редактира вече бона, защото е записан в КЛЕН; няма как да се изтрие от опашката, защото това ще създаде неконсистентност. Според Вас сървърът на НАП трябва да приеме каквото подаде СУПТО към ФУ.

При приемане на данни от фискални бонове не се прави валидация на полетата за ЕИК на получател на документ и тип на ЕИК, тъй като те са опционални, а и именно поради наличието на фактури, които се издават на чужденци, тези полета може да не са попълнени със значещи за НАП стойности. В тази връзка сървърът на НАП ще приеме каквото е подадено от СУПТО към ФУ.

Въпрос

Трябва ли по дистанционната връзка с FBDATA XML да се подават и канцелираните бонове? Това са бонове, които са започнати в софтуера и във ФУ, но по някаква причина не са приключени (например недостиг на платежни средства от страна на клиента и отказване на цялата транзакция, или паркиране на бона за последващо разплащане от друга каса или след известно време и т.н.)? Според Приложение № 1, раздел ІІІб, т.1, буква „е“, канцелираните бонове трябва да се предават („всяка фискална касова бележка за извършена продажба, издадена и записана в КЛЕН“). Конкретният въпрос е породен от това, че канцелираните бонове реално не са фискални касови бележки за извършена продажба – продажбата е пропаднала поради някаква причина.

На основание чл. 25, ал. 4 от Наредба №Н-18/2006 г. данни от всяка фискална касова бележка се предават автоматично от ФУ/ИАСУТД по дистанционната връзка към НАП съгласно Приложение №17.

Въпрос

Как НАП си гарантира, че структурираният експорт от КЛЕН на ФУ по Приложение 34 съдържа коректна информация? Файлът се подписва от сервизен техник след като е направен експортът (и то ако експортът се прави от КЛЕН – има и хипотеза по Приложение 29). Добрите практики водят към нужда от подписване на експортния файл от самия принтер, за да се гарантира невъзможността за промяна на информацията от сервизния техник.

Считам, че при възникване на съмнения за манипулиране на експорта от КЛЕН може да бъде направен повторен експорт, тъй като лицето е задължено да съхранява КЛЕН в сроковете по чл. 38 от Данъчно осигурителния процесуален кодекс (ДОПК). Предложението може да бъде обсъдено при подготовка на бъдещи изменения в Наредба №Н-18/2006 г.

Въпрос

Какви може да са документите по Приложение 1, Раздел III, т. 3, буква „б“: документи във връзка с извършване на служебни операции, касаещи отчетността на фискалното устройство?

Изразът „документи във връзка с извършване на служебни операции, касаещи отчетността на фискалното устройство“, касае всички операции, свързани с отчетността на устройството, например: дубликат на фискален бон, документ за доставка на гориво, документ за прекъсната/възстановена връзка, документ, отпечатван с основните данни на електронната система с фискалната памет, отчет по оператори, отчет по артикули, отчет по департаменти, дневен финансов отчет без нулиране, документи за броячите на средствата за измерване и на нивомерната измервателна система и др.

Въпрос

Защо не се добави тип на ФУ 12 ЕКАФП за СУПТО и 22 ФУ за СУПТО? Ако са налични тези номенклатури в RREG XML-а за регистрация на ФУ, ще е ясно, че тези устройства ВИНАГИ подават реквизита по чл.26, т. 17 УНП.

Предложението ще бъде обсъдено при подготовка на бъдещи изменения в Наредба Н-18/2006 г.

Въпрос

Кога ще е наличен тестовият сървър с всичките му функции по преглед на получените данни? Как може да се тестват разработваните устройства при липса на обратна връзка?

Тестови сървър за тест на съобщенията съгласно последните изменения в   Наредба №Н-18/2006 г. е публикуван на 8.10.2018 г. На всяко изпратено съобщение от ФУ/ИАСУТД НАП връща отговор, който съдържа статус и грешка, при наличие на такава, които се получават от изпращащата страна. Актуализирано приложение, през което да са видими получените в НАП съобщения съгласно новите изисквания на Наредба №Н-18/2006 г. през потребителски интерфейс, е публикувано и достъпно от 26.10.2018 г.

Въпрос

Защо не е предвидено в публикуваните на 08.10.2018 XML схеми пакетно изпращане на данните от фискалните бонове към сървъра на НАП? Изпращането по единично на всеки бон, и то на интервали от 5 минути (съгласно изискванията на актуалната наредба при предаването на всеки бон трябва да изчакваме до 60 секунди за отговор от сървъра на НАП, т.е. има хипотеза, в която за 5 минути можем да изпратим само 5 бона) може да доведе до блокиране работата на ФУ при търговците с повече клиенти, а и прави неизпълнимо изискването към ИАСУТД за предаване на боновете един по един.

XML схеми са актуализирани с възможност за пакетно изпращане на данните от фискалните бонове към сървъра на НАП, т.е. в едно съобщение по няколко бележки. На 23.10.2018 г. е публикувана актуализация на XSD схемите.

 

Въпрос

По задължението за въвеждане на продажбите, реализирани с касови бележки от кочан при блокирало ФУ и хипотезата за работа повече от 24 часа с ръчни касови бележки (чл. 40, алинея 6). Как ФУ, и съответно НАП, ще разберат кой сумарен оборот към кой точно ден се отнася? Не трябва ли при такива сумарни бонове СУПТО да предаде към ФУ за кой ден се отнася оборотът, за да може поне ФУ да генерира ZT XML-а си с коректен таг <ZD>?

Редът за регистриране във ФУ на оборота от касови бележки от кочан е изчерпателно описан в чл. 40, ал. 6 от Наредба №Н-18/2006 г.

Въпрос

Чл. 39, ал. 1 При продажби на течни горива в/от обекти, които са изцяло на самообслужване, дневният финансов отчет се генерира автоматично и се записва във фискалната памет и в КЛЕН за всеки ден (за всеки 24 часа). Лице по чл. 3, използващо ЕСФП, отпечатва пълен дневен финансов отчет с нулиране и запис във фискалната памет за всеки ден, през който в ЕСФП са регистрирани продажби и/или зареждания на течни горива. Какво означава това – Терминал на самообслужване в бензиностанция може ли само да генерира отчета, без да го печата (ако има нужда от разпечатване, това да се случва от КЛЕН)?

Съгласно действащата нормативна уредба задължително се отпечатва дневен финансов отчет с нулиране и запис във фискалната памет за всеки ден, през който в ЕСФП са регистрирани продажби и/или зареждания на течни горива. Разпоредбата не прави изключения според вида на ЕСФП, напротив задължава всички лица, използващи ЕСФП за отчитане на продажби, да отпечатват отчет.

Въпрос

В момента имаме складов софтуер, софтуер за издаване на фактури и касов апарат, който работи самостоятелно и не е свързан с нито един от двата софтуера. Нямаме търговски обект и нашите продажби се извършват в офиса ни. Когато продаваме стока я изписваме от складовия софтуер, издаваме фактура от фактурния софтуер, пускаме касов бон от касовия апарат и го прикачаме към фактурата. С влизане в сила на новата Наредба Н-18/2006 г. трябва да си сменим касовия апарат, тъй като от фирмата доставчик ни казаха, че сегашният няма да отговаря на изискванията на новата наредба. Въпросът ни е следният:

Складовият софтуер и фактурният софтуер водят ли се “Софтуер за управление на продажбите” според Наредба Н-18/2006 г.? И ако да, кой от двата?

Наредба Н-18/2006 г. не борави с понятията „складов софтуер“ и „фактурен софтуер“, доколкото те могат да имат различно значение и да включват различна по обхвата си функционалност.

Водещо е определението за софтуер за управление на продажби в търговски обект, дадено в §1, т. 84 от Допълнителните разпоредби (ДР) на Закона за данък върху добавената стойност (ЗДДС), а именно софтуер за управление на продажби в търговски обект“ е всеки софтуер или модул от софтуер, независимо от технологиите за реализацията му, използван за обработка на информация за извършване на продажби на стоки и/или услуги в търговски обект, за които е налице задължение за издаване на фискален бон. Определението за „управление на продажбите“ чрез използване на софтуер за управление на продажби в търговски обект, съдържащо се т. 19, §1 от ДР на Наредба №Н-18/2006 г., уточнява, че това е автоматизирана обработка на информация за извършване на продажби на стоки или услуги, включващо проследяване на движението на стоките или изпълнението на услугите от заявяването им до тяхното предоставяне и/или извършване на плащане.

Задължително изискване, заложено в определението, е софтуерът да се използва в търговски обект, в който се извършват продажби и е налице изискване за издаване на фискални бонове. Във вашия случай търговски обект се явява офисът Ви. Друго изискване съгласно определението е обработката на информацията да бъде автоматизирана. Това означава, че софтуерът автоматизирано обработва и съхранява в база данни въвеждана информация за количество, вид и продажна цена на заявени от клиент стоки и/или услуги и отразява тяхното предоставяне/заплащане. В случай че упоменатите от Вас софтуери притежават посочените характеристики, те се явяват софтуери за управление на продажбите в търговски обект (СУПТО) и трябва да отговарят на всички изисквания на Наредба №Н-18/2006 г. Няма пречки СУПТО да има и други функционалности, извън посочените, както и да подава/получава информация към/от други софтуерни модули/продукти.

Въпрос

Трябва ли новият касов апарат да се свързва с някой от двата софтуера или може да си работи самостоятелно, както досега?

Съгласно изискванията на Наредба Н-18/2006 г., ако в търговски обект се използва софтуер за управление на продажбите, той задължително трябва да е свързан и да управлява фискалното/ите  устройство/а в обекта.

Въпрос

Ако новият касов апарат работи самостоятелно и не е свързан с нито един от двата софтуера, тогава трябва ли да се регистрира в НАП някой от двата софтуера като “Софтуер за управление на продажбите”?

Ако касовият апарат продължи да работи самостоятелно, без да е свързан със използвания в обекта СУПТО, това със сигурност ще бъде нарушение на изискванията на Наредба №Н-18/2006 г. Съгласно чл. 118, ал. 18 от ЗДДС лице, което използва софтуер за управление на продажби в търговски обект, е длъжно да използва само софтуер, който е включен в поддържания от НАП публичен електронен списък на софтуерите за управление на продажби в търговските обекти, за които е декларирано съответствие с изискванията.

Въпрос

Имаме аналогичен казус и с наши клиенти, на които сме разработили складов софтуер, в който има модул и за фактуриране. Те като правят продажба от склада, изписват от количествата от софтуера и със същия софтуер издават фактура. При тях също касовият апарат не е свързан със софтуера и работи самостоятелно. Въпросът при тях е следният:  След влизане в сила на новата Наредба Н-18, този наш софтуер води ли се като “Софтуер за управление на продажбите” и трябва ли да го регистрираме в НАП като разработчици?

Аналогично на отговора на Въпрос №1 по-горе, посоченият софтуер попада в обхвата на определенията за „софтуер за управление на продажбите“ съгласно §1, т. 84 от ДР на ЗДДС и „управление на продажбите“ съгласно §1, т. 19 от ДР на Наредба Н-18/2006 г. Съгласно чл. 52а от наредбата софтуерът трябва да отговаря на изискванията, съдържащи се в приложение №29 на наредбата, а производителят му следва да подаде декларация по чл. 118 ал. 14 от ЗДДС, както и информация за софтуера съгласно чл. 52в, ал. 2 от Наредба Н-18/2006 г., описана в приложение №31.

 

Въпрос:

Търговец води наличността и продажбите си с Microsoft Excel, пуска фактури през Софтуер за фактури и пуска касови бележки през касов апарат. Води ли се Microsoft Excel “софтуер за управление на продажбите” според Наредба Н-18/2006 г.? И ако да, как ще се свърже касовият апарат с Microsoft Excel?

В случай че на основата на Microsoft Excel е създаден приложен софтуер, притежаващ посочените в отговора на Въпрос № 1 характеристики, той се явява СУПТО и следва да отговаря на изискванията на Наредба №Н-18/2006 г.

 

В процеса на подготовка на заданията и превеждането на софтуерите, които „…………………..“ произвежда и поддържа на българския пазар, възникна следния крайъгълен, особено за чуждите разработчици въпрос, касаещ изпълнението на изискванията на Наредба №Н-18/2006 г., Приложение №29, точки 16-19. Голяма част от нашите клиенти използват т.нар. в Приложение №29, т. 20 – интегрирана ИС, т.е. софтуера, работещ в обекта (подлежащия на деклариране СУПТО), няма необходимите възможности да съхранява данните в обекта за 11 години (срока по чл. 38 от ДОПК). В част от случаите дори този софтуер няма никакви данни за доставките. Най-общо се наблюдават следните модули в такъв вид реализация на бъдещия СУПТО:

  1. касов модул – получава цени и артикули, както и готови промоции от Централизиран софтуер (един за всички държави, обикновено SAP ERP или друга подобна ERP система); изпраща всяка транзакция, включително и продажбите (фискални бонове, фактури, сторно бонове, кредитни известия) към централно хранилище на данни – Data Warehouse; съхранява въпросните транзакции за 1 до 7 дни (зависи от конкретния софтуер);
  2. бекофисен модул – менажира касиерите като създава касиери; изтрива касиери (ще трябва да се забрани?); променя касиерски данни ( ще трябва да се забрани подмяната на имената?); отчита касиерите; в някой случай служи за създаване на доставки, а в други – не; има много ограничен набор справки, нужен само на нивото на мениджъра на касиерите и/или на управителя на обекта: касиерски разлики; оборот за деня; наличност на парични средства; съхранява БД от всички каси за период от 30 до към 400 дни (различен период за различните софтуери);
  3. транспортно приложение, което комуникира на файлово ниво данните по  т. 1 и т. 2 към т. 4 (Централизираната система)
  4. централизирана система, обикновено SAP, която: а) получава всички транзакции в реално време или квази реално време (на всеки 5 транзакции, на всеки 5 минути) от всички каси и всички магазини; б) може да има модул за заявки и доставки (този модул обаче може и да е външен за системата, т.е. да се явява т.5 в това писмо); в) обобщава въпросната информация от 4а и 4б аналитично и синтетично; г) подготвя заявки към доставчици и централен склад на базата на наличностите на обектите.

При всички случаи, в обекта продажба по дефиниция няма: данни за наличността на стоките, данни за минали периоди, надвишаващи текущия един или няколко месеца, доставни цени, възможност за манипулиране на създадените и процеснати (изпратени към централната система) данни, място за архиви. При всички клиенти с подобна организация на софтуера за продажба на данните от точки 16-19 на Приложение №29 от Наредба №Н-18/2006 г. могат да се получат от т.нар. Интегрирана ИС (описана в т. 4 тук).

Въпрос:

В случай че всички данни са налични в Data Warehouse (виж т.1.Ь), защо е необходимо да се предоставя при Деклариране на софтуера информация за структурата на БД и туул за достъп до тях (изпълним файл и сорс код по чл. 528, (2). 3) за самото СУПТО; тези изисквания могат да бъдат спазени формално — да се предоставят при деклариране, но де факто няма да вършат никаква работа за органите на НАП; на всичко отгоре, СУПТО има БД само с дневни данни на касите, и БД с няколкомесечни данни на БО; тези БД са различни, т.е. на деклариран софтуер ще трябват по две описания на структурата и по два тула … Не е ли по редно тула за достъп до БД и описанието на структурата на тази БД в описания от мен случай да касаят т.нар. Data Warehouse?

Изискванията на чл. 52в, ал. 2, т. 3 от Наредба № Н-18/2006 г. са задължителни за всички производители, разпространители на СУПТО и в тази връзка е задължително предоставянето на описаните от Вас файлове.

Въпрос:

Възможно ли е достъпът до Интегрираната ИС, която съдържа данните по т.16-19 да е само от централния офис в България на всеки от тези клиенти, или трябва да е наличен във всеки от обектите (само от БО)?

Възможно е. Наредбата не ограничава предоставянето на достъпа до данните по т.16-19 от наредбата да бъде извършено от централен офис на територията на страната.

Въпрос:

Трябва ли въпросната Интегрирана ИС да има графичен интерфейс за одиторите на НАП (одиторски профил), или е достатъчно да изпълнява функциите по т.16 — 19 от Приложение 29 и да генерира нужните визуализации (view) и експорти (в тези случаи ще се постараят разработчиците да няма нужда от архиви, т.е. данните да са налични в суров вид за 11 години, за да не се налага Декларираният софтуер през неговия интерфейс да дава достъп до въпросните архиви).

Достъпът чрез конфигурирания в интегрираната ИС „одиторски профил“ до информацията по т.16-19 от наредбата, следва да позволява пълен достъп до всички данни и функционалности в посочените разпоредби.

 

Въпрос:

Какво се има предвид под термина „нефискални печатащи устройства“?

На основание чл. 7 от Наредба № Н-18/2006 г. лицата по чл. 3 са длъжни да монтират, въведат в експлоатация и използват регистрирани в НАП ФУ/ИАСУТД от датата на започване на дейността на обекта. Предвид това в търговските обекти не се допуска работа на нефискализирани фискални устройства. Допустимо е използването на нефискални печатащи устройства, различни от нефискализирани фискални устройства, като например етикетни и баркод принтери, мрежови офис принтери, мултифункционални устройства и др.

 

Защо отново трябва да си сменям касовия апарат?

Въведените през  месец септември на 2017 г. и  през 2018 г. изменения и допълнения на наредбата регламентираха изисквания за нови функционални възможности на фискалните устройства. Целта на тези промени е да се елиминират възможностите за манипулиране на устройствата при използването им, като очакванията са да се препятства неотчитането на извършваните продажби на стоки или услуги.

 

Какво трябва да направя?

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

 

  1. сервизната организация, с която имате сключен договор за техническо обслужване и ремонт;

 

  1. производителя или вносителя на съответния модел фискално устройство;

 

  1. от интернет страницата на НАП.

 

На второ място, трябва да проверите в какви срокове сервизната  организация или производителят/вносителят може да достави или преработи софтуера на фискалното Ви устройство.

Какви са сроковете?

Март 2019 г. – изтича срокът за всички, които са регистрирани по ЗДДС, с изключение на лицата, използващи ЕСФП и ИАСУТД. Юни 2019 г. – изтича срокът за нерегистрираните по ЗДДС лица и лицата, използващи ЕСФП.

 

Декември 2019 г. – изтича срокът  лицата, които за отчитане на продажбите използват  интегрирани автоматизирани системи за управление на търговската дейност.

 

Защо да бързам, срокът ми изтича след месеци?

 

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

 

Какво ще стане, ако работя с  фискално устройство, което не отговаря на новите изисквания?

Неспазването на заложените в Наредба Н-18/2006 г. срокове неминуемо ще доведе до запечатване на търговски обекти и налагане на глоби и/или имуществени санкции, което никога не е било цел на Национална агенция за приходите. В тази връзка НАП създава необходимата организация за безпроблемното и своевременно реализиране на промяната.

 

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

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

Описаната от Вас функционалност на софтуера попада в обхвата на определенията  за „софтуер за управление на продажбите“ съгласно §1, т. 84 от Допълнителните разпоредби (ДР) на Закона за данъка върху добавената стойност (ЗДДС) и „управление на продажбите“ съгласно §1, т. 19 от ДР на Наредба Н-18/2006 г.  В случай, че този софтуер се използва в търговски обекти, в които съгласно чл. 3, ал. 1 от Наредба Н-18/2006 г. е налице задължение за издаване на фискален бон, т.е. извършват се  например плащания в брой, с дебитна или кредитна карта и др., то той трябва да бъде свързан с фискално/и устройство/а (ФУ). Фактът, че към момента няма разработена функционалност за връзка към ФУ, не може да бъде причина за изключване на софтуера от изискванията на Наредба Н-18/2006 г. и такава функционалност трябва да бъде разработена.

 

Ако не е задължително свързването му, изискванията от приетата наредба важат ли за него?

Изискванията, посочени  в Приложение №29 от Наредба Н-18/2006 г., важат за софтуера при условията, посочени в отговора на Въпрос №1.

 

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

Доколкото Вашият софтуер отговаря на определението за софтуер за управление на продажбите, той следва задължително да бъде свързан и да управлява въведените в експлоатация ФУ в обекта.

Не се допуска продажбите да се отразяват в софтуер за управление на продажби, вкл. да се издават фактури, а издаването на ФБ да бъде отделено.

 

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

По смисъла на определението за търговски обект, съдържащо се в §1, т. 41 от  ДР на ЗДДС, електронният магазин е търговски обект, от който се извършват продажби. Когато лицето, извършващо продажби чрез електронен магазин, използва за дейността си софтуер за управление на продажбите и за извършваните продажби е налице задължение за издаване на ФБ съгласно чл. 3, ал. 1 от Наредба Н-18/2006 г.,  софтуерът трябва да отговаря на изискванията на наредбата, респективно, той трябва да бъде свързан с ФУ.

 

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

Специфични изисквания към лицата, които извършват продажби чрез електронен магазин, се съдържат в Глава седма „г“ на Наредба Н-18/2006 г. Съгласно чл. 52н те „са длъжни да съхраняват в сроковете по чл. 38, ал. 1 от ДОПК създаваната чрез софтуера на електронния магазин информация (текуща база данни и архивни копия на базата данни) и при поискване от органите по приходите да осигурят достъп до нея с възможност за експорт и копиране на данни.“ Няма дефинирана конкретна структура, в която да се експортират данните от базата данни на електронния магазин.

По отношение на софтуера за управление на продажбите, когато такъв се използва от лицето, извършващо продажби чрез електронен магазин, са приложими всички изисквания, съдържащи се в Приложение №29 на Наредба Н-18/2006 г.

 

В публикуваната структура на КЛЕН експорта, Приложение 34, т.4, по описания в Наредбата експорт в табличен вид не фигурират някои важни събития от бона, например отстъпки, надбавки, войдове, видове плащания и т.н. Ето и конкретни въпроси:

  1. Очаква ли се дадените отстъпки да се включат в експорта като се отнеме от оборота на съответния артикул (което би променило идеята за КЛЕН експорт (ударението е върху КЛЕН), а ще стане обикновен експорт на данни от ФУ).

Не се очаква експорт на всички данни от ФБ, а само на посочените в приложението. При фискалните бонове (ФБ) с включени отстъпки, надбавки и войдове няма  да има равнение между стойността на стоките (количество * единична цена) и общата сума на ФБ. В хода на контролни производства „липсващите“ в структурирания експорт елементи от бона ще се проверяват в базата данни на софтуера.

  1. На всеки ред ли очаквате всичката информация (поне така е описано, или ще има заглавен ред с ФДРИД, УНП, номер на бон, следващи редове със самите стоки, и закриващ ред с данни за плащанията и тоталите, номера на оригинални документи, ЕИК и други ?

На всеки ред се очаква описаната информация. Изискването е формулирано по този начин с оглед улеснено последващо зареждане и анализ на експортираните от КЛЕН данни в специализиран софтуер, използван от органите на приходите в НАП.

  1. Може ли да публикувате примерен бон с няколко артикула, няколко платежни средства, с отстъпки и надбавки, поне един войд, както и структурирания експорт на този бон ?

………..

Как НАП си гарантира, че структурираният експорт от КЛЕН на ФУ по Приложение 34 съдържа коректна информация ? Файлът се подписва от сервизен техник след като е направен експортът (и то ако експорта се прави от КЛЕН – има и хипотеза по Приложение 29, чл.  ). Добрите практики водят към нужда от подписване на експортния файл от самият принтер, за да се гарантира непромяната на информацията от сервизния техник.

Считаме, че при възникване на съмнения за манипулиране на експорта от КЛЕН може да бъде направен повторен експорт, тъй като лицето е задължено да съхранява КЛЕН в сроковете по чл. 38 от ДОПК. Предложението може да бъде  обсъдено при подготовка на бъдещи изменения в Наредба Н-18/2006 г.

 

Ако УНП е задължителен реквизит (съгласно чл. 26, т.17) при използване на СУПТО, как ще се инсталират във времето новите ФУ и СУПТО (говорим за периода преди 31.03.2019)? Как ще може да работи новият тип ФУ без инсталиран СУПТО (с досегашния недеклариран софтуер), как може да работи СУПТО без новите принтери ? Новите типове ФУ ще очакват УНП и ако не го получат, няма да позволят отварянето на ФБ; от друга страна, СУПТО ще предава команда за отваряне на бон с УНП и ще получава грешка от старото ФУ (невалиден параметър). Единственият вариант, за който се сещам, е да се направят ФУ да изискват УНП като задължителен реквизит на бона САМО след първо получаване на УНП; т.е. да може да се инсталират ФУ от новия тип и да не изискват УНП, докато СУПТО не бъде инсталиран в обекта.

Новият тип ФУ ще трябва да може да работи и без софтуер за управление на продажбите в търговски обект (СУПТО), т.к. не всички търговци ще използват СУПТО.

СУПТО няма да може да работи без новите принтери. Това означава, че търговците, които трябва да приведат дейността си в съответствие с наредбата в определения срок –  31.03.2019 г. или 30.06.2019 г., ще трябва да координират закупуването на ново/и ФУ с инсталирането на новия софтуер.

Как ще се случи това: Когато софтуерът е част от или е свързан с интегрирана информационна система за управление на продажбите/търговската дейност на лицето по чл. 3 и използваната технология за реализацията му не позволява изпълнението на всички или на част от изискванията по т. 16, 17, 18, и 19, изпълнението на тези изисквания следва да бъде осигурено чрез функционалността на интегрираната система. Голяма част от СУПТО са просто касови програми, работят само с дневни бази и получават номенклатурата си, цените от централизирани системи (SAP, MS NAV, AS 400 etc.). Тези касови програми нямат модули за заявки, доставки, промоции  и други. Означава ли новият текст в наредбата, че на тези централизирани системи SAP, MS NAV, AS 400 и други им се вменява изпълнението на т.т.16-19,. без тези софтуери да подлежат на деклариране ?!

Именно поради използването в практиката на т.нар. „касови програми“, които са с твърде ограничена функционалност, Наредба Н-18/2006 г. допуска: „Когато софтуерът е част от или е свързан с интегрирана информационна система за управление на продажбите/търговската дейност на лицето по чл. 3 и използваната технология за реализацията му не позволява изпълнението на всички или на част от изискванията по т. 16, 17, 18, и 19, изпълнението на тези изисквания следва да бъде осигурено чрез функционалността на интегрираната система.“ (Приложение №29, т. 21 от Наредба Н-18/2006 г.)

В случай, че „интегрираната система“ не попада в обхвата на определението за „софтуер за управление на продажбите“ съгласно §1, т. 84 от Допълнителните разпоредби (ДР) на Закона за данъка върху добавената стойност (ЗДДС), то за нея не се изисква подаване на декларация съгласно чл. 52б, ал. 1 от Наредба Н-18/2006 г.

 

Не става ясно как се процедира при подмяна на ФУ от една каса на друга, в обект с повече от една каса, и формираният от СУПТО УНП. Според т.9 от Приложение 29, третата част от УНП, 0000001 в примера от наредбата е 7-разряден пореден номер на продажбата, формиран поотделно за всеки индивидуален номер на ФУ. Т.е. в описаната от мен хипотеза, ако ФУ бъде преместен от една каса на друга, то новата каса ще трябва да си нулира поредния номер на продажбата и да почне отново от номер 0000001; така обаче, ако касиерът в двата случая е един и същ, ще има дублиране на номерацията на боновете, издавани от едната (в момента) и от другата (в минал период) каса;

Въпросът се нуждае от уточнение.

Ако под „каса“ се разбира работно място в даден търговски обект, то преместването на фискално устройство от едно работно място на друго не е свързано с нулиране на номерацията на УНП и не изисква такова. Софтуерът, който управлява фискалните устройства, би трябвало да се „обърне“ към съответното ФУ в примера и да генерира следващ уникален номер на продажба, т.е. последният УНП на предишното работно място плюс „1“.

 

Документите Сторно и Кредитно известие трябва ли да имат УНП за самия документ или само да цитират УНП на оригиналния документ, който коригират ?

Посочените документи следва да съдържат УНП на продажбата, във връзка с която се издават, т.е. „УНП на оригиналния документ“.

 

По хипотезата за паркираните бонове – понеже те ще съдържат и УНП, трябва ли при приключване на деня (преди Z-отчет) тези транзакции да бъдат окончателно анулирани, или могат да се прехвърлят и за следващ ден ? Ако канцелираните бонове не се предават по дистанционната връзка, как ще се отразят дупките в УНП на сървъра на НАП ? Ако се предават канцелираните бонове по дистанционната връзка, следва да има флаг в XML-а за този статус на бона …

При изменението на Наредба Н-18/2006 г. е отчетено, че за някои бизнеси е норма откриването и приключването на продажбите да не се случват в един и същи ден. Поради това, в случай че има открита продажба, която не е приключила към края на деня,  няма пречка да бъде издаден Z-отчет без да е необходимо продажбата да бъде анулирана.

В Наредба Н-18/2006 г. няма термин „канцелиран бон“. Вероятно се има предвид  Сторно  ФБ, който се предава  към сървър на НАП. Структурата на Сторно ФБ е описана в Наредба Н-18/2006 г., Приложение №17, т. 13а и т. 14а.

В случай, че се има предвид анулирана продажба, при която софтуерът „постъпково“ е записвал в КЛЕН информация за отделните стоки, но поради анулирането  формира ФБ с нулева обща сума, няма пречка такъв ФБ да бъде предаден дистанционно към сървър на НАП. За тази особеност на софтуерната реализация производителят/разпространителят би следвало да е направил пояснение при подаването на информация за софтуера съгласно чл. 52в ал. 2 (заедно с декларацията по чл. чл. 52в ал. 1).

 

При така приетата нормативна уредба как е предвидено да се изпълни следната ситуация: фирма, използваща „Система за управление на продажбите“, работи изцяло с разплащания по банков път. Ако системата отговаря на изискванията на Приложение 29, то според т. 8 не се допуска откриване на Продажба без наличието на връзка с фискално устройство (ФУ).

 

Лицата по чл. 118, ал. 18 от Закона за данък върху добавената стойност (ЗДДС) могат да използват в търговски обект, в който се извършват продажби на стоки и услуги, за които е налице задължение за издаване на фискален бон, само софтуер/и за управление на продажбите, отговарящ/и на посочените в приложение № 29 изисквания, като софтуерът/ите задължително управлява/т всички фискални устройства в този обект.

В случай че в търговски обект се извършват продажби, за които не е налице задължение за издаване на фискален бон (ФБ), Наредба №Н-18/2006 г. не изисква наличие на фискално устройство в този обект, респективно регламентираните в Приложение № 29 изисквания не са относими към софтуер, който управлява продажби, за които не е налице задължение за регистрирането и отчитането им чрез фискално устройство. Същият софтуер (същата версия на софтуера) обаче не може да се използва в други търговски обекти, в които се извършват продажби, за които се изисква издаване на ФБ.

 

В случаите, в които „Софтуерът за управление на продажбите“ не е самостоятелно приложение, то изискването в Приложение № 29 към чл. 52а,           ал. 13, което гласи „Софтуерът трябва да има надеждна защита от преднамерено или случайно изтриване или промяна на вече записани данни за приключени продажби – софтуерът няма вградена функционалност за изтриване на записи в базата данни …“, поражда следните въпроси по отношение начина на работа с останалата функционалност на цялостната система.

ВЪПРОС: Как се предвижда да се работи в следните ситуации:

  1. Допуска ли се изтриване/редакция на данни, свързани с функционалност за „Управление на сервизна дейност“?
  2. Допуска ли се изтриване/редакция на данни, свързани с кореспонденцията по:
  3. Продажба (примерите посочени в т.3 до т. 5)
  4. Оферта,
  5. Сервизна дейност,
  6. Обслужване,
  7. Застрахователна дейност,
  8. Отношения с контрагенти
  9. и т.н.

Ето и следните примери:

  1. При вече записана Продажба и закъсняващо плащане, от системата се изпращат уведомителни съобщения (e-mail, SMS и т.н.), съответно информация за изпратените уведомления се съхраняват в допълнителни таблици, но пряко свързани със съответната продажба. Обикновено това се случва при вече записана продажба.
  2. Често към конкретна продажба се издават допълнителни документи, като например Гаранционни карти, Партидни листи, дори експедиционни документи и всички те може да бъдат издадени след записването на Продажбата.
  3. Понякога се отразява допълнителна информация свързана с вече записана продажба, като забележки за уговорки за плащания, коментари и др. подобни.

Разгледаните примери в т3, т.4, т.5 касаят въвеждането на данни към вече записана операция (поради естеството си или времето на възникване).

Как според НАП тази информация, свързана с продажбата може да бъде обработвана. Допуска ли се изтриване/редакция на гореописаните данни без СТОРНИРАНЕ на Продажбата. И може ли да се даде отговор с информация, конкретно кой/какви записи от базата данни не могат да бъдат изтривани или редактирани .

В случаите, в които софтуерът за управление на продажбите не е самостоятелно приложение изискванията на Приложение №29 се отнасят към модула, в който е реализирана функционалността „управление на продажбите“.  Съгласно  чл. 52к, ал. 3 от Наредба № Н-18/2006 г. когато работата на софтуера е свързана с получаване или подаване на информация от или към други софтуери или модули от информационни системи, задължените лица са длъжни да  съхраняват информацията, създавана чрез тези софтуери (модули от информационни системи), в сроковете по чл. 38, ал. 1 от ДОПК и при поискване предоставят на органите по приходите (ОП) достъп до нея с пълни права за четене и експорт на данни.

Съгласно т. 13 от Приложение №29 софтуерът трябва да не позволява изтриване или промяна на вече записани данни за приключени продажби. Посочените примери се отнасят до въвеждане на допълнителна информация за приключени продажби, което не предполага промяна или изтриване на вече записани данни за тях.

 

Ако се използва „Драйвер за управление на фискално устройство“, което позволява проверка за състоянието на ФУ преди започването на продажбата, то счита ли се че може да бъде реализирана операцията, ако отговора от „Драйвера“ не съдържа информация за грешка от страна на ФУ. В наредбата е казано че „Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за статуса на ФУ“, което реално допуска използването на „Драйвер за управление на ФУ“, като налага изискването да се провери статуса на ФУ преди бон. Всички драйвери предлагани от производителите на ФУ връщат информация за състоянието на ФУ след изпълнение на команда, ако винаги преди бон се изпраща команда за сверяване на Дата/час (което изпълнява изискването от т.5 от Приложението), то може да се приеме че получената информация от „Драйверът за управление на ФУ“ е в реално време.

Друг приложим метод е с директната проверка състоянието на ФУ и последващо подаване на команда към „Драйвер за управление на ФУ“.

Изискването в т. 8 от Приложение №29 е софтуерът да осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за неговия статус и да не допуска извършване на операции по откриване и приключване на продажба в случаите, когато статусът на ФУ не позволява издаване на ФБ. Изискването предполага  комуникация между софтуера и ФУ, която да позволява проверка за свързаност с работещо ФУ в момента на откриване на всяка продажба. Това предполага използване не на драйвер, а на протокол за комуникация между софтуера и ФУ.

 

Липсва дефиниция на понятието „Модул“.

ВЪПРОС: Как НАП тълкуват понятието „Модул“.

  1. Как се очаква да бъдат декларирани в ПРИЛОЖЕНИЕ 31 т.1 отделни приложения, който работят с базата данни с която работи и частта за „Управление на продажбите“. Фактически това са отделни модули към системата.
  2. В този смисъл библиотеките (с вградени в тях самостоятелни функционалности, като управление на фискално устройство например, управление на команди към базата данни, управление на команди към интернет магазин) считат ли се за „Модули“ и ако ДА, то каква/коя част от функционалността им трябва да се опише в ПРИЛОЖЕНИЕ №31 т.1.

Съгласно т. ІІ.1 от Приложение №31 производителят/разпространителят следва да предостави информация за наименованията и функционалността на модулите,  съдържащи се в софтуера за управление на продажбите.

С изключение на библиотеките, които се разпространяват със стандартни софтуери или операционни системи, напр. Windows, Linux и др., всички други библиотеки би следвало да се посочат заедно с версията им и функционалността, която е вградена в тях.

 

В Приложение №29, т. 17 „Чрез потребителски интерфейс софтуерът осигурява достъп до създаваните чрез него данни в сроковете по чл. 38, ал. 1 от ДОПК. При архивиране на базата данни софтуерът осигурява създаване и поддържане на архив, както и достъп до архивните данни в сроковете по чл. 38, ал. 1 от ДОПК през потребителски интерфейс.“ :

ВЪПРОС: Какво се има предвид с изискването „.. При архивиране на базата данни софтуерът осигурява … и поддържане на архив …в сроковете по чл. 38, ал. 1 от ДОПК през потребителски интерфейс“, това означава ли че се вменява задължението на софтуерът да съхранява архив в посочените сроковете и ако ДА, то какви са очакванията за начинът по който това „…поддържане на архив… през потребителски интерфейс…“ трябва да се реализира.

Софтуерът следва да позволява архивиране на създаваните данни с периодичност в зависимост от спецификата на бизнеса и желанието на задълженото лице – потребител. Задължение на последния  е да съхранява архивираната информация в сроковете по чл. 38, ал. 1. Софтуерът трябва да има функционалност за достъп до архивираната информация през потребителски интерфейс, така че да е възможно генериране и експорт на информацията, посочена в т.18 от Приложение №29.

 

В Приложение №31, т.7 се изисква подаването на „Информация относно изпълнението на изискванията по т. 16, 17, 18 и 19 от приложение № 29“

ВЪПРОС: Каква част от изискваната подробна информация от посочените точки в Приложение 29 е необходимо да бъде декларирана. Отговори с Да (Да, поддържа се) или Не , достатъчни ли са ?

В случай че софтуерът е част от или е свързан с интегрирана информационна система за управление на продажбите/търговската дейност,  производителят/разпространителят следва да предостави информация, дали изискванията в т. 16, 17, 18 и 19 от Приложение №29 се изпълняват от софтуера или изпълнението им е осигурено от функционалността на интегрираната система. Когато е налице втората хипотеза е необходимо да се посочи, в кои модули е реализирана функционалността за изпълнение на всяко от изискванията в посочените точки.

 

В чл. 52в, ал. 1 се задължават производителите на софтуер да предоставят „…изпълнимият файл, за достъп и извличане на данни от БД в структуриран четим вид с възможност за избор – от всички или от част от таблиците, с които работи софтуерът; “

ВЪПРОС: Възможно е част от извличаната информация да е криптирана с оглед защита на корпоративни интереси от страна на клиента, като ключа се съхранява под опеката на вещи лица на клиента. Как се очаква предоставеното приложение да визуализира/експортва данните (криптирани или декриптирани, ако криптираните данни засягат правата на лица от Регламент 679/2016 на ЕК )?

Съгласно ДОПК органът по приходите има право да изиска, а задължените лица да му осигурят, достъп до счетоводна, търговска и друга документация, за която е преценено, че има значение за определяне на задълженията на лицето. Това изискване е в сила и когато за обработка на информацията се използват информационни системи.

Съгласно ДОПК органите по приходите са длъжни да опазват данъчната и осигурителната информация, вкл. и търговската тайна.

В Приложение №29, т.3 „…В случаите, в които софтуерът за управление на продажби в търговски обект представлява модул от софтуер, останалите модули не могат да имат дублираща функционалност за управление на продажбите ….“

ВЪПРОС: Често в практиката се налага обособена функционалност в системите, чрез която се изписват различни стоки поради ред причини (но не свързани с продажба), като бракуване на стоки, изписване на стоки за вътрешна употреба, движение между вътрешни складове и други.

Ако се приеме, че понятието „модул“ е „отделно от основната система приложение“ (и не е синоним на функционалност), то

  • Допуска ли се използването на такава функционалност в системата, притежаваща и функционалност за „Управление на продажбите“, която да позволява изпълнението на ако гореописаните операции, ако НЕ то какъв механизъм трябва да бъде предвиден за отразяване на посочените действия чрез системата.
  • Допуска ли се използването на функционалност в системата, притежаваща функционалност за „Управление на продажбите“, чрез която се издават първични счетоводни и други документи за продажбите.

Считам, че няма пречка софтуерът да притежава функционалност, чрез която да се отразяват действия като посочените от Вас –  „бракуване“, „движение на стоки между складове“, „изписване на стоки за вътрешна употреба“, доколкото тези операции не са свързани с процеса по управление на продажбите. Производителят/разпространителят следва да подаде информация за наличната функционалност в софтуера, който произвежда/разпространява съгласно т. II.1 от Приложение №31.

Ако модулът за издаване на първични и други документи за продажби  има функционалност за управление на продажбите, същият попада в обхвата на определението за софтуер за управление на продажбите в търговски обект съгласно т.84 от §1 на ДР на ЗДДС, във връзка с §1, т. 19 от ДР на Наредба Н-18 и следва да отговаря на изискванията на Приложение №29.

 

В Приложение №29, т.18.9 се изисква извеждане на информация за „видове операции (действия)

– код, наименование, дата на първоначално конфигуриране в системата, дата на последна промяна, дата на деактивиране; „

ВЪПРОС: Какъв вид действия се очаква да бъдат изведени?

  1. Създаване, Редакция, Изтриване на номенклатури са вградени като действия в системата, но не са декларирани в табличен вид
  2. Приемане в сервиз, добавяне на ремонт, Издаване на клиент за функционалност „Сервизна поддръжка“ са вградени като действия в системата, но не са декларирани в табличен вид
  3. Откриване/Започване, Анулиране, Сторниране, Приключване, Плащане и др са действия, отнасящи се за операциите (сред които е и Продажба), вградени в системата, но не са декларирани в табличен вид.

Всяко от гореописаните действия се записват в Log списък, с наименование, дата на възникване и оператор извършил действието, но липсват изискваните параметри „… дата на първоначално конфигуриране в системата, дата на последна промяна, дата на деактивиране…“

Наредбата не предявява изисквания по отношение на структурирането на базата данни на софтуерите за управление на продажбите. В т. 18 от Приложение №29 се съдържа изискване по отношение на експорта на информация от базата данни. Именно експорт трябва да може да се направи в табличен вид в указания формат и това трябва да бъде осигурено от софтуера.

 

В Приложение №29, т.18.9 се изисква „…работни места – код, търговски обект, в който се намира, индивидуален номер на свързаното към него ФУ, дата на първоначално конфигуриране в системата, дата на последна промяна, дата на деактивиране; …“

ВЪПРОС: Ако не се поддържа в таблична форма, а номерата на работните места са динамични (но не се позволява две работни места с един номер да работят едновременно). Допуска ли се този тип номенклатура да не се експортира.

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

Въпрос

В Приложение №29 т.6 „Софтуерът има вградени контроли за задължително попълване на данни за потребителите (операторите) …. начало/ край на периода на активност на потребителя (оператора) за всяка от присвоените му роли“

ВЪПРОС: Какъв вид „.. контроли… за всяка от присвоените му роли“ се изисква да бъдат вградени в системата, ако оператора изпълнява ролята на сервитьор, барман и управител в търговски обект, коя от тези роли трябва да бъде въведена в системата за оператора и как се предвижда контролата да контролира края на едната роля и началото на другата.

Ако се съхранява Log списък, в които се отразява направената промяна при преминаването от едната към другата роля в системата, счита ли се че системата има „.. вградени контроли… за всяка от присвоените му роли“. Естествено при въвеждане/редакция на оператор не се допуска запис без посочена Роля.

Ролята, която даден служител има в системата (софтуера), се свързва с правата, които той има по отношение на достъп до функционалност, права за четене или запис, на определени данни, промени например в номенклатурни файлове и др. От софтуера се изисква логически контрол на въвежданите данни за потребителите (операторите). Отговорност на задължените лица е осигурят вярно и точно въвеждане на посочената информация в приложение №29, т.6.

 

Според Приложение №29,  т.20 „Софтуерът не притежава възможност за работа в тестови режим, режим за обучение или друг подобен.“

ВЪПРОС: Ако производителят е предоставил версия, приведена в съответствие с Наредба Н-18 на интернет сайтове с цел реклама, следва ли тези версии да бъдат изтеглени/свалени. Ако ДА, то по какъв начин се допуска да бъде извършвана реклама на предлаганите продукти.

Наредбата не ограничава рекламата на софтуери за управление на продажбите, които отговарят на изискванията на наредбата и са включени в поддържания от НАП публичен списък на софтуерите.

 

С т.4 от Приложение №29 се изисква „Софтуерът съдържа вградена при разработването му защита от промяна или добавяне, без оторизация от производителя/разпространителя, на външни модули“.

ВЪПРОС: Възможно ли е НАП да посочи приемлив според тях „начин на защита“

Начинът на защита на софтуера е избор на производителя на софтуера. Обща информация за това, какъв вид защита е използван, следва да се подаде с информацията за софтуера съгласно Приложение №31, т.8. Тази информация не се включва в публичния списък на софтуерите, за които е декларирано съответствие с изискванията, посочени в Приложение №29 към чл. 52а от Наредба № Н-18.

 

При така наложените изисквания в Приложение №29, т.9 за „При въвеждане в софтуера на информация за продажба софтуерът генерира уникален номер на продажбата (УНП)“, как се очаква да се държи системата за управление на продажбите, ако:

  1. бъде отворена Нова продажба – се генерира номер: DT123456-0005-0000001 (“…7-разряден пореден номер на продажбата, формиран поотделно за всеки индивидуален номер на ФУ…”
  2. маркират се 2 артикула
  3. в този момент се отваря от друго работно място продажба с номер: DT123456-0002-0000002, което е с пореден номер на операцията 2, тъй като се използва същото ФУ
  4. на Работно място 1 (т.1) се приключва работният ден без приключване на продажбата.
  5. На работно място 2 (т.2) се записва продажбата и се генерират още 3 продажби, което довежда брояча до поредност 6 (т.е. следващата операция за това ФУ трябва да бъде 6)
  6. на следващият ден става ясно че артикулите от отворената продажба от т.1 се анулират и операцията се освобождава. Дори и фискалните устройства да са различни, то отново съществува възможност за възникването на описаните по – долу казуси.
  7. Какво се очаква да се случи тук (следните възможни варианти):
  8. Генерираният номер изчезва от системата в поредността на номерациите за ФУ в записаните продажби
  9. Операцията се записва със нулева стойност, без клиент и нулево съдържание
  10. Генерираният номер се съхранява до приключване със смислени данни, т.е. Запазва се до като се появи реален клиент с реални данни. В този случай обаче как ще се разглежда информацията за анулираните артикули.

Нито един от посочените от вас варианти а), b) или с) не отговаря на изискванията на наредбата.

В посочения от Вас пример информация за неприключената продажба с УНП DT123456-0005-0000001 следва да бъде записана в БД на софтуера – записват се и се съхраняват всички въведени данни, вкл. вид, количество и стойност на артикулите и др., както и индикатор, че продажбата с посочения УНП е анулирана.

Моля, обърнете внимание на формулировката в т. 12 от Приложение №29: „При анулиране (пълно или частично) на открита, но неприключена продажба софтуерът задължително съхранява в базата данни пълна информация за анулираната продажба – анулирани стоки/услуги, количество, стойност, оператор и др.“