|
Изх. № М-26-А-476 Дата: 15.10.2019 год. |
Наредба № Н-18, Приложение № 29
ОТНОСНО: поставени въпроси по Наредба №Н-18/2006 г. за регистриране и отчитане на продажбите в търговски обекти чрез фискални устройства, изискванията към софтуерите за управлението им и изисквания към лицата, които извършват продажби чрез електронен магазин(Наредба №Н-18/2006 г.)
В Централно управление на Национална агенция за приходите (НАП) е получено Ваше писмо, в което поставяте въпроси относно прилагането на Наредба №Н-18/2006 г.
І. СУПТО Регистрация
Внедряването на ...... софтуера се базира на включените в него стандартни бизнес процеси за управление на продажбите, индустриални решения (като напр. търговия на дребно) и локализация за страната, включваща изискванията по българското законодателство, като напр. ДДС дневници и декларации, оборотни ведомости на материали, основни данни на материали, доставчици, клиенти и потребители и потребителски права и др.
Това внедряване се осъществява с възлагане от страна на ползвателя на СУПТО (възложител), който задава бизнес изискванията и най-добре познава процесите и организацията на работата си. Внедрителят работи на проектна основа с начало и край и настройва софтуера съгласно изискванията на възложителя, като предоставя системата за ползване от страна на възложителя.
При промяна на законовите изисквания към СУПТО, обикновено производителят на софтуера прави локализация за клиентите, заплатили софтуерна абонаментна поддръжка. В случай че производителят не направи такава локализация (както в момента това беше заявено от .....), възложителят следва да поръча такава доработка и кастъмизиране от внедрителя и да я заплати допълнително. В случай на вече регистрирана СУПТО и ако възложителят не поръча такава доработка, внедрителят ще носи административната тежест и санкция от това, че СУПТО не отговоря на изискванията. С оглед на избягване на такава санкция, внедрителят следва да работи безвъзмездно за своя клиент. В допълнение, за внедрителя е много трудно да декларира съответствие на софтуер, за който няма сорс код и цялата информация на разработчика и производител и да предостави пълния набор от документация, която или е конфиденциална и няма право да предостави, или изобщо не я притежава.
Предложение А: Възложителят (търговец) би могъл в много по-адекватна степен да декларира съответствие на СУПТО с изискванията на Наредбата и законодателството вместо внедрителя.
Предложение Б: Към момента Наредбата не дава възможност да се регистрира кастъмизиран софтуер като СУПТО, което е уникално само за съответния клиент. Предлагаме да бъде добавена такава възможност да се регистрира от ползвателя на СУПТО и възможността да се регистрира кастъмизирания софтуер с информация за конкретния ползвател.
ІІ. Кредитни известия към много фактури:
В стандартните САП бизнес процеси съществува издаване на кредитни известия с референции към много на брой фактури. Например в ....... модул "Работни споразумения с клиенти" се издават кредитни известия за бонус оборот за определен период от време. В този случай едно кредитно известие трябва да реферира към УНП номерата към много на брой фактури (напр. 10 хил. броя), което е технически и оперативно невъзможно.
Предложение: За такъв тип документи (кредитни известия към много фактури) да се съставя отделна УНП номерация, като за тези документи да бъде изготвен отчет за референция към оригинални фактури, за които то е издадено.
ІІІ. Начин на плащане
Следва ли да се счита прихващането на вземане и задължение по ЗЗД и закриване/нетиране на фактури и кредитни известия като безкасово плащане?
ІV. Използване на одит файл
Съществуват бизнес процеси, при които продажбите се извършват при условията на разносна търговия, като за всяка една продажба се генерират фактури. Доставките се извършват от служители на търговеца, снабдени с мобилни устройства, на които е инсталиран софтуер, свързан с мобилни ФУ. Този софтуер позволява единствено отразяване на плащане и подаване на команда към ФУ за разпечатване на ФБ - няма функционалност за генериране на поръчки, продажби, промяна на данни за продажба и т.н. При тези условия фактури се заплащат отложено (например 30 дни след издаване на фактурата), като при касово плащане към датата на падежа им те се отразяват чрез мобилните устройства, свързани с мобилни ФУ.
Според обсъжданите проекто-промени е заложена възможността за използване на одит файл и отпадане на изискването за свързаност с ФУ в случай на касови плащания до 5%.
Предложение А: Горната възможност да е приложима, като от посочения процент на касовите плащания се изключат продажби при условията на разносна търговия.
Предложение Б: В рамките на 5% ограничение да се считат само касовите плащания, извършени на място в търговския обект при извършване на продажбата.
Предвид изложената фактическа обстановка и съобразявайки относимата нормативна уредба, на основание чл. 10, ал. 1, т. 10 от Закона за Националната агенция за приходите, изразявам следното становище по зададените от Вас въпроси:
По въпрос І
Считам, че когато производителят на софтуера не прави локализация за клиентите, т.е същият предоставя софтуер с основни стандартни функции, които обаче не са достатъчни да работят самостоятелно, и този софтуер придобива завършен, работен вид след доработка или от внедрителя, или от търговеца, ползвател на СУПТО, то дружеството, което прави промени във функционалността на софтуера по смисъла на Наредба №Н-18/2006 г., следва да се третира като производител. В конкретния случай това може да бъде направено както от внедрителя, така и от търговеца (възложителя), ползвател на СУПТО, в зависимост от това кое лице прави настройките на софтуера. Предвид това считам, че лицето, което извършва настройките, се явява производител на софтуера. И в двата случая е препоръчително да се направят пояснения относно основния софтуер, вкл. неговия производител, като това може да бъде направено или в изискващото се Подробно ръководство за работа със софтуера, или в отделен приложен документ.
По въпрос ІІ
Изискването на т. 9 от Приложение № 29 от Наредба № Н-18/2006 г. е при въвеждане в софтуера на информация за продажбата, софтуерът да генерира уникален номер на продажбата (УНП). За документи от типа кредитни известия към много фактури не следва да се генерира УНП, тъй като кредитно известие се издава за вече извършени продажби, а не документира нова такава. Изискването на наредбата е, в случай, че се издава сторно фискален бон по фискален бон за продажба, съдържащ уникалния номер на продажбата, този номер да се отразява и в сторно документа. Според посочения от Вас пример се издават кредитни известия за бонус оборот за определен период от време, като според Вас в този случай едно кредитно известие трябва да реферира към УНП номерата към много на брой фактури (напр. 10 хил. броя), което е технически и оперативно невъзможно. В този случай обаче обичайно не се възстановяват суми в брой, поради което и не възниква задължение за издаване на сторно документ чрез фискално устройство, респективно не е необходимо да се сторнират много на брой фискални бонове с различни УНП. Обръщам внимание, че изискването за посочване на УНП е налице, само когато кредитното известие се издава от ФУ като разширен сторно фискален бон и именно поради това че известието се издава от ФУ. В ЗДДС няма изискване за посочване на такъв реквизит в кредитните известия.
По въпрос ІІІ
Прихващането е способ за погасяване на две насрещни задължения до размера на по-малкото от тях. Чрез него задължението се погасява чрез приспадане на насрещното вземане, което длъжникът има към своя кредитор. Погасяването е пълно, когато двете насрещни вземания имат еднакъв размер, и частично, когато те нямат еднакъв размер. В случая при прихващане на вземания и задължения с пълно погасяване, когато страните уреждат своите облигационни отношения без движение на парични средства, изискващи регистриране и отчитане чрез издаване на фискален бон, а само документално (т.нар. закриване/нетиране на фактури и кредитни известия), считам, че същото е безкасово и не следва да се издава фискален бон.
По въпрос ІV
Така предложената алтернативна възможност е относима за дейността на задълженото лице като цяло, а не се разглежда за конкретен търговски обект.
ЗАМ.ИЗПЪЛНИТЕЛЕН ДИРЕКТОР НА НАП:
/ПЛАМЕН ДИМИТРОВ/
В Централно управление на НАП е постъпило запитване относно прилагането на Наредба № Н-18/2006 г. за регистриране и отчитане на продажбите в търговски обекти чрез фискални устройства, изискванията към софтуерите за управлението им и изисквания към лицата, които извършват продажби чрез електронен магазин.
I. СУПТО - регистрация
Описано е внедряване на софтуер ......, базирано на включени в него стандартни бизнес процеси за управление на продажбите, индустриални решения (например търговия на дребно) и локализация за страната, включваща изискванията по българското законодателство, като: ДДС дневници и декларации, оборотни ведомости на материали, основни данни на материали, доставчици, клиенти и потребители, потребителски права и др.
Внедряването се осъществява по възлагане от ползвателя на СУПТО (възложител), който задава бизнес изискванията и познава процесите и организацията на работата си. Внедрителят работи на проектна основа с начало и край и настройва софтуера съгласно изискванията на възложителя, като предоставя системата за ползване от възложителя.
При промяна на законовите изисквания към СУПТО обичайно производителят на софтуера прави локализация за клиентите, заплатили софтуерна абонаментна поддръжка. Когато производителят не прави такава локализация (както е заявено от ......), възложителят следва да поръча доработка и кастъмизиране от внедрителя и да я заплати допълнително.
Посочено е, че при вече регистрирана СУПТО, ако възложителят не поръча такава доработка, внедрителят ще носи административната тежест и санкция за това, че СУПТО не отговаря на изискванията. За да избегне санкция, внедрителят би следвало да работи безвъзмездно за клиента. Допълнително се посочва, че за внедрителя е много трудно да декларира съответствие на софтуер, за който няма сорс код и пълна информация от разработчика и производителя, както и да предостави пълния набор от документация, която или е конфиденциална и не може да бъде предоставена, или изобщо не се притежава.
Изложени са следните предложения:
Предложение А: Възложителят (търговецът) да може в по-адекватна степен да декларира съответствие на СУПТО с изискванията на Наредбата и законодателството вместо внедрителя.
Предложение Б: Към момента Наредбата не дава възможност да се регистрира кастъмизиран софтуер като СУПТО, който е уникален само за съответния клиент. Предлага се да бъде добавена възможност той да се регистрира от ползвателя на СУПТО, включително с информация за конкретния ползвател.
Въпрос I: Кой следва да се счита за производител на СУПТО и съответно да декларира съответствие и да носи отговорност, когато производителят предоставя само стандартен софтуер без локализация, а завършеният работен вид се постига чрез доработка от внедрителя или от търговеца - ползвател?
В отговор се посочва, че когато производителят на софтуера не прави локализация за клиентите, а предоставя софтуер с основни стандартни функции, които не са достатъчни да работят самостоятелно, и този софтуер придобива завършен, работен вид след доработка от внедрителя или от търговеца - ползвател на СУПТО, то дружеството, което прави промени във функционалността на софтуера по смисъла на Наредба № Н-18/2006 г., следва да се третира като производител.
В конкретния случай това може да бъде както внедрителят, така и търговецът (възложителят), ползвател на СУПТО, в зависимост от това кое лице прави настройките на софтуера. Лицето, което извършва настройките, се явява производител на софтуера.
Извод: За производител на СУПТО по смисъла на Наредба № Н-18/2006 г. се счита лицето, което извършва промените и настройките във функционалността на софтуера, независимо дали това е внедрителят или търговецът - ползвател, като то носи отговорност и следва да декларира съответствието.
II. Кредитни известия към много фактури
Описано е, че в стандартните САП бизнес процеси съществува издаване на кредитни известия с референции към много на брой фактури. Например в модул "Работни споразумения с клиенти" се издават кредитни известия за бонус оборот за определен период от време. В този случай едно кредитно известие трябва да реферира към УНП номерата на много на брой фактури (например 10 000 броя), което е технически и оперативно невъзможно.
Направено е следното предложение: за такъв тип документи (кредитни известия към много фактури) да се съставя отделна УНП номерация, като за тези документи да бъде изготвен отчет за референция към оригиналните фактури, за които са издадени.
Въпрос II: Как следва да се прилага изискването за УНП при кредитни известия, които реферират към голям брой фактури, и необходимо ли е тези кредитни известия да съдържат УНП на всички фактури?
В отговор се посочва, че съгласно т. 9 от Приложение № 29 към Наредба № Н-18/2006 г. при въвеждане в софтуера на информация за продажбата софтуерът трябва да генерира уникален номер на продажбата (УНП). За документи от типа кредитни известия към много фактури не следва да се генерира УНП, тъй като кредитното известие се издава за вече извършени продажби и не документира нова продажба.
Изискването на наредбата е, когато се издава сторно фискален бон по фискален бон за продажба, съдържащ УНП, този номер да се отразява и в сторно документа.
Според посочения пример се издават кредитни известия за бонус оборот за определен период от време, като според запитването едно кредитно известие трябва да реферира към УНП номерата на много на брой фактури (например 10 000 броя), което е технически и оперативно невъзможно. В този случай обаче обичайно не се възстановяват суми в брой, поради което не възниква задължение за издаване на сторно документ чрез фискално устройство и съответно не е необходимо да се сторнират много на брой фискални бонове с различни УНП.
Обръща се внимание, че изискването за посочване на УНП е налице само когато кредитното известие се издава от фискално устройство като разширен сторно фискален бон и именно поради това, че известието се издава от фискално устройство. В Закона за данък върху добавената стойност няма изискване за посочване на такъв реквизит в кредитните известия.
Извод: За кредитни известия към много фактури не се генерира УНП, тъй като те не документират нова продажба, а при обичайните случаи на бонус оборот без възстановяване на суми в брой не възниква задължение за сторно фискални бонове и съответно за посочване на УНП; изискването за УНП се прилага само при кредитни известия, издадени от фискално устройство като разширен сторно фискален бон.
III. Начин на плащане - прихващане
Въпрос III: Следва ли да се счита прихващането на вземане и задължение по Закона за задълженията и договорите и закриването/нетирането на фактури и кредитни известия като безкасово плащане?
В отговор се посочва, че прихващането е способ за погасяване на две насрещни задължения до размера на по-малкото от тях. Чрез него задължението се погасява чрез приспадане на насрещното вземане, което длъжникът има към своя кредитор. Погасяването е пълно, когато двете насрещни вземания имат еднакъв размер, и частично, когато те нямат еднакъв размер.
В разглеждания случай, при прихващане на вземания и задължения с пълно погасяване, когато страните уреждат своите облигационни отношения без движение на парични средства, които да изискват регистриране и отчитане чрез издаване на фискален бон, а само документално (т.нар. закриване/нетиране на фактури и кредитни известия), не е налице плащане в брой или с банкови карти, подлежащо на регистриране чрез фискално устройство.
Извод: Прихващането на насрещни вземания и задължения, при което няма реално движение на парични средства, представлява документално уреждане на отношенията и не се третира като плащане, изискващо издаване на фискален бон.
IV. Използване на одит файл и разносна търговия
Описани са бизнес процеси, при които продажбите се извършват при условията на разносна търговия, като за всяка продажба се генерират фактури. Доставките се извършват от служители на търговеца, снабдени с мобилни устройства, на които е инсталиран софтуер, свързан с мобилни фискални устройства. Този софтуер позволява единствено отразяване на плащане и подаване на команда към фискалното устройство за разпечатване на фискален бон, без функционалност за генериране на поръчки, продажби, промяна на данни за продажба и др.
Фактурите се заплащат отложено (например 30 дни след издаването им), като при касово плащане към датата на падежа те се отразяват чрез мобилните устройства, свързани с мобилни фискални устройства.
Посочено е, че според обсъжданите проекто-промени е предвидена възможност за използване на одит файл и отпадане на изискването за свързаност с фискално устройство в случай на касови плащания до 5%.
Направени са следните предложения:
- Предложение А: Възможността за използване на одит файл и отпадане на изискването за свързаност с фискално устройство да е приложима, като от посочения процент на касовите плащания се изключат продажбите при условията на разносна търговия.
- Предложение Б: В рамките на 5% ограничение да се считат само касовите плащания, извършени на място в търговския обект при извършване на продажбата.
По тези предложения в цитирания текст не е изложен изричен правен отговор или окончателно становище, а са описани фактическите обстоятелства и предложенията на запитващия във връзка с предстоящи проекто-промени.
Извод: В рамките на изложеното становище са представени фактическите особености на разносната търговия и предложенията относно прилагането на одит файл и 5% ограничение за касови плащания, без да е формулиран конкретен нормативен извод или промяна по действащата Наредба № Н-18/2006 г. в тази част.
