КОНТРОЛЕН ЛИСТ ЗА СУПТО

№

Изискване за подаване на информация

Пояснение

Основание, на което е декларирано съответствие на СУПТО с изискванията на Наредба №Н-18

чл.52а, ал.1

чл.52а, ал.2

чл.52а¹

В среда на клиента

SааS

I. ПОДАВАНИ ИНФОРМАЦИЯ И ДОКУМЕНТИ

1.

ИНФОРМАЦИЯ ЗА СОФТУЕРА

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

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

Х

Х

Х

Х

2.

ДОКУМЕНТИ, КОИТО СЕ ПРИЛАГАТ

2.1.

Подробно ръководство за работа със софтуера в частта, свързана с функционалността за управление на продажбите (чл. 52в, ал. 2, т. 2)

Пояснения относно съдържанието на подробното ръководство за работа със софтуера са дадени в т. II – 1 по-долу в настоящия материал.

Х

Х

Х

Х

2.2.

Описание на начина, по който са реализирани изискванията съгласно Приложение № 29, придружено с екранни снимки (чл. 52в, ал. 2, т. 2)

Пояснения относно начина, по който да се представи реализацията на изискванията съгласно Приложение №29 са дадени в т. II – 2 по-долу в настоящия материал.

Х

Х

Х

Х

2.3.

Описание на обектите в БД, свързани с управлението на продажбите, вкл. таблици и предназначението им, връзки между тях, описание на полетата в таблиците.

Изисква се да бъде посочено предназначението на всяка таблица; описание на съдържанието на всяко поле  в таблиците /колона description/ - на български език; ключови полета и връзки между таблиците.

Х

-

-

Х

2.4.

Изпълним файл за достъп и извличане на данни от БД в структуриран четим вид с възможност за избор - от всички или от част от таблиците, с които работи софтуерът. (чл. 52в, ал. 2, т.3)

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

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

Необходимо е да бъде предоставен source-кодът, от който е генериран посоченият изпълним файл.

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

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

Допуска се да не бъде представен изпълним файл,  при условие че софтуерът разполага с функционалност, изисквана за изпълнимия файл (чл. 52в, ал. 4). В този случай се изискват указания, вкл. онагледяване, как да се достъпва и изпълнява посочената функционалност.

Х

-

-

Х

2.5.

Описание на функциониране на SaaS,  технически канали за комуникация между облачната услуга и ФУ, локални компоненти, местонахождение на БД  (чл. 52в, ал. 2, т. 4)

Изисква се подробно описание на функционирането на облачната услуга (SaaS), вкл. на локалните компоненти, които могат или задължително трябва да се инсталират в среда на клиента.

В случай че софтуерът работи и с локална база данни, е необходимо да се предостави информацията съгласно чл. 52в, ал.2, т. 3 – описание на БД, изпълним файл и source-кода му и т.н..

Х

Х

Частично-

чл.52в ал. 2, т.5)

II. ПРОВЕРКА НА СЪДЪРЖАНИЕТО 

1.

Подробно ръководство за работа със софтуера

1.1. 

Предназначение на софтуера

Изисква се кратко представяне на софтуера от гл. т. на предназначението му - за конкретен бизнес или с по-общо предназначение.

Х

Х

Х

Х

1.2.

Описание на функционирането на софтуера

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

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

Х

Х

Х

Х

1.3.

Декларирани модули

Описани ли са всички модули, които са посочени в информацията към подадената декларация за софтуера.

Х

Х

Х

Х

1.4.

Функционалност

Изисква се описание на функционалността на софтуера за управление на продажбите, подкрепена с екранни снимки, вкл. тази за конфигуриране и поддържане на номенклатури.

Функционалността, която не е свързана с управление на продажбите (ако има такава, напр. HR-модул, модул „Производство“ и др.) само се посочва, без да се описва подробно.

Х

Х

Х

Х

1.5.

Продажби

Специално внимание се обръща на частта с указания към потребителя при извършване на продажби.

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

Х

Х

Х

1.5.1.

Проверява се наличието на указания към потребителя относно :

-       Изискването за свързаност на софтуера с ФУ съгласно  т. 8 от Приложение 29;

-       Проверката на готовността на ФУ и при откриване, и при приключване на продажба;

-       Как реагира софтуерът при липса на свързаност с ФУ или когато ФУ не е в готовност за работа;

-       Как се анулират и сторнират продажби (т.12 и т. 13 от Приложение 29) 

Изисква се:

·             прилагане на екранни снимки със съобщения за липса на свързаност с ФУ или за липса на готовност на ФУ за работа. Софтуерът следва да блокира операциите по откриване и приключване на продажба в случаите, когато статусът на ФУ не позволява издаване на ФБ

·             насоки за работа на потребителите при анулиране на неприключили продажби (частично или пълно) – онагледване с екранни снимки;

·             насоки за работа на потребителите при сторниране  на приключили продажби – онагледване с екранни снимки;

Х

Х

Х

1.5.2.

УНП

Проверява се, има ли информация, кога се генерира УНП

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

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

Допуска се УНП да се генерира и в момента на записа в БД на софтуера на въведените в екранна форма стоки/услуги, предмет на продажбата.

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

Не се допуска генерирането на УНП да става в края на продажбата, непосредствено преди отпечатването на ФБ.

Генерираният УНП следва да се визуализира на екранната форма, в която потребителят въвежда информацията за продажбата – изисква се екранна снимка. Когато УНП се генерира в  момента на запис в БД на информацията от екранната форма – УНП следва да се визуализира в екранната форма след записа й.

Х

Х

 Х

2. РЕАЛИЗАЦИЯ НА ИЗИСКВАНИЯТА СЪГЛАСНО ПРИЛОЖЕНИЕ №29 

2.1.

Режим на работа

Софтуер, деклариран като СУПТО, не може да работи в режим, различен от СУПТО (не-СУПТО)

Х

Х

Х

Х

2.2.

Проверява се описана ли е реализацията на изискванията съгласно Приложение №29.

Не е достатъчно само декларативно да се посочи, че дадено изискване е спазено. Реализацията на всички 21 бр. изисквания от Приложение №29  трябва да бъде ясно описана и навсякъде, където е възможно – онагледена с екранни снимки. Екранните снимки трябва да са четими и  да съдържат данни от тестовата среда на производителя/разпространителя. Неприемливо е данните в тях да се зачертават (правят невидими) под предлог, че съдържат лична информация. В случай, че онагледяването на справките се извършва с данни от реална БД се допуска „маскиране“ на лични данни и медицинска информация, без това да пречи на онагледяването на реализацията в съответствие с изискванията.

Х

Х

Само за т. 1,2,4,6 и 7 от Прил.№29

Х

2.2.1.

Интерфейс на български език

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

Когато СУПТО е част от функционалността от по-голям софтуер /напр. модули от ERP-система/, това изискване се отнася само за модулите, декларирани като СУПТО.

Х

Х

Х

Х

2.2.2.

Пълнота и интегритет на данните

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

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

Обвръзката между взаимно свързаните данни за продажбите трябва да съществува и да е валидна за всички периоди назад във времето (като минимум в сроковете по ДОПК), независимо че към настоящия момент е възможно да са налице множество промени, например промени в номенклатурни таблици (служители, стоки, видове плащания и т. н.). Така напр. софтуерът не следва да позволява изтриване на номенклатури, които са използвани при приключили продажби – такива номенклатури следва да се деактивират.

Х

Х

Х

Х

2.2.3.

Други модули с дублираща функционалност

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

Х

Х

Х

2.2.4.

Защита от промяна или добавяне на външни модули

Представя се обща информация на какви принципи е реализирана защитата

Х

Х

Х

Х

2.2.5.

Точно астрономическо време и синхронизиране на времето на софтуера с времето на  ФУ

Софтуерът и ФУ на работното място следва да работят в синхрон - не се допуска разлика във времената им. Софтуерът трябва периодично да проверява времето на ФУ и при необходимост – да го сверява. При липса на синхронизация следва да се блокира процесът по продажби на съответното работно място до отстраняването й.

Изискването е СУПТО по възможност да използва източник на точно астрономическо време, но е задължително да синхронизира времето м/у работното място и свързаното към него ФУ.

Посочва се начинът, по който се осигурява работа на софтуера с точно астрономическо време.

Когато софтуерът използва източник на точно астрономическо време /напр. NTP сървър/ той задължително синхронизира времето м/у работното място и свързаното към него ФУ.

Когато софтуерът няма функционалност или възможност за използване на източник на точно астрономическо време, той също следва задължително да осигури синхрон между времето м/у работното място и свързаното към него ФУ. В случай че ФУ не позволи такава синхронизация /ФУ не допускат връщане на времето на устройството преди това на последния записан блок във фискалната памет/ - софтуерът следва да изведе съобщение за грешка и да изиска сверяване на текущото му време – неговото или на ФУ.

Изисква се визуализация на извежданите съобщения за грешки при липса на синхрон м/у времето на софтуера и времето на ФУ.

Х

Х

Х

2.2.6.

Вградени контроли за задължително попълване на данни за потребителите

Посочват се реализираните контроли при валидация на въвеждането на имената на потребителите (операторите) – напр. недопускане въвеждането на еднакви символи, наличие на интервали при въвеждане на имената и др.

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

Онагледява се с екранна снимка каква информация се въвежда за потребителите.

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

Х

Х

Х

Х

2.2.7.

Еднозначна автентикация на потребителите

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

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

Х

Х

Х

Х

2.2.8.

Свързаност с ФУ, позволяваща получаване на информация от ФУ в реално време

Необходимо е да се опише начинът, по който се осъществява комуникацията с ФУ-  вградена ли е в source-кода на софтуера или се предоставя като допълнителен външен файл/приложение. Във всички случаи това е част от софтуера, за коректното функциониране на която производителят/разпространителят поема отговорност с декларацията си. 

Х

Х

Х

2.2.9.

Генериране на УНП

Вж. т. 1.5.2.

Х

Х

Х

2.2.10.

Отпечатване на ФБ (т.10 от Приложение №29). Изисквания за подаване на информация от софтуера за генериране на ФБ

При плащане по продажба, за което съгласно чл. 118, ал. 3 от ЗДДС се изисква издаване на ФБ, софтуерът задължително подава УНП към ФУ за включването му в бона.

Видовете  плащания, за които  задължително се отпечатва ФБ, следва да са съобразени с чл. 118, ал. 3 от ЗДДС. Не трябва да има настройка – да се отпечатва или не ФБ.

При плащане, за което се изисква издаване на ФБ не се допуска да има бутон за потвърждаване отпечатването на бона от оператора.

Изисква се в софтуера да е реализирана задължителна обвръзка между вид плащане и издаване или неиздаване на  ФБ съгласно чл. 118, ал. 3 от ЗДДС и чл. 3 ал. 1 от Наредба Н-18 по отношение на всички възможни видове плащания. Част от видовете плащания могат да бъдат неактивни при конкретна инсталация, в случай че даден търговец не ги използва.

Изисква се функционалността на СУПТО да осигури генериране на ФБ, съдържащ всички задължителни реквизити, съгласно Наредба №Н-18/2006 г.

 Не се допуска софтуерът да подава към ФУ за включване във ФБ като свободен текст (ограден с „#”) изискваните съгласно наредбата задължителни реквизити на ФБ -  напр. наименование на стоката/услугата, код на данъчна група, количество и стойност,  да се отпечатват като свободен текст.

Следва да се има предвид, че като реквизит във фискалната бележка се изисква да бъде посочван най-малко съответният вид на продаваната стока, в зависимост от предлагания в търговския обект асортимент, и цена.  Например, в обект за продажба на ядки минималната детайлизация на видовете стоки във ФБ следва да бъде: фъстъци, лешници, бадеми, орехи, кайсии, фурми, стафиди и т.н. При регистриране на продажба на различни стоки от един и същ вид, но  с различни цени, те следва да се посочват на отделен ред, заедно с количеството и стойността им.

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

Необходимо е да се приложи снимка на ФБ, вкл. за преценка дали съдържанието на ФБ отговаря на разпоредбата в чл. 26, ал.1 от Наредба Н-18.

Х

Х

Х

2.2.11.

Служебни бонове (СБ)

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

·             служебно въведени суми във ФУ;

·             служебно изведени суми от ФУ;

·             дневен финансов отчет без нулиране  и запис във ФП (Х-отчет); 

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

Х

Х

Х

2.2.12.

Анулиране на неприключила продажба

Изисква се софтуерът да поддържа функционалност за анулиране (пълно или частично) и съответно съхраняване на информацията за анулираните продажби. Реализацията на това изискване трябва да бъде обяснена и онагледена с екранна/и снимка/и.

Х

Х

Х

2.2.13.

Защита от преднамерено или случайно изтриване или промяна на вече записани данни за приключени продажби.

Сторниране на приключена продажба

Не трябва да има  функционалност за изтриване на записи.

Позволява се деактивиране на позиции от номенклатури, но не и тяхното физическо изтриване.

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

Х

Х

Х

2.2.14.

Отпечатване на други документи

При създаване  на други документи, различни от ФБ, и отпечатването им от нефискално печатащо устройство, не се допуска те да съдържат думите "Фискален", "Фискална", "Фискално", "Фискални" или производни словосъчетания. Изискването не се отнася до наименованията на търговците, които при отпечатване се придружават от правно-организационната им форма и техния ЕИК, както и до вида на закупуваната стока.

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

·             Когато от нефискален принтер се издават документи, чието съдържание наподобява съдържанието на ФБ (съдържат например вид, количество, цена на стока/услуга - например складови разписки, протоколи за предаване на стоки, оферти и др.), тези документи съдържат задължително надпис „По този документ не се дължи плащане“ с размер на шрифта, 3 пъти по-голям от шрифта на останалия текст. Това изискване не се отнася към отпечатването на нефискален принтер на фактури, доколкото те нямат характер на информационен документ, а формират задължение на лицето за плащане по продажба.

·             В ресторантските софтуери:

o   Бележките за кухня и  бар не трябва да съдържат стойности;

o   Информация за текуща сума по сметка на клиент -  Допуска се отпечатване от нефискално печатащо устройство на текущо дължимата сума само като обща стойност (без разбивка по артикули и цени);

o   Когато в хотел и ресторант към хотела се използват два СУПТО и се допуска гостите в хотела да не плащат при всяка консумация, а да платят всичко накрая на престоя си в хотела – допуска се в СУПТО на ресторанта да се издаде документ с наименование  „Информация за предоставени допълнителни стоки/услуги към хотелско настаняване“ който да се подпише от клиента. Документът съдържа минимум следните задължителни реквизити: УНП, № на стая, име на гост, наименование, количество, цена и обща стойност на предоставените стоки/услуги, дата, час и подпис на клиента.

Документът задължително съдържа  надпис „По този документ не се дължи плащане“ (Настоящият документ не удостоверява извършено плащане).

Х

Х

Х

2.2.15.

Структуриран лог на действията на потребителите

Софтуерът поддържа информация в структуриран вид като минимум за следните изпълнени действия:

а) въвеждане/промяна на потребителите (операторите) на софтуера и присвоената им роля в системата - кой и кога е извършил действието и описание на промяната;

б) данни, свързани с действията (операциите) на потребителите (операторите) на системата:

- име на потребителя (оператора);

- код на потребителя (оператора);

- роля;

- дата и час на действието (операцията);

- вид на действието (операцията) - регистрират се като минимум следните действия (операции): влизане и излизане в/от системата (login/logout), сторниране, анулиране и промени в номенклатурите на софтуера; за действия (операции) "сторниране" и "анулиране" на продажба - и уникалният номер на продажбата.

Х

Х

Х

2.2.16.

Визуализация на структурирания лог на действията

Изисква се онагледяване с екранни снимки.

Х

Х

Х

2.2.17.

Достъп до данни в сроковете по чл. 38, ал. 1 от ДОПК

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

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

**Под “архив” не се разбират регулярните  копия на БД (backup), които се правят с цел сигурност и защита. 

Х

Х

Х

2.2.18

Справочни таблици

Изисква се визуализация на справките по т.18 – екранни снимки, онагледяващи всяка една от справките  с данни от тестовата среда на производителя/разпространителя, вкл. и възможностите за филтриране на извежданата информация съгласно посочените в т. 18 критерии.

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

Не е достатъчно да се визуализира само меню и подменю с наименованията на таблиците по т. 18.1-18.9.

Х

Х

Х

2.2.19.

Одиторски профил

·  Вграден в софтуера одиторски профил;

·  Достъп

·  Функционалност на одиторския профил по т. 19 от Прил.29 (аналогичен на администраторски с права само за четене)

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

Трябва да бъде обяснено, как се достъпва одиторският профил; има ли значение от кое работно място се достъпва, кой предоставя User и парола и др.

Одиторският профил трябва да включва не   само таблиците по т. 18 от Прил.29, но и достъп:

Ø   До функционалността по т. 16 (структуриран лог на действията на операторите);

Ø   До данните, създавани чрез софтуера в сроковете по чл.38(1) от ДОПК (6-11 год); ако се правят архиви, достъп и до архивните данни през потребителски интерфейс;

Ø   До конфигурационните параметри на софтуера – трябва да са ясни параметрите, предмет на настройка при отделните потребители;

Ø   Пълен достъп до справочната част, която СУПТО осигурява;

Изисква се онагледяване с екранни снимки.

Х

Х

Х

2.2.20

Тестови режим на работа, режим за обучение или друг подобен /напр. демо-версия/

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

*Не е допустимо инсталиране и работа с демо-версии на софтуера в търговски обекти или офиси на клиенти.

Х

Х

Х

2.2.21.

Кой софтуер изпълнява изискванията по т. 16,17,18 и 19

Допуска се изискванията по т. 16,17,18 и 19 да не се изпълняват от софтуера, за който се подава декларация и информация, само когато приложените технологии за разработката му не го позволяват.

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

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

Х

Х

Х

III. ДРУГИ

3.1.

Импорт в СУПТО

/на заявки/поръчки/резервации/

·         от друг СУПТО

·         от източници, които не притежават характеристики на СУПТО

·         от софтуери на електронни магазини

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

Не се допуска импорт на данни за продажби /заявки, поръчки и др./ от други софтуери, които не са СУПТО, с изключение на посочените в т. ІІ от документ  „Разяснения относно импорт на данни за продажби в СУПТО…“, достъпен на уебсайта на НАП.

Ако има описан импорт – той следва да е реализиран при спазване на изискванията, посочени в документ  „Разяснения относно импорт на данни за продажби в СУПТО…“:

1.           Импорт в СУПТО_А от СУПТО_Б

2.           Импорт на данни за продажби от други източници, които не притежават характеристиките на СУПТО (най-често структурирани файлове)

СУПТО трябва да гарантира, че импортира заявките в пълен обем и с непроменено съдържание;

В БД се съхранява следната информация:

А) генерирания УНП при импорта

Б) идентификатор на заявката, присвоена от външния източник;

В) дата и време на импорт в СУПТО;

Г) източник на импортираните данни (например ЕИК на контрагент);

Д) начин на импорт (например API, електронен портал за получаване на заявки от бизнес-партньори, импорт от файл)

Е)пълни данни за всяка импортирана продажба

3.           Импорт на данни за продажби (поръчки) от електронен магазин – Допустим е, когато продажбите не се управляват чрез софтуера на електронния магазин.

Изисква се СУПТО да импортира заявките от електронния магазин чрез автоматизиран интерфейс; Предполага се, че СУПТО познава БД на електронни магазини, функциониращи на базата на конкретна свободно достъпна платформа за е-магазини в интернет; Производителят посочва от коя платформа (например OpenCart, Magento, ….. друга) осигурява импорт, към коя/кои таблица/и на какъв интервал се обръща за изчитане на информация за заявките.

В БД се съхранява следната информация:

А) генерирания УНП при импорта;

Б) оригинален  номер на заявката в БД на електронния магазин, съответстващ на генерирания УНП;

В) източник (наименование на домейна на електронния магазин),

Г) дата и време на импорт в СУПТО;

Д) пълни данни за всяка импортирана заявка.

Не се допуска софтуер, който се декларира като СУПТО, да „обяви“, че предлага функционалност за импорт в определена файлова структура, без да се направят допълнителни пояснения:

-  Какъв е видът (xml, txt….) и каква е структурата (полетата) на файла за импорт;

-  За какви източници на заявки за продажби е разработен импортът?

-  Какво съдържание се предвижда за поле  „източник на импортираните данни“?

В случай, че целта е да се импортират заявки от контрагенти, би следвало да се контролира  подаването на идентификационен номер (ЕИК) на контрагента.

-  Указва начина на импорт – API, ЕКОД, файл …

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

С това изискване се превентира възможността за неправомерен импорт на данни за продажби (заявки) от не-СУПТО.

Х

Х

Х

3.2.

Импорт в СУПТО на информация за приключени продажби

Допуска се в СУПТО да се въвежда информация за приключени продажби /от ФУ или от друг софтуер – не-СУПТО/. Това могат да бъдат следните примерни ситуации:

·      Извършват се продажби от ФУ без стационарен обект по време на панаири, изложения и др., които след приключване на събитието търговецът желае да отрази в  софтуер – СУПТО, използван в стационарния му обект;

·      Извършват се т.нар. мобилни продажби, без предварителна заявка, за тях се издава ФБ от мобилно ФУ, след което търговецът желае тези продажби да бъдат отразени в СУПТО в стационарния му обект (напр. склад);

·      Извършват се продажби чрез софтуер не-СУПТО,  използван в обект, в който не се приемат плащания, изискващи издаване на ФБ, след което търговецът желае тези продажби да бъдат отразени в използван от него СУПТО. Такива могат да бъдат, например:

·      Софтуер на е-магазин, в който се приемат само плащания, неизискващи издаване на ФБ;

·      Софтуер, използван в търговски обект, в който се извършват продажби, плащанията по които не изискват издаване на ФБ /например офис, в който се приемат само банкови плащания/.

В посочените по-горе случаи, при въвеждане в СУПТО на информацията за приключилите продажби, може да се приложи един от следните два подхода:

1)             Въвеждане на всяка отделна продажба, при което в СУПТО се  генерира УНП и продажбата се приключва с начин на плащане – неизискващ издаване на ФБ. Конфигурираният в СУПТО начин на плащане следва да позволява обвръзка с източника на импортираните продажби, например:

„Продажба чрез ФУ с ИН <въвежда се индивидуален номер на ФУ>“ или

„Продажба чрез е-магазин не-СУПТО“ <въвежда се домейнът на електронния магазин>;

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

„Продажба/и чрез ФУ с ИН <въвежда се индивидуален номер на ФУ>“ или

„Продажба/и чрез е-магазин не-СУПТО“ <въвежда се домейнът на електронния магазин>;

Х

Х

Х

3.3.

Експорт от СУПТО

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

Х

Х

Х

IV

ИНФОРМАЦИЯ ОТНОСНО ПРОЦЕСА НА ПРЕГЛЕД НА ПОДАДЕНАТА ДЕКЛАРАЦИЯ В НАП

4.1.

Първоначално подаване на декларация и информация за софтуера

Подадената декларация и прикачени документи се преглеждат в съответствие с направените по-горе разяснения.

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

Съобщението се изпраща на електронния адрес, вписан в КЕП, с който е подадена декларацията. 

Х

Х

Х

Х

4.2.

Корекция на върната от НАП декларация и информация за софтуера със статус „за корекция“

Корекциите, които се правят след връщане „за корекция“ през електронната услуга на НАП, следва не само да се опишат в отделен файл, но и да намерят отражение в прилаганите документи към декларацията – подробно ръководство за работа, реализация на изискванията съгласно Приложение №29, описание на БД и т.н.

При подаване на коригиращата декларация  е необходимо в част V – Прикачени документи, категория „Други“, да се прикачи допълнителен файл с наименование

„Отговор_по_бележки_за_корекция_<дата>.doc“. В него трябва да се отговори на всички въпроси и забележки, получени от през електронната услуга, както и да се посочи къде - в декларативната част и/или в прикачените документи (наименование, стр. №) е направена промяна.

**Към декларацията се прикачат само актуализираните документи, а предходните им състояния, прикачени при предходно подаване на декларация и информация, се премахват през електронната услуга - част  V, действие „Премахни“. Премахването не се отнася за файла/файловете „Отговор_по_бележки_за_корекция_<дата>.doc“.

Обработката на коригиращата декларация ще се извършва  приоритетно, по възможност в рамките на 2-3 работни дни от подаването й.

Х

Х

Х

Х

4.3.

Корекция на потвърдена от НАП декларация и информация – при настъпване на нови обстоятелства

При подаване на коригираща декларация за включен в публичния списък софтуер е необходимо в част V – Прикачени документи, категория „Други“, да се прикачи допълнителен файл с наименование „Описание_на_корекцията_<дата>.doc“. В него трябва да се изброят променените обстоятелства и да се посочи къде - в декларативната част и/или в прикачените документи (наименование, стр. №) е направена промяна.

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

**Към декларацията се прикачат само актуализираните документи, а предходните им състояния, прикачени при предходно подаване на декларация и информация, се премахнат през електронната услуга - част  V, действие „Премахни“.

Премахването не се отнася за файла/файловете

„Описание_на_корекцията_<дата>.doc“.

Х

Х

Х

Х

4.4.

Подаване на декларация за нова версия на включен в публични списък софтуер

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

„Промени_във_версия_<№ на версия>“.doc” следва да се посочи същността на промяната в новата версия, в съпоставка с предходната версия (упоменава се номерът й), както и дали са променени и кои от прикачените документи – ръководство за работа със софтуера, описание на БД и т.н. (посочват се наименование, секция, глава, страница,….)

**Към декларацията се прикачат само актуалните за версия документи, а подадените такива за предходни версии, се премахнат през електронната услуга - част  V, действие „Премахни“.

Премахването не се отнася за файла/файловете

„Промени_във_версия_<№ на версия>“.doc”

Х

Х

Еднократно –до 28.02. на следв.календарна година

Х