Списък с изискванията

• Софтуерът поддържа интерфейс на български език.
• Софтуерът осигурява пълнота и интегритет на данните, създавани при използването му.
• В случаите, в които софтуерът за управление на продажби в търговски обект представлява модул от софтуер, останалите модули не могат да имат дублираща функционалност за управление на продажбите или функционалност, целяща заобикаляне на изискванията в това приложение.
• Софтуерът съдържа вградена при разработването му защита от промяна или добавяне, без оторизация от производителя/разпространителя, на външни модули, позволяващи промяна на функционалността на софтуера с цел заобикаляне на изискванията, посочени в настоящото приложение.
• Софтуерът използва по възможност надежден източник на точно астрономическо време и задължително осигурява синхронизиране на времето между всяко работно място и използваното от него за печат ФУ.
• Софтуерът има вградени контроли за задължително попълване на данни за потребителите (операторите)- уникален код на потребител (оператор) в рамките на системата, три имена, заемана длъжност, роля в системата, начало/край на периода на активност на потребителя (оператора) за всяка от присвоените му роли.
• Софтуерът осигурява еднозначна автентикация на потребителите (операторите) при работа с него.
• Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за статуса на ФУ. Софтуерът блокира операциите по откриване и приключване на продажба в случаите, когато статусът на ФУ не позволява издаване на ФБ. Когато в търговския обект има повече от едно работно място, софтуерът блокира операциите по откриване/приключване на продажби и подаване на команда към ФУ за генериране на Дневен отчет (Z-отчет) за конкретното работно място, за което са установени посочените обстоятелства.
• При въвеждане в софтуера на информация за продажба софтуерът генерира уникален номер на продажбата (УНП), който се формира по следния начин - Индивидуален номер на ФУ - Код на оператор - Пореден номер на продажбата.
• При плащане по въведена в софтуера продажба, за което съгласно изискванията на настоящата наредба следва да бъде издаден ФБ, софтуерът задължително подава към фискалното устройство уникалния номер на продажбата за включването му във ФБ. Когато плащанията по продажбата са повече от едно, уникалният номер на продажбата се включва в издавания ФБ за всяко плащане, включително и в Сторно-ФБ, ако такъв бъде издаден.
• Софтуерът не допуска отпечатване на служебни бонове за направени клиентски поръчки в рамките на една продажба.
• При анулиране (пълно или частично) на открита, но неприключена софтуерът задължително съхранява в базата данни пълна информация за анулираната продажба - анулирани стоки/услуги, количество, стойност, оператор и др.
• Софтуерът трябва да има надеждна защита от преднамерено или случайно изтриване или промяна на вече записани данни за приключени продажби
  • софтуерът няма вградена функционалност за изтриване на записи в базата данни;
  • софтуерът позволява сторниране на приключени продажби (сторно-операции), като задължително съхранява сторнираните данни.
• При създаване на документи, различни от фискален бон, софтуерът не допуска включване на текст, съдържащ думите "Фискален", "Фискална", "Фискално", "Фискални" или производни словосъчетания. Изискването не се отнася до наименованията на търговците, които при отпечатване се придружават от правно-организационната им форма и техния ЕИК, както и до вида на закупуваната стока.
• Софтуерът поддържа информация в структуриран вид за следните изпълнени действия
  • въвеждане/промяна на потребителите (операторите) на софтуера и присвоената им роля в системата - кой и кога е извършил действието и описание на промяната;
  • данни, свързани с действията (операциите) на потребителите (операторите) на системата - име на потребителя (оператора); - код на потребителя (оператора); - роля; - дата и час на действието (операцията); - вид на действието (операцията)- регистрират се като минимум следните действия (операции)~ влизане и излизане в/от системата (login/logout), сторниране, анулиране и промени в номенклатурите на софтуера; за действия (операции) "сторниране" и "анулиране" на продажба - и уникалният номер на продажбата.
• Софтуерът осигурява визуализация през потребителски интерфейс на записаната по т.15 информация с възможност за филтриране по един или няколко критерия~ период, потребител (оператор), вид извършени действия, др.
• Чрез потребителски интерфейс софтуерът осигурява достъп до създаваните чрез него данни в сроковете по чл. 38, ал. 1 от ДОПК. При архивиране на базата данни софтуерът осигурява създаване и поддържане на архив, както и достъп до архивните данни в сроковете по чл. 38, ал. от ДОПК през потребителски интерфейс.
• Софтуерът следва да осигурява чрез потребителски интерфейс визуализация и експорт на данни от базата данни в табличен вид, файлов формат XLS/XLSX илиCSV, при прилагане на следните филтри~ За търговец (приSaaS); За период (от дата до дата) и/или За търговски обект (всички или конкретно посочен), и/или За ФУ, на което са регистрирани продажбите (всички ФУ или конкретно ФУ), и/или За работно място (всички или конкретно посочено), и/или За оператор (всички или конкретно посочен). Експортираните данни са със следната структура
  • Обобщени данни за продажбите
  • Данни за плащанията по продажбите
  • Детайлни данни за продажбите
  • Сторнирани продажби
  • Анулирани продажби
  • Обобщени данни за доставки (ако софтуерът разполага с функционалност за регистриране на доставки)
  • Детайлни данни за доставки (ако софтуерът разполага с функционалност за регистриране на доставки)
  • Движение на стоки за период (ако софтуерът разполага с функционалност за проследяване движението на стоките)
  • Движение на стоки за период (ако софтуерът разполага с функционалност за проследяване движението на стоките)
  • Таблици с номенклатури на стоки/услуги, доставчици, клиенти, видове операции, видове плащания, търговски обекти, работни места, потребители , роли на потребителите, права
• За целите на контролната дейност на НАП всеки софтуер следва да има конфигуриран "одиторски профил" по аналог с администраторския профил, но с права само за четене. Одиторският профил трябва да предоставя като минимум следните възможности~
  • достъп до функционалността на софтуера съгласно т.16, 17 и18 (приSaaS - за съответния търговец);
  • достъп до конфигурационните параметри на софтуера (приSaaS - за съответния търговец);
  • пълен достъп до справочната част на софтуера (при SaaS - за съответния търговец).
• Софтуерът не притежава възможност за работа в тестови режим, режим за обучение или друг подобен.
• Когато софтуерът е част от или е свързан с интегрирана информационна система за управление на продажбите/търговската дейност на лицето по чл.3 и използваната технология за реализацията му не позволява изпълнението на всички или на част от изискванията по т. 16, 17, 18 и 19, изпълнението на тези изисквания следва да бъде осигурено чрез функционалността на интегрираната система.