Информационна бележка

Информационна бележка

Съгласно изискванията на Закон за защита на личните данни (ЗЗЛД) , и на Закона за електронната търговия, финансово-счетоводна кантора ЕВРО ФИНАНС 2007 ЕООД е длъжна да приема личните Ви данни, които ни предоставяте относно Вас, член на семейството Ви или друго лице, и да съхранява без да ги разпространява. Целта на събирането на тези данни е да бъде изпращана кореспонденция, да бъдат изпълнени поръчките и да се изготвят собствени статистики.

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

Регистрираната информация е предназначена да бъде използвана от счетоводител и само за следните получатели: финансово-счетоводен отдел - бази данни от фирма “ЕВРО ФИНАНС 2007” ЕООД.

Съгласно разпоредбите на ЗЗЛД всяко физическо лице има право на достъп до отнасящи се за него лични данни, право да се противопостави на обработката на лични данни отнасящи се за него, право и да изиска изтриване на данните *, както и правото да се обърне към съда.

Ако някои от данните Ви са грешни Ви молим да ни информирате възможно по-бързо.

Забележка:

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

  • 9:00 am to 5:30 pm

Свържете се нас

02/ 44 16 359

Посетете офисът ни

София, ул. Враня № 73, ателие 1

Пишете ни на имейл

eurofinance_2007@abv.bg

Работно време

9:00 am to 5:30 pm пн - пк

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

  • Начало
  • Новини
  • 80 дни до крайния срок за смяна на софтуера за управление на продажбите и касовите апарати
blog article

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

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

Въведените през месец септември на 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 съдържа коректна информация ? Файлът се подписва от сервизен техник след като е направен експортът (и то ако експорта се прави от КЛЕН – има и хипотеза по Приложение 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 „Софтуерът не притежава възможност за работа в тестови режим, режим за обучение или друг подобен.“

ВЪПРОС: Ако производителят е предоставил версия, приведена в съответствие с Наредба Н-18 на интернет сайтове с цел реклама, следва ли тези версии да бъдат изтеглени/свалени. Ако ДА, то по какъв начин се допуска да бъде извършвана реклама на предлаганите продукти.

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


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

ВЪПРОС: Възможно ли е НАП да посочи приемлив според тях „начин на защита“

Начинът на защита на софтуера е избор на производителя на софтуера. Обща информация за това, какъв вид защита е използван, следва да се подаде с информацията за софтуера съгласно Приложение №31, т.8. Тази информация не се включва в публичния списък на софтуерите, за които е декларирано съответствие с изискванията, посочени в Приложение №29 към чл. 52а от Наредба № Н-18.


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

  • 1. бъде отворена Нова продажба – се генерира номер: DT123456-0005-0000001 (“...7-разряден пореден номер на продажбата, формиран поотделно за всеки индивидуален номер на ФУ...”
  • 2. маркират се 2 артикула
  • 3. в този момент се отваря от друго работно място продажба с номер: DT123456-0002-0000002, което е с пореден номер на операцията 2, тъй като се използва същото ФУ
  • 4. на Работно място 1 (т.1) се приключва работният ден без приключване на продажбата.
  • 5. На работно място 2 (т.2) се записва продажбата и се генерират още 3 продажби, което довежда брояча до поредност 6 (т.е. следващата операция за това ФУ трябва да бъде 6)
  • 6. на следващият ден става ясно че артикулите от отворената продажба от т.1 се анулират и операцията се освобождава. Дори и фискалните устройства да са различни, то отново съществува възможност за възникването на описаните по–долу казуси.
  • 7. Какво се очаква да се случи тук (следните възможни варианти):
    • a) Генерираният номер изчезва от системата в поредността на номерациите за ФУ в записаните продажби
    • b) Операцията се записва със нулева стойност, без клиент и нулево съдържание
    • c) Генерираният номер се съхранява до приключване със смислени данни, т.е. Запазва се до като се появи реален клиент с реални данни. В този случай обаче как ще се разглежда информацията за анулираните артикули.

Нито един от посочените от вас варианти а), b) или с) не отговаря на изискванията на наредбата.

В посочения от Вас пример информация за неприключената продажба с УНП DT123456-0005-0000001 следва да бъде записана в БД на софтуера – записват се и се съхраняват всички въведени данни, вкл. вид, количество и стойност на артикулите и др., както и индикатор, че продажбата с посочения УНП е анулирана.

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


blog article

Вижте често задаваните въпроси в раздел FAQ за всичко, което ви интересува:

logo

"Евро Финанс 2007" ЕООД
финансово-счетоводна кантора
София, ул. Враня № 73,
ателие 1
02/ 44 16 359
eurofinance_2007@abv.bg

Екипът ни

Галерия

Copyright © 2018 Евро Финанс 2007; Website developed by Sekkeido