Въпроси и отговори, свързани с разработката на СУПТО


1. В Таблиците за продажби, според Наредба Н-18,които всяко СУПТО следва да осигури има два неясни за нас параметъра:
-дата на приключване на продажбата
-време на приключване на продажбата
Какво се има в предвид за тези параметри при различните видове продажби: в брой, по банка ,смесено или частично плащане и други.

Отговор: Плащането и вида на плащане не е свързано с „приключване на продажбата“ в СУПТО. При приключване на продажбата в СУПТО се издава първичен счетоводен документ и се предоставя стоката или услугата на клиента. След тази дата и час продажбата с това УНП не може да бъде променяна. В срок най-късно от 5 дни указан в ЗДДС трябва да бъде издаден данъчен документ (фискален бон или фактура по банка). Фискален бон и фактура могат да са и самите първични счетоводни документи издадени при „приключване на продажбата“, ако издаването им или плащането съвпада с момента на „приключване на продажбата“ и не е необходимо да се издава друг такъв.   


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

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


3. Правилно ли е нашето тълкувание на Наредба Н-18, че частичните плащания по дадена продажба нямат собствено УНП, а присвояват УНП на оригиналната продажба, по която е плащането?

Отговор: Да. За всяко плащане по продажба е необходимо да се укаже единствено УНП по който се плаща и ако плащането е в брой или с ПОС-терминал да се отпечата този УНП на фискалния бон. 


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

Отговор: Съгласно Чл.26 (1) от Н-18 (ДВ, бр. 76 от 2017 г.) на фискалния бон следва да се посочи „т.7 наименование на стоката/услугата, код на данъчна група, количество и стойност по видове закупени стоки или услуги;“ Съгласно Чл. 27. (3) Задължително се програмират и регистрират с наименование и единична цена като отделни артикули стоките или услугите:
1. отнасящи се към данъчна група А;
2. с фиксирани цени в нормативен акт;
(заб. такъв артикул са тютюневите изделия регулирани с НАРЕДБА за условията и реда за регистриране на цените на тютюневите изделия (ДВ, бр. 19 от 2011 г., в сила от 8.03.2011 г.)

Детайлизацията на наименованията на стоките или услугите, които трябва да се отпечатат на фискалния бон е един от най-дискутираните проблеми. Например когато е издадена фактура, в която е описано подробно по пера характеристиките на сделката като стоки или услуги, тяхната единична цена и количество, отпечатването на фискалния бон „Плащане по фактура No.XXXXXXXXXX“ не е ли достатъчно. ФУ в ръчен режим могат да регистрират плащания както по Департамент така и по Артикул. Департаментите са ограничен брой за разлика от артикулите. Детайлизацията в наименованията на Департаментите е неясна и доста свободно тълкувана. Също е неясно тълкуванието на въпроса, при СУПТО отпечатването на данните за продажбата по наименования и цени задължително ли трябва да се осъществява с командата „продажба по артикул или департамент“, и ползването на опцията „отстъпка“ върху цената, която се изчислява от фърмуерите (софтуерите) на ФУ по различен начин и в повечето случаи е съществен проблем за синхронизирането й с изчисленията в СУПТО, или подробна информация за продажбата да се отпечатва като „нефискален текст“ в рамките на фискалния бон, а тотали-те по данъчни групи да се регистрират като „продажби по данъчна група Х“ с команда „продажба по артикул или департамент“ например след отпечатване на подробната информация като нефискален текст. Трябва да се отбележи, че подробна информация за всяко УНП се съхранява в базата данни на СУПТО и тя не може да бъде изтривана или променяна и НАП може да получи достъп до нея по всяко време по реда в Н-18 и налагането на ограничаващи изисквания за отпечатване на фискален бон е необосновано. Решение по тези казуси се налага да се вземе незабавно поради кратките срокове и рисковете от свободни тълкувания.  


5. В първоначалния вариант на проекта за промяна на Наредбата, след неуспешно предаване в НАП на касови бележки в продължение на 24 часа, ФУ блокира. След което се занася в сервиза да бъде деблокирано от сервизния техник със специални средства. Проблемът беше, че на практика блокировката се дължи на лоша връзка на мобилния оператор, което е проблем от мастно значение, в точката където е търговския обект, а в сервиза ФУ ползва за връзка друга клетка на мобилния оператор и ФУ работи. Търговецът, връщайки се в населеното място, където е търговския обект, който е например на 50 км от сервиза, се оказва, че отново ФУ не работи. Поради гореописаното текстът, за деблокиране в сервиза отпадна, но блокировката след 24 часа остана (виж Преходни и заключителни разпоредби от ДВ. Бр. 80/2018 г., Функционални изисквания, IIIб, т. 1, буква м).). Според новия, окончателен текст, деблокирането става автоматично, след възстановяване на връзката. Защо при лоша дистанционна връзка с НАП след 24 часа касата трябва да блокира и автоматично се деблокира при възстановяване на връзката? Много по-просто е касата да не се блокира. Ако ФУ е блокирало поради лоша връзка в продължение на 24 часа, търговецът реагира първо-сигнално и се обажда или отива в сервиза, където се установява причината. Търговецът не може да установи защо не работи ФУ.

Отговор: Технологията за комуникация между ФУ и сървъра на НАП се осъществява чрез SIM-карта на мобилен оператор, колкото и каквито и проблеми да създава това. Това е решение на НАП и моето мнение, е че това е един от основните технологични проблеми, свързани с начина на комуникация и идентификация на ФУ към сървъра на НАП, които измененията в Н-18 не решиха. Единственото смислено действие при тази ситуация е ФУ да работи с карта на оператор с най-голяма степен на покритие на мрежата в района в който ФУ е регистрирано и се опитва да комуникира.



6. Приложение 29 т.3 Може ли по-подробно обяснение какво се разбира под дублираща функционалност. 

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


7. Приложение 29 т.4 Каква е тази защита? Дайте примери.

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


8. Каква е технологията на работа при възстановяване на базата на ПК от предходна дата и отново въвеждане на вече издадени фактури и връзката с КА.

Отговор: Повторно въвеждане на вече направени и „изгубени“ продажби в СУПТО не е възможно. Дори да допуснем, че след „счупването“ на базата данни нямате плащания в брой и ФУ не е изпратило вече към сървъра на НАП плащане по въведено вече УНП, смятам че повторно въвеждане не е коректно. При направени плащания в брой или с ПОС терминал това е невъзможно, тъй като няма как да въведете отново плащане в СУПТО в брой или с ПОС терминал без да издадете фискален бон. След възстановяване на базата данни единствения смислен ход е СУПТО да има функционалност да въведете последно „генерирания“ УНП, който може да вземете от КЛЕН на ФУ или по друг начин предоставен от производителя на ФУ. В зависимост от технологията, която ползва СУПТО е необходимо да изискате от производителя на СУПТО да ви предложи всички възможни методи и начини загуба на данни да не се допуска.   


9. Според т.8 от приложение 29 за софтуера не може да се прави продажба на други работни места, освен на мястото където има КА? Как стои въпросът с резервен касов апарат, смяна на работното място на касовия апарат.

Отговор: Това не е точно. Продажба може да се въвежда на всяко работно място, където при откриване на продажбата СУПТО се обръща и получава коректен статус от ФУ, независимо това как е осъществено технически. ФУ могат да бъдат „свързани“ към всяка точка на продажба или ако производителите предоставят технологична възможност това може да стане и от няколко работни места към едно ФУ, като всяко работно място да получи отговор от ФУ за коректен статус при отваряне на продажба. Резервно ФУ е със сигурност задължително при натоварени търговски обекти, но не е необходимо то да бъде свързано към СУПТО. При повреда на „свързано“ ФУ то винаги може да бъде „заместено“ от резервното и работното място да продължи да работи, получавайки коректен статус от новото „свързано“ устройство. Единственото изискване е ФУ да не може да работи в ръчен режим в обект, в който е декларирано СУПТО. 


10. Има вътрешни скриптове в софтуера – те представляват ли plug-ins които са проблем и трябва ли да се декларират.

Отговор: Всички технологични подробности в СУПТО се изисква да се декларират. Всяка технология по реализацията на софтуера си има своите специфики и е необходимо да се коментира конкретно. 


12. Хиляди бизнес единици в страната използват следния модел: Две бази данни – 1.логистична (за подготовка на клиентски заявки, оферти, логистика на стоката и др.) и 2.фактурираща за продажби/фактури/стойности към един и същи софтуер. В частност в първата база данни много от процесите се изпълняват през документ продажба, въпреки че това не е реалната продажба. Това как трябва да се реши, понеже софтуерът ще издаде УНП и в двете бази за една продажба. 4.При две бази данни или при две програми (в смисълът на горния въпрос), това представлява ли "дублираща функционалност за управление на продажбите или функционалност"

Отговор: Въвеждане на данни за продажби може да има само в СУПТО и базата данни, която той управлява и е декларирано по реда в Н-18. Ако в обекта има логистичен софтуер, в който се осъществяват всички други операции, свързани с доставки, вътрешни движения между обекти, статистики и анализи и други процеси, несвързани с въвеждане на продажби и той работи с друга база данни, този софтуер не може да има функционалност, която да касае въвеждане на данни за продажби. Тълкуването на „оферта“ като въвеждане на данни с артикули, цени и данни за клиент е нещо, което не бих рискувал да имам като функционалност в този софтуер. Възможно е импортиране в този софтуер на продажбите генерирани в базата данни на СУПТО, което е необходимо при следене на складови наличности и маркетингови процеси. Възможно е и експортиране от този софтуер на данни към СУПТО, за наличности например или номенклатури, които в СУПТО са необходими за ефективно въвеждане продажби и обслужване на клиенти. Информация за направените промени при импорт в СУПТО задължително смятам, че трябва да се съхраняват според изискванията на Приложение 29. Достъп до този софтуер сте задължени да предоставите при проверка от НАП. Такъв тип софтуер, който няма функционалност за въвеждане на продажби и работещ в различна база данни от тази, управлявана от СУПТО не попада в изискванията на Н-18. Той може да бъде и в много случаи от производител или разпространител, различен от този на СУПТО.


12. При базите данни за 2-3 години стават много големи (десетки гигабайти), че почти не могат да се обработват в реално време от компютърните системи и мрежи. Тогава се прави
архивиране/салдиране за даден период. Оставя се една година активна и предходните се изтриват и се местят в архив. При така насложени допълнителни записи, базите ще нарастват с още по големи темпове. Това противоречи ли на "т. 13. Софтуерът трябва да има надеждна защита от преднамерено или случайно изтриване или промяна на вече записани данни за приключени продажби:"

Отговор: Не смятам, че разделяне и архивиране на базата данни не се допуска. Задължението е до архивираните бази данни да се предостави незабавен достъп и възможност за експорт на данни при проверка и искане от НАП по реда на Н-18 в сроковете по ДОПК. Смятам, че изискванията за генериране, последователност на УНП и предаването в реално време към сървъра на НАП на платените УНП в брой или с ПОС-терминал, невъзможността за въвеждане на продажби без свързано ФУ, и изобщо всички рестрикции на Н-18, достатъчно и неотменно гарантират невъзможността за манипулиране на базите данни, както управляваната текущо от СУПТО, така и архивираните.   
 


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

2 Коментари

  1. Avatar
    присмехулник 2019-03-12 23:00:06

    а иначе и данъчните можели да влизат в софтуера ми и да взимат архивирана базата ми с данни и после \\\"за колко ли пари\\\" някой данъчен ще я продаде както дадоха 16 милиарда ДДС на измамниците къде е тогава защитата на личните данни и това не противоречи ли на европейската директива кого да гоним като ни вземат чрез нелоялна конкуренция клиентите и доставчиците ни

  2. Avatar
    присмехулник 2019-03-12 22:59:27

    както се разбира СУПТО било и екселската таблица ми да искат лиценз от Бил Гейтс тъпънарите ще се връщаме на кочаните то е ясно тая данъчната не е продала и една карфица в реалния живот затова е така

Напиши коментар