Министерски съвет
Портал за обществени консултации
С направени промени в Наредба № Н-18/2006 г. (обн., ДВ, бр. 9 от 2020 г.) срокът за привеждане на лицата в съответствие с изискванията на наредбата беше удължен до 31 юли 2020 г. В оставащия до влизане в сила срок възникват редица допълнителни проблеми, свързани с наличието на различни бизнес модели, прилагани от икономическите оператори, което налага удължаване на срока за лицата.
Отчитайки комплексния характер на процесите по привеждане в съответствие с изискванията, са проведени работни срещи с представители на бизнеса, браншови, работодателски и професионални организации, разработчици на софтуер, дистрибутори, производители и вносители на фискални устройства и др., в резултат на които са и част от настоящите предложения за изменения и допълнения на Наредба № Н-18/2006 г. Останалата част от предлаганите промени са свързани с: промени, касаещи софтуерите за управление на продажбите в търговските обекти (СУПТО); регистрирането и отчитането на продажбите чрез фискални устройства (ФУ) и интегрирани автоматизирани системи за управление на търговската дейност (ИАСУТД); работата на междуведомствената комисия; промени в работата на електронните системи с фискална памет и с прецизиране на разпоредби на наредбата.
---
Пакет основни документи
Консултационен документ
---
Справка становища
---
Предвидени промени:
§ 35., т.3 гласи: "3. Точка 8 се изменя така:
„8. Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за готовността на ФУ за отпечатване на фискален бон и получаване на неговия ИН.
Свързаността се проверява:
- при стартиране на софтуера от работно място, имащо достъп до функционалността за управление на продажбите - за проверка на готовността за работа на ФУ.
При липса на отговор за свързаност с ФУ или на готовност за отпечатване на фискален бон, се блокира функционалността за откриване на продажби и за плащане, изискващо издаване на фискален бон."
Предложение:
Да отпадне необходимостта от проверка за свързаност с ФУ при стартиране на софтуера и идентифициране на потребителя при вход в системата за софтуери, които не са на модулен принцип.
Мотив:
В случаите, когато софтуерът не е на модулен принцип, а представлява комлексно решение (съвкупност от функционални възможности, реализирани в менюта и подменюта или прозорци компилирани в общ изпълним файл/*.exe) не може да се определи причината за стартиране на приложението и лог-ване в системата.
То може да е продиктувано от необходимост за генериране на управленски справки или използване на функционалност не пряко свързана с издаване на документи за продажба,
заявки от клиент или отразяване на плащания по продажби.
Предвидени промени:
§ 35., т.3 гласи: "3. Точка 8 се изменя така:
„8. Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за готовността на ФУ за отпечатване на фискален бон и получаване на неговия ИН.
Свързаността се проверява:
- при стартиране на софтуера от работно място, имащо достъп до функционалността за управление на продажбите - за проверка на готовността за работа на ФУ.
При липса на отговор за свързаност с ФУ или на готовност за отпечатване на фискален бон, се блокира функционалността за откриване на продажби и за плащане, изискващо издаване на фискален бон."
Предложение:
Да отпадне необходимостта от проверка за свързаност с ФУ при стартиране на софтуера и идентифициране на потребителя при вход в системата за софтуери, които не са на модулен принцип.
Мотив:
В случаите, когато софтуерът не е на модулен принцип, а представлява комлексно решение (съвкупност от функционални възможности, реализирани в менюта и подменюта или прозорци компилирани в общ изпълним файл/*.exe) не може да се определи причината за стартиране на приложението и лог-ване в системата.
То може да е продиктувано от необходимост за генериране на управленски справки или използване на функционалност не пряко свързана с издаване на документи за продажба,
заявки от клиент или отразяване на плащания по продажби.
Ясно е, че продажби на физическо лице на стоки за потребление не са търговски продажби. „Търговска продажба” по смисъла на чл. 318 от Търговския закон продажба в търговски обект ли е? Това, какво средство ползва купувачът да плати цената, не променя задълженията на страните – купувачът може да плати паричното задължение с пари в наличност или ползвайки услуги на банка. Трябва да става ясно, че търговски обект е място, където се извършват продажби на физически лица или продажби на стоки за лично потребление, за които търговецът не е длъжен да издаде данъчен документ. Конструкцията на чл. 118 от ЗДДС и на чл. 3 от Наредба Н-18 се разрушава при отложено плащане по вече изпълнена доставка.
НАП, реферирайки се към чл. 3 от Наредба Н-18, съветва бизнеса да задължава своите клиенти да използват само услуги на банки за плащане на парично задължение и така да се избегне задължението по чл. 118 ал.18 от ЗДДС. При съществуващата дефиниция на търговски обект, всяко място и всяко помещение - цялата територия на страната, и при липсата на знание какво е продажба в търговски обект, подобен съвет излага бизнеса на риск. В чл.3 от Наредба Н-18 е посочено само кога лице, задължено по чл. 118 ал.1 ЗДДС, не е длъжно да издава ФБ. Задължението по чл. 118 ал. 18 от ЗДДС е свързано с чл. 118 ал.1 от ЗДДС, а не с чл. 3 от Наредба Н-18. В чл. 118 ал.4 т.4 е посочено, че в наредба се определя издаването на фискални касови бележки и техните реквизити.
Липсва знание какво е продажба в търговски обект, но се полага особено усилие да се обясни, как тези продажби се управляват и то най-вече чрез софтуер. Очевидна е нуждата от нормативно определение на „продажби в търговски обект”.
Ясно е, че продажби на физическо лице на стоки за потребление не са търговски продажби. „Търговска продажба” по смисъла на чл. 318 от Търговския закон продажба в търговски обект ли е? Това, какво средство ползва купувачът да плати цената, не променя задълженията на страните – купувачът може да плати паричното задължение с пари в наличност или ползвайки услуги на банка. Трябва да става ясно, че търговски обект е място, където се извършват продажби на физически лица или продажби на стоки за лично потребление, за които търговецът не е длъжен да издаде данъчен документ. Конструкцията на чл. 118 от ЗДДС и на чл. 3 от Наредба Н-18 се разрушава при отложено плащане по вече изпълнена доставка.
НАП, реферирайки се към чл. 3 от Наредба Н-18, съветва бизнеса да задължава своите клиенти да използват само услуги на банки за плащане на парично задължение и така да се избегне задължението по чл. 118 ал.18 от ЗДДС. При съществуващата дефиниция на търговски обект, всяко място и всяко помещение - цялата територия на страната, и при липсата на знание какво е продажба в търговски обект, подобен съвет излага бизнеса на риск. В чл.3 от Наредба Н-18 е посочено само кога лице, задължено по чл. 118 ал.1 ЗДДС, не е длъжно да издава ФБ. Задължението по чл. 118 ал. 18 от ЗДДС е свързано с чл. 118 ал.1 от ЗДДС, а не с чл. 3 от Наредба Н-18. В чл. 118 ал.4 т.4 е посочено, че в наредба се определя издаването на фискални касови бележки и техните реквизити.
Липсва знание какво е продажба в търговски обект, но се полага особено усилие да се обясни, как тези продажби се управляват и то най-вече чрез софтуер. Очевидна е нуждата от нормативно определение на „продажби в търговски обект”.
Предложение: Да се даде определение на „продажба в търговски обект”, като се определи: купувачът, кога е извършена продажбата в търговски обект, кога тя е изпълнена, кога се издава ФБ и кога се отчита чрез отчет продажби по чл. 119. Въпросът е свързан и с нововъведението „частично плащане” в Наредба Н-18 и съдържанието на ФБ за „частично плащане”, както и с понятията „мълчалив ангажимент” на търговеца и „предполагане на намерение”, с които клиентът се поставя в позиция да тълкува действия на търговеца или да извърши продажба, без да е поискал.
В момента е прието разбирането, че всяка продажба на стоки/услуги, извършена навсякъде (от дефиницията на търговски обект в ЗДДС), за която е платено в брой, с карта или ваучер, е „продажба в търговски обект”. Задължението на търговеца възниква не от плащането на купувача, а от това, че извършва „продажби в търговски обект”. Взаимоотношенията търговец-купувач не се определят от средството, което използва купувача за плащане на парично задължение. Ако задължението възниква според средството за плащане на парично задължение, то едни и същи продажби един път ще са „продажби в ТО”, а друг път няма да бъдат, т.е. задължението, определено в чл. 118 ал. 1, ще възниква случайно. „Търговски обект” в текста на чл. 118 със сигурност не се употребява случайно и едва ли, за да се придаде смисъл „продажби навсякъде”. Ако понятие се тълкува като „навсякъде”, не би се употребило в нормативен текст.
Предложение: Да се даде определение на „продажба в търговски обект”, като се определи: купувачът, кога е извършена продажбата в търговски обект, кога тя е изпълнена, кога се издава ФБ и кога се отчита чрез отчет продажби по чл. 119. Въпросът е свързан и с нововъведението „частично плащане” в Наредба Н-18 и съдържанието на ФБ за „частично плащане”, както и с понятията „мълчалив ангажимент” на търговеца и „предполагане на намерение”, с които клиентът се поставя в позиция да тълкува действия на търговеца или да извърши продажба, без да е поискал.
В момента е прието разбирането, че всяка продажба на стоки/услуги, извършена навсякъде (от дефиницията на търговски обект в ЗДДС), за която е платено в брой, с карта или ваучер, е „продажба в търговски обект”. Задължението на търговеца възниква не от плащането на купувача, а от това, че извършва „продажби в търговски обект”. Взаимоотношенията търговец-купувач не се определят от средството, което използва купувача за плащане на парично задължение. Ако задължението възниква според средството за плащане на парично задължение, то едни и същи продажби един път ще са „продажби в ТО”, а друг път няма да бъдат, т.е. задължението, определено в чл. 118 ал. 1, ще възниква случайно. „Търговски обект” в текста на чл. 118 със сигурност не се употребява случайно и едва ли, за да се придаде смисъл „продажби навсякъде”. Ако понятие се тълкува като „навсякъде”, не би се употребило в нормативен текст.
Един от основните проблеми при прилагането на изискванията на Наредбата при всичките й промени през последните две години винаги не бил срокът, в който се очаква те (новите изисквания) да бъдат анализирани, бизнес процесите да бъдат променени спрямо тях, софтуерните продукти за управление на продажбите да бъдат разработени (едновременно за много клиенти, защото в много бизнеси за всеки клиент трябва да се разработи и декларира отделна версия), да бъдат подадени за деклариране, да се премине през многократни искания за корекции (някои от тях напълно основателни, но някои небазиращи се на никой текст от Наредбата, което води до продължителни кореспонденции), окончателната версия да се внедри на десетки или стотици работни места, да се обучат потребителите и т.н.
Предвид обема на промените в НИД-а, за пореден път срокът от 5 месеца за целия този процес е крайно недостатъчен за извършване на всички тези технически и административни дейности - очевидно е, че всички СУПТО трябва да бъдат променени и декларирани наново. Предложението ни е, на база досегашния опит с прилагане на промените в Наредбата, срокът този път да е реалистичен - поне 8 месеца.
В допълнение - предложеният срок реално е още по-кратък, предвид факта, че формалният е 31.12. - период с изключително намалена бизнес активност, множество официални почивни дни и отсъствия.
Един от основните проблеми при прилагането на изискванията на Наредбата при всичките й промени през последните две години винаги не бил срокът, в който се очаква те (новите изисквания) да бъдат анализирани, бизнес процесите да бъдат променени спрямо тях, софтуерните продукти за управление на продажбите да бъдат разработени (едновременно за много клиенти, защото в много бизнеси за всеки клиент трябва да се разработи и декларира отделна версия), да бъдат подадени за деклариране, да се премине през многократни искания за корекции (някои от тях напълно основателни, но някои небазиращи се на никой текст от Наредбата, което води до продължителни кореспонденции), окончателната версия да се внедри на десетки или стотици работни места, да се обучат потребителите и т.н.
Предвид обема на промените в НИД-а, за пореден път срокът от 5 месеца за целия този процес е крайно недостатъчен за извършване на всички тези технически и административни дейности - очевидно е, че всички СУПТО трябва да бъдат променени и декларирани наново. Предложението ни е, на база досегашния опит с прилагане на промените в Наредбата, срокът този път да е реалистичен - поне 8 месеца.
В допълнение - предложеният срок реално е още по-кратък, предвид факта, че формалният е 31.12. - период с изключително намалена бизнес активност, множество официални почивни дни и отсъствия.
чл. 26 (6) Се изменя: Съпътващите документи издавани във връзка с продажбата не могат да съдържат атрибутите съгласно чл. 26(1) т.10.
Мотив:
Фискална касова бележка дефинирана в чл. 2 от наредбата се издава само в случаите на плащане в брой или еквивалентно. Не допустимо е да се твърди в документ свързан с продажбата, че не се дължи плащане, на етап изпълнение на сделката не може да се договаря начина на плащане, начина само се констатира, чрез вписване в първичния документ и то само в случаите, че плащането се извърши веднага. Текста „че по него не се дължи плащане“ нарушава разпоредбите на ЗЗД, за всяка предоставена стока и услуга се дължи престация, ако не уговорено друго. Предложения текст създава предпоставка за конфронтация. Достатъчно е да няма лого идентифициращо фискализация. Не допустимо да се смесват функциите на различните първични документи. Понятието "текуща сметка" се ползва само в продажбите на дребно, при продажбите на едро в практиките се използват множество документи съпътсващи продажбите. Документа Информация за текуща сметка не кореспондира с никой от използваните в практиката документи.
чл. 26 (6) Се изменя: Съпътващите документи издавани във връзка с продажбата не могат да съдържат атрибутите съгласно чл. 26(1) т.10.
Мотив:
Фискална касова бележка дефинирана в чл. 2 от наредбата се издава само в случаите на плащане в брой или еквивалентно. Не допустимо е да се твърди в документ свързан с продажбата, че не се дължи плащане, на етап изпълнение на сделката не може да се договаря начина на плащане, начина само се констатира, чрез вписване в първичния документ и то само в случаите, че плащането се извърши веднага. Текста „че по него не се дължи плащане“ нарушава разпоредбите на ЗЗД, за всяка предоставена стока и услуга се дължи престация, ако не уговорено друго. Предложения текст създава предпоставка за конфронтация. Достатъчно е да няма лого идентифициращо фискализация. Не допустимо да се смесват функциите на различните първични документи. Понятието "текуща сметка" се ползва само в продажбите на дребно, при продажбите на едро в практиките се използват множество документи съпътсващи продажбите. Документа Информация за текуща сметка не кореспондира с никой от използваните в практиката документи.
Предложение за добавяне на алтернативен канал за предаване на данни на базата на стандарнатна интернет обвързаност.
Мотив:
Съгласно Чл. 17. (1) т. 5а от ДАНЪЧНО-ОСИГУРИТЕЛЕН ПРОЦЕСУАЛЕН КОДЕКС НАП е задължена: "5.да им бъдат осигурени и предоставени безплатно: а) приемането на всички документи, представени от задължени и трети лица относно публичните им задължения;". Заплащането на такса към мобилен оператор конкретно и само за деклариране на данъчна информация от страна на ФУ се явява нарушение на това право. В конкретната разпоредбда не са изключени електронните документите т.е. отчетите за продажбите.
Предложение за добавяне на алтернативен канал за предаване на данни на базата на стандарнатна интернет обвързаност.
Мотив:
Съгласно Чл. 17. (1) т. 5а от ДАНЪЧНО-ОСИГУРИТЕЛЕН ПРОЦЕСУАЛЕН КОДЕКС НАП е задължена: "5.да им бъдат осигурени и предоставени безплатно: а) приемането на всички документи, представени от задължени и трети лица относно публичните им задължения;". Заплащането на такса към мобилен оператор конкретно и само за деклариране на данъчна информация от страна на ФУ се явява нарушение на това право. В конкретната разпоредбда не са изключени електронните документите т.е. отчетите за продажбите.
Фискалните устройства подържат пределен брой редове като съдържание на фискален бон. Това ограничение, при функционирането на СУПТО, води до аварийни ситуации и съответно затормозява процеса на продажба. В Българското законодателство няма заложено подобно изискване.
Предложение: Да се задължат производителите на фискални устройства да премахнат това ограничение в режим "Фискален принтер".
Фискалните устройства подържат пределен брой редове като съдържание на фискален бон. Това ограничение, при функционирането на СУПТО, води до аварийни ситуации и съответно затормозява процеса на продажба. В Българското законодателство няма заложено подобно изискване.
Предложение: Да се задължат производителите на фискални устройства да премахнат това ограничение в режим "Фискален принтер".
Предложение за изменение: т.3 да отпадне
Мотиви: Тук се засяга експорт от СУПТО софтуери към такива, които не се използват като СУПТО, като се изисква допълнително пренасяне и на генерираното УНП. Смятаме, че това е ненужно и утежняващо изискване по няколко причини:
- В огромната си част, такива софтуери ще бъдат НЕСУПТО софтуери (в противен случай, те биха били декларирани като СУПТО и тогава ще се отнесем към Приложение 41). Тези софтуери могат да бъдат най-различни, писани от различни програмисти, много често конкретно за специфичните изисквания на клиента и съобразени с неговия бизнес модел. Не винаги тези софтуери имат и адекватна поддръжка. За да се приеме УНП от генерирания експорт, ще бъде необходимо да се направят корекции в импорта на всички тези софтуери, да се коригира базата им с данни, за да може да се запише УНП и т.н. и т.н. Това че СУПТО софтуерът ще добави поле за УНП в експорта на документите, не означава автоматично, че другата система ще може да го получи и съхрани. За всички такива софтуери ще се налага дописване и корекция, а за някои няма да бъде дори и възможно. Всичко това ще доведе до още по-големи разходи за клиентите, които освен разходите за СУПТО софтуери, ще трябва допълнително да направят още и за тези, които не са СУПТО.
- От друга страна цялата информация е налична в СУПТО софтуера и тя може да бъде извлечена и съпоставена с тази, намираща се в другата система. Наличието на УНП номер с нищо няма да спомогне допълнително, този номер го има към конкретния номер на документ в СУПТО софтуера и съпоставянето дали е коректен експорта и импорта може да се направи по номерата на документите. Това е и по-коректния начин за сравнение, тъй като много документи могат да имат едно УНП.
Наличието на УНП номера в софтуер, който не е деклариран като СУПТО би могло да доведе до заблуждения у потребителите, както и да доведе до възможности и опити за злоупотреби. Този УНП номер не би трябвало да присъства като информация в НЕСУПТО софтуер.
Предложение за изменение: т.3 да отпадне
Мотиви: Тук се засяга експорт от СУПТО софтуери към такива, които не се използват като СУПТО, като се изисква допълнително пренасяне и на генерираното УНП. Смятаме, че това е ненужно и утежняващо изискване по няколко причини:
- В огромната си част, такива софтуери ще бъдат НЕСУПТО софтуери (в противен случай, те биха били декларирани като СУПТО и тогава ще се отнесем към Приложение 41). Тези софтуери могат да бъдат най-различни, писани от различни програмисти, много често конкретно за специфичните изисквания на клиента и съобразени с неговия бизнес модел. Не винаги тези софтуери имат и адекватна поддръжка. За да се приеме УНП от генерирания експорт, ще бъде необходимо да се направят корекции в импорта на всички тези софтуери, да се коригира базата им с данни, за да може да се запише УНП и т.н. и т.н. Това че СУПТО софтуерът ще добави поле за УНП в експорта на документите, не означава автоматично, че другата система ще може да го получи и съхрани. За всички такива софтуери ще се налага дописване и корекция, а за някои няма да бъде дори и възможно. Всичко това ще доведе до още по-големи разходи за клиентите, които освен разходите за СУПТО софтуери, ще трябва допълнително да направят още и за тези, които не са СУПТО.
- От друга страна цялата информация е налична в СУПТО софтуера и тя може да бъде извлечена и съпоставена с тази, намираща се в другата система. Наличието на УНП номер с нищо няма да спомогне допълнително, този номер го има към конкретния номер на документ в СУПТО софтуера и съпоставянето дали е коректен експорта и импорта може да се направи по номерата на документите. Това е и по-коректния начин за сравнение, тъй като много документи могат да имат едно УНП.
Наличието на УНП номера в софтуер, който не е деклариран като СУПТО би могло да доведе до заблуждения у потребителите, както и да доведе до възможности и опити за злоупотреби. Този УНП номер не би трябвало да присъства като информация в НЕСУПТО софтуер.
Да се промени навсякъде в таблиците
Вместо:
– дата на откриване на продажбата;
– време на откриване на продажбата (час, минута, секунда);
Да стане съответно:
Мотив
Нееднократно повдиганото искане за дефиниция на „дата на откриване на продажбата“. Ако липсва такава дефиниция, се позволява широко и необосновано тълкуване, какво следва да се включи като информация в одиторския профил.
В СУПТО е напълно възможно да липсва информация относно датата и времето на откриване на продажба, особено в случаите на доставки с непрекъснато/повтарящо се изпълнение, продажби, започнали преди внедряването на СУПТО, информация за продажби, импортирани в СУПТО по силата на т.22 на приложение 29. В Наредбата няма дефиниция на дата на откриване на продажба, но има точни правила кога и по какъв начин да се генерира УНП като дата и време. В одиторския профил може да присъства само известна за СУПТО информация, а тя е датата и времето на генериране на УНП номера от СУПТО, съгласно правилата на т.9 на приложение 29.
Да се промени навсякъде в таблиците
Вместо:
– дата на приключване на продажбата;
– време на приключване на продажбата (час, минута, секунда);
Да стане съответно:
Мотив
Нееднократно повдиганото искане за дефиниция на „дата на приключване на продажба“. Ако липсва такава дефиниция, се позволява широко и необосновано тълкуване, какво следва да се включи като информация в одиторския профил.
В Наредбата няма дефиниция за дата и време на приключване на продажба, но в дефиницията по т. 19 на ДР към Наредбата се посочва кои крайни действия са в обхвата на СУПТО, а това е обработка на информация, свързана с текущо проследяване на процеса по продажба в търговски обект до предоставянето на стоки или услуги или до заплащането им. За заплащането на предоставените стоки или услуги има отделна самостоятелна таблица, в която присъства датата на плащане, ето защо, е добре в таблиците, в които се визира дата на приключване на продажбата тя да бъде заменена с дата на предоставяне на стоките или услугите. Така се получава последователност на въвежданата и предоставяната за проверка информация.
Да се промени навсякъде в таблиците
Вместо:
– дата на откриване на продажбата;
– време на откриване на продажбата (час, минута, секунда);
Да стане съответно:
Мотив
Нееднократно повдиганото искане за дефиниция на „дата на откриване на продажбата“. Ако липсва такава дефиниция, се позволява широко и необосновано тълкуване, какво следва да се включи като информация в одиторския профил.
В СУПТО е напълно възможно да липсва информация относно датата и времето на откриване на продажба, особено в случаите на доставки с непрекъснато/повтарящо се изпълнение, продажби, започнали преди внедряването на СУПТО, информация за продажби, импортирани в СУПТО по силата на т.22 на приложение 29. В Наредбата няма дефиниция на дата на откриване на продажба, но има точни правила кога и по какъв начин да се генерира УНП като дата и време. В одиторския профил може да присъства само известна за СУПТО информация, а тя е датата и времето на генериране на УНП номера от СУПТО, съгласно правилата на т.9 на приложение 29.
Да се промени навсякъде в таблиците
Вместо:
– дата на приключване на продажбата;
– време на приключване на продажбата (час, минута, секунда);
Да стане съответно:
Мотив
Нееднократно повдиганото искане за дефиниция на „дата на приключване на продажба“. Ако липсва такава дефиниция, се позволява широко и необосновано тълкуване, какво следва да се включи като информация в одиторския профил.
В Наредбата няма дефиниция за дата и време на приключване на продажба, но в дефиницията по т. 19 на ДР към Наредбата се посочва кои крайни действия са в обхвата на СУПТО, а това е обработка на информация, свързана с текущо проследяване на процеса по продажба в търговски обект до предоставянето на стоки или услуги или до заплащането им. За заплащането на предоставените стоки или услуги има отделна самостоятелна таблица, в която присъства датата на плащане, ето защо, е добре в таблиците, в които се визира дата на приключване на продажбата тя да бъде заменена с дата на предоставяне на стоките или услугите. Така се получава последователност на въвежданата и предоставяната за проверка информация.
Предложение за нов текст:
Чл. 52з
(10) Когато лице по чл. 118, ал. 18 от ЗДДС извършва продажби и чрез електронен магазин, се допуска софтуерът на електронния магазин да не отговаря на изискванията на приложение № 29, но при спазване на изискванията, посочени в приложение № 42.
Мотив:
Изискването СУПТО "автоматизирано извлича и зарежда в базата си данни най-малко на всеки 15 минути информацията за направените поръчки", ще направи почти невъзможна връзката с електронни магазини. Съществуват много безплатни и платени платформи, чрез които може да се направи електронен магазин. Не всяка една от тях обаче дава възможност за връзка на софтуер към тях или има разработени API функции за тази цел. Отделно от това, има много собствени разработки на фирми, съобразени с техните специфични изисквания. Те също нямат (или ако имат, те са съвсем различни) методи и функции за достъп до електронен магазин. При това положение, един стандартен софтуер за СУПТО ще трябва да произведе, да поддържа и да декларира отделни импортери за всеки един електронен магазин, от който ще импортира данни - нещо, което е невъзможно, защото за всеки отделен клиент ще трябва да се прави отделна версия и отделна разработка, която трябва да се поддържа. В допълнение, разработените досега импортери, които отговаряха на публикуваните схеми на НАП, вече няма да могат да работят и всички клиенти на СУПТО, които в момента работят, ще трябва да спрат и евентуално да заплатят нови разходи (и то не малки, защото ще бъдат конкретни разработки само за тях), за да могат да подновят дейността си.
Предложение за нов текст:
Чл. 52з
(10) Когато лице по чл. 118, ал. 18 от ЗДДС извършва продажби и чрез електронен магазин, се допуска софтуерът на електронния магазин да не отговаря на изискванията на приложение № 29, но при спазване на изискванията, посочени в приложение № 42.
Мотив:
Изискването СУПТО "автоматизирано извлича и зарежда в базата си данни най-малко на всеки 15 минути информацията за направените поръчки", ще направи почти невъзможна връзката с електронни магазини. Съществуват много безплатни и платени платформи, чрез които може да се направи електронен магазин. Не всяка една от тях обаче дава възможност за връзка на софтуер към тях или има разработени API функции за тази цел. Отделно от това, има много собствени разработки на фирми, съобразени с техните специфични изисквания. Те също нямат (или ако имат, те са съвсем различни) методи и функции за достъп до електронен магазин. При това положение, един стандартен софтуер за СУПТО ще трябва да произведе, да поддържа и да декларира отделни импортери за всеки един електронен магазин, от който ще импортира данни - нещо, което е невъзможно, защото за всеки отделен клиент ще трябва да се прави отделна версия и отделна разработка, която трябва да се поддържа. В допълнение, разработените досега импортери, които отговаряха на публикуваните схеми на НАП, вече няма да могат да работят и всички клиенти на СУПТО, които в момента работят, ще трябва да спрат и евентуално да заплатят нови разходи (и то не малки, защото ще бъдат конкретни разработки само за тях), за да могат да подновят дейността си.
Предложение за нов текст:
Чл. 52з
(7) В случай че лицето по чл. 118, ал. 18 от ЗДДС използва интегрирана информационна система за управление на продажбите/търговската дейност, всички налични функционалности, съгласно т.19 от Допълнителните разпоредби, се считат за софтуер за управление на продажби, който трябва да отговаря на изискванията, съгласно приложение № 29.
Мотиви:
Съгласно § 29, т.19 от Допълнителните разпоредби се променя и допълва с конкретна и ясна дефиниция за СУПТО, както и процесите, които обхваща. Изброяването на отделни функционалности в чл.52з(7) би могло да доведе до заблуди, двусмислие, различно тълкуване и прилагане на нормата, както сега, така и за в бъдеще. Логично е всички дефиниции и определения да бъдат едни и същи в цялата Наредба № Н-18/2006.
Предложение за нов текст:
Чл. 52з
(7) В случай че лицето по чл. 118, ал. 18 от ЗДДС използва интегрирана информационна система за управление на продажбите/търговската дейност, всички налични функционалности, съгласно т.19 от Допълнителните разпоредби, се считат за софтуер за управление на продажби, който трябва да отговаря на изискванията, съгласно приложение № 29.
Мотиви:
Съгласно § 29, т.19 от Допълнителните разпоредби се променя и допълва с конкретна и ясна дефиниция за СУПТО, както и процесите, които обхваща. Изброяването на отделни функционалности в чл.52з(7) би могло да доведе до заблуди, двусмислие, различно тълкуване и прилагане на нормата, както сега, така и за в бъдеще. Логично е всички дефиниции и определения да бъдат едни и същи в цялата Наредба № Н-18/2006.
Предложение за нов текст:
Чл. 52е1
(3) В 14 дневен срок от включване на новата версия на софтуера в публичния списък по чл. 118, ал. 19 от ЗДДС, производителят/разпространителят е длъжен да уведоми всички свои потребители, по договорените с тях средства и начини за комуникация, за наличието на нова версия и обстоятелствата по алинея 4.
Мотиви:
По-голямата част от СУПТО-софтуерите и ЕРП системите не са облачни услуги, а са инсталирани директно при клиента, в неговата инфраструктура и сървъри.
Производителят/разпространителят нямат достъп до тази инфраструктура и в тези случаи е невъзможно да се извърши такава актуализация.
От друга страна, производителят/разпространителят може и да не получи от потребителите желания достъп (дори и да поиска) или да няма техническа възможност за такъв, или пък да се нарушават правилата за информационна сигурност при клиента (вкл. и ISO-27001). Тогава би се наложило физически да се посещават такива потребители, да се съгласува с тях време за достъп, да се осигури посещение и т.н., което при по-голям брой клиенти също би било невъзможно.
При всички срещи представителите на НАП са обяснявали, че е недопустимо Наредба Н-18/2006 да се намесва в търговски взаимоотношения между производител/разпространител и лицата по чл. 3, които използват СУПТО.
Производителят/разпространителят е длъжен да уведоми, че след изтичане на срока по визираната алинея 3, версията ще бъде свалена от списъка на НАП, оттам е въпрос на търговски взаимоотношения как лицата по чл. 118 ал. 18 ще изпълнят своите задължения по Наредбата.
Предложение за нов текст:
Чл. 52е1
(3) В 14 дневен срок от включване на новата версия на софтуера в публичния списък по чл. 118, ал. 19 от ЗДДС, производителят/разпространителят е длъжен да уведоми всички свои потребители, по договорените с тях средства и начини за комуникация, за наличието на нова версия и обстоятелствата по алинея 4.
Мотиви:
По-голямата част от СУПТО-софтуерите и ЕРП системите не са облачни услуги, а са инсталирани директно при клиента, в неговата инфраструктура и сървъри.
Производителят/разпространителят нямат достъп до тази инфраструктура и в тези случаи е невъзможно да се извърши такава актуализация.
От друга страна, производителят/разпространителят може и да не получи от потребителите желания достъп (дори и да поиска) или да няма техническа възможност за такъв, или пък да се нарушават правилата за информационна сигурност при клиента (вкл. и ISO-27001). Тогава би се наложило физически да се посещават такива потребители, да се съгласува с тях време за достъп, да се осигури посещение и т.н., което при по-голям брой клиенти също би било невъзможно.
При всички срещи представителите на НАП са обяснявали, че е недопустимо Наредба Н-18/2006 да се намесва в търговски взаимоотношения между производител/разпространител и лицата по чл. 3, които използват СУПТО.
Производителят/разпространителят е длъжен да уведоми, че след изтичане на срока по визираната алинея 3, версията ще бъде свалена от списъка на НАП, оттам е въпрос на търговски взаимоотношения как лицата по чл. 118 ал. 18 ще изпълнят своите задължения по Наредбата.
Предложение за удължаване на срока от 7 на 14 дни в ал.2 :
Чл. 52е1
(2) В 14-дневен срок от установяването на обстоятелството по ал. 1 производителят/разпространителят е длъжен да подаде декларация по чл. 52б за нова версия на софтуера, съответстваща на изискванията на приложение № 29.
Мотиви:
В много случаи намирането и отстраняването на грешка в софтуера изисква повече време, особено при логическа грешка. Това може да засегне и преработка на много модули и функции. Самият „билд“ (създаване) на нова версия, както и декларирането ѝ също изискват допълнително време.
Предложение за удължаване на срока от 7 на 14 дни в ал.2 :
Чл. 52е1
(2) В 14-дневен срок от установяването на обстоятелството по ал. 1 производителят/разпространителят е длъжен да подаде декларация по чл. 52б за нова версия на софтуера, съответстваща на изискванията на приложение № 29.
Мотиви:
В много случаи намирането и отстраняването на грешка в софтуера изисква повече време, особено при логическа грешка. Това може да засегне и преработка на много модули и функции. Самият „билд“ (създаване) на нова версия, както и декларирането ѝ също изискват допълнително време.
Предложение за нов текст:
Чл. 31
(2а) При документиране на сторно операция, във връзка с която е издадено кредитно известие или друг първичен счетоводен документ по чл. 6, ал. 1 от Закона за счетоводството, в което са посочени количеството и вида на стоките или услугите, в сторно документа се допуска да се отпечата сумарния оборот по съответните данъчни групи и кода на данъчната група, като задължително се посочи номера и датата на кредитното известие. Предходното изречение не се прилага в случаите на чл. 27, ал. 3, т. 3.
Мотив
Промяната се предлага, за да се допусне издаване на СТОРНО сумарен фискален бон по данъчни групи в случаите на:
Анулиране на фактура или дебитно известие, което се прави по силата на чл. 116 от ЗДДС, по които вече има издаден сумарен фискален бон.
Анулиране на друг първичен счетоводен по чл. 6, ал. 1 на Закона за счетоводството по силата на чл. 8 от Закона на счетоводството, по който вече има издаден вече сумарен фискален бон.
Предложение за нов текст:
Чл. 31
(2а) При документиране на сторно операция, във връзка с която е издадено кредитно известие или друг първичен счетоводен документ по чл. 6, ал. 1 от Закона за счетоводството, в което са посочени количеството и вида на стоките или услугите, в сторно документа се допуска да се отпечата сумарния оборот по съответните данъчни групи и кода на данъчната група, като задължително се посочи номера и датата на кредитното известие. Предходното изречение не се прилага в случаите на чл. 27, ал. 3, т. 3.
Мотив
Промяната се предлага, за да се допусне издаване на СТОРНО сумарен фискален бон по данъчни групи в случаите на:
Анулиране на фактура или дебитно известие, което се прави по силата на чл. 116 от ЗДДС, по които вече има издаден сумарен фискален бон.
Анулиране на друг първичен счетоводен по чл. 6, ал. 1 на Закона за счетоводството по силата на чл. 8 от Закона на счетоводството, по който вече има издаден вече сумарен фискален бон.
Предложение за нов текст:
Чл. 26
(7) При продажба, за която е издадена фактура, дебитно известие, туристически ваучер, резервационна бланка по смисъла на Закона за туризма или друг първичен счетоводен документ по чл. 6, ал. 1 от Закона за счетоводството, в която/което/който са посочени количеството и вида на стоките или услугите, във фискалния/системния бон се допуска да се отпечата сумарния оборот по съответните данъчни групи и код на данъчната група, като задължително се посочи номера и датата на фактурата, дебитното известие, туристическия ваучер, резервационната бланка или първичния счетоводен документ, по която/което/който се извършва плащането. Предходното изречение не се прилага в случаите на чл. 27, ал. 3, т. 3. Издадените документи по изречение първо се съхраняват най-малко в срока по чл. 38 от ДОПК.
Мотив
Предложената промяна на този текст е с цел да се върне първоначално предложения текст, който беше обсъждан на срещите между НАП и бизнеса на срещите преди публикуването на Проект за НИД на Наредба Н-18/2006 и беше приет без възражения. На тези срещи се стигна до извода, че този текст решава в голямата си степен множество технически трудности, които имат софтуерите при подаване на коректна информация към фискалните устройства по отношение на конкретни наименования на стоката/услугата, количества, цени и търговски отстъпки включително и множеството постъпили запитвания за разликите между начина на работа на изчисленията във фискалните устройства и заложените такива във софтуерите, които по никакъв начин не нарушават законодателството в момента. От друга страна, не се нарушава проследимостта и възможността за фискален контрол. Не се нарушава и правото на клиентите да получат подробна и точна информация за направената покупка.
За съжаление, в публикувания за обществено обсъждане Проект на НИД на Наредба Н-18/2006 беше предложен различен текст, който на срещата с бизнеса беше изяснено, че е техническа грешка от механичното пренасяне на текстове от определението по т. 19 към тази разпоредба, което обаче връща нещата в изходна позиция.
Предложение за нов текст:
Чл. 26
(7) При продажба, за която е издадена фактура, дебитно известие, туристически ваучер, резервационна бланка по смисъла на Закона за туризма или друг първичен счетоводен документ по чл. 6, ал. 1 от Закона за счетоводството, в която/което/който са посочени количеството и вида на стоките или услугите, във фискалния/системния бон се допуска да се отпечата сумарния оборот по съответните данъчни групи и код на данъчната група, като задължително се посочи номера и датата на фактурата, дебитното известие, туристическия ваучер, резервационната бланка или първичния счетоводен документ, по която/което/който се извършва плащането. Предходното изречение не се прилага в случаите на чл. 27, ал. 3, т. 3. Издадените документи по изречение първо се съхраняват най-малко в срока по чл. 38 от ДОПК.
Мотив
Предложената промяна на този текст е с цел да се върне първоначално предложения текст, който беше обсъждан на срещите между НАП и бизнеса на срещите преди публикуването на Проект за НИД на Наредба Н-18/2006 и беше приет без възражения. На тези срещи се стигна до извода, че този текст решава в голямата си степен множество технически трудности, които имат софтуерите при подаване на коректна информация към фискалните устройства по отношение на конкретни наименования на стоката/услугата, количества, цени и търговски отстъпки включително и множеството постъпили запитвания за разликите между начина на работа на изчисленията във фискалните устройства и заложените такива във софтуерите, които по никакъв начин не нарушават законодателството в момента. От друга страна, не се нарушава проследимостта и възможността за фискален контрол. Не се нарушава и правото на клиентите да получат подробна и точна информация за направената покупка.
За съжаление, в публикувания за обществено обсъждане Проект на НИД на Наредба Н-18/2006 беше предложен различен текст, който на срещата с бизнеса беше изяснено, че е техническа грешка от механичното пренасяне на текстове от определението по т. 19 към тази разпоредба, което обаче връща нещата в изходна позиция.
Предложение за нов текст:
Чл. 25
(4) Допуска се да не се издава документът по чл. 3, ал. 1, изречение второ, ако за продажбата е издаден данъчен документ по чл. 112 на ЗДДС, съдържащ данните по чл. 26, ал. 1, т. 1, 4, 7 и 8, с изключение на кода на данъчната група.
Мотив
При изменение на данъчната основа на доставка или при развалянето на доставка, за която е издадена фактура, доставчикът е длъжен да издаде известие към фактурата. С промяната на текста се цели обхващане на всички случаи и документи свързани с такъв тип продажби.
Предложение за нов текст:
Чл. 25
(4) Допуска се да не се издава документът по чл. 3, ал. 1, изречение второ, ако за продажбата е издаден данъчен документ по чл. 112 на ЗДДС, съдържащ данните по чл. 26, ал. 1, т. 1, 4, 7 и 8, с изключение на кода на данъчната група.
Мотив
При изменение на данъчната основа на доставка или при развалянето на доставка, за която е издадена фактура, доставчикът е длъжен да издаде известие към фактурата. С промяната на текста се цели обхващане на всички случаи и документи свързани с такъв тип продажби.
Предложение 3: в чл.52з се създава нова алинея 14 "Изискванията по алинеи 8, 9 и 10 не се отнасят за лице по чл. 118,ал.18 от ЗДДС, използващо софтуер по чл.52а¹ "
Мотив: Съгласно предложената в проекта промяна софтуерът по чл.52а¹ може да не отговаря на изискването на новата т.22 от Приложение №29. От друга страна с премахването на изискването за задължително генериране на УНП не е възможно изпълнение на изискванията в Приложение 41 и Приложение 42, отнасящи се до УНП, както и изисквания за информация в одиторските справки и др.
Предложение 3: в чл.52з се създава нова алинея 14 "Изискванията по алинеи 8, 9 и 10 не се отнасят за лице по чл. 118,ал.18 от ЗДДС, използващо софтуер по чл.52а¹ "
Мотив: Съгласно предложената в проекта промяна софтуерът по чл.52а¹ може да не отговаря на изискването на новата т.22 от Приложение №29. От друга страна с премахването на изискването за задължително генериране на УНП не е възможно изпълнение на изискванията в Приложение 41 и Приложение 42, отнасящи се до УНП, както и изисквания за информация в одиторските справки и др.
2. чл.52а¹, ал.5 и Приложение 37
Предложение: В изречение първо на ал.5 на чл.52а¹ след " регистрирани в софтуера" се добавя текст " операции по" и след "продажби" се добавя текст " ( откриване, плащане, анулиране, сторниране и приключване)"
Мотив: В наредбата няма определение за регистрирана продажба. Необходимо е прецизиране на текста с цел яснота за операциите по една продажба, които трябва да бъдат декларирани в текущата и следващи календарни години. Сегашният текст без проблем може да се приложи за продажби, които са открити, анулирани, сторнирани и приключени през една календарна година. Ако по една открита продажба има операции в следваща календарна година не е ясно дали трябва и каква информация следва да се посочи.
Предложение: в Приложение 37 на редове "обща сума на продажба-без ДДС, в лева", "отстъпка-в лв." и "дължима сума по продажбата-в лв. " в колона Забележка се добавя текст "Полето се попълва с 0,00 ако годината на ред дата на откриване на продажба е различна от годината на ред календарна година, с изключение на увеличение на сумата". На ред "ДДС-сума-в лв" в колона Забележка се добавя текст "Полето се попълва с 0,00 ако годината на ред дата на откриване на продажбата е различна от годината на ред календарна година, с изключение на увеличение на ДДС сума и при продажби, за които ДДС е 0,00 или не се начислява ДДС"
Мотив: Прецизиране с цел коректно подаване на информация и избягване на повторно подаване на информация за извършени през предходна година операции по една продажба. Информация на редове обща сума на продажби, отстъпка, ДДС и дължима сума за открита през предходна година продажба е логично да има в следваща календарна година само при промяна в посока увеличение-например при дебитно известие, добавяне на нови артикули в открита поръчка, увеличение при разлика между сумата при откриване в поръчката и сумата при фактуриране и др. По отношение на ред ДДС тъй като при ВОД, износ, услуги към чужбина и др. ДДС е 0,00 или няма ДДС, а тези продажби също се регистрират в софтуера и не са изключени в подаваната информация, полето не трябва да е задължително или за тях трябва да е попълнено с 0.00
2. чл.52а¹, ал.5 и Приложение 37
Предложение: В изречение първо на ал.5 на чл.52а¹ след " регистрирани в софтуера" се добавя текст " операции по" и след "продажби" се добавя текст " ( откриване, плащане, анулиране, сторниране и приключване)"
Мотив: В наредбата няма определение за регистрирана продажба. Необходимо е прецизиране на текста с цел яснота за операциите по една продажба, които трябва да бъдат декларирани в текущата и следващи календарни години. Сегашният текст без проблем може да се приложи за продажби, които са открити, анулирани, сторнирани и приключени през една календарна година. Ако по една открита продажба има операции в следваща календарна година не е ясно дали трябва и каква информация следва да се посочи.
Предложение: в Приложение 37 на редове "обща сума на продажба-без ДДС, в лева", "отстъпка-в лв." и "дължима сума по продажбата-в лв. " в колона Забележка се добавя текст "Полето се попълва с 0,00 ако годината на ред дата на откриване на продажба е различна от годината на ред календарна година, с изключение на увеличение на сумата". На ред "ДДС-сума-в лв" в колона Забележка се добавя текст "Полето се попълва с 0,00 ако годината на ред дата на откриване на продажбата е различна от годината на ред календарна година, с изключение на увеличение на ДДС сума и при продажби, за които ДДС е 0,00 или не се начислява ДДС"
Мотив: Прецизиране с цел коректно подаване на информация и избягване на повторно подаване на информация за извършени през предходна година операции по една продажба. Информация на редове обща сума на продажби, отстъпка, ДДС и дължима сума за открита през предходна година продажба е логично да има в следваща календарна година само при промяна в посока увеличение-например при дебитно известие, добавяне на нови артикули в открита поръчка, увеличение при разлика между сумата при откриване в поръчката и сумата при фактуриране и др. По отношение на ред ДДС тъй като при ВОД, износ, услуги към чужбина и др. ДДС е 0,00 или няма ДДС, а тези продажби също се регистрират в софтуера и не са изключени в подаваната информация, полето не трябва да е задължително или за тях трябва да е попълнено с 0.00
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а¹ "
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а¹ "
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
Предложение: текста " извличане на данни от БД" се заменя с " извличане на данни, свързани с управление на продажбите от БД"
Мотив: дълъг процес на експортиране на данни от големи бази данни
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
Предложение: текста " извличане на данни от БД" се заменя с " извличане на данни, свързани с управление на продажбите от БД"
Мотив: дълъг процес на експортиране на данни от големи бази данни
Отлагане до преминаване на финансовата криза и докато НАП отговори на всички въпроси изпратени официално и се изчистят всички проблемни точки по наредбата.
Отлагане до преминаване на финансовата криза и докато НАП отговори на всички въпроси изпратени официално и се изчистят всички проблемни точки по наредбата.
Изпратили сме официални запитвания до НАП във връзка с Н18 януари и още чакаме отговор. Защо НАП не отговаря на запитванията? Не сме само ние в подобна ситуация. Не може да се очаква от нас да изпълним сроковете поставени в Наредбата като 31.07, а в същото време да не получаваме отговори.
Изпратили сме официални запитвания до НАП във връзка с Н18 януари и още чакаме отговор. Защо НАП не отговаря на запитванията? Не сме само ние в подобна ситуация. Не може да се очаква от нас да изпълним сроковете поставени в Наредбата като 31.07, а в същото време да не получаваме отговори.
Анализ на проблемите и обосноваване от страна на НАП защо фискализацията в реално време трябва да включва всички плащания, а не само касовите. Защо фискализацията трябва да контролира бизнес процеси? Концентриране върху реалните проблеми за укриване на приходи, а не аргументиране на опитите за контрол на бизнес процесите във всички фирми. (Като пример - на най-проблемния сектор с най-голямо подозрение, че укрива приходи му намалиха ДДС-то :) Обосноваване на логиката на НАП да превърне всички софтуери в софтуерни касови апарати, които да управляват досегашните касови апарати?
Анализ на проблемите и обосноваване от страна на НАП защо фискализацията в реално време трябва да включва всички плащания, а не само касовите. Защо фискализацията трябва да контролира бизнес процеси? Концентриране върху реалните проблеми за укриване на приходи, а не аргументиране на опитите за контрол на бизнес процесите във всички фирми. (Като пример - на най-проблемния сектор с най-голямо подозрение, че укрива приходи му намалиха ДДС-то :) Обосноваване на логиката на НАП да превърне всички софтуери в софтуерни касови апарати, които да управляват досегашните касови апарати?
Изчистване на понятието продажба и премахване на задължението да се обвързват поръчки и да се подава информация за тях, тъй като поръчката НЕ представлява продажба и НЕ е разбираемо защо НАП желае да получава информация за всички поръчки, когато такава не ѝ е нужна за целите на фискалния контрол. До момента на извършване на продажба, търговецът няма задължение към фиска, тъй като пари не са получени и сделка не е била осъществена, а има само изразено намерение за такава обективирано в поръчка или оферта. Същинската продажба се извършва с прехвърляне на собствеността или правото, като заедно с прехвърляне на собствеността важи правилото, че вещта погива за собственика.
Изчистване на понятието продажба и премахване на задължението да се обвързват поръчки и да се подава информация за тях, тъй като поръчката НЕ представлява продажба и НЕ е разбираемо защо НАП желае да получава информация за всички поръчки, когато такава не ѝ е нужна за целите на фискалния контрол. До момента на извършване на продажба, търговецът няма задължение към фиска, тъй като пари не са получени и сделка не е била осъществена, а има само изразено намерение за такава обективирано в поръчка или оферта. Същинската продажба се извършва с прехвърляне на собствеността или правото, като заедно с прехвърляне на собствеността важи правилото, че вещта погива за собственика.
Искане:
Да се добави към изискването за език на всички системи алтернатива те да могат да бъдат „на английски език или на български език“ вместо единствено и само на български.
Мотиви:
Това ще осигури по-голяма гъвкавост и възможност за включване към СУПТО и Н18 на повече софтуери, особено на чуждестранните такива, на тежки обемни софтуери, които изискват значително време и ресурс за техния превод, при по-ниски разходи като от своя страна няма да задължи фиска да говори всички възможни чужди езици. Ще предостави по-голяма възможност за адаптиране в бъдеще.
Английският е смятан за „световен език“, „лингва франка“ на съвремието. Той е официален език на Европейския съюз, ООН, НАТО и на повечето международни организации. Английският е най-често използваният език в науката и основен за бизнеса в 21 век, особено ако този бизнес иска да бъде конкурентен. По данни към 2000 г. над 2 млрд. от общо 8 млрд. души говорят английски. Официален е в 67 държави и 27 несуверенни.
Искане:
Да се добави към изискването за език на всички системи алтернатива те да могат да бъдат „на английски език или на български език“ вместо единствено и само на български.
Мотиви:
Това ще осигури по-голяма гъвкавост и възможност за включване към СУПТО и Н18 на повече софтуери, особено на чуждестранните такива, на тежки обемни софтуери, които изискват значително време и ресурс за техния превод, при по-ниски разходи като от своя страна няма да задължи фиска да говори всички възможни чужди езици. Ще предостави по-голяма възможност за адаптиране в бъдеще.
Английският е смятан за „световен език“, „лингва франка“ на съвремието. Той е официален език на Европейския съюз, ООН, НАТО и на повечето международни организации. Английският е най-често използваният език в науката и основен за бизнеса в 21 век, особено ако този бизнес иска да бъде конкурентен. По данни към 2000 г. над 2 млрд. от общо 8 млрд. души говорят английски. Официален е в 67 държави и 27 несуверенни.
Искане:
POS, PayPal, TransferWise, Skrill, Revolut и други Fintech решения да се изключат от искането за издаване на фискален бон
Мотиви:
Това са перфектно проследими плащания, тъй като задължително преминават през банкови и платежни системи, за тях съществува документална следа и не следва да се приравняват на плащане в брой, където единственото доказателство за съществуването на извършено плащане е фискалният бон.
ОК е фирмите да предоставят извлечения и да декларират всички такива плащания към НАП, под каквато форма НАП прецени, така както са длъжни да го правят и с банковите плащания и с всички останали плащания, а НАП да си изискват засичане от съответните банкови и платежни оператори, стига да не се налага пренаписване и превод на целия български и световен софтуер и изменение на всички бизнес процеси във фирмите, както и тази форма на фискален контрол да не налага разход за една фирма, който надвишава разхода за преместването на бизнеса ѝ в друга юрисдикция.
Искане:
POS, PayPal, TransferWise, Skrill, Revolut и други Fintech решения да се изключат от искането за издаване на фискален бон
Мотиви:
Това са перфектно проследими плащания, тъй като задължително преминават през банкови и платежни системи, за тях съществува документална следа и не следва да се приравняват на плащане в брой, където единственото доказателство за съществуването на извършено плащане е фискалният бон.
ОК е фирмите да предоставят извлечения и да декларират всички такива плащания към НАП, под каквато форма НАП прецени, така както са длъжни да го правят и с банковите плащания и с всички останали плащания, а НАП да си изискват засичане от съответните банкови и платежни оператори, стига да не се налага пренаписване и превод на целия български и световен софтуер и изменение на всички бизнес процеси във фирмите, както и тази форма на фискален контрол да не налага разход за една фирма, който надвишава разхода за преместването на бизнеса ѝ в друга юрисдикция.
Искане:
Да се предостави възможност за софтуерна фискализация без прекомерни СУПТО изисквания, която да е гъвкава, лесна и евтина за внедряване от фирмите, да опростява фискалния контрол без да затруднява и да повлиява/изменя основните бизнес процеси на предприятията.
Същата да е направена с мисъл за бъдещото развитие на технологиите, а не да бъде направена по „остарял“ начин, та да се окаже неработеща и невъзможна за надграждане в хоризонт от 2-5-10 години.
Държавата да предложи API от тяхна страна.
Държавата да се поинтересува от добрите примери за фискален контрол в други държави, и да почерпи ноу-хау, така че ползите да са оптимални, а негативите – минимални – за всички ангажирани страни.
Мотиви:
Не е вариант връзката към НАП да е през касов апарат и не е вариант да се ограничава свободното ползване на софтуер от бизнеса, който да е удобен и полезен за дейността му и то единствено за целите на фискалния контрол. Не е вариант цялата структура да се организира около ползване на СИМ карти.
Няма как чуждестранни компании със стотици хиляди клиенти по цял свят да се занимават с изискванията на НАП и да преработват софтуера си. eBay, Facebook, Etsy, SAP, WooCommerce, Magento, маркетплейсите? Примерите могат да бъдат много.
Българският бизнес трябва да е конкурентен на международно ниво, за да генерира повече приход, тогава и приходът в хазната ще е по-голям.
Трябва да се измисли решение, което да не ограничава избора на софтуер и да не пречи на свободната бизнес инициатива, която генерира стойност за бизнеса, обществото, пълни държавния бюджет и създава работни места.
И най-накрая, държавата, в частност НАП, да наеме ИТ специалисти в екипа, който обсъжда Н18 с различните представители на бизнеса, не може функционалности на софтуер да се обсъждат с икономисти, които не са компетентни в техническата част и техническият им хоризонт се ограничава с понятията ФУ, QR код и СИМ карта, с които са се запознали буквално през последната 1 година.
Оправете си осраната наредба, докато все още има време, защото нанасяте щета и ако не сте го разбрали вече, ще го разберете по трудния начин.
Искане:
Да се предостави възможност за софтуерна фискализация без прекомерни СУПТО изисквания, която да е гъвкава, лесна и евтина за внедряване от фирмите, да опростява фискалния контрол без да затруднява и да повлиява/изменя основните бизнес процеси на предприятията.
Същата да е направена с мисъл за бъдещото развитие на технологиите, а не да бъде направена по „остарял“ начин, та да се окаже неработеща и невъзможна за надграждане в хоризонт от 2-5-10 години.
Държавата да предложи API от тяхна страна.
Държавата да се поинтересува от добрите примери за фискален контрол в други държави, и да почерпи ноу-хау, така че ползите да са оптимални, а негативите – минимални – за всички ангажирани страни.
Мотиви:
Не е вариант връзката към НАП да е през касов апарат и не е вариант да се ограничава свободното ползване на софтуер от бизнеса, който да е удобен и полезен за дейността му и то единствено за целите на фискалния контрол. Не е вариант цялата структура да се организира около ползване на СИМ карти.
Няма как чуждестранни компании със стотици хиляди клиенти по цял свят да се занимават с изискванията на НАП и да преработват софтуера си. eBay, Facebook, Etsy, SAP, WooCommerce, Magento, маркетплейсите? Примерите могат да бъдат много.
Българският бизнес трябва да е конкурентен на международно ниво, за да генерира повече приход, тогава и приходът в хазната ще е по-голям.
Трябва да се измисли решение, което да не ограничава избора на софтуер и да не пречи на свободната бизнес инициатива, която генерира стойност за бизнеса, обществото, пълни държавния бюджет и създава работни места.
И най-накрая, държавата, в частност НАП, да наеме ИТ специалисти в екипа, който обсъжда Н18 с различните представители на бизнеса, не може функционалности на софтуер да се обсъждат с икономисти, които не са компетентни в техническата част и техническият им хоризонт се ограничава с понятията ФУ, QR код и СИМ карта, с които са се запознали буквално през последната 1 година.
Оправете си осраната наредба, докато все още има време, защото нанасяте щета и ако не сте го разбрали вече, ще го разберете по трудния начин.
Искане: Цялостно пренаписване на Н18 отначало до край и извършване на РЕАЛНА ИСТИНСКА оценка на въздействието, както и на разяснителна кампания от страна на НАП.
Мотиви:
В същността си Наредба Н18 кара целия бизнес в България да промени начина си на работа и се опитва да наложи контрол над бизнес процесите на предприятията, което е далеч извън рамките на контрола над отчетността, който НАП следва да извършва.
Разпоредбите са неясни и се създава възможност за произвол от страна на държавни служители, които не носят персонална правно-материална отговорност.
Н18 променя бизнес процесите във фирмите по начин, който ЗДДС не изисква.
Искане: Цялостно пренаписване на Н18 отначало до край и извършване на РЕАЛНА ИСТИНСКА оценка на въздействието, както и на разяснителна кампания от страна на НАП.
Мотиви:
В същността си Наредба Н18 кара целия бизнес в България да промени начина си на работа и се опитва да наложи контрол над бизнес процесите на предприятията, което е далеч извън рамките на контрола над отчетността, който НАП следва да извършва.
Разпоредбите са неясни и се създава възможност за произвол от страна на държавни служители, които не носят персонална правно-материална отговорност.
Н18 променя бизнес процесите във фирмите по начин, който ЗДДС не изисква.
Как се третира казусът, когато някой иска да поръча онлайн, но да дойде и да плати на място?
Това сделка през ЕЛМ ли е (т.е. прави невъзможна употребата на режима с одиторски файл), или присъствена сделка без връзка с ЕЛМ (т.е. магазинът си работи на облекчен режим, понеже неговата клиентела и допустими методи за плащане са формално разделени от тези на присъствения магазин?
Как се третира казусът, когато някой иска да поръча онлайн, но да дойде и да плати на място?
Това сделка през ЕЛМ ли е (т.е. прави невъзможна употребата на режима с одиторски файл), или присъствена сделка без връзка с ЕЛМ (т.е. магазинът си работи на облекчен режим, понеже неговата клиентела и допустими методи за плащане са формално разделени от тези на присъствения магазин?
НАП превишава правомощията си създавайки регистрационен режим на софтуерите и вменявайки си права за извършване на контрол.
Необходимите компетенции за подобни контролни функции липсват.
Изискванията към софтуера за управление на продажбите в търговските обекти и към производителите, разпространителите и ползвателите на такъв софтуер не могат да бъдат в прерогативите на Министъра на финансите или на НАП.
Напомням, че съгласно АПК Основания за оспорване Чл. 146. Основанията за оспорване на административните актове са: 1. липса на компетентност;
Интересно, проверяващите на място служители на Агенциа за Приходите с каква ИТ компетентност ще разполагат, за да установяват неосъответствия в софтуера, ъпдейтите му, наличен друг софтуер на машини на търговците в ТО, който би могъл да бъде СУПТО, за да налагат административни актове за нарушения?
НАП превишава правомощията си създавайки регистрационен режим на софтуерите и вменявайки си права за извършване на контрол.
Необходимите компетенции за подобни контролни функции липсват.
Изискванията към софтуера за управление на продажбите в търговските обекти и към производителите, разпространителите и ползвателите на такъв софтуер не могат да бъдат в прерогативите на Министъра на финансите или на НАП.
Напомням, че съгласно АПК Основания за оспорване Чл. 146. Основанията за оспорване на административните актове са: 1. липса на компетентност;
Интересно, проверяващите на място служители на Агенциа за Приходите с каква ИТ компетентност ще разполагат, за да установяват неосъответствия в софтуера, ъпдейтите му, наличен друг софтуер на машини на търговците в ТО, който би могъл да бъде СУПТО, за да налагат административни актове за нарушения?
Казус за НАП:
Все повече чужденци (от ЕС) намират онлайн магазина ни в България и използват Google преводач, за да направят поръчки.
Тези, които честичко купуват големи количества, препродават нашата стока на цена в €. Тъй като всичко си е наша марка и произведено в България, клиентите им намират нашия онлайн магазин (по марката) и поръчват.
Приемаме плащания с ППП и банков превод, но когато им пишем, че трябва да преведат определена сума в € по наша сметка, за да изпратим продуктите, ни задават въпроси:
Не може ли по PayPal? Как ще съм сигурна, че ще ми изпратите нещата след като преведа парите?
Не може ли с карта?
Явно се довереяват на PayPal и на банките си (chargeback), а ние не желаем да изпратим стока за 500€ и след това да чакаме превод от клиент до 3-5 раб.дни. За нас е важно да можем да приемаме плащания в момента от клиенти в чужбина. Такива клиенти не ползват ППП. А стандартният банков превод е прекалено бавен и за двете страни.
Имаме и физически магазини. Онлайн магазинът е на различен адрес от физическите. Сайтът ни е направен специално за нас от няколко програмиста къстъм, които НЕ желаят и не могат да създават СУПТО отговарящо на изискванията на приложение 29, да го регистрират в НАП и да отговарят за него, а имаме много детайли, изпълнени през годините, които ги няма в готовите решения за онлайн магазини.
Не желаем да търсим някой да ги създава отново, а и са си наше ноу-хау, за да ги "подскажем" на други. Доволни сме от сегашния ни онлайн сайт! Да не говорим за финансовият ресурс, който би ни струвало подобно нещо.
Според последните предложения за приеманe на неприсъствено плащане с кредитна или дебитна карта в Наредба Н-18, как бихме могли да приемаме такива? Как да продаваме на европейския пазар, където клиентите да заплащат по удобен за тях начин? Да се местим в друга държава?
Благодаря!
Вече сме интегрирали СУПТО във физическите ни магазини. Сега ще трябва да чакаме да изпълнят изискванията на приложение 42, но и те не са много уверени. Ще има отново изпращане за одобрение и корекции. Не видях голямо желание да го направят от фирмата със СУПТО още с първите промени, защото много пъти се променяха промените и се отлагаха нещата.
Всички тези разходи и несигурност около СУПТО не помагат на бизнеса ни.
Казус за НАП:
Все повече чужденци (от ЕС) намират онлайн магазина ни в България и използват Google преводач, за да направят поръчки.
Тези, които честичко купуват големи количества, препродават нашата стока на цена в €. Тъй като всичко си е наша марка и произведено в България, клиентите им намират нашия онлайн магазин (по марката) и поръчват.
Приемаме плащания с ППП и банков превод, но когато им пишем, че трябва да преведат определена сума в € по наша сметка, за да изпратим продуктите, ни задават въпроси:
Не може ли по PayPal? Как ще съм сигурна, че ще ми изпратите нещата след като преведа парите?
Не може ли с карта?
Явно се довереяват на PayPal и на банките си (chargeback), а ние не желаем да изпратим стока за 500€ и след това да чакаме превод от клиент до 3-5 раб.дни. За нас е важно да можем да приемаме плащания в момента от клиенти в чужбина. Такива клиенти не ползват ППП. А стандартният банков превод е прекалено бавен и за двете страни.
Имаме и физически магазини. Онлайн магазинът е на различен адрес от физическите. Сайтът ни е направен специално за нас от няколко програмиста къстъм, които НЕ желаят и не могат да създават СУПТО отговарящо на изискванията на приложение 29, да го регистрират в НАП и да отговарят за него, а имаме много детайли, изпълнени през годините, които ги няма в готовите решения за онлайн магазини.
Не желаем да търсим някой да ги създава отново, а и са си наше ноу-хау, за да ги "подскажем" на други. Доволни сме от сегашния ни онлайн сайт! Да не говорим за финансовият ресурс, който би ни струвало подобно нещо.
Според последните предложения за приеманe на неприсъствено плащане с кредитна или дебитна карта в Наредба Н-18, как бихме могли да приемаме такива? Как да продаваме на европейския пазар, където клиентите да заплащат по удобен за тях начин? Да се местим в друга държава?
Благодаря!
Вече сме интегрирали СУПТО във физическите ни магазини. Сега ще трябва да чакаме да изпълнят изискванията на приложение 42, но и те не са много уверени. Ще има отново изпращане за одобрение и корекции. Не видях голямо желание да го направят от фирмата със СУПТО още с първите промени, защото много пъти се променяха промените и се отлагаха нещата.
Всички тези разходи и несигурност около СУПТО не помагат на бизнеса ни.
QR код за ЕЛМ, които работят по чл.3(17) трябва да бъде проверим в реално време (до 5 мин след транзакцията) от потребителя или да отпадне изцяло
Мотиви:
Ако QR-а не може да верифицира сделката с приложението на НАП е безсмислено утежнение, което ще се явява допълнителен разход за търговеца, който ще трябва да го интегрира в своя ЕЛМ.
QR код за ЕЛМ, които работят по чл.3(17) трябва да бъде проверим в реално време (до 5 мин след транзакцията) от потребителя или да отпадне изцяло
Мотиви:
Ако QR-а не може да верифицира сделката с приложението на НАП е безсмислено утежнение, което ще се явява допълнителен разход за търговеца, който ще трябва да го интегрира в своя ЕЛМ.
Искане: Отлагане на Наредба Н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 не е сега. В момента е важно възможно най-голяма част от бизнеса просто да оцелее.
Искане: Отлагане на Наредба Н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 не е сега. В момента е важно възможно най-голяма част от бизнеса просто да оцелее.
Ако се приемат текстове, с които се налага редактирането на свалена в СУПТО поръчка от електронен магазин (ЕЛМ) да става само чрез СУПТО, то трябва да с еима предвид, че всеки потребител на ЕЛМ може да промени поръчката си по всяко време, което означава че в следната ситуация НАП ще създаде условия за пряко нарушаване на Н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 ще трябва да променят коренно начинът си на работа. Ще е необходим дълъг обучителен период и най-вероятно няколкократни смени на СУПТО.
Ако се приемат текстове, с които се налага редактирането на свалена в СУПТО поръчка от електронен магазин (ЕЛМ) да става само чрез СУПТО, то трябва да с еима предвид, че всеки потребител на ЕЛМ може да промени поръчката си по всяко време, което означава че в следната ситуация НАП ще създаде условия за пряко нарушаване на Н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 ще трябва да променят коренно начинът си на работа. Ще е необходим дълъг обучителен период и най-вероятно няколкократни смени на СУПТО.
Предлагам, в случайте когато в СУПТО е открита грешка и е декларирано това пред НАП вместо 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 работни дни да декларира промяната на версията пред НАП.
Предлагам, в случайте когато в СУПТО е открита грешка и е декларирано това пред НАП вместо 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 работни дни да декларира промяната на версията пред НАП.
По коментираните днес теми на срещата с бизнеса, предлагаме следното решение по отношение на закръгленията във сумите и техните "напасвания" във фискалният бон, а именно:
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: #уго описание - за яснота на клиента
Тук не е възможно да се посочи номер на фактура тъй като тя не е издадена все още, може да се цитира документа, но товара може да е съпроводен с няколко документа кой точно да се цитира?
По коментираните днес теми на срещата с бизнеса, предлагаме следното решение по отношение на закръгленията във сумите и техните "напасвания" във фискалният бон, а именно:
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: #уго описание - за яснота на клиента
Тук не е възможно да се посочи номер на фактура тъй като тя не е издадена все още, може да се цитира документа, но товара може да е съпроводен с няколко документа кой точно да се цитира?
Предлагам "Чл. 52(3) (Нова - ДВ, бр. 52 от 2019 г., в сила от 02.07.2019 г.) Всяко лице, което извършва сервизно обслужване на ФУ, за които не е наличен отдалечен достъп, е длъжно да обнови версията на фърмуера на въведените в експлоатация ФУ при вписана в регистъра по чл. 10, ал. 9 нова версия в срок до 45 дни след вписването и” да отпадне напълно.
Мотиви :
Не може да се вмени такова задължение в такива срокове на лицата , извършващи сервизно обслужване на ФУ поради неясно начало, респективно и край на срока и обстоятелства , описани в Чл,52 (3) поради следните обстоятелства :
1. Сервиза не е собственик на ФУ и няма гарантиран достъп до него.
2. Собственика на ФУ е дал грешни контакти за връзка или не осугурява достъп на серизната организация до ФУ . Няма как да се извърши обновяване на версия на ФУ по принудителен начин.
3. Ъпдейтите на всяко едно ФУ се вписват в регистъра на дата Х ,а сервизните организации получават достъп до въпросният ъпдейт на фърмуера на дата У ,която може да е две-три седмици по-късно.
4. Не е възможно да се следят обновленията и датата на вписване в регистъра по чл.10 ал.9 поради липса на достъп на лицата, сервизиращи ФУ до регистъра по чл/10 ,ал.9.
5. В билинга на производителите (с изключение на два от произоводителите) липсва информация кое ФУ е ъпдейтнато, кое ФУ подлежи на ъпдейт и кое ФУ все още чака нова версия на фърмуер и съответно сервизната организация няма как да знае дали ФУ е ъпдейтнато ,дори и за тези ФУ които е възможен автоматичният ъпдейт.
Предлагам "Чл. 52(3) (Нова - ДВ, бр. 52 от 2019 г., в сила от 02.07.2019 г.) Всяко лице, което извършва сервизно обслужване на ФУ, за които не е наличен отдалечен достъп, е длъжно да обнови версията на фърмуера на въведените в експлоатация ФУ при вписана в регистъра по чл. 10, ал. 9 нова версия в срок до 45 дни след вписването и” да отпадне напълно.
Мотиви :
Не може да се вмени такова задължение в такива срокове на лицата , извършващи сервизно обслужване на ФУ поради неясно начало, респективно и край на срока и обстоятелства , описани в Чл,52 (3) поради следните обстоятелства :
1. Сервиза не е собственик на ФУ и няма гарантиран достъп до него.
2. Собственика на ФУ е дал грешни контакти за връзка или не осугурява достъп на серизната организация до ФУ . Няма как да се извърши обновяване на версия на ФУ по принудителен начин.
3. Ъпдейтите на всяко едно ФУ се вписват в регистъра на дата Х ,а сервизните организации получават достъп до въпросният ъпдейт на фърмуера на дата У ,която може да е две-три седмици по-късно.
4. Не е възможно да се следят обновленията и датата на вписване в регистъра по чл.10 ал.9 поради липса на достъп на лицата, сервизиращи ФУ до регистъра по чл/10 ,ал.9.
5. В билинга на производителите (с изключение на два от произоводителите) липсва информация кое ФУ е ъпдейтнато, кое ФУ подлежи на ъпдейт и кое ФУ все още чака нова версия на фърмуер и съответно сервизната организация няма как да знае дали ФУ е ъпдейтнато ,дори и за тези ФУ които е възможен автоматичният ъпдейт.
Изменение на чл. 26А (1) след ЧАСТИЧНИ ПЛАЩАНИЯ се добавя или АВАНСОВИ ПЛАЩАНИЯ.
В чл. 26А (2) се заличва изречението: след което се извършва стойностна отстъпка, равна на размера на частично заплатената/заплатените сума/и
И след всички стоки и услуги се добавя: сумата на авансово плащане се приспада със знак минус пред единичната цена и отрицателен резултат на междинен сбор на този ред
Добавя се в чл. 26А алинея (3) (3) При разсрочено (частично) плащане се издава касова бележка в зависимост от разпоредбите на закона за ДДС за облагане на финансово-обвързан или оперативен лизинг.
Мотив:
Частичното плащане и авансовото имат два аспекта, не е допустимо да се замества понятието авансово плащане с понятието отстъпка. В практиката се използва приспадане на авансовите суми изписани със знак минус в документа, това трябва да бъде отразено и при касовите бележки. Предлаганите у нас ФУ поддържат редове със знак минус това е видно от документацията им предназначена за други държави. Във тази връзка не е мотив да не се промени фирмуера за работа с отрицателни суми.
Изменение на чл. 26А (1) след ЧАСТИЧНИ ПЛАЩАНИЯ се добавя или АВАНСОВИ ПЛАЩАНИЯ.
В чл. 26А (2) се заличва изречението: след което се извършва стойностна отстъпка, равна на размера на частично заплатената/заплатените сума/и
И след всички стоки и услуги се добавя: сумата на авансово плащане се приспада със знак минус пред единичната цена и отрицателен резултат на междинен сбор на този ред
Добавя се в чл. 26А алинея (3) (3) При разсрочено (частично) плащане се издава касова бележка в зависимост от разпоредбите на закона за ДДС за облагане на финансово-обвързан или оперативен лизинг.
Мотив:
Частичното плащане и авансовото имат два аспекта, не е допустимо да се замества понятието авансово плащане с понятието отстъпка. В практиката се използва приспадане на авансовите суми изписани със знак минус в документа, това трябва да бъде отразено и при касовите бележки. Предлаганите у нас ФУ поддържат редове със знак минус това е видно от документацията им предназначена за други държави. Във тази връзка не е мотив да не се промени фирмуера за работа с отрицателни суми.
Практика в търговията е да се дават на клиента стоки-подаръци (на нулеви цени) при определени условия на сделката. Технически някои модели фискални устройства не приемат команди с нулеви цени.
Предложение: Да се задължат производителите на фискални устройства да усигурят възможност да се продават стоки с нулеви цени (директно, а не с 100% търговска отстъпка).
Практика в търговията е да се дават на клиента стоки-подаръци (на нулеви цени) при определени условия на сделката. Технически някои модели фискални устройства не приемат команди с нулеви цени.
Предложение: Да се задължат производителите на фискални устройства да усигурят възможност да се продават стоки с нулеви цени (директно, а не с 100% търговска отстъпка).
В търговията е допустимо сумите на сторната по фискални бонове да надвишават сумите по продажбите с фискални бонове за деня. В такава ситуация някои модели фискални устройства издават грешеш дневен оборот: обявяват резултативния дневен оборот с положителен знак.
Предложение: Да се задължат производителите на фискални устройства да издават верни дневни отчети (резултативния дневен оборот с отрицателен знак! ) при случаите, когато сумите по сторната по фискални бонове надвишават сумите по продажбите с фискални бонове.
В търговията е допустимо сумите на сторната по фискални бонове да надвишават сумите по продажбите с фискални бонове за деня. В такава ситуация някои модели фискални устройства издават грешеш дневен оборот: обявяват резултативния дневен оборот с положителен знак.
Предложение: Да се задължат производителите на фискални устройства да издават верни дневни отчети (резултативния дневен оборот с отрицателен знак! ) при случаите, когато сумите по сторната по фискални бонове надвишават сумите по продажбите с фискални бонове.
Член 31, ал. 3 позволява да се издаде сторно по фискален бон с основание "операторска грешка" без да е необходима касова наличност на фискалното устройство. Технически след издаване на сторно с основание "операторска грешка" касовата наличност се намалява. Това води до разминаване на реалната косова наличност с тази на фискалното устройство.
Предложение: Да се задължат производителите на фискални устройства да не променят касовата наличност на фискалното устройство при издаване на сторно по фискален бон с основание "операторска грешка".
Член 31, ал. 3 позволява да се издаде сторно по фискален бон с основание "операторска грешка" без да е необходима касова наличност на фискалното устройство. Технически след издаване на сторно с основание "операторска грешка" касовата наличност се намалява. Това води до разминаване на реалната косова наличност с тази на фискалното устройство.
Предложение: Да се задължат производителите на фискални устройства да не променят касовата наличност на фискалното устройство при издаване на сторно по фискален бон с основание "операторска грешка".
Член 25 ал. 2 изисква да се издава предварително фискален бон при продажба при разнос
Липсва разяснение как да се издаде касовия бон без да се увеличи паричната наличност на фискалното устройство.
Предложение: Към член 25, ал. 2 да се добави описание за издаване на фискален бон при разнос.
Член 25 ал. 2 изисква да се издава предварително фискален бон при продажба при разнос
Липсва разяснение как да се издаде касовия бон без да се увеличи паричната наличност на фискалното устройство.
Предложение: Към член 25, ал. 2 да се добави описание за издаване на фискален бон при разнос.
Член 31, ал. 2 задължава сторно да се издава задължително по конкретен фискален бон. Тази задължителна връзка е нормална при продажба към краен потребител. В търговията на едро е нормална практика да се издават кредитни известия за намаление стойността на сделката (бонус при постигнат оборот за определен период). Така първо трябва да се издадат сторна по всеки фискален бон по отделно, а в последствие да се изброят фактурите по които си издава кредитното известие. Изикването за сторно по конкретен фискарен бон усложнява в десетки пъти издаването на кредитното известие като дублира ненужно списъка по фактурите, по които се издава кредитното известие.
Предложение: Да отпадне изискването сторното да се издава по конкретен фискарен бон, когато е свързано с кредитно известие.
Член 31, ал. 2 задължава сторно да се издава задължително по конкретен фискален бон. Тази задължителна връзка е нормална при продажба към краен потребител. В търговията на едро е нормална практика да се издават кредитни известия за намаление стойността на сделката (бонус при постигнат оборот за определен период). Така първо трябва да се издадат сторна по всеки фискален бон по отделно, а в последствие да се изброят фактурите по които си издава кредитното известие. Изикването за сторно по конкретен фискарен бон усложнява в десетки пъти издаването на кредитното известие като дублира ненужно списъка по фактурите, по които се издава кредитното известие.
Предложение: Да отпадне изискването сторното да се издава по конкретен фискарен бон, когато е свързано с кредитно известие.
Недопустимо е да се използват имена на XML таговете с различна от Letter case-separated words конвенция, както и наименованията трябва да са съобразени с SAF-T Schema v. 2.00.
Мотив:
Задължително е спазването на международните конвенции за изграждане на XML структори. Не е допумо създаване на одиторски файл без да е съобразен с SAF-T спецификацията.
Недопустимо е да се използват имена на XML таговете с различна от Letter case-separated words конвенция, както и наименованията трябва да са съобразени с SAF-T Schema v. 2.00.
Мотив:
Задължително е спазването на международните конвенции за изграждане на XML структори. Не е допумо създаване на одиторски файл без да е съобразен с SAF-T спецификацията.
В Приложение № 33 към чл. 52м, ал. 1 и чл. 52р т. 7.2 думата ПОС се заменя с устройство за приемане на картови разплащания.
В 7.6, и 7.7 думата POS се заменя с устройство за приемане на картови разплащания.
Мотив:
Не могат да се използват съкращения без да се дефинират в параграф към наредбата. Съкращението POS е Point Of Sale, което не е устройството с което се извършва процеса да плащане чрез карта. ПОС не го открих като дефиниция.
Не е допустимо в да се използват две понятия за едно и също нещо.
В Приложение № 33 към чл. 52м, ал. 1 и чл. 52р т. 7.2 думата ПОС се заменя с устройство за приемане на картови разплащания.
В 7.6, и 7.7 думата POS се заменя с устройство за приемане на картови разплащания.
Мотив:
Не могат да се използват съкращения без да се дефинират в параграф към наредбата. Съкращението POS е Point Of Sale, което не е устройството с което се извършва процеса да плащане чрез карта. ПОС не го открих като дефиниция.
Не е допустимо в да се използват две понятия за едно и също нещо.
В момента текстовете в наредбата са съобразени само с апаратните възможности на ФУ, но противоречат на закона. Добавя се в чл. 31 алинея 1а: (1а) Сторно операция се извършва при рекламация или връщане на стока като количеството се изписва със знак минус. При намаление на данъчната основа със знак минус за единичната цена.
Мотив:
Коригирането на количеството или стойността в първичния документ ако не е специално кредитно известие, а е приспадане на количества или стойност в последващ документ трябва да се извършва задължително със знак минус. Чрез това изменение ще се даде възможност за коректно изписване на приспаднатите авансови плащания и проследими корекции в рамките на една сделка, последните в момента се заличават.
ФУ трябва да визуализира знака само в случаите, когато не се печата кредит нота.
Тази възможност при работа с ФУ съществува в много европейски законодателства.
В момента текстовете в наредбата са съобразени само с апаратните възможности на ФУ, но противоречат на закона. Добавя се в чл. 31 алинея 1а: (1а) Сторно операция се извършва при рекламация или връщане на стока като количеството се изписва със знак минус. При намаление на данъчната основа със знак минус за единичната цена.
Мотив:
Коригирането на количеството или стойността в първичния документ ако не е специално кредитно известие, а е приспадане на количества или стойност в последващ документ трябва да се извършва задължително със знак минус. Чрез това изменение ще се даде възможност за коректно изписване на приспаднатите авансови плащания и проследими корекции в рамките на една сделка, последните в момента се заличават.
ФУ трябва да визуализира знака само в случаите, когато не се печата кредит нота.
Тази възможност при работа с ФУ съществува в много европейски законодателства.
В чл. 52Б след софтуер за управление на продажби в търговски обект, се вмъква: както и производител/разпространител на драйвери или посредници за връзка към фискални устройства
Мотив:
При интегриране на потока на данни те преминават през различни слоеве на софтуера, част от тези нива в конкретност драйверите и посредниците за връзка с ФУ се произвеждат от различен субект. При вградена в апаратна среда стандартна протоколна връзка емулираща касова бележка това не е необходимо, но при по голяма част от ФУ контрола им се осъществява чрез последователни команди, който не са стандартизирани. Идеята е, че посредника или драйвера трябва да приема и обработва заявки във същият формат като този който изпраща към НАП, за да е гарантирано съдържанието. В момента липсва унификация на отидорските файлове въпреки конвенцията SAF-T. Предадената информация от СУПТО към посредника на база SAF-T конвенцията а обработката и от посредника с цел изпълнение от ФУ трябва да става само лицензиран софтуер.
В чл. 52Б след софтуер за управление на продажби в търговски обект, се вмъква: както и производител/разпространител на драйвери или посредници за връзка към фискални устройства
Мотив:
При интегриране на потока на данни те преминават през различни слоеве на софтуера, част от тези нива в конкретност драйверите и посредниците за връзка с ФУ се произвеждат от различен субект. При вградена в апаратна среда стандартна протоколна връзка емулираща касова бележка това не е необходимо, но при по голяма част от ФУ контрола им се осъществява чрез последователни команди, който не са стандартизирани. Идеята е, че посредника или драйвера трябва да приема и обработва заявки във същият формат като този който изпраща към НАП, за да е гарантирано съдържанието. В момента липсва унификация на отидорските файлове въпреки конвенцията SAF-T. Предадената информация от СУПТО към посредника на база SAF-T конвенцията а обработката и от посредника с цел изпълнение от ФУ трябва да става само лицензиран софтуер.
Във връзка з направения от нас анализ сред членовете на асоциацията и потребителите на СУПТО. Можем да заявим, че не устоновяваме пречка за разделяне на срока по въвеждане на последните версии касови апарати от този с влизането на СУПТО в сила.
За да получим адекватна оценка и гледаната точка на НАП, ще изпратим въпросник за оценка на готовността на бизнеса.
Ако резултатите покажат висока степен на готовност и НАП потвърди еднозначно доверието си за използване на фискални устройства за контрол на фиска и с това раздели сроковете за СУПТО и въвеждане на касови апарати , БАРБС ще подкрепи по ранен срок за преминаване към последните модели ФУ , като ще продължи да настоява за отлагане на всички теми със СУПТО по които няма съгласие а именно:
- Дублираща функционалност
- Обхват
- Разширен обхват на текста на наредбата в частта достъп до данни
- Изисквания за български език и др.
Във връзка з направения от нас анализ сред членовете на асоциацията и потребителите на СУПТО. Можем да заявим, че не устоновяваме пречка за разделяне на срока по въвеждане на последните версии касови апарати от този с влизането на СУПТО в сила.
За да получим адекватна оценка и гледаната точка на НАП, ще изпратим въпросник за оценка на готовността на бизнеса.
Ако резултатите покажат висока степен на готовност и НАП потвърди еднозначно доверието си за използване на фискални устройства за контрол на фиска и с това раздели сроковете за СУПТО и въвеждане на касови апарати , БАРБС ще подкрепи по ранен срок за преминаване към последните модели ФУ , като ще продължи да настоява за отлагане на всички теми със СУПТО по които няма съгласие а именно:
- Дублираща функционалност
- Обхват
- Разширен обхват на текста на наредбата в частта достъп до данни
- Изисквания за български език и др.
БАРБС предложи много ясна процедура за промяна на чл. 52 е,ж. Едно предложение с ясна фомулировка.
Какво приеха :
„Чл. 52е¹. (1) В случай че производител/разпространител установи грешка във
функционирането на декларирана от него по чл. 52б версия на софтуера, касаещ
изискванията на приложение № 29 е длъжен незабавно да уведоми писмено Централно
управление на НАП за това обстоятелство и да преустанови неговото разпространение.
(2) В 7-дневен срок от установяването на обстоятелството по ал. 1
производителят/разпространителят е длъжен да подаде декларация по чл. 52б за нова
версия на софтуера, съответстваща на изискванията на приложение № 29.
(3) В 14-дневен срок от включване на новата версия на софтуера в публичния
списък по чл. 118, ал. 19 от ЗДДС, производителят/разпространителят е длъжен да
подмени версията по ал. 1 при всички потребители.
8
(4) Версията по ал. 1 се заличава от публичния списък по чл. 118, ал. 19 от
ЗДДС след изтичане на срока по ал. 3.“
§ 20. В чл. 52ж се правят следните изменения и допълнения:
1. В ал. 1 думите „чл. 52в, ал. 9 и чл. 52е, ал. 2“ се заменят с „чл. 52в, ал. 9, чл.
52е, ал. 2 и чл. 52е¹, ал. 4“.
2. Алинея 2 се отменя.
3. В ал. 3 думите „и за задължението им незабавно да преустановят неговото
използване“ се заличават.
4. Създава се ал. 4:
„(4) В случаите на ал. 3, лицата по чл. 3 са длъжни да преустановят
използването на софтуера в 14-дневен срок от по-късната дата от публикуване на
съобщението или от заличаването от регистъра.“
Какво предложихме :
Чл. 52е. (1) Когато в хода на контролно производство се установи несъответствие с изискванията в приложение № 29 на функционалността на софтуер, за който е подадена декларация по реда на чл. 52в, ал. 1, органът по приходите възлaga извършване на експертиза по реда на ДОПК. В този случай производителят/разпространителят на софтуера оказва съдействие и предоставя изисканата за целите на експертизата информация, включително:
1. предоставя пълен инсталационен пакет на версията/версиите на софтуера, предмет на експертизата (при SaaS - създаване на нов клиентски акаунт за целите на експертизата); или
2. осигурява контролирана среда и съдейства за провеждане на изпитвания на софтуера с оглед откриване на причините за установеното несъответствие.
(2) В случай че в хода на възложена експертиза производителят/разпространителят на софтуера или в резултат от извършена експертиза се установи несъответствие на включен/и в публичния списък версия/версии на софтуер с изискванията на приложение № 29 по причини, за които производителят/разпространителят отговаря, Националната агенция за приходите връчва предписание за отстраняване на несъответствията за срок не по-кратък от 14 дни.
(3) В случай на неотстраняване на несъответствията съгласно предписанията по ал. 2, Националната агенция за приходите предприема действия по заличаването на версията/версиите на софтуера от списъка.
(4) В случай, че несъответствия се дължат на манипулиране на софтуера от ползвател на този софтуер или трето лице, несвързано с производителя/разпространителя, то Националната агенция за приходите предприема действия по санкциониране на съответния нарушител.
Чл. 52ж. (1) В случаите по чл. 52в, ал. 9 и чл. 52е, ал. 3 актът за заличаване на версията/версиите на софтуер за управление на продажби от поддържания от НАП публичен електронен списък се издава от оправомощен от изпълнителния директор на НАП орган по приходите. Актът подлежи на обжалване пред компетентния административен съд по реда на Административнопроцесуалния кодекс.
(2) В случай на неотстраняване на несъответствията съгласно чл. 52е, ал. 3, административният акт по ал. 1 се публикува на интернет страницата на Националната агенция за приходите, а лицата по чл. 3, използващи версията/версиите на софтуера и подали информация по реда на чл. 52з, се уведомяват по електронен път. В случаите на чл. 52е, ал 4, не се предприемат действия по заличаването на версията/версиите на софтуера от списъка и не се издава акт за заличаване съгласно ал. 1.
(3) След влизане в сила на административния акт по ал. 1 на интернет страницата на Националната агенция за приходите се публикува съобщение, а лицата по чл. 3, използващи версията/версиите на софтуера и подали информация по реда на чл. 52з, се уведомяват по електронен път за изключване на софтуера от публичния списък и за задължението им незабавно да преустановят неговото използване.
БАРБС предложи много ясна процедура за промяна на чл. 52 е,ж. Едно предложение с ясна фомулировка.
Какво приеха :
„Чл. 52е¹. (1) В случай че производител/разпространител установи грешка във
функционирането на декларирана от него по чл. 52б версия на софтуера, касаещ
изискванията на приложение № 29 е длъжен незабавно да уведоми писмено Централно
управление на НАП за това обстоятелство и да преустанови неговото разпространение.
(2) В 7-дневен срок от установяването на обстоятелството по ал. 1
производителят/разпространителят е длъжен да подаде декларация по чл. 52б за нова
версия на софтуера, съответстваща на изискванията на приложение № 29.
(3) В 14-дневен срок от включване на новата версия на софтуера в публичния
списък по чл. 118, ал. 19 от ЗДДС, производителят/разпространителят е длъжен да
подмени версията по ал. 1 при всички потребители.
8
(4) Версията по ал. 1 се заличава от публичния списък по чл. 118, ал. 19 от
ЗДДС след изтичане на срока по ал. 3.“
§ 20. В чл. 52ж се правят следните изменения и допълнения:
1. В ал. 1 думите „чл. 52в, ал. 9 и чл. 52е, ал. 2“ се заменят с „чл. 52в, ал. 9, чл.
52е, ал. 2 и чл. 52е¹, ал. 4“.
2. Алинея 2 се отменя.
3. В ал. 3 думите „и за задължението им незабавно да преустановят неговото
използване“ се заличават.
4. Създава се ал. 4:
„(4) В случаите на ал. 3, лицата по чл. 3 са длъжни да преустановят
използването на софтуера в 14-дневен срок от по-късната дата от публикуване на
съобщението или от заличаването от регистъра.“
Какво предложихме :
Чл. 52е. (1) Когато в хода на контролно производство се установи несъответствие с изискванията в приложение № 29 на функционалността на софтуер, за който е подадена декларация по реда на чл. 52в, ал. 1, органът по приходите възлaga извършване на експертиза по реда на ДОПК. В този случай производителят/разпространителят на софтуера оказва съдействие и предоставя изисканата за целите на експертизата информация, включително:
1. предоставя пълен инсталационен пакет на версията/версиите на софтуера, предмет на експертизата (при SaaS - създаване на нов клиентски акаунт за целите на експертизата); или
2. осигурява контролирана среда и съдейства за провеждане на изпитвания на софтуера с оглед откриване на причините за установеното несъответствие.
(2) В случай че в хода на възложена експертиза производителят/разпространителят на софтуера или в резултат от извършена експертиза се установи несъответствие на включен/и в публичния списък версия/версии на софтуер с изискванията на приложение № 29 по причини, за които производителят/разпространителят отговаря, Националната агенция за приходите връчва предписание за отстраняване на несъответствията за срок не по-кратък от 14 дни.
(3) В случай на неотстраняване на несъответствията съгласно предписанията по ал. 2, Националната агенция за приходите предприема действия по заличаването на версията/версиите на софтуера от списъка.
(4) В случай, че несъответствия се дължат на манипулиране на софтуера от ползвател на този софтуер или трето лице, несвързано с производителя/разпространителя, то Националната агенция за приходите предприема действия по санкциониране на съответния нарушител.
Чл. 52ж. (1) В случаите по чл. 52в, ал. 9 и чл. 52е, ал. 3 актът за заличаване на версията/версиите на софтуер за управление на продажби от поддържания от НАП публичен електронен списък се издава от оправомощен от изпълнителния директор на НАП орган по приходите. Актът подлежи на обжалване пред компетентния административен съд по реда на Административнопроцесуалния кодекс.
(2) В случай на неотстраняване на несъответствията съгласно чл. 52е, ал. 3, административният акт по ал. 1 се публикува на интернет страницата на Националната агенция за приходите, а лицата по чл. 3, използващи версията/версиите на софтуера и подали информация по реда на чл. 52з, се уведомяват по електронен път. В случаите на чл. 52е, ал 4, не се предприемат действия по заличаването на версията/версиите на софтуера от списъка и не се издава акт за заличаване съгласно ал. 1.
(3) След влизане в сила на административния акт по ал. 1 на интернет страницата на Националната агенция за приходите се публикува съобщение, а лицата по чл. 3, използващи версията/версиите на софтуера и подали информация по реда на чл. 52з, се уведомяват по електронен път за изключване на софтуера от публичния списък и за задължението им незабавно да преустановят неговото използване.
Във връзка с предложената редакция на чл. 52з, ал.7 – считаме, че текста в частта „проследяване движението на продаваните стоки/услуги“ е твърде общо формулиран и не води до еднозначно и непротиворечиво тълкуване.
Интегрираните информационни системи проследяват множество процеси, свързани с движение на стоки, които са част от изпълнение задължението на търговеца да предостави продадените стоки/ услуги, но не са част от продажбения процес и се осъществяват преди същинското предаване на стоките на крайния клиент.
Примери: дейности като местене на наличности между собствени обекти, всичко от обхвата на WMS (Warehouse Management System) модулите като управление местоположението на стоките в склада, събиране на стоки, окомплектоване, опаковане и т.н.
Всички тези дейности се отразяват в системите с типове документи по чл. 6, ал. 3 от Закона за счетоводството, които с ново предлаганата дефиниция на т.19 от § 1 изрично са изключени от обхвата на СУПТО.
Ето защо предлагаме текста на чл.52з, ал.7: „В случай че лицето по чл. 118, ал. 18 от ЗДДС използва интегрирана информационна система за управление на продажбите/търговската дейност функционалностите за обработка на заявки/поръчки, проследяване движението на продаваните стоки/услуги, отразяване на предоставянето и заплащането им се считат за софтуер за управление на продажби, който трябва да отговаря на изискванията съгласно приложение № 29.“
Да се замени с: „В случай че лицето по чл. 118, ал. 18 от ЗДДС използва интегрирана информационна система за управление на продажбите/търговската дейност функционалностите за обработка на заявки/поръчки, проследяване предоставянето на продаваните стоки/услуги, отразяване на предоставянето и заплащането им се считат за софтуер за управление на продажби, който трябва да отговаря на изискванията съгласно приложение № 29.“
Относно предложената редакция на Приложение 29, т.8, първи булет - с оглед избягване неясното тълкуване какво се разбира под "стартиране на софтуер" в случаите на интегрирани софтуерни системи, които съдържат по-широк кръг функционалности от тези, попадащи в обхвата на СУПТО - предлагаме текста на т.8, първи булет: „- при стартиране на софтуера от работно място, имащо достъп до функционалността за управление на продажбите - за проверка на готовността за работа на ФУ. При липса на отговор за свързаност с ФУ или на готовност за отпечатване на фискален бон, се блокира функционалността за откриване на продажби и за плащане, изискващо издаване на фискален бон.“
Да се замени с: "- при стартиране на функционалност, свързана с откриване на продажба и за плащане - за проверка на готовността за работа на ФУ. При липса на отговор за свързаност с ФУ или на готовност за отпечатване на фискален бон, се блокира функционалността за откриване на продажби и за плащане, изискващо издаване на фискален бон."
Алтернативно предложение – да отпадне изобщо текста на първи булет и да останат да се прилагат директно другите два.
Във връзка с предложената редакция на чл. 52з, ал.7 – считаме, че текста в частта „проследяване движението на продаваните стоки/услуги“ е твърде общо формулиран и не води до еднозначно и непротиворечиво тълкуване.
Интегрираните информационни системи проследяват множество процеси, свързани с движение на стоки, които са част от изпълнение задължението на търговеца да предостави продадените стоки/ услуги, но не са част от продажбения процес и се осъществяват преди същинското предаване на стоките на крайния клиент.
Примери: дейности като местене на наличности между собствени обекти, всичко от обхвата на WMS (Warehouse Management System) модулите като управление местоположението на стоките в склада, събиране на стоки, окомплектоване, опаковане и т.н.
Всички тези дейности се отразяват в системите с типове документи по чл. 6, ал. 3 от Закона за счетоводството, които с ново предлаганата дефиниция на т.19 от § 1 изрично са изключени от обхвата на СУПТО.
Ето защо предлагаме текста на чл.52з, ал.7: „В случай че лицето по чл. 118, ал. 18 от ЗДДС използва интегрирана информационна система за управление на продажбите/търговската дейност функционалностите за обработка на заявки/поръчки, проследяване движението на продаваните стоки/услуги, отразяване на предоставянето и заплащането им се считат за софтуер за управление на продажби, който трябва да отговаря на изискванията съгласно приложение № 29.“
Да се замени с: „В случай че лицето по чл. 118, ал. 18 от ЗДДС използва интегрирана информационна система за управление на продажбите/търговската дейност функционалностите за обработка на заявки/поръчки, проследяване предоставянето на продаваните стоки/услуги, отразяване на предоставянето и заплащането им се считат за софтуер за управление на продажби, който трябва да отговаря на изискванията съгласно приложение № 29.“
Относно предложената редакция на Приложение 29, т.8, първи булет - с оглед избягване неясното тълкуване какво се разбира под "стартиране на софтуер" в случаите на интегрирани софтуерни системи, които съдържат по-широк кръг функционалности от тези, попадащи в обхвата на СУПТО - предлагаме текста на т.8, първи булет: „- при стартиране на софтуера от работно място, имащо достъп до функционалността за управление на продажбите - за проверка на готовността за работа на ФУ. При липса на отговор за свързаност с ФУ или на готовност за отпечатване на фискален бон, се блокира функционалността за откриване на продажби и за плащане, изискващо издаване на фискален бон.“
Да се замени с: "- при стартиране на функционалност, свързана с откриване на продажба и за плащане - за проверка на готовността за работа на ФУ. При липса на отговор за свързаност с ФУ или на готовност за отпечатване на фискален бон, се блокира функционалността за откриване на продажби и за плащане, изискващо издаване на фискален бон."
Алтернативно предложение – да отпадне изобщо текста на първи булет и да останат да се прилагат директно другите два.
В подкрепа на мнението на VentsiVas от 23 юни 2020 г. 10:47:21 ч.
Да отпадне изискването за импорт на поръчки от ЕЛМ в СУПТО, когато фирмата има регистрирано СУПТО и отчита продажбите в него. Да остане задължение в такъв случай всички извършени продажби да бъдат отчитани (извършвани) чрез СУПТО, с което да се предостави свободата фирмата да приема поръчки свободно от ограничения чрез всички достъпни методи - от онлайн магазини, български и чуждестранни платформи за обяви и малки обяви, специализирани инструменти за оферти и каталози, по телефона, чрез социални мрежи, маркетплейс платформи, през имейл, преки оферти чрез съобщения и т.н.
Обвързването на СУПТО и разнообразните методи за продажба по друг начин е невъзможно и ограничава продажбите до един или малко на брой канали, за които, ако въобще е възможно, фирмата трябва да намери решение на понякога почти напълно изолиран проблем. В противен случай може да е принудена да мигрира на коренно различна платформа, което е пагубно за интернет търговията и изграждани с години позиции.
В подкрепа на мнението на VentsiVas от 23 юни 2020 г. 10:47:21 ч.
Да отпадне изискването за импорт на поръчки от ЕЛМ в СУПТО, когато фирмата има регистрирано СУПТО и отчита продажбите в него. Да остане задължение в такъв случай всички извършени продажби да бъдат отчитани (извършвани) чрез СУПТО, с което да се предостави свободата фирмата да приема поръчки свободно от ограничения чрез всички достъпни методи - от онлайн магазини, български и чуждестранни платформи за обяви и малки обяви, специализирани инструменти за оферти и каталози, по телефона, чрез социални мрежи, маркетплейс платформи, през имейл, преки оферти чрез съобщения и т.н.
Обвързването на СУПТО и разнообразните методи за продажба по друг начин е невъзможно и ограничава продажбите до един или малко на брой канали, за които, ако въобще е възможно, фирмата трябва да намери решение на понякога почти напълно изолиран проблем. В противен случай може да е принудена да мигрира на коренно различна платформа, което е пагубно за интернет търговията и изграждани с години позиции.
3.) По отношение на "§ 35. 3. Точка 8 се изменя така:...."
Предвид че във ФУ не съществува команда, с която да се изпълни изискването "получаване в реално време на информация за готовността на ФУ за отпечатване на фискален бон", а е налице единствено информация за липса или наличие на грешки препятстващи отварянето на фискален бон, предлагам текстът да се коригира по следният начин даващ ясна насока на разработчиците на СУПТО в кои случай се счита за валидна проверката на ФУ, а именно: "„8. Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за статуса на ФУ и при отсъствие на грешки, софтуерът може да приеме, че са налице условия за отпечатване на фискален бон и получаване на неговия ИН....."
4.) По отношение на § 45. (2) - След влизането в сила на измененията, версиите на софтуерите включени в списъка по чл. 118, ал. 19 ЗДДС, ще трябва ли да бъдат Дерегистрирани или тяхната дерегистрация ще стане автоматично ?
Ако продължат да съществуват в списъка, то те ще могат ли да бъдат използвани от лицата по чл. 3 ?
3.) По отношение на "§ 35. 3. Точка 8 се изменя така:...."
Предвид че във ФУ не съществува команда, с която да се изпълни изискването "получаване в реално време на информация за готовността на ФУ за отпечатване на фискален бон", а е налице единствено информация за липса или наличие на грешки препятстващи отварянето на фискален бон, предлагам текстът да се коригира по следният начин даващ ясна насока на разработчиците на СУПТО в кои случай се счита за валидна проверката на ФУ, а именно: "„8. Софтуерът осигурява свързаност с ФУ по начин, позволяващ получаване в реално време на информация за статуса на ФУ и при отсъствие на грешки, софтуерът може да приеме, че са налице условия за отпечатване на фискален бон и получаване на неговия ИН....."
4.) По отношение на § 45. (2) - След влизането в сила на измененията, версиите на софтуерите включени в списъка по чл. 118, ал. 19 ЗДДС, ще трябва ли да бъдат Дерегистрирани или тяхната дерегистрация ще стане автоматично ?
Ако продължат да съществуват в списъка, то те ще могат ли да бъдат използвани от лицата по чл. 3 ?
2.) По отношение на " § 21 Чл. 52з. ....(10) " - в която алинея 10 се вменява задължението към СУПТО "автоматизирано извлича и зарежда в базата си данни най-малко на всеки 15 минути информацията за направените поръчки в софтуера". При тази формулировка на текста в алинея 10 предвидена ли е практиката, че една заявка в интернет магазин може да "живее" няколко дни. Всяка заявка до нейното получаване от клиента може да бъде променяна от заявителя и от страна на обслужващата страна, както като съдържание, така и само по статус. Тази промяна в текстовете на Н18 налага промяна на действащи системи , но не дава ясна насока какво се очаква да се "извлича":
- само новите поръчки и/или променените поръчки.
С оглед на използваната практика в съществуващите импортери, ще поставя следният примери предложение за промяна на текстовете в § 9.
Пример: Интернет магазин, който използва софтуер за управление на продажбите в обекта и свързан към него импортер приема по 30 нови заявки на денонощие, офисът (магазина) работи с работно време от 09:00 до 18:30. През работното си време обектът импортира новите поръчки от интернет магазина и заявява за доставка, следи наличности и подготвя за изпращане наличните и заявени стоки.
Едновременно с импортът на поръчките се прави проверка за това кои от вече импортираните поръчки са променени от техните заявители (в практиката, често се случва клиентът да промени решението си, да добави или премахне определени стоки от поръчката си).
Импортерът следи за такива промени и автоматично ги обработва с цел те да бъдат своевременно отразени в глобалната система.
При така поставените изисквания да "извлича и зарежда в базата си данни най-малко на всеки 15 минути" се поставят няколко трудни за разрешаване задачи.
1. Как трябва да работи Импортерът извън работното време на офиса? Как ще се разглеждат от НАП случайте на заявени поръчки, но не обработени в СУПТО
2. Предвиден ли е разходът за ресурсите (процесорно време на сървъра и изискванията към техниката на лицата по чл.3) при поставените изисквания за периодична проверка при един натоварен интернет магазин (над 100 нови и 30% променени поръчки за 24 часа).
3. Предвидени ли са другите методи за обмен на информация между интернет магазин и софтуер в офиса (в разглежданият пример СУПТО се обръща към интернет магазина, но в практиката съществува и обратната опция - интернет магазина при настъпила промяна изпраща (или записва директно) към СУПТО информацията за измененията по поръчките.
4. Предвидени ли са ситуациите, в който за да отговорят на законовите изисквания търговците ще поставят СУПТО и импортер, но ще продължат да управляват заявките/поръчките единствено от платформата на интернет магазина си.
Предложение: "(10) Когато лице по чл. 118, ал. 18 от ЗДДС извършва продажби и чрез електронен магазин се допуска софтуерът на електронния магазин да не отговаря на изискванията на приложение № 29, при условие че използван от лицето софтуер за управление на продажби автоматизирано:
- извлича и зарежда в базата си данни най-малко на всеки 15 минути между две последователни проверки
- получава директно в базата си данни
- извлича и зарежда в базата си данни по инициатива на лицето по чл. 118 ал. 18 най - малко на всеки 15 минути между две последователни проверки
информацията за направените НОВИ поръчки и/или за поръчки ПРОМЕНЕНИ в рамките на 7 календарни дни в софтуера на електронния магазин. Когато автоматизацията не е възможно да се изпълнява през целият 24 часов диапазон на деня, то тя трябва да се изпълнява най-малко в периода на работното време на търговският обект, в който е разположен софтуер за управление на продажби при спазване на изискванията, посочени в приложение № 42. "
2.) По отношение на " § 21 Чл. 52з. ....(10) " - в която алинея 10 се вменява задължението към СУПТО "автоматизирано извлича и зарежда в базата си данни най-малко на всеки 15 минути информацията за направените поръчки в софтуера". При тази формулировка на текста в алинея 10 предвидена ли е практиката, че една заявка в интернет магазин може да "живее" няколко дни. Всяка заявка до нейното получаване от клиента може да бъде променяна от заявителя и от страна на обслужващата страна, както като съдържание, така и само по статус. Тази промяна в текстовете на Н18 налага промяна на действащи системи , но не дава ясна насока какво се очаква да се "извлича":
- само новите поръчки и/или променените поръчки.
С оглед на използваната практика в съществуващите импортери, ще поставя следният примери предложение за промяна на текстовете в § 9.
Пример: Интернет магазин, който използва софтуер за управление на продажбите в обекта и свързан към него импортер приема по 30 нови заявки на денонощие, офисът (магазина) работи с работно време от 09:00 до 18:30. През работното си време обектът импортира новите поръчки от интернет магазина и заявява за доставка, следи наличности и подготвя за изпращане наличните и заявени стоки.
Едновременно с импортът на поръчките се прави проверка за това кои от вече импортираните поръчки са променени от техните заявители (в практиката, често се случва клиентът да промени решението си, да добави или премахне определени стоки от поръчката си).
Импортерът следи за такива промени и автоматично ги обработва с цел те да бъдат своевременно отразени в глобалната система.
При така поставените изисквания да "извлича и зарежда в базата си данни най-малко на всеки 15 минути" се поставят няколко трудни за разрешаване задачи.
1. Как трябва да работи Импортерът извън работното време на офиса? Как ще се разглеждат от НАП случайте на заявени поръчки, но не обработени в СУПТО
2. Предвиден ли е разходът за ресурсите (процесорно време на сървъра и изискванията към техниката на лицата по чл.3) при поставените изисквания за периодична проверка при един натоварен интернет магазин (над 100 нови и 30% променени поръчки за 24 часа).
3. Предвидени ли са другите методи за обмен на информация между интернет магазин и софтуер в офиса (в разглежданият пример СУПТО се обръща към интернет магазина, но в практиката съществува и обратната опция - интернет магазина при настъпила промяна изпраща (или записва директно) към СУПТО информацията за измененията по поръчките.
4. Предвидени ли са ситуациите, в който за да отговорят на законовите изисквания търговците ще поставят СУПТО и импортер, но ще продължат да управляват заявките/поръчките единствено от платформата на интернет магазина си.
Предложение: "(10) Когато лице по чл. 118, ал. 18 от ЗДДС извършва продажби и чрез електронен магазин се допуска софтуерът на електронния магазин да не отговаря на изискванията на приложение № 29, при условие че използван от лицето софтуер за управление на продажби автоматизирано:
- извлича и зарежда в базата си данни най-малко на всеки 15 минути между две последователни проверки
- получава директно в базата си данни
- извлича и зарежда в базата си данни по инициатива на лицето по чл. 118 ал. 18 най - малко на всеки 15 минути между две последователни проверки
информацията за направените НОВИ поръчки и/или за поръчки ПРОМЕНЕНИ в рамките на 7 календарни дни в софтуера на електронния магазин. Когато автоматизацията не е възможно да се изпълнява през целият 24 часов диапазон на деня, то тя трябва да се изпълнява най-малко в периода на работното време на търговският обект, в който е разположен софтуер за управление на продажби при спазване на изискванията, посочени в приложение № 42. "
1.) В § 30.
3. В раздел V се създават букви „аж“ и „аз“:
„аж) фискален бон за частично плащане“
е представен шаблон за частично плащане. Притеснително за мен е съществуващият първи коментарен ред с текст
"#Поръчка на мебели #", което създава усещането, че частичните плащания налагат изискването да се издават фискални бонове към записани заявки/поръчки, преди те да са се превърнали в приключена продажба.
В случайте по който се приема плащане (капаро или аванс) по заявка/поръчка за доставка на стоки преди да е предоставена стоката съгласно ЗДДС се документира с издаването на фактура. В така предвидените изменения как ще се отразява във фактурата издадена за плащане в случайте на частично плащане по заявка/поръчка.
Предложение:
1. да отпадне коментарният текст от шаблона, който въвежда в заблуждение за момента към който възниква задължението за издаване на фискален бон за "частично плащане".
2. Да бъде променен текстът в § 9. чл. 26а (1) така: "„Чл. 26а. (1) За продажби чрез софтуер за управление на продажбите, за които лице по чл. 3 приема частични плащания по записана продажба, по която не е отразено плащане се допуска ФУ/ИАСУТД да се програмира така, че продажбите да се регистрират в департамент с обобщено наименование "ЧАСТИЧНИ ПЛАЩАНИЯ", в който се регистрират всички получени суми по частични плащания. Информацията за продажбите на конкретните стоки/услуги, за които се извършва частично плащане, следва да е отразена като свободен текст, оградена със знак „#“ в началото и в края на допълнителните редове.
А в случайте на работа в ръчен режим за продажби, за които лице по чл. 3 приема частични плащания се допуска ФУ/ИАСУТД да се програмира така, че продажбите да се регистрират в департамент с обобщено наименование "ЧАСТИЧНИ ПЛАЩАНИЯ", в който се регистрират всички получени суми по частични плащания. "
1.) В § 30.
3. В раздел V се създават букви „аж“ и „аз“:
„аж) фискален бон за частично плащане“
е представен шаблон за частично плащане. Притеснително за мен е съществуващият първи коментарен ред с текст
"#Поръчка на мебели #", което създава усещането, че частичните плащания налагат изискването да се издават фискални бонове към записани заявки/поръчки, преди те да са се превърнали в приключена продажба.
В случайте по който се приема плащане (капаро или аванс) по заявка/поръчка за доставка на стоки преди да е предоставена стоката съгласно ЗДДС се документира с издаването на фактура. В така предвидените изменения как ще се отразява във фактурата издадена за плащане в случайте на частично плащане по заявка/поръчка.
Предложение:
1. да отпадне коментарният текст от шаблона, който въвежда в заблуждение за момента към който възниква задължението за издаване на фискален бон за "частично плащане".
2. Да бъде променен текстът в § 9. чл. 26а (1) така: "„Чл. 26а. (1) За продажби чрез софтуер за управление на продажбите, за които лице по чл. 3 приема частични плащания по записана продажба, по която не е отразено плащане се допуска ФУ/ИАСУТД да се програмира така, че продажбите да се регистрират в департамент с обобщено наименование "ЧАСТИЧНИ ПЛАЩАНИЯ", в който се регистрират всички получени суми по частични плащания. Информацията за продажбите на конкретните стоки/услуги, за които се извършва частично плащане, следва да е отразена като свободен текст, оградена със знак „#“ в началото и в края на допълнителните редове.
А в случайте на работа в ръчен режим за продажби, за които лице по чл. 3 приема частични плащания се допуска ФУ/ИАСУТД да се програмира така, че продажбите да се регистрират в департамент с обобщено наименование "ЧАСТИЧНИ ПЛАЩАНИЯ", в който се регистрират всички получени суми по частични плащания. "
Чл. 29 (6) предложената промяна се изменя както следва, след: (7) Когато задължено лице, в качеството си на довереник се добавя: и не е лице по чл. 118, ал. 18 от ЗДДС и
Изречението: Когато довереникът е лице по чл. 118, ал. 18 от ЗДДС, регистрирането и отчитането на продажбите на доверителя се извършва по реда на ал. 6. се заличава
Мотив:
Текста създава циклично недвусмислен
Чл. 29 (6) предложената промяна се изменя както следва, след: (7) Когато задължено лице, в качеството си на довереник се добавя: и не е лице по чл. 118, ал. 18 от ЗДДС и
Изречението: Когато довереникът е лице по чл. 118, ал. 18 от ЗДДС, регистрирането и отчитането на продажбите на доверителя се извършва по реда на ал. 6. се заличава
Мотив:
Текста създава циклично недвусмислен
В чл. 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, с изключение на кода на данъчната група.
Мотив:
Предложеният текст е със смислови грешки извън контекста на стария текст
В чл. 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, с изключение на кода на данъчната група.
Мотив:
Предложеният текст е със смислови грешки извън контекста на стария текст
Във връзка с предвидената промяна на чл. 52а1 („§ 16. В чл. 52а¹ се правят следните изменения: 1. Алинея 1 се изменя така: „(1) Лице по чл. 118, ал. 18 от ЗДДС може да използва софтуер за управление на продажби, който отговаря най-малко на изискванията по т. 2, 4, 6 и 7 от приложение № 29. В случай че интерфейсът на софтуера не е на български език, търговецът е длъжен да предостави негов превод на български език при поискване от орган по приходите.“ 2. Алинея 2 се отменя.”):
Предложение:
Чл. 53з (3) Лицата по чл. 118, ал. 18 от ЗДДС могат да използват в търговски обект, в който се извършват продажби на стоки и услуги, за които е налице задължение за издаване на фискален бон, само софтуер/и за управление на продажбите, отговарящ/и на посочените в приложение № 29 изисквания. Софтуерът/ите задължително управлява/т всички фискални устройства в този обект с изключение на софтуер по чл. 52а, ал. 2..“ да се допълни И СОФТУЕР ПО чл. 52 а1, ал. 1 .
„§ 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, ал. 1 и 2, ал.2 да отпадне.
Във връзка с предвидената промяна на чл. 52а1 („§ 16. В чл. 52а¹ се правят следните изменения: 1. Алинея 1 се изменя така: „(1) Лице по чл. 118, ал. 18 от ЗДДС може да използва софтуер за управление на продажби, който отговаря най-малко на изискванията по т. 2, 4, 6 и 7 от приложение № 29. В случай че интерфейсът на софтуера не е на български език, търговецът е длъжен да предостави негов превод на български език при поискване от орган по приходите.“ 2. Алинея 2 се отменя.”):
Предложение:
Чл. 53з (3) Лицата по чл. 118, ал. 18 от ЗДДС могат да използват в търговски обект, в който се извършват продажби на стоки и услуги, за които е налице задължение за издаване на фискален бон, само софтуер/и за управление на продажбите, отговарящ/и на посочените в приложение № 29 изисквания. Софтуерът/ите задължително управлява/т всички фискални устройства в този обект с изключение на софтуер по чл. 52а, ал. 2..“ да се допълни И СОФТУЕР ПО чл. 52 а1, ал. 1 .
„§ 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, ал. 1 и 2, ал.2 да отпадне.
Фирма ползва регистриран СУПТО в офиса и ползва (както всяка нормална фирма в съвременнния свят) и електронен магазин, който е на свободна платформа WooCommerce.
Поръчките, които се правят от клиентите в Електронни магазин се пренабират в СУПТО и от там се раализират продажбите (ако се стигне до продажба). В Електронният магазин не се рализират и следят продажби, там само са посочени продукти и цени. Всички продажби се отчитат в СУПТО програмата в офиса.
Изискването на Чл. 52з. (10), за автоматичен импорт на поръчките при платформите с отворен код е неприложимо (не може да накараш американската компания WooCoomerce да прави импорт за българско СУПТО). Има решения за импорт, които обачен са на цена 500-600 лв. Това е доста голяма сума. Защо се натоварват фирмите с допълнителни разходи. Това ли е идеята?
Каква е логиката да има автоматичен импорт от електронен магазин във фирменото СУПТО, при положение, че:
1. Поръчките от електронен магазин се въвеждат в СУПТО програмата и си получават УНП номер от нея.
2. Поръчките от електронен магазин не винаги стават продажба ( ако се реализира продажба, тя се реализира през СУПТО и се отчита в НАП).
3. Каква е логиката да се следят поръчките, а не продажбите. Както вскички знаем (силно се надявам вскички да го знаем), че не всяка поръчка става продажба.
Нали абревиатурата на НАП е Национална агенция за ПРИХОДИТЕ (които се реализират от продажби), а не е Национална агенция на ПОРЪЧКИТЕ?
Предложение:
Да отпадне изискването за автоматичен импорт на поръчките от Електонния магазин в СУПТО, при положение, че фирмата има регистрирано СУПТО и следи и отчита всички поръчки и продажби в него независимо как са получени те ( в офиса, по телефона, през електронния магазин, по мейла, с SMS, по Viber, Messenger, пощенско писмо, устно и т.н.)
С Уважение!
Фирма ползва регистриран СУПТО в офиса и ползва (както всяка нормална фирма в съвременнния свят) и електронен магазин, който е на свободна платформа WooCommerce.
Поръчките, които се правят от клиентите в Електронни магазин се пренабират в СУПТО и от там се раализират продажбите (ако се стигне до продажба). В Електронният магазин не се рализират и следят продажби, там само са посочени продукти и цени. Всички продажби се отчитат в СУПТО програмата в офиса.
Изискването на Чл. 52з. (10), за автоматичен импорт на поръчките при платформите с отворен код е неприложимо (не може да накараш американската компания WooCoomerce да прави импорт за българско СУПТО). Има решения за импорт, които обачен са на цена 500-600 лв. Това е доста голяма сума. Защо се натоварват фирмите с допълнителни разходи. Това ли е идеята?
Каква е логиката да има автоматичен импорт от електронен магазин във фирменото СУПТО, при положение, че:
1. Поръчките от електронен магазин се въвеждат в СУПТО програмата и си получават УНП номер от нея.
2. Поръчките от електронен магазин не винаги стават продажба ( ако се реализира продажба, тя се реализира през СУПТО и се отчита в НАП).
3. Каква е логиката да се следят поръчките, а не продажбите. Както вскички знаем (силно се надявам вскички да го знаем), че не всяка поръчка става продажба.
Нали абревиатурата на НАП е Национална агенция за ПРИХОДИТЕ (които се реализират от продажби), а не е Национална агенция на ПОРЪЧКИТЕ?
Предложение:
Да отпадне изискването за автоматичен импорт на поръчките от Електонния магазин в СУПТО, при положение, че фирмата има регистрирано СУПТО и следи и отчита всички поръчки и продажби в него независимо как са получени те ( в офиса, по телефона, през електронния магазин, по мейла, с SMS, по Viber, Messenger, пощенско писмо, устно и т.н.)
С Уважение!
Тъй като в чл. 29 ал.1 т.6 се регламентира възможността, реда и начина, как една продажба на Доверител, може да бъде регистрирана чрез СУПТО и ФУ на Довереник, с което задължението за издаване на ФБ се прехвърля на Довереника, взимащ сумата от крайния потребител и издаващ фискалния бон, то от гледна точка на Доверителя и неговата минимално необходима правна сигурност, следва да се поясни в Чл. 3 ал.1, че регистрирането на продажба чрез СУПТО и ФУ на Довереник освобождава Доверителя от задължението и той да издава касов бон за същата продажба.
Предложение:
В Чл. 3 ал.1, след изречението "освен когато плащането се извършва чрез внасяна на пари в наличност по платежна сметка, кредитен превод....." да се добави "или чрез регистриране на продажба със СУПТО и ФУ на Довереник".
Тъй като в чл. 29 ал.1 т.6 се регламентира възможността, реда и начина, как една продажба на Доверител, може да бъде регистрирана чрез СУПТО и ФУ на Довереник, с което задължението за издаване на ФБ се прехвърля на Довереника, взимащ сумата от крайния потребител и издаващ фискалния бон, то от гледна точка на Доверителя и неговата минимално необходима правна сигурност, следва да се поясни в Чл. 3 ал.1, че регистрирането на продажба чрез СУПТО и ФУ на Довереник освобождава Доверителя от задължението и той да издава касов бон за същата продажба.
Предложение:
В Чл. 3 ал.1, след изречението "освен когато плащането се извършва чрез внасяна на пари в наличност по платежна сметка, кредитен превод....." да се добави "или чрез регистриране на продажба със СУПТО и ФУ на Довереник".
22.06.2020
22.07.2020
---
Справка или съобщение.---
Окончателен акт на Министерския съвет
Предвидени промени: § 19. Създава се чл. 52е¹:
(3) В 14-дневен срок от включване на новата версия на софтуера в публичния списък по чл. 118, ал. 19 от ЗДДС, производителят/разпространителят е длъжен да подмени версията по ал. 1 при всички потребители.
Предложение: Увеличаване на срока, съобразно броя клиенти ползващи проблемната версия.
Мотиви: Срокът предвиден за подмяна на версията е прекалено кратък и физически неизпълним, когато се налага обслужването на стотици клиенти.
Предвидени промени: § 19. Създава се чл. 52е¹:
(3) В 14-дневен срок от включване на новата версия на софтуера в публичния списък по чл. 118, ал. 19 от ЗДДС, производителят/разпространителят е длъжен да подмени версията по ал. 1 при всички потребители.
Предложение: Увеличаване на срока, съобразно броя клиенти ползващи проблемната версия.
Мотиви: Срокът предвиден за подмяна на версията е прекалено кратък и физически неизпълним, когато се налага обслужването на стотици клиенти.