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

1. Софтуерът поддържа интерфейс на български език.

Софтуерът поддържа интерфейс на български език.

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

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

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

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

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

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

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

Софтуерът следи разликата във времената на фискалното устройство и системата (чието астрономическо време се сверява чрез NTP от надеждни източници) и при откриване на разлика по-голяма от 2 часа се блокират операциите по откриване и приключване на продажби. При разлика по-голяма от 5 минути се извежда предупреждение към оператора.

Софтуерът осигурява функционалност за сверяване на времето на ФУ с времето на системата.

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

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

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

Всяка промяна по настройките на потребителите се съхранява в отделен журнал на промените.

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

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

Потребителите се автентикират към системата с уникална комбинация от клиентски код, потребителско име и парола.

8. Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за статуса на ФУ. Софтуерът блокира операциите по откриване и приключване на продажба в случаите, когато статусът на ФУ не позволява издаване на ФБ. Когато в търговския обект има повече от едно работно място, софтуерът блокира операциите по откриване/приключване на продажби и подаване на команда към ФУ за генериране на Дневен отчет (Z-отчет) за конкретното работно място, за което са установени посочените обстоятелства.

Свързаността с ФУ се осъществява чрез драйвер за управление на фискални устройства на различни производители EDA FPGate.

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

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

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

Индивидуален номер на ФУ - Код на оператор - Пореден номер на продажбата. Отделянето на елементите в уникалния номер на продажбата със знак "-" е задължително.

Пример за УНП: XXXХХХХХ-ZZZZ-0000001, където ХХХХХХXX- 8-разряден индивидуален номер на ФУ, присвоен от производителя, ZZZZ - 4-разряден код на оператора, въвел данните за продажбата, съгласно номенклатурата на софтуера,0000001 - 7-разряден пореден номер на продажбата, формиран поотделно за всеки индивидуален номер на ФУ. Номерът нараства възходящо със стъпка 1 за всяка продажба и съдържа само арабски цифри.

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

Индивидуален номер на ФУ (получен от регистъра на ФУ) - Код на оператор (оператор асоцииран с ФУ) - Пореден номер на продажбата (брояч на пореден номер в контекста на ФУ в регистъра).

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

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

11. Софтуерът не допуска отпечатване на служебни бонове за направени клиентски поръчки в рамките на една продажба.

Софтуерът не допуска отпечатване на служебни бонове за направени клиентски поръчки.

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

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

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

• софтуерът няма вградена функционалност за изтриване на записи в базата данни;

• софтуерът позволява сторниране на приключени продажби (сторно-операции), като задължително съхранява сторнираните данни.

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

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

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

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

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

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

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

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

- роля;

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

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

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

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

б) всяка сесия на потребителите съдържа подробна информация за действията в лог на активността, който съдържа следната информация: име/код на потребителя (оператора), дата и час на действието (операцията), IP адрес, вид на действието. Регистрират се всички действия включително влизане и излизане в/от системата, редакция, сторниране, анулиране и промени в номенклатурите на софтуера; за действия (операции) "сторниране" и "анулиране" на продажба – и уникалният номер на продажбата.

16. Софтуерът осигурява визуализация през потребителски интерфейс на записаната по т. 15 информация с възможност за филтриране по един или няколко критерия: период, потребител (оператор), вид извършени действия, др.

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

17. (доп.- ДВ, бр. 26 от 2019 г., в сила от 29.03.2019 г.) Чрез потребителски интерфейс софтуерът осигурява достъп до създаваните чрез него данни в сроковете по чл. 38, ал. 1 от ДОПК. При архивиране на базата данни софтуерът осигурява създаване и поддържане на архив, както и достъп до архивните данни в сроковете по чл. 38, ал. 1 от ДОПК през потребителски интерфейс. Не се изисква достъп до архивните данни в случаите, в които създаваната чрез софтуера информация се съхранява в текущата база данни в посочените срокове.

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

18. Софтуерът следва да осигурява чрез потребителски интерфейс визуализация и експорт на данни от базата данни в табличен вид, файлов формат XLS/XLSX или CSV, при прилагане на следните филтри: За търговец (при SaaS); За период (от дата до дата) и/или За търговски обект (всички или конкретно посочен), и/или За ФУ, на което са регистрирани продажбите (всички ФУ или конкретно ФУ), и/или За работно място (всички или конкретно посочено), и/или За оператор (всички или конкретно посочен). Експортираните данни са със следната структура:

Софтуерът осигурява чрез потребителски интерфейс визуализация и експорт на данни от базата данни в табличен вид, файлов формат XML, Excel XML (XLS) и CSV. Наборът от изискуемите справки по т. 18.1-18.7 са обособени в отделна секция потребителски отчети „Наредба Н-18“. Справка по т. 18.8 се покрива от отчет „Отчети/Складово стопанство/Оборотна ведомост“. Изискванията по т. 18.9 се покриват от функционалността на следните регистри: асортименти, доставчици, клиенти, начини на плащане, клонове/обекти на фирмата, работни места, фискални устройства, потребители, групи и роли.

18.1. Таблица - Обобщени данни за продажбите:

18.2 Таблица - Данни за плащанията по продажбите:

18.3. Таблица - Детайлни данни за продажбите:

18.4. Таблица - Сторнирани продажби:

18.5. Таблица - Анулирани продажби:

18.6. Таблица - Обобщени данни за доставки (ако софтуерът разполага с функционалност за регистриране на доставки):

18.7. Таблица - Детайлни данни за доставки (ако софтуерът разполага с функционалност за регистриране на доставки):

18.8. Таблица - Движение на стоки за период (ако софтуерът разполага с функционалност за проследяване движението на стоките):

18.9. Таблици с номенклатури на:

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

19. За целите на контролната дейност на НАП всеки софтуер следва да има конфигуриран "одиторски профил" по аналог с администраторския профил, но с права само за четене.

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

- достъп до функционалността на софтуера съгласно т.16, 17 и18 (при SaaS – за съответния търговец);

- достъп до конфигурационните параметри на софтуера (при SaaS - за съответния търговец);

- пълен достъп до справочната част на софтуера (при SaaS - за съответния търговец).

Софтуерът има конфигуриран „одиторски профил„ (роля/вид потребител „Одитор“) с пълни права за четене на всички регистри в системата, достъп до пълната функционалност, достъп до конфигурационните параметри и генериране на отчети.

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

Софтуерът няма обособен тестов режим на работа.

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

Софтуерът е цялостна интегрирана информационна система.