СкладИН18. Универсална складова програма

СкладНТ меню

 Как СкладИН18 реализира изискванията на Наредба Н-18


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

СкладИН18 поддържа изцяло интерфейс на български език.

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

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

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

СкладИН18 не е модул от софтуер, а самостоятелно действаща система.

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

СкладИН18 се компилирана и свързана програма, към която е невъзможно да се сключат външни модули, заобикалящи изискванията.

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

Операционна система периодично проверява вътрешния часовник на компютъра и при нужда го сверява. Всички ФУ сверяват свойте часовници спрямо вътрешния часовник на компютъра.

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

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

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

Всяко влизане и излизане на потребител в системата се записва в дневник на събитията.

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

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

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

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

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

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

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

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


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

При създаване на документ за продажба, за нея се генерира уникален номер на продажба (УНП). Изпълняват се следните стъпки:
  • проверка за връзка с фискално устройство
  • формиране на УНП от конфигурирания сериен номер на фискалното устройство, кода на текущия оператор и пореден номер на продазбата за текущото ФУ.
  • записване на УНП в текущия документ.
Създадения номер не може да бъде променян. По него може да се извърши търсене и проследяване.

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

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

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

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

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

Операцията може да бъде извършена само при следните условия:
  • подаване на номер на сторнирана продажба (от която се взима УНП, дата, номер на ФБ и номер на ФП)
  • достатъчна касова наличност, регистирана във фискалното устройство.
  • налична връзка с фискално устройство за касата, която сторнира
  • При приключване на сторниращата продажба, операцията се отразява в фискалното устройство с фискална бележка от тип “Сторно”.

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

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

При частично анулиране на неприключена продажба СкладИН18 прави сторно на анулирания артикул. При пълно анулиране на неприключена продажба СкладИН18 поставя нула в общата стойност на продажбата, но запазва непроменени включените артикули в нея. Така се запазва пълна информация за анулираната продажба.

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

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

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

При редактиране на информация, свързана с оформянето на бележките/боновете, софтуерът проверява въведените от потребителя данни за наличието следните последователности от символи: ФИСКАЛЕН, ФИСКАЛНА, ФИСКАЛНО, ФИСКАЛНИ. При наличие на съвпадение, операцията се прекратява и потребителя получава съобщение за грешка.

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

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

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

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

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

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

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

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

Експортираните данни са с опсочените в наредбата структура. Експостират се следните таблици:
  • 18.1. Таблица - Обобщени данни за продажбите
  • 18.2. Таблица - Данни за плащанията по продажбите
  • 18.3. Таблица - Детайлни данни за продажбите
  • 18.4. Таблица - Сторнирани продажби
  • 18.5. Таблица - Анулирани продажби
  • 18.6. Таблица - Обобщени данни за доставки
  • 18.7. Таблица - Детайлни данни за доставки
  • 18.8. Таблица - Движение на стоки за период
  • 18.9. Таблици с номенклатури на
    • 18.9.1 стоки/услуги
    • 18.9.2 доставчици
    • 18.9.3 клиенти
    • 18.9.4 видове операции (действия)
    • 18.9.5 видове плащания
    • 18.9.6 търговски обекти
    • 18.9.7 работни места
    • 18.9.8 потребители (оператори)
    • 18.9.9 роли на потребителите (операторите) на софтуера
    • 18.9.10 права, присвоявани на ролите

19. За целите на контролната дейност на НАП всеки софтуер следва да има конфигуриран “одиторски профил” по аналог с администраторския профил, но с права само за четене. Одиторският профил трябва да предоставя като минимум следните възможности:
  • достъп до функционалността на софтуера съгласно т.16, 17 и 18;
  • достъп до конфигурационните параметри на софтуера;
  • пълен достъп до справочната част на софтуера.

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

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

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

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

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