Защо отново трябва да си сменям касовия апарат?

Posted by System Administrator 18/12/2018 0 Comment(s)

 

 


 

 

Защо отново трябва да си сменям касовия апарат?

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

 

Какво трябва да направя?

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

 

1. сервизната  организация, с която имате сключен договор за техническо обслужване и ремонт;

 

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

 

3. от интернет страницата на НАП.

 

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

 

Какви са сроковете?

 

Март 2019 г. – изтича срокът за всички, които са регистрирани по ЗДДС, с изключение на лицата, използващи ЕСФП и ИАСУТД. Юни 2019 г. – изтича срокът за нерегистрираните по ЗДДС лица и лицата, използващи ЕСФП.

 

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

 

Защо да бързам, срокът ми изтича след месеци?

 

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

 

Какво ще стане, ако работя с  фискално устройство, което не отговаря на новите изисквания?

Неспазването на заложените в Наредба Н-18/2006 г. срокове неминуемо ще доведе до запечатване на търговски обекти и налагане на глоби и/или имуществени санкции, което никога не е било цел на Национална агенция за приходите. В тази връзка НАП създава необходимата организация за безпроблемното и своевременно реализиране на промяната.

 

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

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

Описаната от Вас функционалност на софтуера попада в обхвата на определенията  за „софтуер за управление на продажбите“ съгласно §1, т. 84 от Допълнителните разпоредби (ДР) на Закона за данъка върху добавената стойност (ЗДДС) и „управление на продажбите“ съгласно §1, т. 19 от ДР на Наредба Н-18/2006 г.  В случай, че този софтуер се използва в търговски обекти, в които съгласно чл. 3, ал. 1 от Наредба Н-18/2006 г. е налице задължение за издаване на фискален бон, т.е. извършват се  например плащания в брой, с дебитна или кредитна карта и др., то той трябва да бъде свързан с фискално/и устройство/а (ФУ). Фактът, че към момента няма разработена функционалност за връзка към ФУ, не може да бъде причина за изключване на софтуера от изискванията на Наредба Н-18/2006 г. и такава функционалност трябва да бъде разработена. 

 

Ако не е задължително свързването му, изискванията от приетата наредба важат ли за него?

Изискванията, посочени  в Приложение №29 от Наредба Н-18/2006 г., важат за софтуера при условията, посочени в отговора на Въпрос №1. 

 

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

Доколкото Вашият софтуер отговаря на определението за софтуер за управление на продажбите, той следва задължително да бъде свързан и да управлява въведените в експлоатация ФУ в обекта.

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

 

Даден електронен магазин трябва ли да е свързан с касов апарат?

По смисъла на определението за търговски обект, съдържащо се в §1, т. 41 от  ДР на ЗДДС, електронният магазин е търговски обект, от който се извършват продажби. Когато лицето, извършващо продажби чрез електронен магазин, използва за дейността си софтуер за управление на продажбите и за извършваните продажби е налице задължение за издаване на ФБ съгласно чл. 3, ал. 1 от Наредба Н-18/2006 г.,  софтуерът трябва да отговаря на изискванията на наредбата, респективно, той трябва да бъде свързан с ФУ.

 

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

Специфични изисквания към лицата, които извършват продажби чрез електронен магазин, се съдържат в Глава седма „г“ на Наредба Н-18/2006 г. Съгласно чл. 52н те „са длъжни да съхраняват в сроковете по чл. 38, ал. 1 от ДОПК създаваната чрез софтуера на електронния магазин информация (текуща база данни и архивни копия на базата данни) и при поискване от органите по приходите да осигурят достъп до нея с възможност за експорт и копиране на данни.“ Няма дефинирана конкретна структура, в която да се експортират данните от базата данни на електронния магазин.

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

 

В публикуваната структура на КЛЕН експорта, Приложение 34, т.4, по описания в Наредбата експорт в табличен вид не фигурират някои важни събития от бона, например отстъпки, надбавки, войдове, видове плащания и т.н. Ето и конкретни въпроси:

  • Очаква ли се дадените отстъпки да се включат в експорта като се отнеме от оборота на съответния артикул (което би променило идеята за КЛЕН експорт (ударението е върху КЛЕН), а ще стане обикновен експорт на данни от ФУ). 

Не се очаква експорт на всички данни от ФБ, а само на посочените в приложението. При фискалните бонове (ФБ) с включени отстъпки, надбавки и войдове няма  да има равнение между стойността на стоките (количество * единична цена) и общата сума на ФБ. В хода на контролни производства „липсващите“ в структурирания експорт елементи от бона ще се проверяват в базата данни на софтуера.

  • На всеки ред ли очаквате всичката информация (поне така е описано, или ще има заглавен ред с ФДРИД, УНП, номер на бон, следващи редове със самите стоки, и закриващ ред с данни за плащанията и тоталите, номера на оригинални документи, ЕИК и други ? 

На всеки ред се очаква описаната информация. Изискването е формулирано по този начин с оглед улеснено последващо зареждане и анализ на експортираните от КЛЕН данни в специализиран софтуер, използван от органите на приходите в НАП.

  • Може ли да публикувате примерен бон с няколко артикула, няколко платежни средства, с отстъпки и надбавки, поне един войд, както и структурирания експорт на този бон ?

………..

Как НАП си гарантира, че структурираният експорт от КЛЕН на ФУ по Приложение 34 съдържа коректна информация ? Файлът се подписва от сервизен техник след като е направен експортът (и то ако експорта се прави от КЛЕН – има и хипотеза по Приложение 29, чл.  ). Добрите практики водят към нужда от подписване на експортния файл от самият принтер, за да се гарантира непромяната на информацията от сервизния техник.

Считаме, че при възникване на съмнения за манипулиране на експорта от КЛЕН може да бъде направен повторен експорт, тъй като лицето е задължено да съхранява КЛЕН в сроковете по чл. 38 от ДОПК. Предложението може да бъде  обсъдено при подготовка на бъдещи изменения в Наредба Н-18/2006 г.

 

Ако УНП е задължителен реквизит (съгласно чл. 26, т.17) при използване на СУПТО, как ще се инсталират във времето новите ФУ и СУПТО (говорим за периода преди 31.03.2019)? Как ще може да работи новият тип ФУ без инсталиран СУПТО (с досегашния недеклариран софтуер), как може да работи СУПТО без новите принтери ? Новите типове ФУ ще очакват УНП и ако не го получат, няма да позволят отварянето на ФБ; от друга страна, СУПТО ще предава команда за отваряне на бон с УНП и ще получава грешка от старото ФУ (невалиден параметър). Единственият вариант, за който се сещам, е да се направят ФУ да изискват УНП като задължителен реквизит на бона САМО след първо получаване на УНП; т.е. да може да се инсталират ФУ от новия тип и да не изискват УНП, докато СУПТО не бъде инсталиран в обекта.

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

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

Как ще се случи това: Когато софтуерът е част от или е свързан с интегрирана информационна система за управление на продажбите/търговската дейност на лицето по чл. 3 и използваната технология за реализацията му не позволява изпълнението на всички или на част от изискванията по т. 16, 17, 18, и 19, изпълнението на тези изисквания следва да бъде осигурено чрез функционалността на интегрираната система. Голяма част от СУПТО са просто касови програми, работят само с дневни бази и получават номенклатурата си, цените от централизирани системи (SAP, MS NAV, AS 400 etc.). Тези касови програми нямат модули за заявки, доставки, промоции  и други. Означава ли новият текст в наредбата, че на тези централизирани системи SAP, MS NAV, AS 400 и други им се вменява изпълнението на т.т.16-19,. без тези софтуери да подлежат на деклариране ?!

Именно поради използването в практиката на т.нар. „касови програми“, които са с твърде ограничена функционалност, Наредба Н-18/2006 г. допуска: „Когато софтуерът е част от или е свързан с интегрирана информационна система за управление на продажбите/търговската дейност на лицето по чл. 3 и използваната технология за реализацията му не позволява изпълнението на всички или на част от изискванията по т. 16, 17, 18, и 19, изпълнението на тези изисквания следва да бъде осигурено чрез функционалността на интегрираната система.“ (Приложение №29, т. 21 от Наредба Н-18/2006 г.)

В случай, че „интегрираната система“ не попада в обхвата на определението за „софтуер за управление на продажбите“ съгласно §1, т. 84 от Допълнителните разпоредби (ДР) на Закона за данъка върху добавената стойност (ЗДДС), то за нея не се изисква подаване на декларация съгласно чл. 52б, ал. 1 от Наредба Н-18/2006 г.

 

Не става ясно как се процедира при подмяна на ФУ от една каса на друга, в обект с повече от една каса, и формираният от СУПТО УНП. Според т.9 от Приложение 29, третата част от УНП, 0000001 в примера от наредбата е 7-разряден пореден номер на продажбата, формиран поотделно за всеки индивидуален номер на ФУ. Т.е. в описаната от мен хипотеза, ако ФУ бъде преместен от една каса на друга, то новата каса ще трябва да си нулира поредния номер на продажбата и да почне отново от номер 0000001; така обаче, ако касиерът в двата случая е един и същ, ще има дублиране на номерацията на боновете, издавани от едната (в момента) и от другата (в минал период) каса;

Въпросът се нуждае от уточнение.

Ако под „каса“ се разбира работно място в даден търговски обект, то преместването на фискално устройство от едно работно място на друго не е свързано с нулиране на номерацията на УНП и не изисква такова. Софтуерът, който управлява фискалните устройства, би трябвало да се „обърне“ към съответното ФУ в примера и да генерира следващ уникален номер на продажба, т.е. последният УНП на предишното работно място плюс „1“.

 

Документите Сторно и Кредитно известие трябва ли да имат УНП за самия документ или само да цитират УНП на оригиналния документ, който коригират ?

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

 

По хипотезата за паркираните бонове – понеже те ще съдържат и УНП, трябва ли при приключване на деня (преди Z-отчет) тези транзакции да бъдат окончателно анулирани, или могат да се прехвърлят и за следващ ден ? Ако канцелираните бонове не се предават по дистанционната връзка, как ще се отразят дупките в УНП на сървъра на НАП ? Ако се предават канцелираните бонове по дистанционната връзка, следва да има флаг в XML-а за този статус на бона …

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

В Наредба Н-18/2006 г. няма термин „канцелиран бон“. Вероятно се има предвид  Сторно  ФБ, който се предава  към сървър на НАП. Структурата на Сторно ФБ е описана в Наредба Н-18/2006 г., Приложение №17, т. 13а и т. 14а.

В случай, че се има предвид анулирана продажба, при която софтуерът „постъпково“ е записвал в КЛЕН информация за отделните стоки, но поради анулирането  формира ФБ с нулева обща сума, няма пречка такъв ФБ да бъде предаден дистанционно към сървър на НАП. За тази особеност на софтуерната реализация производителят/разпространителят би следвало да е направил пояснение при подаването на информация за софтуера съгласно чл. 52в ал. 2 (заедно с декларацията по чл. чл. 52в ал. 1). 

 

При така приетата нормативна уредба как е предвидено да се изпълни следната ситуация: фирма, използваща „Система за управление на продажбите“, работи изцяло с разплащания по банков път. Ако системата отговаря на изискванията на Приложение 29, то според т. 8 не се допуска откриване на Продажба без наличието на връзка с фискално устройство (ФУ).

 

Лицата по чл. 118, ал. 18 от Закона за данък върху добавената стойност (ЗДДС) могат да използват в търговски обект, в който се извършват продажби на стоки и услуги, за които е налице задължение за издаване на фискален бон, само софтуер/и за управление на продажбите, отговарящ/и на посочените в приложение № 29 изисквания, като софтуерът/ите задължително управлява/т всички фискални устройства в този обект.

 В случай че в търговски обект се извършват продажби, за които не е налице задължение за издаване на фискален бон (ФБ), Наредба №Н-18/2006 г. не изисква наличие на фискално устройство в този обект, респективно регламентираните в Приложение № 29 изисквания не са относими към софтуер, който управлява продажби, за които не е налице задължение за регистрирането и отчитането им чрез фискално устройство. Същият софтуер (същата версия на софтуера) обаче не може да се използва в други търговски обекти, в които се извършват продажби, за които се изисква издаване на ФБ. 

 

В случаите, в които „Софтуерът за управление на продажбите“ не е самостоятелно приложение, то изискването в Приложение № 29 към чл. 52а,           ал. 13, което гласи „Софтуерът трябва да има надеждна защита от преднамерено или случайно изтриване или промяна на вече записани данни за приключени продажби - софтуерът няма вградена функционалност за изтриване на записи в базата данни ...“, поражда следните въпроси по отношение начина на работа с останалата функционалност на цялостната система.

ВЪПРОС: Как се предвижда да се работи в следните ситуации:

  1. Допуска ли се изтриване/редакция на данни, свързани с функционалност за „Управление на сервизна дейност“?
  2. Допуска ли се изтриване/редакция на данни, свързани с кореспонденцията по:

    1. Продажба (примерите посочени в т.3 до т. 5)

    2. Оферта,

    3. Сервизна дейност,

    4. Обслужване,

    5. Застрахователна дейност,

    6. Отношения с контрагенти

    7. и т.н.

    Ето и следните примери:

  3. При вече записана Продажба и закъсняващо плащане, от системата се изпращат уведомителни съобщения (e-mail, SMS и т.н.), съответно информация за изпратените уведомления се съхраняват в допълнителни таблици, но пряко свързани със съответната продажба. Обикновено това се случва при вече записана продажба.
  4. Често към конкретна продажба се издават допълнителни документи, като например Гаранционни карти, Партидни листи, дори експедиционни документи и всички те може да бъдат издадени след записването на Продажбата.
  5. Понякога се отразява допълнителна информация свързана с вече записана продажба, като забележки за уговорки за плащания, коментари и др. подобни.

Разгледаните примери в т3, т.4, т.5 касаят въвеждането на данни към вече записана операция (поради естеството си или времето на възникване).

Как според НАП тази информация, свързана с продажбата може да бъде обработвана. Допуска ли се изтриване/редакция на гореописаните данни без СТОРНИРАНЕ на Продажбата. И може ли да се даде отговор с информация, конкретно кой/какви записи от базата данни не могат да бъдат изтривани или редактирани .

В случаите, в които софтуерът за управление на продажбите не е самостоятелно приложение изискванията на Приложение №29 се отнасят към модула, в който е реализирана функционалността „управление на продажбите“.  Съгласно  чл. 52к, ал. 3 от Наредба № Н-18/2006 г. когато работата на софтуера е свързана с получаване или подаване на информация от или към други софтуери или модули от информационни системи, задължените лица са длъжни да  съхраняват информацията, създавана чрез тези софтуери (модули от информационни системи), в сроковете по чл. 38, ал. 1 от ДОПК и при поискване предоставят на органите по приходите (ОП) достъп до нея с пълни права за четене и експорт на данни.

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

 

Ако се използва „Драйвер за управление на фискално устройство“, което позволява проверка за състоянието на ФУ преди започването на продажбата, то счита ли се че може да бъде реализирана операцията, ако отговора от „Драйвера“ не съдържа информация за грешка от страна на ФУ. В наредбата е казано че „Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за статуса на ФУ“, което реално допуска използването на „Драйвер за управление на ФУ“, като налага изискването да се провери статуса на ФУ преди бон. Всички драйвери предлагани от производителите на ФУ връщат информация за състоянието на ФУ след изпълнение на команда, ако винаги преди бон се изпраща команда за сверяване на Дата/час (което изпълнява изискването от т.5 от Приложението), то може да се приеме че получената информация от „Драйверът за управление на ФУ“ е в реално време.

Друг приложим метод е с директната проверка състоянието на ФУ и последващо подаване на команда към „Драйвер за управление на ФУ“.

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

 

Липсва дефиниция на понятието „Модул“.

ВЪПРОС: Как НАП тълкуват понятието „Модул“.

  1. Как се очаква да бъдат декларирани в ПРИЛОЖЕНИЕ 31 т.1 отделни приложения, който работят с базата данни с която работи и частта за „Управление на продажбите“. Фактически това са отделни модули към системата.
  2. В този смисъл библиотеките (с вградени в тях самостоятелни функционалности, като управление на фискално устройство например, управление на команди към базата данни, управление на команди към интернет магазин) считат ли се за „Модули“ и ако ДА, то каква/коя част от функционалността им трябва да се опише в ПРИЛОЖЕНИЕ №31 т.1.

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

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

 

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

ВЪПРОС: Какво се има предвид с изискването „.. При архивиране на базата данни софтуерът осигурява ... и поддържане на архив ...в сроковете по чл. 38, ал. 1 от ДОПК през потребителски интерфейс“, това означава ли че се вменява задължението на софтуерът да съхранява архив в посочените сроковете и ако ДА, то какви са очакванията за начинът по който това „...поддържане на архив... през потребителски интерфейс...“ трябва да се реализира.

Софтуерът следва да позволява архивиране на създаваните данни с периодичност в зависимост от спецификата на бизнеса и желанието на задълженото лице – потребител. Задължение на последния  е да съхранява архивираната информация в сроковете по чл. 38, ал. 1. Софтуерът трябва да има функционалност за достъп до архивираната информация през потребителски интерфейс, така че да е възможно генериране и експорт на информацията, посочена в т.18 от Приложение №29.

 

В Приложение №31, т.7 се изисква подаването на „Информация относно изпълнението на изискванията по т. 16, 17, 18 и 19 от приложение № 29“

ВЪПРОС: Каква част от изискваната подробна информация от посочените точки в Приложение 29 е необходимо да бъде декларирана. Отговори с Да (Да, поддържа се) или Не , достатъчни ли са ?

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

 

В чл. 52в, ал. 1 се задължават производителите на софтуер да предоставят „...изпълнимият файл, за достъп и извличане на данни от БД в структуриран четим вид с възможност за избор – от всички или от част от таблиците, с които работи софтуерът; “

ВЪПРОС: Възможно е част от извличаната информация да е криптирана с оглед защита на корпоративни интереси от страна на клиента, като ключа се съхранява под опеката на вещи лица на клиента. Как се очаква предоставеното приложение да визуализира/експортва данните (криптирани или декриптирани, ако криптираните данни засягат правата на лица от Регламент 679/2016 на ЕК )?

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

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

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

ВЪПРОС: Често в практиката се налага обособена функционалност в системите, чрез която се изписват различни стоки поради ред причини (но не свързани с продажба), като бракуване на стоки, изписване на стоки за вътрешна употреба, движение между вътрешни складове и други.

Ако се приеме, че понятието „модул“ е „отделно от основната система приложение“ (и не е синоним на функционалност), то

  • Допуска ли се използването на такава функционалност в системата, притежаваща и функционалност за „Управление на продажбите“, която да позволява изпълнението на ако гореописаните операции, ако НЕ то какъв механизъм трябва да бъде предвиден за отразяване на посочените действия чрез системата.
  • Допуска ли се използването на функционалност в системата, притежаваща функционалност за „Управление на продажбите“, чрез която се издават първични счетоводни и други документи за продажбите.

Считам, че няма пречка софтуерът да притежава функционалност, чрез която да се отразяват действия като посочените от Вас -  „бракуване“, „движение на стоки между складове“, „изписване на стоки за вътрешна употреба“, доколкото тези операции не са свързани с процеса по управление на продажбите. Производителят/разпространителят следва да подаде информация за наличната функционалност в софтуера, който произвежда/разпространява съгласно т. II.1 от Приложение №31.

Ако модулът за издаване на първични и други документи за продажби  има функционалност за управление на продажбите, същият попада в обхвата на определението за софтуер за управление на продажбите в търговски обект съгласно т.84 от §1 на ДР на ЗДДС, във връзка с §1, т. 19 от ДР на Наредба Н-18 и следва да отговаря на изискванията на Приложение №29.

 

В Приложение №29, т.18.9 се изисква извеждане на информация за „видове операции (действия)

– код, наименование, дата на първоначално конфигуриране в системата, дата на последна промяна, дата на деактивиране; „

ВЪПРОС: Какъв вид действия се очаква да бъдат изведени?

  1. Създаване, Редакция, Изтриване на номенклатури са вградени като действия в системата, но не са декларирани в табличен вид
  2. Приемане в сервиз, добавяне на ремонт, Издаване на клиент за функционалност „Сервизна поддръжка“ са вградени като действия в системата, но не са декларирани в табличен вид
  3. Откриване/Започване, Анулиране, Сторниране, Приключване, Плащане и др са действия, отнасящи се за операциите (сред които е и Продажба), вградени в системата, но не са декларирани в табличен вид.

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

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

 

В Приложение №29, т.18.9 се изисква „...работни места – код, търговски обект, в който се намира, индивидуален номер на свързаното към него ФУ, дата на първоначално конфигуриране в системата, дата на последна промяна, дата на деактивиране; ...“

ВЪПРОС: Ако не се поддържа в таблична форма, а номерата на работните места са динамични (но не се позволява две работни места с един номер да работят едновременно). Допуска ли се този тип номенклатура да не се експортира.

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

Въпрос №11

В Приложение №29 т.6 „Софтуерът има вградени контроли за задължително попълване на данни за потребителите (операторите) .... начало/ край на периода на активност на потребителя (оператора) за всяка от присвоените му роли“

ВЪПРОС: Какъв вид „.. контроли... за всяка от присвоените му роли“ се изисква да бъдат вградени в системата, ако оператора изпълнява ролята на сервитьор, барман и управител в търговски обект, коя от тези роли трябва да бъде въведена в системата за оператора и как се предвижда контролата да контролира края на едната роля и началото на другата.

Ако се съхранява Log списък, в които се отразява направената промяна при преминаването от едната към другата роля в системата, счита ли се че системата има „.. вградени контроли... за всяка от присвоените му роли“. Естествено при въвеждане/редакция на оператор не се допуска запис без посочена Роля.

Ролята, която даден служител има в системата (софтуера), се свързва с правата, които той има по отношение на достъп до функционалност, права за четене или запис, на определени данни, промени например в номенклатурни файлове и др. От софтуера се изисква логически контрол на въвежданите данни за потребителите (операторите). Отговорност на задължените лица е осигурят вярно и точно въвеждане на посочената информация в приложение №29, т.6.

 

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

Loading...
Loading...