Регистиране на продажба на Доверител, чрез СУПТО и ФУ на Довереник

Тъй като в чл. 29 ал.1 т.6 се регламентира възможността, реда и начина, как една продажба на Доверител, може да бъде регистрирана чрез СУПТО и ФУ на Довереник, с което задължението за издаване на ФБ се прехвърля на Довереника, взимащ сумата от крайния потребител и издаващ фискалния бон, то от гледна точка на Доверителя и неговата минимално необходима правна сигурност, следва да се поясни в Чл. 3 ал.1, че регистрирането на продажба чрез СУПТО и ФУ на Довереник освобождава Доверителя от задължението и той да издава касов бон за същата продажба.



Предложение:



В Чл. 3 ал.1, след изречението "освен когато плащането се извършва чрез внасяна на пари в наличност по платежна сметка, кредитен превод....." да се добави "или чрез регистриране на продажба със СУПТО и ФУ на Довереник".

Обект със СУПТО и връзка електронен магазин

Фирма ползва регистриран СУПТО в офиса и ползва (както всяка нормална фирма в съвременнния свят) и електронен магазин, който е на свободна платформа WooCommerce. 

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

Изискването на Чл. 52з. (10), за автоматичен импорт на поръчките при платформите с отворен код е неприложимо (не може да накараш американската компания WooCoomerce да прави импорт за българско СУПТО). Има решения за импорт, които обачен са на цена 500-600 лв. Това е доста голяма сума. Защо се натоварват фирмите с допълнителни разходи. Това ли е идеята?

Каква е логиката да има автоматичен импорт от електронен магазин във фирменото СУПТО, при положение, че:

1. Поръчките от електронен магазин се въвеждат в СУПТО програмата и си получават УНП номер от нея.

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

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

Нали абревиатурата на НАП е Национална агенция за ПРИХОДИТЕ (които се реализират от продажби), а не е Национална агенция на ПОРЪЧКИТЕ?

Предложение:

Да отпадне изискването за автоматичен импорт на поръчките от Електонния магазин в СУПТО, при положение, че фирмата има регистрирано СУПТО и следи и отчита всички поръчки и продажби в него независимо как са получени те ( в офиса, по телефона, през електронния магазин, по мейла, с SMS, по Viber, Messenger, пощенско писмо, устно и т.н.)

С Уважение!

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

Във връзка с предвидената промяна на чл. 52а¹  („§ 16. В чл. 52а¹ се правят следните изменения: 1. Алинея 1 се изменя така: „(1) Лице по чл. 118, ал. 18 от ЗДДС може да използва софтуер за управление на продажби, който отговаря най-малко на изискванията по т. 2, 4, 6 и 7 от приложение № 29. В случай че интерфейсът на софтуера не е на български език, търговецът е длъжен да предостави негов превод на български език при поискване от орган по приходите.“ 2. Алинея 2 се отменя.”):

1. Не следва ли софтуера по този член да се допълни към изключението предвидено в чл. 52з, ал. 3, изречение второ?

Предложение:

Чл. 53з (3) Лицата по чл. 118, ал. 18 от ЗДДС могат да използват в търговски обект, в който се извършват продажби на стоки и услуги, за които е налице задължение за издаване на фискален бон, само софтуер/и за управление на продажбите, отговарящ/и на посочените в приложение № 29 изисквания. Софтуерът/ите задължително управлява/т всички фискални устройства в този обект с изключение на софтуер по чл. 52а, ал. 2..“ да се допълни  И СОФТУЕР ПО чл. 52 а¹, ал. 1 .

2. По отношение на:

„§ 48. В Наредбата за изменение и допълнение на Наредба № Н-18 от 2006 г. за регистриране и отчитане чрез фискални устройства на продажбите в търговските обекти, изискванията към софтуерите за управлението им и изисквания към лицата, които извършват продажби чрез електронен магазин (обн., ДВ, бр. 75 от 2019 г.; изм. и доп., бр. 9 от 2020 г.) в § 13 от преходните и заключителните разпоредби се правят следните изменения:

 1. В ал. 1, изречение първо думите „31 юли 2020 г.“ се заменят с „31 декември 2020 г.“, а в изречение второ думите „30 септември 2020 г.“ се заменят с „31 януари 2021 г.“.

2. В ал. 2, изречение второ думите „31 юли 2020 г.“ се заменят с „31 декември 2020 г.“, а думите „30 септември 2020 г.“ се заменят с „31 януари 2021 г.“.

3. В ал. 4 думите „31 юли 2020 г.“ се заменят с „31 декември 2020 г.“, а думите „30 септември 2020 г.“ се заменят с „31 януари 2021 г.““

Предложение:

Освен промяната на сроковете, на всякъде в текста,  където се цитира 52а¹, ал. 1 и 2, ал.2 да отпадне.

Предложения по текстовете

Предложение за изменение на чл. 3(16) и чл. 25 (3) и (4)

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

Мотив:

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



В чл. 25 (3) се заменя с Когато продажбата се извършва в отсъствието на клиента и стоката се предоставя, чрез куриер и/или предоставя услуга, чрез дистанционна продажба документът по чл. 3, ал. 1 се издава от задълженото лице:

1. на хартиен носител, който трябва да придружава стоката и се предоставя на клиента заедно със стоката; или

2. в електронен вид най-късно към момента, в който стоката напусне търговския обект на лицето, а в случаите на предоставяне на услуги най-късно при предоставяне/плащане на услугата

Мотив:

във връзка с предходното измение



Чл. 25 (4) се заменя с:

(4) Фискалната касова бележка в случаите по ал. 1 се издава при извършване на плащането. Лицата по чл. 3 са длъжни едновременно с получаване на плащането да предоставят на клиента издадената фискална касова бележка. При продажби по чл. 3, ал. 8 фискалната касова бележка се визуализира на контролния дисплей на ФУВАС. При продажби от лице по чл. 3, ал. 16 фискалният/системният бон може да се генерира в електронен вид, като се изпраща на електронен адрес на клиента. Допуска се да не се издава документът по чл. 3, ал. 1 ако за продажбата е издадена фактура, съдържаща данните по чл. 26, ал. 1, т. 1, 4, 7 и 8, с изключение на кода на данъчната група.

Мотив:

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

Измение на промяната на чл. 29

Чл. 29 (6) предложената промяна се изменя както следва, след: (7) Когато задължено лице, в качеството си на довереник се добавя:  и не е лице по чл. 118, ал. 18 от ЗДДС и

Изречението: Когато довереникът е лице по чл. 118, ал. 18 от ЗДДС, регистрирането и отчитането на продажбите на доверителя се извършва по реда на ал. 6. се заличава

Мотив:

Текста създава циклично недвусмислен

Коментари от СУПТО разработчик 1/3

Коментари от СУПТО разработчик 2/3

Коментари от СУПТО разработчик 3/3

Предложения за промяна 1/2

Предложения за промяна 2/3

Предложения за промяна 3/3

Да отпаднат изискванията за импорт в СУПТО при обект със СУПТО, ползващ и ЕЛМ/платформи/обяви и др.

В подкрепа на мнението на VentsiVas от 23 юни 2020 г. 10:47:21 ч.

Да отпадне изискването за импорт на поръчки от ЕЛМ в СУПТО, когато фирмата има регистрирано СУПТО и отчита продажбите в него. Да остане задължение в такъв случай всички извършени продажби да бъдат отчитани (извършвани) чрез СУПТО, с което да се предостави свободата фирмата да приема поръчки свободно от ограничения чрез всички достъпни методи - от онлайн магазини, български и чуждестранни платформи за обяви и малки обяви, специализирани инструменти за оферти и каталози, по телефона, чрез социални мрежи, маркетплейс платформи, през имейл, преки оферти чрез съобщения и т.н. 



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

редакция на чл. 52з, ал.7

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

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

Примери: дейности като местене на наличности между собствени обекти, всичко от обхвата на WMS (Warehouse Management System) модулите като управление местоположението на стоките в склада, събиране на стоки, окомплектоване, опаковане и т.н.

Всички тези дейности се отразяват в системите с типове документи по чл. 6, ал. 3 от Закона за счетоводството, които с ново предлаганата дефиниция на т.19 от § 1 изрично са изключени от обхвата на СУПТО.

Ето защо предлагаме текста на чл.52з, ал.7: „В случай че лицето по чл. 118, ал. 18 от ЗДДС използва интегрирана информационна система за управление на продажбите/търговската дейност функционалностите за обработка на заявки/поръчки, проследяване движението на продаваните стоки/услуги, отразяване на предоставянето и заплащането им се считат за софтуер за управление на продажби, който трябва да отговаря на изискванията съгласно приложение № 29.“

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

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

Да се замени с: "- при стартиране на функционалност, свързана с откриване на продажба и за плащане - за проверка на готовността за работа на ФУ. При липса на отговор за свързаност с ФУ или на готовност за отпечатване на фискален бон, се блокира функционалността за откриване на продажби и за плащане, изискващо издаване на фискален бон."

Алтернативно предложение – да отпадне изобщо текста на първи булет и да останат да се прилагат директно другите два.

редакция на чл. 52 е и ж - Нужен е консенсус по тази точка

Касови апарати и СУПТО - срокове

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

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

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

- Дублираща функционалност

- Обхват

- Разширен обхват на текста на наредбата в частта достъп до данни

- Изисквания за български език  и др.

Предложение за разширавяне обхвата на алинея 7 от чл. 26 / част 1от2

Предложение за разширавяне обхвата на алинея 7 от чл. 26 / част 2от2

Чл. 52б обхват на регистрация на софтуерите

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

Мотив:

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

Сторно операции и авансови плащания

В момента текстовете в наредбата са съобразени само с апаратните възможности на ФУ, но противоречат на закона. Добавя се в чл. 31 алинея 1а: (1а) Сторно операция се извършва при рекламация или връщане на стока като количеството се изписва със знак минус. При намаление на данъчната основа със знак минус за единичната цена.

Мотив:

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

ФУ трябва да визуализира знака само в случаите, когато не се печата кредит нота.

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

Понятието ПОС

В Приложение № 33 към чл. 52м, ал. 1 и чл. 52р т. 7.2 думата ПОС се заменя с устройство за приемане на картови разплащания.

В 7.6, и 7.7 думата POS се заменя с устройство за приемане на картови разплащания.

Мотив:

Не могат да се използват съкращения без да се дефинират в параграф към наредбата. Съкращението POS е Point Of Sale, което не е устройството с което се извършва процеса да плащане чрез карта. ПОС не го открих като дефиниция.

Не е допустимо в да се използват две понятия за едно и също нещо.

Стандартизиран одиторски файл

Недопустимо е да се използват имена на XML таговете с различна от Letter case-separated words конвенция, както и наименованията трябва да са съобразени с SAF-T Schema v. 2.00.

Мотив:

Задължително е спазването на международните конвенции за изграждане на XML структори. Не е допумо създаване на одиторски файл без да е съобразен с SAF-T спецификацията.

Сторно по фискален бон

Член 31, ал. 2 задължава сторно да се издава задължително по конкретен фискален бон. Тази задължителна връзка е нормална при продажба към краен потребител. В търговията на едро е нормална практика да се издават кредитни известия за намаление стойността на сделката (бонус при постигнат оборот за определен период). Така първо трябва да се издадат сторна по всеки фискален бон по отделно, а в последствие да се изброят фактурите по които си издава кредитното известие. Изикването за сторно по конкретен фискарен бон усложнява в десетки пъти издаването на кредитното известие като дублира ненужно списъка по фактурите, по които се издава кредитното известие.

Предложение: Да отпадне изискването сторното да се издава по конкретен фискарен бон, когато е свързано с кредитно известие.

Разнос - сторно по фискален бон

Член 25 ал. 2 изисква да се издава предварително фискален бон при продажба при разнос

Липсва разяснение как да се издаде касовия бон без да се увеличи паричната наличност на фискалното устройство.

Предложение: Към член 25, ал. 2 да се добави описание за издаване на фискален бон при разнос.

Сторно с основание "операторска грешка"

Член 31, ал. 3 позволява да се издаде сторно по фискален бон с основание "операторска грешка" без да е необходима касова наличност на фискалното устройство. Технически след издаване на сторно с основание "операторска грешка" касовата наличност се намалява. Това води до разминаване на реалната косова наличност с тази на фискалното устройство.

Предложение: Да се задължат производителите на фискални устройства да не променят касовата наличност на фискалното устройство при издаване на сторно по фискален бон с основание "операторска грешка".

Дневен отчет

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

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

Нулеви цени

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

Предложение: Да се задължат производителите на фискални устройства да усигурят възможност да се продават стоки с нулеви цени (директно, а не с 100% търговска отстъпка).

Чл. 26а Авансови и частични плащания

Изменение на чл. 26А (1) след ЧАСТИЧНИ ПЛАЩАНИЯ се добавя или АВАНСОВИ ПЛАЩАНИЯ.

В чл. 26А (2) се заличва изречението: след което се извършва стойностна отстъпка, равна на размера на частично заплатената/заплатените сума/и

И след всички стоки и услуги се добавя: сумата на авансово плащане се приспада със знак минус пред единичната цена и отрицателен резултат на междинен сбор на този ред

Добавя се в чл. 26А алинея (3) (3) При разсрочено (частично) плащане се издава касова бележка в зависимост от разпоредбите на закона за ДДС за облагане на финансово-обвързан или оперативен лизинг.

Мотив:

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



 

Предложение относно Чл. 52(3)

Предлагам "Чл. 52(3) (Нова - ДВ, бр. 52 от 2019 г., в сила от 02.07.2019 г.) Всяко лице, което извършва сервизно обслужване на ФУ, за които не е наличен отдалечен достъп, е длъжно да обнови версията на фърмуера на въведените в експлоатация ФУ при вписана в регистъра по чл. 10, ал. 9 нова версия в срок до 45 дни след вписването и” да отпадне напълно.

Мотиви :

Не може да се вмени такова задължение в такива срокове на лицата , извършващи сервизно обслужване на ФУ поради неясно начало, респективно и край на срока и обстоятелства , описани в Чл,52 (3) поради следните обстоятелства :

1. Сервиза не е собственик на ФУ и няма гарантиран достъп до него. 

2. Собственика на ФУ е дал грешни контакти за връзка или не осугурява достъп на серизната организация до ФУ . Няма как да се извърши обновяване на версия на ФУ по принудителен начин. 

3. Ъпдейтите на всяко едно ФУ се вписват в регистъра на дата Х ,а сервизните организации получават достъп до въпросният ъпдейт на фърмуера на дата У ,която може да е две-три седмици по-късно. 

4. Не е възможно да се следят обновленията и датата на вписване в регистъра по чл.10 ал.9 поради липса на достъп на лицата, сервизиращи ФУ до регистъра по чл/10 ,ал.9. 

5. В билинга на производителите (с изключение на два от произоводителите) липсва информация кое ФУ е ъпдейтнато, кое ФУ подлежи на ъпдейт и кое ФУ все още чака нова версия на фърмуер и съответно сервизната организация няма как да знае дали ФУ е ъпдейтнато ,дори и за тези ФУ които е възможен автоматичният ъпдейт.

Закръгления във фискалният бон

По коментираните днес теми на срещата с бизнеса, предлагаме следното решение по отношение на закръгленията във сумите и техните "напасвания" във фискалният бон, а именно:

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

2. Предвид т.1 да се оформи подходящ формат за подаването на тази информация в първият фискален ред за да е възможно тя да бъде правилно прочетена при ескпорт в CSV от ФУ.

За да бъда ясен ще предложа следната фактология:

Да се отчете че най-евтините ФУ разполагат с 22 символа за всеки фискален ред в името на артикула, така ако се приеме, че в първият ред се подава кол. и ед. цена до N на брой знака и че разделител между тях е единствено знак X (на латиница) и десетичен разделител е . (точка) и се подават едионствено цифри, то може да се изработи от производителите на ФУ единствено корекция във експортирането на КЛЕН в CSV като се обработят данните по следният начин:

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

Да се допусне възможност допълнителното описание на артикула или преносът на името да се реализира за яснота и в диези (т.е. ако Не е достатъчен вторият фискален ред за пълното описание след него да се подадат коментарни редове с преноса на името)

Ефектът който ще се постигне:

1. ФУ няма да се доработват, а само експортът от КЛЕН и то по съществуваща методика.

2. Методът работи независимо дали ФУ поддържат 22 или 48 символа. Не е зависим от възможносттите на ФУ

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

4. Допуска се подаването на допълнителни описателни данни за артикула и в коментарни редове.

5. Бизнесът ще има алтернатива на начинът си на обработка на цени и отстъпки

Ето и един реален пример.

1. Страна А е договорила със страна В покупка на 1 000 000 бири на цена 1.2077 без ДДС за 12 месеца

2. Страна Б (посредник) доставя и продава количествата на договорените цени, като при достигане на определен лимит цената се намалява в зависимост от реализацията.

3. попада се в ситуация, в която СУПТО трябва да продаде 960 бр на ед. цена с ДДС 1,4492 лв = 1391,23

Това на ФУ излиза така:

960 * 1,45 = 1392 лв с ДДС, издава се приемо - предавателен протокол (фактурира се на по - късен етап съгласно договора) и касов бон.

Ако се позволи описаният от мен метод, ще имаме във фУ със 22 символа следното:

фискален ред 1 : ______960.00X1.4492___  - долните черти са само за визуализация на примера за размера на полето

фискален ред 2: Найменование на стокат     1391.23 Б  - ФУ фискализира общата сума.

коментарен ред 1: #а с много символи и др   - пренася се останалата част от името 

коментарен ред 2: #уго описание  - за яснота на клиента

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

Срок за корекция на версия след открита грешка

Предлагам, в случайте когато в СУПТО е открита грешка и е декларирано това пред НАП вместо 14 дневният срок, да се посочи срок съгласно списък за актуализация на клиентите.

1. 14 работни дни да е срока в който се пусне за регистрация пред НАП нова версия с отстраненият проблем на СУПТО.

2. Да се предвиди /разреши допълнително време, например не повече от 30 календарни дни, но от датата на вписване в списъка за извършване на актуализация на лицата по чл.3.

3. Да се опише с какви документи може/трябва да се регистрира от разработчика на СУПТО и/или лицата по чл. 3, че предстои актуализация на версията.

Ето пример: в СУПТО с версия 10001 се открива програмна грешка и разработчика я декларира, като описва, че се прави корекция с версия 10008. НАП се уведомява за това (до 14 работни дни) и започва процес по регистрация на новата версия. С получаването на инфромация от разработчика и потвърждение на регистрацията на новата версия, НАП разпространява предупреждение към всички лица използващи "грешната" версия за това, че трябва да я подменят в срок от 14 работни дни от датата на съобщението с версия 10008 на същият СУПТО.

Разработчикът до 5 работни дни от датата на регистрацията на версия 10008 изпраща списък на всички записани в списък за актуализация свой клиенти с техните ЕИК и имена и дата на планирана актуализация към НАП по електронна поща или на обявен адрес на сървъра на НАП.

Цели които се постигат:

1. НАП ще информира всички лица по чл. 3, че са застрашени от санкция но няма да отнеме лиценз а ще информира лицата че имат алтернатива и решение на възникналият проблем (обществана функция)

2. Разработчиците ще имат време (времето по регистрация на новата версия) за да подготвят списъците на клиентите за актуализация и да направят опит да се свържат с тях.

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

4. На разработчиците да се дадат до 30 календарни дни за актуализация на конкретен клиент от списъка от датата посочена в списъка, така ако Фирма 1 е планирана за 06.08.2020 по списък  разработчика ще има 30 календарни дни от тази дата за актуализация, а лицето по чл. 3, 7 работни дни да декларира промяната на версията пред НАП. 

Срок за корекция на версия след открита грешка

Предлагам, в случайте когато в СУПТО е открита грешка и е декларирано това пред НАП вместо 14 дневният срок, да се посочи срок съгласно списък за актуализация на клиентите.

1. 14 работни дни да е срока в който се пусне за регистрация пред НАП нова версия с отстраненият проблем на СУПТО.

2. Да се предвиди /разреши допълнително време, например не повече от 30 календарни дни, но от датата на вписване в списъка за извършване на актуализация на лицата по чл.3.

3. Да се опише с какви документи може/трябва да се регистрира от разработчика на СУПТО и/или лицата по чл. 3, че предстои актуализация на версията.

Ето пример: в СУПТО с версия 10001 се открива програмна грешка и разработчика я декларира, като описва, че се прави корекция с версия 10008. НАП се уведомява за това (до 14 работни дни) и започва процес по регистрация на новата версия. С получаването на инфромация от разработчика и потвърждение на регистрацията на новата версия, НАП разпространява предупреждение към всички лица използващи "грешната" версия за това, че трябва да я подменят в срок от 14 работни дни от датата на съобщението с версия 10008 на същият СУПТО.

Разработчикът до 5 работни дни от датата на регистрацията на версия 10008 изпраща списък на всички записани в списък за актуализация свой клиенти с техните ЕИК и имена и дата на планирана актуализация към НАП по електронна поща или на обявен адрес на сървъра на НАП.

Цели които се постигат:

1. НАП ще информира всички лица по чл. 3, че са застрашени от санкция но няма да отнеме лиценз а ще информира лицата че имат алтернатива и решение на възникналият проблем (обществана функция)

2. Разработчиците ще имат време (времето по регистрация на новата версия) за да подготвят списъците на клиентите за актуализация и да направят опит да се свържат с тях.

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

4. На разработчиците да се дадат до 30 календарни дни за актуализация на конкретен клиент от списъка от датата посочена в списъка, така ако Фирма 1 е планирана за 06.08.2020 по списък  разработчика ще има 30 календарни дни от тази дата за актуализация, а лицето по чл. 3, 7 работни дни да декларира промяната на версията пред НАП. 

Промяна на поръчка от ЕЛМ само в СУПТО

Ако се приемат текстове, с които се налага редактирането на свалена в СУПТО поръчка от електронен магазин (ЕЛМ) да става само чрез СУПТО, то трябва да с еима предвид, че всеки потребител на ЕЛМ може да промени поръчката си по всяко време, което означава че в следната ситуация НАП ще създаде условия за пряко нарушаване на Н18:

Клиент се регистрира в ЕЛМ и прави поръчка на 2 броя "стока 1", потвърждава я в 11:35 на 08.07.2020, чрез ИМПРОРТЕР след 15 минути (11:50) тази поръчка е регистрирана в СУПТО, тя обаче ще бъде обработена (проверка за наличности уговорка с клиента и т.н.) на следващият работен ден тъй като политиката на магазина е че обработва нови заявки до 11:00, а следващите часове прави заявка за доставка от доставчици и подготвя пратки  към куриер.

В 20:00 на 08.07.2020, клиентът променя поръчката и вместо 2 броя ги намалява на 1 бр, но добавя нов артикул (нека за примера да кажем, че се поръчват телефон и протектор).

В тази ситуация, а тя е масова в практиката какво се случва:

1. СУПТО има свалена поръчка, но тя няколко час апо - късно вече не отговаря на реалността.

2. Клиентът може по всяко време (в рамките на няколко дни - работни или НЕ) да си прави промени без да уведоми лицето по чл. 3 за това - масова практика.

3. Поради тези си действия в т.2 клиентът ще създаде проблем на лицето по чл. 3 пред НАП ако в часовият диапазон се направи проверка.

Какви проблеми отваря предвидените промени (станали ясни от видеосрещата от 08.07.2020):

1. Лицата по чл. 3 трябва да изискат от разработчиците промяна на съществена функционалност в ЕЛМ и да се забрани редакцията на записна поръчка НЕзависимо, че тя не е обработена/изпратена. Това ще доведе до тежки смени на платформи, тъй като световните разработчици най-вероятно на платформи за ЕЛМ ще откажат орязването на тази функционалност само заради българският пазар.

2. Лицата по чл.3 ще трябва да променят коренно начинът си на работа. Ще е необходим дълъг обучителен период и най-вероятно няколкократни смени на СУПТО. 

Към: "Закръгления във фискалният бон" от 08.07.2020 22:26:34

Отлагане на Наредба Н18 за средата на 2022 г.

Искане: Отлагане на Наредба Н18 за средата на 2022 г.

Мотиви:

Пандемията от COVID19 представлява тежко сътресение за световната и за европейската икономика, което води до много сериозни социално-икономически последици, а към днешна дата НЯМА ДАННИ до кога ще продължи (втора вълна и т.н.).

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

Според икономическата прогноза от пролетта на 2020 г. икономиката на еврозоната ще се свие с рекордните 7¾ % през 2020 г.

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

Като се има предвид взаимозависимостта на икономиките на ЕС, динамиката на възстановяването във всяка държава членка ще се отрази също така на степента на възстановяване на останалите държави членки.

До края на 2021 г. НЕ се очаква икономиката на ЕС да компенсира напълно загубите от текущата година.

В структурата на българската икономика делът на индустрията в добавената стойност е 24.4%, а търговията, транспортът и туризмът създават 22.1% от добавената стойност - това са най-силно засегнатите от кризата сектори. Основните търговски партньори на България (внос - износ) са сред най-засегнатите икономики в ЕС (Германия, Италия и т.н.).

Нека да напомня, че икономиката на България все още е развиваща се, а не развита, както и че населението под прага на бедността е: 22,0% в бедност (2017), 32,5% (2,279 млн.) в риск от бедност или социално изключване (2019).

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

В лятната прогноза се казва, че БВП на страната ще се свие с "около 7%" през настоящата 2020 г. и ще нарасне с 5.3% през следващата година. Сравнението с пролетната прогноза, разпространена в началото на май, сочи, че тогава рецесията за България е била прогнозирана на минус 7.2%, но е имало по-оптимистични очаквания за ръст от 6% от БВП за 2021 г.

Предвид факта, че за 2019 г. ръстът на икономиката е бил от 3.4%, това означава, че завръщането към нивото от миналата година вероятно може да се очаква някъде в средата на 2022 г.

През първото тримесечие растежът на реалния БВП е намалял до 1.2% на годишна база. Това би трябвало да означава, че тежките месеци на 2020 г. за икономиката, хората и приходите в бюджета предстоят.

Проучване на Българската стопанска камара (БСК) е установило, че въвеждането на новите правила за касовите апарати, предвидени с промени в Наредба № Н-18/2006 г., ще струва средно 2 432 лв. на едно ФУ заедно с необходимия софтуер.

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

Моля, обърнете внимание, че разходите за изпълнение на Н18 не са еднакви за фирмите и зависят от големината на предприятието, структурата и бизнес процесите. Бизнесът в България НЕ Е само бакалии или заведения с по 10-ина маси. Цената на Н18 не е равна на 200 лв. за нов касов апарат, а експоненциално по-висока. Моментът за въвеждане на изискванията по Н18 не е сега. В момента е важно възможно най-голяма част от бизнеса просто да оцелее.

QR код за ЕЛМ

QR код за ЕЛМ, които работят по чл.3(17) трябва да бъде проверим в реално време (до 5 мин след транзакцията) от потребителя или да отпадне изцяло

Мотиви:

Ако QR-а не може да верифицира сделката с приложението на НАП е безсмислено утежнение, което ще се явява допълнителен разход за търговеца, който ще трябва да го интегрира в своя ЕЛМ.

Казус

Казус за НАП:

Все повече чужденци (от ЕС) намират онлайн магазина ни в България и използват Google преводач, за да направят поръчки.

Тези, които честичко купуват големи количества, препродават нашата стока на цена в €. Тъй като всичко си е наша марка и произведено в България, клиентите им намират нашия онлайн магазин (по марката) и поръчват.

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

Не може ли по PayPal? Как ще съм сигурна, че ще ми изпратите нещата след като преведа парите?

Не може ли с карта?

Явно се довереяват на PayPal и на банките си (chargeback), а ние не желаем да изпратим стока за 500€ и след това да чакаме превод от клиент до 3-5 раб.дни. За нас е важно да можем да приемаме плащания в момента от клиенти в чужбина. Такива клиенти не ползват ППП. А стандартният банков превод е прекалено бавен и за двете страни.

Имаме и физически магазини. Онлайн магазинът е на различен адрес от физическите. Сайтът ни е направен специално за нас от няколко програмиста къстъм, които НЕ желаят и не могат да създават СУПТО отговарящо на изискванията на приложение 29, да го регистрират в НАП и да отговарят за него, а имаме много детайли, изпълнени през годините, които ги няма в готовите решения за онлайн магазини.

Не желаем да търсим някой да ги създава отново, а и са си наше ноу-хау, за да ги "подскажем" на други. Доволни сме от сегашния ни онлайн сайт! Да не говорим за финансовият ресурс, който би ни струвало подобно нещо.

Според последните предложения за приеманe на неприсъствено плащане с кредитна или дебитна карта в Наредба Н-18, как бихме могли да приемаме такива? Как да продаваме на европейския пазар, където клиентите да заплащат по удобен за тях начин? Да се местим в друга държава?

Благодаря!

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

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

Липса на компетентност

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

Необходимите компетенции за подобни контролни функции липсват.

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

Напомням, че съгласно АПК Основания за оспорване Чл. 146. Основанията за оспорване на административните актове са: 1. липса на компетентност;

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

Сделка през ЕЛМ или не?

Как се третира казусът, когато някой иска да поръча онлайн, но да дойде и да плати на място?

Това сделка през ЕЛМ ли е (т.е. прави невъзможна употребата на режима с одиторски файл), или присъствена сделка без връзка с ЕЛМ (т.е. магазинът си работи на облекчен режим, понеже неговата клиентела и допустими методи за плащане са формално разделени от тези на присъствения магазин?

Пренаписване на Н18

Искане: Цялостно пренаписване на Н18 отначало до край и извършване на РЕАЛНА ИСТИНСКА оценка на въздействието, както и на разяснителна кампания от страна на НАП.

Мотиви:

В същността си Наредба Н18 кара целия бизнес в България да промени начина си на работа и се опитва да наложи контрол над бизнес процесите на предприятията, което е далеч извън рамките на контрола над отчетността, който НАП следва да извършва.

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

Н18 променя бизнес процесите във фирмите по начин, който ЗДДС не изисква.

 

Софтуерна фискализация

Искане:

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

Същата да е направена с мисъл за бъдещото развитие на технологиите, а не да бъде направена по „остарял“ начин, та да се окаже неработеща и невъзможна за надграждане в хоризонт от 2-5-10 години.

Държавата да предложи API от тяхна страна.

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

Мотиви:

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

Няма как чуждестранни компании със стотици хиляди клиенти по цял свят да се занимават с изискванията на НАП и да преработват софтуера си. eBay, Facebook, Etsy, SAP, WooCommerce, Magento, маркетплейсите? Примерите могат да бъдат много.

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

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

И най-накрая, държавата, в частност НАП, да наеме ИТ специалисти в екипа, който обсъжда Н18 с различните представители на бизнеса, не може функционалности на софтуер да се обсъждат с икономисти, които не са компетентни в техническата част и техническият им хоризонт се ограничава с понятията ФУ, QR код и СИМ карта, с които са се запознали буквално през последната 1 година.

Оправете си осраната наредба, докато все още има време, защото нанасяте щета и ако не сте го разбрали вече, ще го разберете по трудния начин.

Искане за издаване на фискален бон

Искане:

POS, PayPal, TransferWise, Skrill, Revolut и други Fintech решения да се изключат от искането за издаване на фискален бон

Мотиви:

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

ОК е фирмите да предоставят извлечения и да декларират всички такива плащания към НАП, под каквато форма НАП прецени, така както са длъжни да го правят и с банковите плащания и с всички останали плащания, а НАП да си изискват засичане от съответните банкови и платежни оператори, стига да не се налага пренаписване и превод на целия български и световен софтуер и изменение на всички бизнес процеси във фирмите, както и тази форма на фискален контрол да не налага разход за една фирма, който надвишава разхода за преместването на бизнеса ѝ в друга юрисдикция.

Превод на български

Искане:

Да се добави към изискването за език на всички системи алтернатива те да могат да бъдат „на английски език или на български език“ вместо единствено и само на български.

Мотиви:

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

Английският е смятан за „световен език“, „лингва франка“ на съвремието. Той е официален език на Европейския съюз, ООН, НАТО и на повечето международни организации. Английският е най-често използваният език в науката и основен за бизнеса в 21 век, особено ако този бизнес иска да бъде конкурентен. По данни към 2000 г. над 2 млрд. от общо 8 млрд. души говорят английски. Официален е в 67 държави и 27  несуверенни.

Продажба или поръчка

Изчистване на понятието продажба и премахване на задължението да се обвързват поръчки и да се подава информация за тях, тъй като поръчката НЕ представлява продажба и НЕ е разбираемо защо НАП желае да получава информация за всички поръчки, когато такава не ѝ е нужна за целите на фискалния контрол. До момента на извършване на продажба, търговецът няма задължение към фиска, тъй като пари не са получени и сделка не е била осъществена, а има само изразено намерение за такава обективирано в поръчка или оферта. Същинската продажба се извършва с прехвърляне на собствеността или правото, като заедно с прехвърляне на собствеността важи правилото, че вещта погива за собственика.

Обсоноваване

Анализ на проблемите и обосноваване от страна на НАП защо фискализацията в реално време трябва да включва всички плащания, а не само касовите. Защо фискализацията трябва да контролира бизнес процеси? Концентриране върху реалните проблеми за укриване на приходи, а не аргументиране на опитите за контрол на бизнес процесите във всички фирми. (Като пример - на най-проблемния сектор с най-голямо подозрение, че укрива приходи му намалиха ДДС-то :) Обосноваване на логиката на НАП да превърне всички софтуери в софтуерни касови апарати, които да управляват досегашните касови апарати?

Защо НАП не отговаря на официалните запитвания свързани с Н18?

Изпратили сме официални запитвания до НАП във връзка с Н18 януари и още чакаме отговор. Защо НАП не отговаря на запитванията? Не сме само ние в подобна ситуация. Не може да се очаква от нас да изпълним сроковете поставени в Наредбата като 31.07, а в същото време да не получаваме отговори.

Отлагане

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

XML-ът да бъде в Unicode, а не в Win-1251 кодировка

XML файлът във връзка с алтернативния режим на отчитане на ЕЛМ да бъде в Unicode, да не ползва Win-1251 кодировка

 

предложения за промяна чл.26 и Приложение 29

1. чл.26, ал.10 и Приложение 39

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

В Приложение №39 текста " Настоящият документ не удостоверява извършено плащане, а с подписването му клиентът се съгласява да извърши плащане най-късно при напускане на обекта" се променя на " Настоящият документ не удостоверява извършено плащане, а с подписването му клиентът се съгласява да извърши плащане при или след напускане на обекта"

Мотив: първото предложение е с цел прецизиране на такста, тъй като преди прочита на ал.11 не става ясно, че ал.10 касае наличието на повече от едно СУПТО. Второто предложение е свързано със ситуация, при която напускането на обекта не завършва с плащане в бой или с карта. Ако клиента е фирма може да има договорка плащането да се осъществи на по-късен етап по банков път. Сегашния текст на проекта изключва продажбите към тези лица. От предложената в проекта ал.11 на чл.26 не става ясно следва ли да се издава документ  съгл. Приложение 39 от лицата, ползващи едно СУПТО.С цел еднозначно тълкуване е необходимо прецизиране на текста.

2. Приложение №29

Предложение: в новата т.22 на Приложение 29 текста " чл.26, ал.11" се заменя с "чл.26, ал.10" и текста "чл.52з, ал.7 и ал.8" се заменя с "чл.52з, ал.8 и ал.9"

Мотив: В случаите по ал.11 на чл.26 и ал.7 на чл.52з задълженото лице работи с едно СУПТО и една база данни и няма импорт на информация от едно СУПТО към друго СУПТО

3. чл.52в, ал.1 т.3

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

Мотив: дълъг процес на експортиране на данни от големи бази данни

Предложения за промяна във връзка с промените в чл. 52а¹ -1/1

1. чл.52з

Предложение 1: в изречение второ на чл.52з, ал.3 след "по член 52а, ал.2" се добавя " и по чл.52а¹ "

Мотив: Съгласно предложената в проекта промяна с параграф 16 в ал.1 на чл.52а¹ и отмяна на ал.2, лице по чл.118, ал.11 от ЗДДС, което отговаря на изискванията на чл.52а¹, ал.3 може да използа софтуер за управление на продажбите, който не отговаря на изискванията на т.8 от Приложение №29, която касае свързаност с ФУ и т.10, съгласно която при плащане по въведена в софтуера продажба, за което съгласно изискванията на настоящата наредба следва да бъде издаден фискален бон, софтуерът задължително подава към ФУ уникалниея номер на продажбата. Следователно софтуерът по чл.52а¹ не е задължен да управлява ФУ в обекта.

Предложение 2: в ал.13 на чл.52з в края на изречението се добавя "и чл.52а¹ "

Мотив: невъзможност за деклариране изпълнение на изискванията на т.15 и т.19 от Приложение №32 към чл.52з, ал.1

Предложение 3: в чл.52з се създава нова алинея 14 " Изискванията по алинеи 8, 9 и 10 не се отнасят за лице по чл.118, ал.18, използващо софтуер по чл.52а¹ "

Предложения за промяна във връзка с промените в чл. 52а¹ -2/2

2. чл.52а¹, ал.5 и Приложение 37

Предложение: В изречение първо на ал.5 на чл.52а¹  след " регистрирани в софтуера" се добавя текст " операции по" и след "продажби" се добавя текст " ( откриване, плащане, анулиране, сторниране и приключване)"

Мотив:  В наредбата няма определение за регистрирана продажба. Необходимо е прецизиране на текста с цел яснота за операциите по една продажба, които трябва да бъдат декларирани в текущата и следващи календарни години. Сегашният текст без проблем може да се приложи за продажби, които са открити, анулирани, сторнирани и приключени през една календарна година. Ако по една открита продажба има операции в следваща календарна година не е ясно дали трябва и каква информация следва да се посочи.

Предложение: в Приложение 37 на редове "обща сума на продажба-без ДДС, в лева", "отстъпка-в лв." и "дължима сума по продажбата-в лв. " в колона Забележка се добавя текст "Полето се попълва с 0,00 ако годината на ред дата на откриване на продажба е различна от годината на ред календарна година, с изключение  на увеличение на  сумата". На ред "ДДС-сума-в лв" в колона Забележка се добавя текст "Полето се попълва с 0,00 ако годината на ред дата на откриване на продажбата е различна от годината на ред календарна година, с изключение на увеличение на ДДС сума и при продажби, за които ДДС е 0,00 или не се начислява ДДС"

Мотив: Прецизиране с цел коректно подаване на информация и избягване на повторно подаване на  информация за извършени през предходна година операции по една продажба. Информация на редове обща сума на продажби, отстъпка,  ДДС и дължима сума за открита през предходна година продажба е логично да има в следваща календарна година само при промяна в посока увеличение-например при дебитно известие, добавяне на нови артикули в открита поръчка, увеличение при разлика между сумата при откриване в поръчката и сумата при фактуриране и др. По отношение на ред ДДС тъй като при ВОД, износ, услуги към чужбина и др. ДДС е 0,00 или няма ДДС, а тези продажби също се регистрират в софтуера и не са изключени в подаваната информация, полето не трябва да е задължително или за тях трябва да е попълнено с 0.00

чл.52з

Предложение 3: в чл.52з се създава нова алинея 14 "Изискванията по алинеи 8, 9 и 10 не се отнасят за лице по чл. 118,ал.18 от ЗДДС, използващо софтуер по чл.52а¹ "

Мотив: Съгласно предложената в проекта промяна софтуерът по чл.52а¹ може да не отговаря на изискването на новата т.22 от Приложение №29. От друга страна с премахването на изискването за задължително генериране на УНП не е възможно изпълнение на изискванията в Приложение 41 и Приложение 42, отнасящи се до УНП, както и изисквания за информация в одиторските справки и др.

Предложение за промяна на текст в §7 Член 25 алинея 4

Предложение за нов текст:

Чл. 25

(4) Допуска се да не се издава документът по чл. 3, ал. 1, изречение второ, ако за продажбата е издаден данъчен документ по чл. 112 на ЗДДС, съдържащ данните по чл. 26, ал. 1, т. 1, 4, 7 и 8, с изключение на кода на данъчната група.

Мотив

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

Предложение за промяна на текст в § 8 Член 26 алинея 7

Предложение за нов текст:

Чл. 26

(7) При продажба, за която е издадена фактура, дебитно известие,  туристически ваучер, резервационна бланка по смисъла на Закона за туризма или друг първичен счетоводен документ по чл. 6, ал. 1 от Закона за счетоводството, в която/което/който са посочени количеството и вида на стоките или услугите, във фискалния/системния бон се допуска да се отпечата сумарния оборот по съответните данъчни групи и код на данъчната група, като задължително се посочи номера и датата на фактурата, дебитното известие,  туристическия ваучер, резервационната бланка или първичния счетоводен документ, по която/което/който се извършва плащането. Предходното изречение не се прилага в случаите на чл. 27, ал. 3, т. 3. Издадените документи по изречение първо се съхраняват най-малко в срока по чл. 38 от ДОПК.

Мотив

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

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

Предложение за промяна на член 31 алинея 2а във връзка с промяна на текст в § 8 Член 26 алинея 7

Предложение за нов текст:

Чл. 31

(2а) При документиране на сторно операция, във връзка с която е издадено кредитно известие или друг първичен счетоводен документ по чл. 6, ал. 1 от Закона за счетоводството, в което са посочени количеството и вида на стоките или услугите, в сторно документа се допуска да се отпечата сумарния оборот по съответните данъчни групи и кода на данъчната група, като задължително се посочи номера и датата на кредитното известие. Предходното изречение не се прилага в случаите на чл. 27, ал. 3, т. 3.

Мотив

Промяната се предлага, за да се допусне издаване на СТОРНО сумарен фискален бон по данъчни групи в случаите на:

Анулиране на фактура или дебитно известие, което се прави по силата на чл. 116 от ЗДДС, по които вече има издаден сумарен фискален бон.

Анулиране на друг първичен счетоводен по чл. 6, ал. 1 на Закона за счетоводството по силата на чл. 8 от Закона на счетоводството, по който вече има издаден вече сумарен фискален бон.

Предложение за промяна на текст по §19 член 52е1 алинея 2

Предложение за удължаване на срока от 7 на 14 дни в ал.2 :

Чл. 52е¹

(2) В 14-дневен срок от установяването на обстоятелството по ал. 1 производителят/разпространителят е длъжен да подаде декларация по чл. 52б за нова версия на софтуера, съответстваща на изискванията на приложение № 29.

Мотиви:

В много случаи намирането и отстраняването на грешка в софтуера изисква повече време, особено при логическа грешка. Това може да засегне и преработка на много модули и функции. Самият „билд“ (създаване) на нова версия, както и декларирането ѝ също изискват допълнително време.

Предложение за промяна на текст по §19 член 52е1 алинея 3

Предложение за нов текст:

Чл. 52е¹

(3) В 14 дневен срок от включване на новата версия на софтуера в публичния списък по чл. 118, ал. 19 от ЗДДС, производителят/разпространителят е длъжен да уведоми всички свои потребители, по договорените с тях средства и начини за комуникация, за наличието на нова версия и обстоятелствата по алинея 4.

Мотиви:

По-голямата част от СУПТО-софтуерите и ЕРП системите не са облачни услуги, а са инсталирани директно при клиента, в неговата инфраструктура и сървъри.

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

От друга страна, производителят/разпространителят може и да не получи от потребителите желания достъп (дори и да поиска) или да няма техническа възможност за такъв, или пък да се нарушават правилата за информационна сигурност при клиента (вкл. и ISO-27001). Тогава би се наложило физически да се посещават такива потребители, да се съгласува с тях време за достъп, да се осигури посещение и т.н., което при по-голям брой клиенти също би било невъзможно.

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

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

Предложение за промяна на текст по §21 член 52з алинея 7

Предложение за нов текст:

Чл. 52з

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

Мотиви:

Съгласно § 29, т.19 от Допълнителните разпоредби се променя и допълва с конкретна и ясна дефиниция за СУПТО, както и процесите, които обхваща. Изброяването на отделни функционалности в чл.52з(7) би могло да доведе до заблуди, двусмислие, различно тълкуване и прилагане на нормата, както сега, така и за в бъдеще. Логично е всички дефиниции и определения да бъдат едни и същи в цялата Наредба № Н-18/2006.

Предложение за промяна на § 21 член 52з алинея 10

Предложение за нов текст:

Чл. 52з

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

Мотив:

Изискването СУПТО "автоматизирано извлича и зарежда в базата си данни най-малко на всеки 15 минути информацията за направените поръчки", ще направи почти невъзможна връзката с електронни магазини. Съществуват много безплатни и платени платформи, чрез които може да се направи електронен магазин. Не всяка една от тях обаче дава възможност за връзка на софтуер към тях или има разработени API функции за тази цел. Отделно от това, има много собствени разработки на фирми, съобразени с техните специфични изисквания. Те също нямат (или ако имат, те  са съвсем различни) методи и функции за достъп до електронен магазин. При това положение, един стандартен софтуер за СУПТО ще трябва да произведе, да поддържа и да декларира отделни импортери за всеки един електронен магазин, от който ще импортира данни - нещо, което е невъзможно, защото за всеки отделен клиент ще трябва да се прави отделна версия и отделна разработка, която трябва да се поддържа. В допълнение, разработените досега импортери, които отговаряха на публикуваните схеми на НАП, вече няма да могат да работят и всички клиенти на СУПТО, които в момента работят, ще трябва да спрат и евентуално да заплатят нови разходи (и то не малки, защото ще бъдат конкретни разработки само за тях), за да могат да подновят дейността си.

Предложение за допълване на промяна в § 35 Приложение № 29 т.18

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

Вместо:

– дата на откриване на продажбата;

– време на откриване на продажбата (час, минута, секунда);

Да стане съответно:

• Дата на генериране на УНП
• Време на генериране на УНП (час, минута, секунда);

Мотив

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

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

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

Вместо:

– дата на приключване на продажбата;

– време на приключване на продажбата (час, минута, секунда);

Да стане съответно:

• Дата на въвеждане в СУПТО на информация за предоставяне на стоките или услугите;
• Време на въвеждане в СУПТО на информация за предоставяне на стоките или услугите (час, минута, секунда);

Мотив

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

В Наредбата няма дефиниция за дата и време на приключване на продажба, но в дефиницията по т. 19 на ДР към Наредбата се посочва кои крайни действия са в обхвата на СУПТО, а това е обработка на информация, свързана с текущо проследяване на процеса по продажба в търговски обект до предоставянето на стоки или услуги или до заплащането им. За заплащането на предоставените стоки или услуги има отделна самостоятелна таблица, в която присъства датата на плащане, ето защо, е добре в таблиците, в които се визира дата на приключване на продажбата тя да бъде заменена с дата на предоставяне на стоките или услугите. Така се получава последователност на въвежданата и предоставяната за проверка информация.

Относно предложението на АИКБ за промени в приложение 42 – I. т.3

Предложение за изменение:  т.3 да отпадне

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

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

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

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

Допустим брой редове в фискален бон

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

Предложение: Да се задължат производителите на фискални устройства да премахнат това ограничение в режим "Фискален принтер".

Предаване на даани през мобилна мрежа

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



Мотив:

Съгласно Чл. 17. (1) т. 5а от ДАНЪЧНО-ОСИГУРИТЕЛЕН ПРОЦЕСУАЛЕН КОДЕКС НАП е задължена: "5.да им бъдат осигурени и предоставени безплатно: а) приемането на всички документи, представени от задължени и трети лица относно публичните им задължения;". Заплащането на такса към мобилен оператор конкретно и само за деклариране на данъчна информация от страна на ФУ се явява нарушение на това право. В конкретната разпоредбда не са изключени електронните документите т.е. отчетите за продажбите.

чл. 26(6) Издаване на текуща сметка

чл. 26 (6) Се изменя: Съпътващите документи издавани във връзка с продажбата не могат да съдържат атрибутите съгласно чл. 26(1) т.10.

Мотив:

Фискална касова бележка дефинирана в чл. 2 от наредбата се издава само в случаите на плащане в брой или еквивалентно. Не допустимо е да се твърди в документ свързан с продажбата, че не се дължи плащане, на етап изпълнение на сделката не може да се договаря начина на плащане, начина само се констатира, чрез вписване в първичния документ и то само в случаите, че плащането се извърши веднага. Текста „че по него не се дължи плащане“ нарушава разпоредбите на ЗЗД, за всяка предоставена стока и услуга се дължи престация, ако не уговорено друго. Предложения текст създава предпоставка за конфронтация. Достатъчно е да няма лого идентифициращо фискализация. Не допустимо да се смесват функциите на различните първични документи. Понятието "текуща сметка" се ползва само в продажбите на дребно, при продажбите на едро в практиките се използват множество документи съпътсващи продажбите. Документа Информация за текуща сметка не кореспондира с никой от използваните в практиката документи.

Становище на Баркод Системи България ООД относно сроковете

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

Предвид обема на промените в НИД-а, за пореден път срокът от 5 месеца за целия този процес е крайно недостатъчен за извършване на всички тези технически и административни дейности - очевидно е, че всички СУПТО трябва да бъдат променени и декларирани наново. Предложението ни е, на база досегашния опит с прилагане на промените в Наредбата, срокът този път да е реалистичен - поне 8 месеца. 

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

Да се дефинира „продажби в търговски обект”

Предложение: Да се даде определение на „продажба в търговски обект”, като се определи: купувачът, кога е извършена продажбата в търговски обект, кога тя е изпълнена, кога се издава ФБ и кога се отчита чрез отчет продажби по чл. 119. Въпросът е свързан и с нововъведението „частично плащане” в Наредба Н-18 и съдържанието на ФБ за „частично плащане”, както и с понятията „мълчалив ангажимент” на търговеца и „предполагане на намерение”, с които клиентът се поставя в позиция да тълкува действия на търговеца или да извърши продажба, без да е поискал.

В момента е прието разбирането, че всяка продажба на стоки/услуги, извършена навсякъде (от дефиницията на търговски обект в ЗДДС), за която е платено в брой, с карта или ваучер, е „продажба в търговски обект”. Задължението на търговеца възниква не от плащането на купувача, а от това, че извършва „продажби в търговски обект”. Взаимоотношенията търговец-купувач не се определят от средството, което използва купувача за плащане на парично задължение. Ако задължението възниква според средството за плащане на парично задължение, то едни и същи продажби един път ще са „продажби в ТО”, а друг път няма да бъдат, т.е. задължението, определено в чл. 118 ал. 1, ще възниква случайно. „Търговски обект” в текста на чл. 118 със сигурност не се употребява случайно и едва ли, за да се придаде смисъл „продажби навсякъде”. Ако понятие се тълкува като „навсякъде”, не би се употребило в нормативен текст. 

Да се дефинира „продажби в търговски обект” - 2

Ясно е, че продажби на физическо лице на стоки за потребление не са търговски продажби. „Търговска продажба” по смисъла на чл. 318 от Търговския закон продажба в търговски обект ли е? Това, какво средство ползва купувачът да плати цената, не променя задълженията на страните – купувачът може да плати паричното задължение с пари в наличност или ползвайки услуги на банка. Трябва да става ясно, че търговски обект е място, където се извършват продажби на физически лица или продажби на стоки за лично потребление, за които търговецът не е длъжен да издаде данъчен документ. Конструкцията на чл. 118 от ЗДДС и на чл. 3 от Наредба Н-18 се разрушава при отложено плащане по вече изпълнена доставка.

НАП, реферирайки се към чл. 3 от Наредба Н-18, съветва бизнеса да задължава своите клиенти да използват само услуги на банки за плащане на парично задължение и така да се избегне задължението по чл. 118 ал.18 от ЗДДС. При съществуващата дефиниция на търговски обект, всяко място и всяко помещение - цялата територия на страната, и при липсата на знание какво е продажба в търговски обект, подобен съвет излага бизнеса на риск. В чл.3 от Наредба Н-18 е посочено само кога лице, задължено по чл. 118 ал.1 ЗДДС, не е длъжно да издава ФБ. Задължението по чл. 118 ал. 18 от ЗДДС е свързано с чл. 118 ал.1 от ЗДДС, а не с чл. 3 от Наредба Н-18. В чл. 118 ал.4 т.4 е посочено, че в наредба се определя издаването на фискални касови бележки и техните реквизити.

Липсва знание какво е продажба в търговски обект, но се полага особено усилие да се обясни, как тези продажби се управляват и то най-вече чрез софтуер. Очевидна е нуждата от нормативно определение на „продажби в търговски обект”.

Проверка за свързаност с ФУ

Предвидени промени:

§ 35., т.3 гласи: "3. Точка 8 се изменя така:

„8. Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за готовността на ФУ за отпечатване на фискален бон и получаване на неговия ИН.

Свързаността се проверява:

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

При липса на отговор за свързаност с ФУ или на готовност за отпечатване на фискален бон, се блокира функционалността за откриване на продажби и за плащане, изискващо издаване на фискален бон."

Предложение:

Да отпадне необходимостта от проверка за свързаност с ФУ при стартиране на софтуера и идентифициране на потребителя при вход в системата за софтуери, които не са на модулен принцип.



Мотив:

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

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

заявки от клиент или отразяване на плащания по продажби.

Отстраняване на грешки при функционирането на СУПТО

Предвидени промени: § 19. Създава се чл. 52е¹:

(3) В 14-дневен срок от включване на новата версия на софтуера в публичния списък по чл. 118, ал. 19 от ЗДДС, производителят/разпространителят е длъжен да подмени версията по ал. 1 при всички потребители.

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

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