Министерски съвет
Портал за обществени консултации
С проекта се предлага лицата, които извършват продажби на стоки и/или услуги чрез електронен магазин, да регистрират и отчитат продажбите вместо с фискален или системен бон чрез документ за регистриране на продажбата, който не е издаден от ФУ или ИАСУТД, когато по продажбата е извършено неприсъствено плащане с кредитна или дебитна карта.
За да могат да се ползват от предложения нов ред за регистриране и отчитане на продажбите лицата следва да подават допълнителна информация относно електронния/те магазин/и за методите на плащане, предлагани от електронния магазин, доставчиците на платежни услуги, с които има сключен договор за предоставяне на виртуален ПОС, платежните сметки, по които получава плащания от продажбите на стоки или услуги, включително тези, с които е виртуалният ПОС.
Предлага се удължаване на срока за лицата, използващи интегрираните автоматизирани системи за управление на търговската дейност (ИАСУТД) за привеждане в съответствие с изискванията на наредбата, тъй като в хода на доработване на съществуващите и разработване на нови ИАСУТД, се установява, че предвидените срокове са недостатъчни по отношение изпълняване изискванията на наредбата за предаване на данни от всяка извършена продажба. Причина за това е наличието на множеството специфики във вида и организацията на стопанската дейност на дружествата, които използват или възнамеряват да ползват ИАСУТД за регистриране и отчитане на приходите от продажби на стоки и услуги. С оглед комплексния характер на процесите по разработка и необходимото време за изпитване и одобряване на ИАСУТД, се предлага срокът да се удължи до 31 март 2020 г. , при условие, че до 31.01.2019 г. лицата са подали в НАП и Българския институт по метрология изискуемите документи за изпитване на ИАСУТД.
Отговорна дирекция:Данъчна политикаE-mail:taxpolicy@minfin.bgДата на откриване:20.12.2019Дата на приключване:19.01.2020
Министерство на финансите
Адрес: София, ул. Г. С. Раковски № 102
Електронна поща: feedback@minfin.bg
---
Пакет основни документи
Консултационен документ
---
Справка становища
---
Похвално е, че законодателят се е опитал да разреши казуса с неприсъствените плащания с кредитна или дебитна карта, тъй като все повече плащания се извършват по този начин. Опасенията ми като сътрудник в малък бизнес са по предложения ред за регистриране на тези плащания и по ненужната административна тежест, която се поставя на бизнеса - особено малкия и среден бизнес. Конкретно идентифицираме следните проблеми:
Похвално е, че законодателят се е опитал да разреши казуса с неприсъствените плащания с кредитна или дебитна карта, тъй като все повече плащания се извършват по този начин. Опасенията ми като сътрудник в малък бизнес са по предложения ред за регистриране на тези плащания и по ненужната административна тежест, която се поставя на бизнеса - особено малкия и среден бизнес. Конкретно идентифицираме следните проблеми:
И това, което е трябвало да се направи от самото начало и може би ще се направи някой добър ден, след като хаоса стане неуправляем, е: Производителите на софтуери за управление на продажби/стопанска дейност, знаейки много добре какви данни се създават в системата им при отразяване на извършена продажба или плащане по отразена вече продажба, трябваше само да създадат стандартен модул за връзка към ФУ и подаване на данни от системата към ФУ. На проверка трябваше да подлежат единствено този модул и драйверите на ФУ. Сега, за този опит на министерство на финансите, всички дружно ще похарчат към 1 милиард лева.
Но най-важното е, че системата на НАП за съхраняване на милиарди ФБ, може да се ползва за лотария с КБ.
И това, което е трябвало да се направи от самото начало и може би ще се направи някой добър ден, след като хаоса стане неуправляем, е: Производителите на софтуери за управление на продажби/стопанска дейност, знаейки много добре какви данни се създават в системата им при отразяване на извършена продажба или плащане по отразена вече продажба, трябваше само да създадат стандартен модул за връзка към ФУ и подаване на данни от системата към ФУ. На проверка трябваше да подлежат единствено този модул и драйверите на ФУ. Сега, за този опит на министерство на финансите, всички дружно ще похарчат към 1 милиард лева.
Но най-важното е, че системата на НАП за съхраняване на милиарди ФБ, може да се ползва за лотария с КБ.
Чл. 52и. – трябва да се промени, така че проверяващ орган да може да поиска достъп до данните на търговеца само след констатирано нарушение, определено ясно в закона за ДДС и наредбата като такова. Невъзможност за обмен на данни между ФУ и системата на НАП, по независещи от търговеца причини, както и последствията от липса на обмен не трябва да се счита за нарушение.
Чл. 52и. – трябва да се промени, така че проверяващ орган да може да поиска достъп до данните на търговеца само след констатирано нарушение, определено ясно в закона за ДДС и наредбата като такова. Невъзможност за обмен на данни между ФУ и системата на НАП, по независещи от търговеца причини, както и последствията от липса на обмен не трябва да се счита за нарушение.
Да се даде дефиниция на система за управление на продажби, която се използва в ТО, в което се извършват продажби с плащания изброени като изключения в чл.3 от Наредбата, а именно плащания за които няма задължение за издаване на ФБ.
Наложилият се в практиката термин не-СУПТО вече не е ясно за какво се използва: за система за управление на продажби, за която изискванията в приложение 29 не се налага да се прилагат или за софтуер, които не е система за управление на продажби изобщо.
Да се уточни възможно ли е лице по чл.3 да използва система за управление на продажби, която не отговаря на изискванията на приложение 29 в търговските обекти, където не е налице задължение за издаване на ФБ.
Схема Пример 2 – ЕРП система и СУПТО от файл Схеми_ERP_04.04.2019, изтеглен от сайта на НАП, валидна ли е в контекста на §75 – Наредба Н-18?
Да се даде дефиниция на система за управление на продажби, която се използва в ТО, в което се извършват продажби с плащания изброени като изключения в чл.3 от Наредбата, а именно плащания за които няма задължение за издаване на ФБ.
Наложилият се в практиката термин не-СУПТО вече не е ясно за какво се използва: за система за управление на продажби, за която изискванията в приложение 29 не се налага да се прилагат или за софтуер, които не е система за управление на продажби изобщо.
Да се уточни възможно ли е лице по чл.3 да използва система за управление на продажби, която не отговаря на изискванията на приложение 29 в търговските обекти, където не е налице задължение за издаване на ФБ.
Схема Пример 2 – ЕРП система и СУПТО от файл Схеми_ERP_04.04.2019, изтеглен от сайта на НАП, валидна ли е в контекста на §75 – Наредба Н-18?
Предлагам облекчение за елетронните търговци за пратки с Наложен платежи за Румъния и Гърция изплатени по банков път. Вместо касов бон да може да се издаде само фактрура.
Като това облекчение се обвърже с изискването за деклариране на преводите и банковата сметка на получателя.
Предлагам облекчение за елетронните търговци за пратки с Наложен платежи за Румъния и Гърция изплатени по банков път. Вместо касов бон да може да се издаде само фактрура.
Като това облекчение се обвърже с изискването за деклариране на преводите и банковата сметка на получателя.
Трябва да се създаде гаранционен фонд за обезщетяване на засегнати ползватели на регистрирано СУПТО. Производителите/разпространителите на регистрирано СУПТО, изпълняващо изискванията на Приложение 29, трябва да поддържат този гаранционен фонд. Наредбата задължава единствено и само производител/разпространител на СУПТО да поддържа собственото си СУПТО. При ситуация на невъзможност производител/разпространител на СУПТО да извършва тази поддръжка, по каквато и да било причина, трябва да има ред при който ползвателите на въпросното СУПТО да бъдат обезщетени.
Трябва да се създаде гаранционен фонд за обезщетяване на засегнати ползватели на регистрирано СУПТО. Производителите/разпространителите на регистрирано СУПТО, изпълняващо изискванията на Приложение 29, трябва да поддържат този гаранционен фонд. Наредбата задължава единствено и само производител/разпространител на СУПТО да поддържа собственото си СУПТО. При ситуация на невъзможност производител/разпространител на СУПТО да извършва тази поддръжка, по каквато и да било причина, трябва да има ред при който ползвателите на въпросното СУПТО да бъдат обезщетени.
§ 74. (1) Параграф 27 влиза в сила от 1 декември 2018 г.
(2) (Изм. - ДВ, бр. 26 от 2019 г., в сила от 29.03.2019 г., изм. - ДВ, бр. 75 от 2019 г.) Производител/разпространител може да разпространява софтуер, който не отговаря на изискванията, определени в § 26, в срок до 31 януари 2020 г.
§ 26. Създава се глава седма „а“ с чл.52а:
Чл. 52а. Софтуерът за управление на продажби в търговски обект трябва да отговаря на изискванията съгласно приложение № 29.“
Това означава ли, че производител/разпространител на СУПТО след 01.02.2020г. вече не може да изпълнява договорите си за поддръжка на софтуерите, които не са СУПТО съгласно изискванията на Приложение 29 от Наредбата? Лицата, които не са по чл. 3 от Наредбата, нямат задължение да използват СУПТО, което да отговаря на изискванията на Приложение 29. Принципно, всяка промяна в софтуерите и имплементирането й в системите на клиенти на производител/разпространител на софтуер е разпространяване на софтуер. Например промяна в правилника за ДДС налага и промяна във софтуера за автоматично изготвяне на ДДС дневници и декларации. Промяна се налага в БД, в потребителския интерфейс, в автоматичните процедури (алгоритми) за изготвяне и експортиране на изискваната информация. В разпространявани СУПТО-та функционалността за изготвяне на ДДС дневници и декларации и функционалността за счетоводна отчетност и изготвяне на финансови отчети, не са включени. Дори да се създадат нови дружества, които да произвеждат/разпространяват СУПТО съгласно Наредбата, как се гарантира независимостта на тези дружества?
Както от лицата по чл.3 се изисква, в един стопански обект да не може да се използва СУПТО и не-СУПТО, същото важи ли и за софтуерните производители/разпространители - в един офис/сграда/адрес да не може да се произвежда СУПТО съгласно Приложение 29 и друг софтуер?
§ 74. (1) Параграф 27 влиза в сила от 1 декември 2018 г.
(2) (Изм. - ДВ, бр. 26 от 2019 г., в сила от 29.03.2019 г., изм. - ДВ, бр. 75 от 2019 г.) Производител/разпространител може да разпространява софтуер, който не отговаря на изискванията, определени в § 26, в срок до 31 януари 2020 г.
§ 26. Създава се глава седма „а“ с чл.52а:
Чл. 52а. Софтуерът за управление на продажби в търговски обект трябва да отговаря на изискванията съгласно приложение № 29.“
Това означава ли, че производител/разпространител на СУПТО след 01.02.2020г. вече не може да изпълнява договорите си за поддръжка на софтуерите, които не са СУПТО съгласно изискванията на Приложение 29 от Наредбата? Лицата, които не са по чл. 3 от Наредбата, нямат задължение да използват СУПТО, което да отговаря на изискванията на Приложение 29. Принципно, всяка промяна в софтуерите и имплементирането й в системите на клиенти на производител/разпространител на софтуер е разпространяване на софтуер. Например промяна в правилника за ДДС налага и промяна във софтуера за автоматично изготвяне на ДДС дневници и декларации. Промяна се налага в БД, в потребителския интерфейс, в автоматичните процедури (алгоритми) за изготвяне и експортиране на изискваната информация. В разпространявани СУПТО-та функционалността за изготвяне на ДДС дневници и декларации и функционалността за счетоводна отчетност и изготвяне на финансови отчети, не са включени. Дори да се създадат нови дружества, които да произвеждат/разпространяват СУПТО съгласно Наредбата, как се гарантира независимостта на тези дружества?
Както от лицата по чл.3 се изисква, в един стопански обект да не може да се използва СУПТО и не-СУПТО, същото важи ли и за софтуерните производители/разпространители - в един офис/сграда/адрес да не може да се произвежда СУПТО съгласно Приложение 29 и друг софтуер?
Тази наредба е прецедент, защото изхожда от презумпцията за виновност в зависимост от бизнес процесите, в случая продажба по която се плаща в брой, и на НАП са й вменени разследващи функции. Да не цитирам мотивите за промените на Наредбата.
НАП като изгради собствена система, полезна за целта, да определи каква информация й е необходима за извършване на анализи и контрол и тогава да се изиска от бизнеса да я осигури по законен ред.
Да се дефинира понятието „контролно производство”.
А най-добре да се направи законова промяна – доставки на МЗ/услуги на ЮЛ да се заплащат само по банков път. Сега между ТЕ освен конкурентното предимство неиздаване на фактури ще се добави още едно - плащане в брой. И накрая всички ще станат малки. Бизнеси, които са направили значими инвестиции през последните години и спрат да приемат плащания в брой от ЮЛ, дали ще оцелеят докато НАП дисциплинира тарикатите, правейки проверки в стотици хиляди търговски обекти, анализирайки данните, експортирани от системите им, и сравнявайки ги с незнайно какво?
Тази наредба е прецедент, защото изхожда от презумпцията за виновност в зависимост от бизнес процесите, в случая продажба по която се плаща в брой, и на НАП са й вменени разследващи функции. Да не цитирам мотивите за промените на Наредбата.
НАП като изгради собствена система, полезна за целта, да определи каква информация й е необходима за извършване на анализи и контрол и тогава да се изиска от бизнеса да я осигури по законен ред.
Да се дефинира понятието „контролно производство”.
А най-добре да се направи законова промяна – доставки на МЗ/услуги на ЮЛ да се заплащат само по банков път. Сега между ТЕ освен конкурентното предимство неиздаване на фактури ще се добави още едно - плащане в брой. И накрая всички ще станат малки. Бизнеси, които са направили значими инвестиции през последните години и спрат да приемат плащания в брой от ЮЛ, дали ще оцелеят докато НАП дисциплинира тарикатите, правейки проверки в стотици хиляди търговски обекти, анализирайки данните, експортирани от системите им, и сравнявайки ги с незнайно какво?
УНП при плащане по фактура да се генерира при плащането, УНП трябва да са хронологично поредни и без пропуски и ако има пропуск е индикация за анулиране. В момента при тези изисквания на Наредбата СУПТО-та вече осигуряват нехронологично поредни УНП и разработчиците твърдят, че софтуерът им е лицензиран с тази функционалност. Аванси в брой по сделка се регистрират с различен уникален номер, което обезсмисля формалния контрол сума по продажба, по която има някакво плащане в брой, да не надхвърля 9999.99 лв. ФУ трябва да се използва, където се извършват операции в брой, а не където се въвеждат поръчки/заявки/мисли за продажба. На проверяващ, за да провери дали контролната покупка се е отразила успешно, да пита след 5 минути НАП за ФБ, а не да иска незабавен достъп, за да види дали продажбата се е отразила в системата на търговеца. Нали този търговец подава ДДС дневник. (Едва ли дружества, които не са регистрирани по ДДС - с месечен оборот 4000лв, използват СУПТО.)
Номенклатурата за типове обекти ТЕ е доста семпла и повечето фирми ще попълнят в заявлението тип на дейност - 9. Как ще се развива тази номенклатура? Най-интересни са ТЕ, продаващи стоки непредназначени за лично ползване, но 80% от продажбите им са отчетени в продажби на население, информация от финансови отчети от търговския регистър.
ФБ при плащане по продажба на ЮЛ трябва да се различава от ФБ за продажба на краен потребител.
Сторнираният и сторниращият ФБ да се съхраняват от търговците не само в БД, но и като хартиени документи.
В ЗДДС да се премахне отлагателния период от една година за деклариране на получените доставки.
Да се уточни какво трябва да съдържа справка 18.1 в комбинация с 18.5. Разнообразията в реализациите на справките от Приложение 29 варират според различните бизнес или данъчни събития в процеса на продажба. В момента, при тази структура от данни, за да се генерира релевантна информация трябва да се прилага филтър върху начало на продажба към текущата дата и да се генерира винаги пълната история на продажби и плащания. Никъде в СУПТО софтуерите не се съхранява какъв филтър е приложен върху данните при генериране на тези справки, което е риск за търговците.
УНП при плащане по фактура да се генерира при плащането, УНП трябва да са хронологично поредни и без пропуски и ако има пропуск е индикация за анулиране. В момента при тези изисквания на Наредбата СУПТО-та вече осигуряват нехронологично поредни УНП и разработчиците твърдят, че софтуерът им е лицензиран с тази функционалност. Аванси в брой по сделка се регистрират с различен уникален номер, което обезсмисля формалния контрол сума по продажба, по която има някакво плащане в брой, да не надхвърля 9999.99 лв. ФУ трябва да се използва, където се извършват операции в брой, а не където се въвеждат поръчки/заявки/мисли за продажба. На проверяващ, за да провери дали контролната покупка се е отразила успешно, да пита след 5 минути НАП за ФБ, а не да иска незабавен достъп, за да види дали продажбата се е отразила в системата на търговеца. Нали този търговец подава ДДС дневник. (Едва ли дружества, които не са регистрирани по ДДС - с месечен оборот 4000лв, използват СУПТО.)
Номенклатурата за типове обекти ТЕ е доста семпла и повечето фирми ще попълнят в заявлението тип на дейност - 9. Как ще се развива тази номенклатура? Най-интересни са ТЕ, продаващи стоки непредназначени за лично ползване, но 80% от продажбите им са отчетени в продажби на население, информация от финансови отчети от търговския регистър.
ФБ при плащане по продажба на ЮЛ трябва да се различава от ФБ за продажба на краен потребител.
Сторнираният и сторниращият ФБ да се съхраняват от търговците не само в БД, но и като хартиени документи.
В ЗДДС да се премахне отлагателния период от една година за деклариране на получените доставки.
Да се уточни какво трябва да съдържа справка 18.1 в комбинация с 18.5. Разнообразията в реализациите на справките от Приложение 29 варират според различните бизнес или данъчни събития в процеса на продажба. В момента, при тази структура от данни, за да се генерира релевантна информация трябва да се прилага филтър върху начало на продажба към текущата дата и да се генерира винаги пълната история на продажби и плащания. Никъде в СУПТО софтуерите не се съхранява какъв филтър е приложен върху данните при генериране на тези справки, което е риск за търговците.
Предложения:
Да се премахне регистрацията на софтуерните системи. Въпреки регистрационния режим, единствено бизнесът носи отговорност за използвания от него софтуер и данните, които съхранява. Актуализирането на използваният софтуер спрямо законовите изискванията досега е било задължение на бизнеса. Пример са реализациите на ежегодните актуализации на ЗДДС и правилника за ДДС. Изискванията за регистрация и процесът на проверка от експерти на НАП де факто спират всякакви последващи промени в наредбата или друг закон, които водят и до промяна в използваните софтуери, а и след тези проверки НАП не гарантира съответствие. Регистрациите са безсмислен процес, имайки предвид, че и в момента регистрираните системи имат известни отклонения от изискванията и бизнесът носи пълната отговорност да избере система, която да отговаря на законовите и нормативни изисквания. Промяна в софтуерите, ползвани от бизнесите, може да произтече и от други закони или изисквания (като системи за качество или проследимост) и при този вариант на Наредбата регистрация на версия на софтуера е наложителен. Сега в бизнесът съществува заблуда, че СУПТО e лицензиран и не би трябвало да има проблеми при използването му, но всъщност не е така. Затова само бизнесът трябва да подава информация за ползвания от него софтуер. Единствено драйверите за връзка с ФУ, би трябвало да подлежат на контрол.
Изискването за IP адрес на БД да се премахне. Ако това изискване остане, трябва да се промени ДОПК и народното събрание да приеме IP адрес на БД да се класифицира като данъчна информация, тъй като НАП по закон е длъжен да съхранява и опазва само данъчна информация. В момента бизнесът доброволно предоставя тази информация.
Чл. 32 ал.2 от Наредбата да се премахне. Съгласно това правило, клиент пазарувал като краен потребител може да поиска да му се издаде фактура на юридическо лице. Това е пример за лоша практика, позволена нормативно. Процесът на продажба на юридическо лице, по която се плаща в брой, трябва да се опрости максимално. Плащане само по издадена вече фактура и към НАП да се подава номера на фактурата, по която е платено, или поне ЕИК на ЮЛ получател на документа по който се плаща. ФБ без номер на фактура или ЕИК трябва да е ясно че е потребление. В момента регистрираните СУПТО системи и счетоводните къщи владеят функционалността за промяна на клиент по вече издаден документ за продажба.
Предложения:
Да се премахне регистрацията на софтуерните системи. Въпреки регистрационния режим, единствено бизнесът носи отговорност за използвания от него софтуер и данните, които съхранява. Актуализирането на използваният софтуер спрямо законовите изискванията досега е било задължение на бизнеса. Пример са реализациите на ежегодните актуализации на ЗДДС и правилника за ДДС. Изискванията за регистрация и процесът на проверка от експерти на НАП де факто спират всякакви последващи промени в наредбата или друг закон, които водят и до промяна в използваните софтуери, а и след тези проверки НАП не гарантира съответствие. Регистрациите са безсмислен процес, имайки предвид, че и в момента регистрираните системи имат известни отклонения от изискванията и бизнесът носи пълната отговорност да избере система, която да отговаря на законовите и нормативни изисквания. Промяна в софтуерите, ползвани от бизнесите, може да произтече и от други закони или изисквания (като системи за качество или проследимост) и при този вариант на Наредбата регистрация на версия на софтуера е наложителен. Сега в бизнесът съществува заблуда, че СУПТО e лицензиран и не би трябвало да има проблеми при използването му, но всъщност не е така. Затова само бизнесът трябва да подава информация за ползвания от него софтуер. Единствено драйверите за връзка с ФУ, би трябвало да подлежат на контрол.
Изискването за IP адрес на БД да се премахне. Ако това изискване остане, трябва да се промени ДОПК и народното събрание да приеме IP адрес на БД да се класифицира като данъчна информация, тъй като НАП по закон е длъжен да съхранява и опазва само данъчна информация. В момента бизнесът доброволно предоставя тази информация.
Чл. 32 ал.2 от Наредбата да се премахне. Съгласно това правило, клиент пазарувал като краен потребител може да поиска да му се издаде фактура на юридическо лице. Това е пример за лоша практика, позволена нормативно. Процесът на продажба на юридическо лице, по която се плаща в брой, трябва да се опрости максимално. Плащане само по издадена вече фактура и към НАП да се подава номера на фактурата, по която е платено, или поне ЕИК на ЮЛ получател на документа по който се плаща. ФБ без номер на фактура или ЕИК трябва да е ясно че е потребление. В момента регистрираните СУПТО системи и счетоводните къщи владеят функционалността за промяна на клиент по вече издаден документ за продажба.
Сложен и ненадежден!
Сложен: има много участници и системи, огромен обем разнородни данни, труден е за управление и почти невъзможен за последващо развитие и промяна. Нормативно позволените процеси на продажби са разнообразни. Справките от Приложение 29 имат стандартна структура, но данните са семантично различни. Разчита се на данните от БД на бизнеса, но те пък са и структурно различни. Единствената важна система е тази на НАП, която събира информация чрез фискалните устройства, а тя е непълна. В момента се събират касови бележки за плащания, но НАП не знае това плащане от краен потребител ли е или е по документ издаден на ЮЛ.
Ненадежден: контролиращите са ненадеждни.
Разчита се на 6 000 000 потребители, част от които са деца, пенсионери и туристи, да взимат винаги фискалния бон след пазаруване и да знаят каква информация трябва да съдържа, освен стандартната от която се интересува потребител – продукти/услуги и цени. Всеки потребител трябва и да гледа ФБ много внимателно и всеки път да проверява дали не е получил дубликат. Все още стои проблемът потребител да плати по доставка на юридическо лице и да не разбере, защото фискалният бон изглежда по същия начин.
Разчита се един данъчен инспектор да познава към момента 540 версии на софтуери, а с времето версиите на регистрирани софтуери може да надхвърли хиляда. А в България реално се използват около 30 стандартни софтуера, а масовите да са около 10.
Сложен и ненадежден!
Сложен: има много участници и системи, огромен обем разнородни данни, труден е за управление и почти невъзможен за последващо развитие и промяна. Нормативно позволените процеси на продажби са разнообразни. Справките от Приложение 29 имат стандартна структура, но данните са семантично различни. Разчита се на данните от БД на бизнеса, но те пък са и структурно различни. Единствената важна система е тази на НАП, която събира информация чрез фискалните устройства, а тя е непълна. В момента се събират касови бележки за плащания, но НАП не знае това плащане от краен потребител ли е или е по документ издаден на ЮЛ.
Ненадежден: контролиращите са ненадеждни.
Разчита се на 6 000 000 потребители, част от които са деца, пенсионери и туристи, да взимат винаги фискалния бон след пазаруване и да знаят каква информация трябва да съдържа, освен стандартната от която се интересува потребител – продукти/услуги и цени. Всеки потребител трябва и да гледа ФБ много внимателно и всеки път да проверява дали не е получил дубликат. Все още стои проблемът потребител да плати по доставка на юридическо лице и да не разбере, защото фискалният бон изглежда по същия начин.
Разчита се един данъчен инспектор да познава към момента 540 версии на софтуери, а с времето версиите на регистрирани софтуери може да надхвърли хиляда. А в България реално се използват около 30 стандартни софтуера, а масовите да са около 10.
Много добри промени. Но тези промени не решават напълно проблемите на електронната търговия. Както може би знаете, има огромен брой съвременни методи за електронно плащане, които са популярни в различни страни. От paypal до alipay и bitcoin. Не се надявам, че премахването на N-18 ще се случи и няма да има какво да се направи, но моля, дайте възможност на електронни магазини, които нямат „истински търговски обект“, а продажбите се извършват изключително онлайн, за да отчитат продажби без физическо фискално устройство. Това трябва да стане онлайн. В съвременните реалности е много трудно да се комбинира модерна технология с ортодоксалното фискално устройство от миналото хилядолетие. Например в Русия има виртуални фискални устройства, които работят в облачната инфраструктура и издават електронни чекове, които се изпращат на купувача по имейл. Модерно е, удобно е. В момента НАП не предлага удобна опция за електронни търговци като мен, които продават цифрови стоки. Теоретично продавачите на цифрови стоки като мен, които нямат офлайн магазин (всички продажби се извършват онлайн без истински търговски обект), могат да използват фискални устройства, одобрени от НАП. Но ще бъде толкова удобно и удобно, колкото съветска телевизия в луксозен апартамент. Представено? Удобно, красиво? Можете ли да свържете ябълкова телевизия там? Почти същото, което предлагате да направите на такива продавачи на цифрови стоки, като мен. Моля, дайте ни възможност да отчитаме продажбите по електронен път, независимо кой метод на плащане избира купувачът. Нека е виртуално фискално устройство или каквото и да е, но трябва да е онлайн решение, а не ортодоксално устройство от миналото хилядолетие.
Много добри промени. Но тези промени не решават напълно проблемите на електронната търговия. Както може би знаете, има огромен брой съвременни методи за електронно плащане, които са популярни в различни страни. От paypal до alipay и bitcoin. Не се надявам, че премахването на N-18 ще се случи и няма да има какво да се направи, но моля, дайте възможност на електронни магазини, които нямат „истински търговски обект“, а продажбите се извършват изключително онлайн, за да отчитат продажби без физическо фискално устройство. Това трябва да стане онлайн. В съвременните реалности е много трудно да се комбинира модерна технология с ортодоксалното фискално устройство от миналото хилядолетие. Например в Русия има виртуални фискални устройства, които работят в облачната инфраструктура и издават електронни чекове, които се изпращат на купувача по имейл. Модерно е, удобно е. В момента НАП не предлага удобна опция за електронни търговци като мен, които продават цифрови стоки. Теоретично продавачите на цифрови стоки като мен, които нямат офлайн магазин (всички продажби се извършват онлайн без истински търговски обект), могат да използват фискални устройства, одобрени от НАП. Но ще бъде толкова удобно и удобно, колкото съветска телевизия в луксозен апартамент. Представено? Удобно, красиво? Можете ли да свържете ябълкова телевизия там? Почти същото, което предлагате да направите на такива продавачи на цифрови стоки, като мен. Моля, дайте ни възможност да отчитаме продажбите по електронен път, независимо кой метод на плащане избира купувачът. Нека е виртуално фискално устройство или каквото и да е, но трябва да е онлайн решение, а не ортодоксално устройство от миналото хилядолетие.
1. Непонятна е т3 от чл3, ал.17.
Ръководя фирма за разработка на софтуер за продажба на билети за спектакли
и се опитвам да разбера какво се влага като принцип в тази точка?
За да се продаде билет независимо по какъв начин - на каса или през интернет трябва да се
следи дали е продаден съответно от централна база данни на спектакъла.
Тази база данни е част от СУПТО за продажба на билети от каси с ФУ.
Тази база данни е и неразделна част от софтуер на интернет магазин (и)!
То какво е тълкованието на НАП относно общите модули на различните СУПТО!
И защо едно СУПТО да не може да отчита продажбите от каса и интернет магазини,
при положение че тези продажби се отчитат съгласно изискванията за присъствени и неприсъствени плащания.
Въпроса ми е: В тази точка включва ли се База данни спеделена от интернет магазина и продажбата от каса?
2. Пак не е решен въпроса за сторно операциите
Ще може ли да се прави сторно на каса
ако плащането е през интернет магазин и обратно? Какви са атрибутите за направа на
сторно на каса които ще се подават към ФУ, при положение че няма УНП в класическия вариант?
3. Срокове.
Ако това влезе в сила смятате ли че може да се разработи софтуерно за 10 дни?
1. Непонятна е т3 от чл3, ал.17.
Ръководя фирма за разработка на софтуер за продажба на билети за спектакли
и се опитвам да разбера какво се влага като принцип в тази точка?
За да се продаде билет независимо по какъв начин - на каса или през интернет трябва да се
следи дали е продаден съответно от централна база данни на спектакъла.
Тази база данни е част от СУПТО за продажба на билети от каси с ФУ.
Тази база данни е и неразделна част от софтуер на интернет магазин (и)!
То какво е тълкованието на НАП относно общите модули на различните СУПТО!
И защо едно СУПТО да не може да отчита продажбите от каса и интернет магазини,
при положение че тези продажби се отчитат съгласно изискванията за присъствени и неприсъствени плащания.
Въпроса ми е: В тази точка включва ли се База данни спеделена от интернет магазина и продажбата от каса?
2. Пак не е решен въпроса за сторно операциите
Ще може ли да се прави сторно на каса
ако плащането е през интернет магазин и обратно? Какви са атрибутите за направа на
сторно на каса които ще се подават към ФУ, при положение че няма УНП в класическия вариант?
3. Срокове.
Ако това влезе в сила смятате ли че може да се разработи софтуерно за 10 дни?
В това общественно обсъждане основния фокус е промяната на режима за електронни магазини, които искат да използват сигурен начин за събиране на плащания.
Описаните случаи и изисквания покриват широк спектър от модерната дигитална икономика и предоставят възможност на ползвателите на ЕЛМ да изберат ортодоксалната технология ЕЛМ+ФУ базирана върху електрически касови бележки или да се възползват от модерния подход за електронни документи и отчети.
В тази част измененията и документа заслужават подкрепа.
Единственния пропуск , които може да е въпрос на тълкувание (но по добре да не се разчита на това) е липсата на описание на технологична форма на продажби от разстояни през мобилно приложение инсталирано върху устройство на крайния потребител и плащания през него с кредитна дебитна карта.
Този тип приложения изпълняват изцяло функиционалността на електронен магазин, но са реализирани по този специфичен технологичен подход за да предоставят висока сигурност и удобство.
Предложението ни като асоциация - БАРБС е да :
Въведем разширение на дефиницията за допустимост така, че тези приложения да могат да използват тази модерна технология и възможност а именно чрез включването им като приложения реализиращи функционалност на електронен магазин, като се спазят всички условия към ЕЛМ
Вярваме, че тази промяна ще изпълни целите на НАП и МФ да предостави алтернатива на бизнесите готови да спазват фискалната рамка и използват сигурни канали за отчет и плащане. Бързото развитие на технологията ще гарантрира ръст. Ръста ще доведе до повече данъци. А когато те са платени до развитие на обществото ни.
Какви биха били последствията ако не се вклюат тези приложения:
Чисто технологичната имплементация на решението е, че след избор на стоки и услуги от каталожно приложението клиента / потребител ще бъде пренасочен към ЕЛМ, който да приключи плащането. Тези излишни операции ще затруднят употребата, ще предразположат срадата към по висок кибер риск и ще направят модерна и достъпна технология неприятна поради административен пропукс.
Очакваме предложението ни да бъде разгледано по същество и сме на разположение да съдействаме с експертиза при дефинирането на обхвата.
С уважение БАРБС
В това общественно обсъждане основния фокус е промяната на режима за електронни магазини, които искат да използват сигурен начин за събиране на плащания.
Описаните случаи и изисквания покриват широк спектър от модерната дигитална икономика и предоставят възможност на ползвателите на ЕЛМ да изберат ортодоксалната технология ЕЛМ+ФУ базирана върху електрически касови бележки или да се възползват от модерния подход за електронни документи и отчети.
В тази част измененията и документа заслужават подкрепа.
Единственния пропуск , които може да е въпрос на тълкувание (но по добре да не се разчита на това) е липсата на описание на технологична форма на продажби от разстояни през мобилно приложение инсталирано върху устройство на крайния потребител и плащания през него с кредитна дебитна карта.
Този тип приложения изпълняват изцяло функиционалността на електронен магазин, но са реализирани по този специфичен технологичен подход за да предоставят висока сигурност и удобство.
Предложението ни като асоциация - БАРБС е да :
Въведем разширение на дефиницията за допустимост така, че тези приложения да могат да използват тази модерна технология и възможност а именно чрез включването им като приложения реализиращи функционалност на електронен магазин, като се спазят всички условия към ЕЛМ
Вярваме, че тази промяна ще изпълни целите на НАП и МФ да предостави алтернатива на бизнесите готови да спазват фискалната рамка и използват сигурни канали за отчет и плащане. Бързото развитие на технологията ще гарантрира ръст. Ръста ще доведе до повече данъци. А когато те са платени до развитие на обществото ни.
Какви биха били последствията ако не се вклюат тези приложения:
Чисто технологичната имплементация на решението е, че след избор на стоки и услуги от каталожно приложението клиента / потребител ще бъде пренасочен към ЕЛМ, който да приключи плащането. Тези излишни операции ще затруднят употребата, ще предразположат срадата към по висок кибер риск и ще направят модерна и достъпна технология неприятна поради административен пропукс.
Очакваме предложението ни да бъде разгледано по същество и сме на разположение да съдействаме с експертиза при дефинирането на обхвата.
С уважение БАРБС
20.12.2019
19.01.2020
---
Справка или съобщение.---
Окончателен акт на Министерския съвет
Само една препоръка.
Покажете, че сте последователни и си удържте думата като не удължавате срока.
Стиска ли Ви?
Спестихте си оценка на въздействието за нея, но сега ще го видите и усетите!
Само една препоръка.
Покажете, че сте последователни и си удържте думата като не удължавате срока.
Стиска ли Ви?
Спестихте си оценка на въздействието за нея, но сега ще го видите и усетите!