2. barsy SUPTO и Наредба Н-18

Документа съдържа информация как “barsy SUPTO” реализира изискванията на Наредба Н-18

2.1. Изисквания

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

“barsy SUPTO” поддържа изцяло интерфейс на български език. Всички допълнителни езици са опционални. Ако дадена инсталация е конфигурирана да работи с друг език по подразбиране, то той може да бъде променен от настройките на конкретния потребител.

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

Изискването е реализирано в “barsy SUPTO” по няколко способа:

  • ниво “database”
    • използва се реалационна база данни с твърдо заложени връзки между логическите единици. Това елиминира възможност за изтриване на номенклатури, които са използвани в други операции
  • ниво “бизнес логика”
    • програмата не позволява изтриване на данни, свързани с приключени операции (продажби, плащания, всички складови действия) и номенклатури (артикули, клиенти, контрагенти и т.н.)
    • допълнително при работа с продажби - всяка корекция на неприключена сметка се записва като история на промяна на сметката.
    • програмата поддържа “маркиране като изтрит” за номенклатурите, които вече не се използват, но са свързани с направена операция. Те се маркират като “изтрити”, но реално съществуват в системата, могат да бъдат търсени, виждат се в справки и по тях може да се филтрира. Функционалността се активира автоматично при опит да се използва “изтриване” на използвана номенклатура. Няма загуба на информация. Действието се записва
  • ниво “сигурност” - всяко действие (или неуспешен опит за такова) през интерфейсите на програмата се записва, независимо от кого се извършва - всяка корекция на неприключена операция или действаща номенклатура се регистрира с данните на промяната

Разрешени са изтриване на следните данни:

  • номенклатури (артикули, клиенти, контрагенти) за които НЯМА НИКАКВО движение/операция/използване по никакъв повод. Считат се за създадени по грешка и могат да се изтрият. Това действие се регистрира както всички останали в дневник на събития с всички данни и може да бъде проследено
  • помощни номеклатури (категории), нямащи никакви ангажиращи действия към паричен поток, складови наличности, баланс и прочее отчетност. Тяхното предназначение е помощно и не влия на интегритета на данните. Това действие се регистрира както всички останали в дневник на събития с всички данни и може да бъде проследено
  • неприключени операции складови операции (зареждане, прехвърляне, ревизия), които се считат за “чернова” - не влияят по никакъв начин на паричен поток, складови наличности, баланс и прочее отчетност. Тяхното възникване е по операторска грешка. Това действие се регистрира както всички останали в дневник на събития с всички данни и може да бъде проследено

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

“barsy SUPTO” не е модул от софтуер, а самостоятелно действаща система

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

“barsy SUPTO” се разпространява с криптираща сорса система IonCube Encoder, която предотвратява възможността от външна намеса в начина на работа на софтуера и включване на външни модули, заобикалящи изискванията.

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

“barsy SUPTO” използва международна система за точно време Network Time Protocol project, работеща по протокола NTP. Операционна система периодично проверява вътрешния часовник за разлика спрямо сървърите на организацията и при нужда го сверява. Всички работни места и ФУ сверяват свойте часовници спрямо вътрешния часовник на сървъра на системата. При липса на връзка с интернет и наличие на нелогично текущо време на вътрешния часовник спрямо направените операции, “barsy SUPTO” спира функционирането на цялата система за да предотврати грешни данни.

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

Изискването е реализирано по следните начини:
  • Полетата за въвеждане на трите имена, заемана длъжност и роля в системата в даните на даден потребител са задължителни за попълване. Не може да бъде въведен нов потребител или да бъде редактиран съществуващ, ако полетата не са попълнени.
  • При запис, ситемата автоматично назначава уникален код на потребителя в рамките на системата. Той се използва като референция във всички операции, които изпълнява потребителя. Кодът е видим при преглед на потребител
  • Всяко начало/край на периода на активност на потребителя се записва в списъка с работените му смени
  • Всяко редактиране на потребител се записва в дневник на събития
../_images/61.png

Редактиране на потребителско име, парола и роля

../_images/62.png

Редактиране на имена на потребител


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

Изискването е реализирано по следните начини:
  • за достъп до Администрацията - всеки потребител получава уникален потребител и парола за вход. Те определят еднозначно кой е той и какви права има.
  • за достъп до модул Продажби - всеки потребител получава уникален PIN код за вход. Той определят еднозначно кой е потребителя и какви права има.(screen)
../_images/71.png

Вход в администрацията

../_images/72.png

Вход в модул Продажби

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

Изискването е реализирано по следните начини:

  • Операците “отваряне” или “приключване” на продажба могат да се извършат само при налична свързаност с фискално устройство от системата. За целта, при изпълнение на операция “отваряне” или “приключване” на продажба се прави проверка за връзка до устройството, като се използва функция за взимане на текущ статус.

    • Ако проверката е успешна - операцията продължава
    • Ако устройството не отговаря нормално или няма връзка с него, операцията се прекратява като на потребителя се извежда грешка за проблем
    ../_images/81.png
  • Операцията “Приключване на касов период” (Z-отчет) може да се извърши само при налична свързаност с всички фискални устройство, конфигурирани в системата. Ако с някое от тях няма връзка, касовият период не може да бъде приключен.

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

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

Изискването е изпълнено по следния начин за различните операции:

Клиентски заявки:

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

  • проверка за връзка с фискално устройство
  • получаване на сериен номер на фискалното устройство
  • взимане на пореден свободен номер за текущия потребител и това фискално устройство
  • записване на номера, формиран като “Индивидуален номер на ФУ - Код на оператор - Пореден номер на операцията” към текущия документ.

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

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

../_images/93.png

Виждане на УНП в списък със клиентски заявки

../_images/94.png

Виждане на УНП в преглед на клиентска заявка

Сметки:

При отваряне на нова сметка (без предходящ документ “клиентска заявка”), за нея се генерира уникален номер на продажба (УНП). Той се създава еднокрано и не може да бъде променян. Записва се в базата към сметката. Изпълняват се следните стъпки:

  • потребителя избира желаните артикули и натиска Запиши
  • стартира процес по създаване на сметка. Той включва:
    • проверка за връзка с фискално устройство
    • получаване на сериен номер на фискалното устройство
    • взимане на пореден свободен номер за текущия потребител и това фискално устройство
    • записване на номера, формиран като “Индивидуален номер на ФУ - Код на оператор - Пореден номер на операцията” към текущия документ.
При приключване на сметката се изпълняват следните стъпки:
  • потребителя натиска “Приключване”
  • стартира се процес по приключване на сметка. Той включва:
    • проверка за връзка с фискално устройство
    • получаване на сериен номер на фискалното устройство
    • подаване на данните за продажбата, включващи УНП, артикули с цени и количества, начин на плащане.
    • при успешно финализиране на разпечатването, софтуера маркира сметката като приключена
../_images/95.png

Примерни билежки за продажба с УНП и сторниране на бележка със същото УНП

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

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

../_images/91.png

Виждане на УНП в списък със сметки

../_images/92.png

Виждане на УНП в преглед на сметка

Фактури:

След приключване на сметка, по нея може да се създаде фактура. Фактурата получава връзка със сметката, от която се създадена и наследява нейното УНП

../_images/96.png

Визуализиране на връзката между сметка и фактура

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

Изискването е реализирано по следния начин:

Допълнителни плащания:

“barsy SUPTO” дава възможност за създаване на допълнително плащане по сметка, която не е била платена изцяло при приключването. Извършват се следните стъпки:

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

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

Сторниране на приключена сметка:

При сторниране на приключена сметка, сторниращата сметка получава същото УНП, като сторнираната сметка. Операцията може да бъде извършена само при следните условия:

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

При приключване на сторниращата сметка, операцията се отразява в фискалното устройство с фискална бележка от тип “Сторно”.

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

Изискването е реализирано по следния начин:

  • В рамките на времето, преди приключване на продажба, софтуерът допуска отпечатване на служебни бонове/бележки със следните ограничения:
  • отпечатаните бележки могат да съдържат имена на артикули и количества (с цел обслужване на поръчката)
  • отпечатаните бележки НЕ могат да съдържат единични цени и обща сума на сметката
  • отпечатаните бележки НЕ могат да наподобяват визуално фискална бележка
  • отпечатаните бележки се създават от служебни принтери
  • След приключване на сметката, софтуера допуска отпечатване на служебни бонове с всички реквизите на сметката със следното предназначение:
  • стокова разписка
  • приемо-предавателен протокол
  • информационна бележка за разнос
  • други подобни, с ясно разписано предназначение, неимитиращи фискални бележки

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

Изискването е реализирано по следния начин:

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

../_images/121.png

История на корекциите в сметка

13. Софтуерът трябва да има надеждна защита от преднамерено или случайно изтриване или промяна на вече записани данни за приключени продажби:
  • софтуерът няма вградена функционалност за изтриване на записи в базата данни;
  • софтуерът позволява сторниране на приключени продажби (сторно-операции), като задължително съхранява сторнираните данни.

Изискването е реализирано по следния начин:

  • Софтуерът няма вградена функционалност за изтриване на записи в базата данни;
  • Достъпът до базата данни се подсигурява чрез ограничаване само на локален достъп чрез потребител и парола.
  • Софтуерът осигурява интегритет на въведените данни (както е описано подробно в т.2 от този документ)
14. При създаване на документи, различни от фискален бон, софтуерът не допуска включване на текст, съдържащ думите “Фискален”, “Фискална”, “Фискално”, “Фискални” или производни словосъчетания.

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

Изискването е реализирано по следния начин:

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

  • Привежда всички буквени символи в главните им представяния (uppercase)
  • Премахват се всякакви символи които не представляват буква от българската азбука
  • В получения резултат проверява за следните последователности от символи: ФИСКАЛЕН, ФИСКАЛНА, ФИСКАЛНО, ФИСКАЛНИ

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

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

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

Изискването е реализирано по следния начин:

Всяко действие към софтуера се записва в “Дневник на събития”. За всяко действие се съхранява следната информация:
  • уникален номер на потребителя
  • дата/час на операцията
  • IP адрес на потребителя
  • изпълнена операция (вход, редактиране на номенклатура, продажба и т.н.)
  • параметри на операцията (уникален номер на номенклатура, уникален номер на операция)
../_images/151.png

Дневник на събития

../_images/reports_logs_detail.png

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

Изискването е реализирано по следния начин:

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

../_images/161.png

Дневник на съботия - основен списък

../_images/reports_logs_filters.png

Дневник на съботия - филтри по действие

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

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

Изискването е реализирано по следния начин:

  • Осигурен е достъп до всички данни, създавани от софтуера, чрез наличие на справочна част, която може да визуализира и филтрира необходимата информация.
  • Никаква част от данните не се премахва или скрива при създаване на операция “Архив/резервно копие”.
../_images/171.png

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


18. Софтуерът следва да осигурява чрез потребителски интерфейс визуализация и експорт на данни от базата данни в табличен вид, файлов формат XLS/XLSX или CSV,

при прилагане на следните филтри: За търговец (приSaaS); За период (от дата до дата) и/или Затърговски обект (всички или конкретно посочен), и/или За ФУ, на което са регистрирани продажбите (всички ФУ или конкретно ФУ), и/или За работно място (всички или конкретно посочено), и/или За оператор (всички или конкретно посочен).

../_images/181.png

Всички справки могат да бъдат екпортвани в XLS/XLSX или CSV

Експортираните данни са със следната структура:

../_images/181.png

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

../_images/182.png

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

../_images/183.png

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

../_images/184.png

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

../_images/185.png

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

../_images/186.png

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

../_images/187.png

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

../_images/188.png

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

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

../_images/1891.png

18.9.1 стоки/услуги- код, наименование, дата на първоначално конфигуриране в системата,дата на последна промяна

../_images/1892.png

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

../_images/1893.png

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

../_images/1894.png

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

../_images/1895.png

18.9.5 видове плащания - код, наименование, дата на първоначално конфигуриране в системата, дата на последна промяна

../_images/1896.png

18.9.6 търговски обекти - код, наименование, местонахождение, дата на първоначално конфигуриране в системата, дата на последна промяна

../_images/1897.png

18.9.7 работни места- код, търговски обект, в който се намира, индивидуален номер на свързаното към него ФУ, дата на първоначално конфигуриране в системата, дата на последна промяна

../_images/1898.png

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

../_images/1899.png

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

../_images/18910.png

18.9.10 права, присвоявани на ролите - код, наименование, описание, дата на конфигуриране/деактивиране

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

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

Изискването е реализирано по следния начин:

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

Одиторският профил е предназначен за осъществяване на данъчен контрол над системата съгласно Наредба Н-18. Достъпът до него се осъществява през стандартния вход в администрацията на система barsy със служебно издадени потребител и парола. След вход с този потребител, контролните органи имат достъп до информацията (в съответствие с т. 19 от Приложение 29 на Наребна Н18) с права само за четене.

В “barsy SUPTO” има конфигуриран “одиторски профил”, който може да се използва по следния начин

Създаване на достъп

  • потребител на системата с права Мениджър, влиза в администрацията и избира Помощ > Одиторски профил > Създаване на достъп
  • генерира се нова парола, която е валидна до деактивиране от мениджър и се визуализира на екрана. По желание, същата може да бъде отпечатана на принтер, свързан със системата.
  • адреса за достъп, служебното потребителско име и генерираната парола се предават на контролния органа.
../_images/191.png
../_images/192.png

Използване на достъп

  • получения адрес, потребител и парола се използват като стандартен потребител в Администрацията
  • необходими са :
    • Компютър с достъп до локалната мрежа, в която се намира сървъра с инсталацията на Barsy
    • Инсталиран и актуализиран браузер до последна версия (Google Chrome, Mozilla Firefox, Internet Explorer, Safari)
../_images/71.png

В получените данни се влиза през стандартния интерфейс в Администрацията

../_images/171.png

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

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

Изискването е реализирано по следния начин:

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

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

Изискването е реализирано по следния начин:

Софтуерът не е част от интегрирана система за управление и сам реализира изискванията по т. 16, 17, 18 и 19