Промените в наредба №18 и как тя засяга електронните магазини.

Преди въпросните промени електронните магазини бяха блокирани да приемат други плащания освен пощенски паричен превод (ППП), за който не се изисква издаването на фискален бон. Всичко останало беше в нарушение на №18.

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

I. Приемане на картови плащания

Началото на 'облекченията' за ЕЛМ за приемане на картови плащания без да е регистиран в НАП като СУПТО: (коментирал съм старите текстове от наредбата, в които се вмъкват промените с /*  ... */ за да е по-ясно)

§ 1. В чл. 1:
1. В ал. 1 се създава т. 9:
„9. формата и съдържанието на документите, условията, редът и начинът за издаването им, както и задълженията за предаване на данни при неприсъствено плащане с кредитна или дебитна карта.“
/*=======
Чл.  1. (Изм.  - ДВ, бр.  40 от  2013 г., в сила от 30.04.2013 г.)  
(1) С тази наредба се определят
8. (нова  - ДВ, бр.  80 от 2018 г.) изискванията към лицата, извършващи продажби чрез електронен магазин.
(2) Наредбата регламентира задължението на всяко лице да регистрира и отчита извършените от него продажби в търговски обект чрез издаване на фискална касова бележка от ФУ (фискален бон) или касова бележка от ИАСУТД (системен бон), независимо дали е поискан друг данъчен документ
=======*/

§ 2. В чл. 2, ал. 1 след думите „електронен магазин“ се поставя запетая и се добавя „неприсъствено плащане с кредитна или дебитна карта“, а думите „86 и 87“ се заменят с „86, 87 и 96“.
/*=======
Чл. 2. (1) (Изм. - ДВ, бр. 49 от 2010 г., в сила от 29.06.2010 г., изм. - ДВ, бр. 40 от 2013 г.,в сила от 30.04.2013 г., изм.  - ДВ, бр.  26 от 2019 г., в сила от 29.03.2019 г.) За целите на тазинаредба "фискално устройство", "търговски обект", "интегрирана автоматизирана система за управление на търговската дейност", "краен потребител", "краен разпространител", "фискалнакасова бележка от фискално устройство (фискален бон)", "касова бележка от интегрирана автоматизирана система за управление на търговската дейност (системен бон)", "софтуер за управление на продажби в търговски обект", "производител на софтуер за управление напродажби в търговски обект", "разпространител на софтуер за управление на продажби втърговски обект", "електронен магазин" са тези по  §  1, т.  40,  41,  67,  69,  70,  84,  85,  86 и  87 от допълнителните разпоредби и чл.  118, ал.  3 от Закона за данък върху добавената стойност(ЗДДС)

/* Допълнителните разпоредби на Закона за данъка върху добавената стойност: § 1, т. 87. "Електронен магазин" е софтуер, достъпът до който се осъществява през интернет при използване на уеб-браузер или мобилно приложение, и чрез който се извършва продажба на стоки/услуги посредством сключване на договор от разстояние по чл. 45 от Закона за защита на потребителите, като се предоставя възможност за избор от клиента на стоки/услуги чрез потребителска кошница или по друг начин, както и за предоставяне на информация за контакт с купувача, адреса на доставка и метода за плащане. */

=======*/

И ето най-важното:

5. Създава се ал. 17:
„(17) Лице по ал. 1, което извършва продажби на стоки и/или услуги чрез електронен магазин, може да регистрира и отчита тези продажби вместо с фискален или системен бон чрез документ за регистриране на продажбата, който не е издаден от ФУ или ИАСУТД, когато е извършено неприсъствено плащане с кредитна или дебитна карта и при условие че:
1. софтуерът/софтуерите за управление на продажбите, отговаря/т на изискванията по чл. 52с; и
2. за продажбите, извършвани чрез електронния магазин, лицето приема неприсъствени плащания, извършвани с кредитна и дебитна карта, и не приема други плащания, изискващи издаването на фискален/системен бон; и
3. чрез софтуера/софтуерите по т. 1 не се управляват други продажби, извън продажбите по т. 2.“

Какво значи това? Разглеждам по точки:

1-ва точка 'софтуерът/софтуерите за управление на продажбите, отговаря/т на изискванията по чл. 52с':

Чл. 52с. (1) Софтуерът на електронния магазин, чрез който се извършват продажби на стоки или услуги, заплащани чрез неприсъствено плащане с кредитна или дебитна карта, за които се издава документ по чл. 52о, трябва да генерира уникален номер на всяка поръчка за закупуване на стока или услуга и да отговаря най-малко на изискванията в т. 2, 3 и 7 от приложение № 29.
/*=======
Приложение No 29 към чл. 52
2. Софтуерът осигурява пълнота и интегритет на данните, създавани при използването му.
3. В случаите, в които софтуерът за управление на продажби в търговски обект представлява модул от софтуер, останалите модули не могат да имат дублираща функционалност за управление на продажбите или функционалност, целяща заобикаляне на изискванията в това приложение.
7. Софтуерът осигурява еднозначна автентикация на потребителите (операторите) при работа с него
=======*/

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

Сега разглеждаме нещата в под точки свързани с точка 1 и изискванията на Чл. 52с. и Приложение No 29 към чл. 52, или на какво трябва да отговаря софтуера на вашия ЕЛМ (въпросните т. 2, 3 и 7):

под Точка 2 - Смятам, че всички софтуери на ЕЛМ ще отговорят на нея. Написана е много общо  в стила на 80-те от миналия век 'осигурява пълнота и интегритет на данните' каквото и да означава това към днешна дата...

под Точка 3 - Тук модул явно 'модул' се разглежда като добавка или компонент към Система за управление на съдържанието (CMS) като WP, Joomla, Drupal и др. към които ЕЛМ се инсталира извън ядрото на CMS-а. С 2 думи не може да имате 2 ЕЛМ независими в рамките на един сайт. (поне аз така разбирам нещо, което е писано за друг софтуер и приложено към ЕЛМ).

под Точка 7 ВНИМАНИЕ! - Тук става дума за автентикация (удостоверяване) на потребителите (операторите). Според мен тук може да има определени проблеми защото пак тези изисквания са прекачени към ЕЛМ от складовия софтуер и ПОС точките за продажба (наричани вече СУПТО). Там всеки оператор си има уникален код и неговите действия се записват в системата. Тук трябва да се прегледа възможностите на софтуера на съответният ЕЛМ и да се търси решение. Ако НАП приеме тази 'автентикация' във вида на СУПТО ще се наложи основна преработка на софтуера на CMS-а или на ЕЛМ! // Тук трябва да вметна, че Joomla има подобна функционалност в ядрото и отговаря до някъде на тези изисквания, но за другите широко използвани софтуери ще се наложи да се търси допълнително решение.

2-ра точка 'за продажбите, извършвани чрез електронния магазин, лицето приема неприсъствени плащания, извършвани с кредитна и дебитна карта, и не приема други плащания, изискващи издаването на фискален/системен бон'

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

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

На практика се блокира българския бизнес за продажби извън границите на България за продажба на стоки. Всеизвестен е факта, че тук (в България) предпочитания начин за плащане е наложен платеж и сега заместен с пощенски паричен превод (Н. №18). Не е приемливо и не възможно да се използва подобен начин на плащане извън територията на България. Там има една наложила се практика - плащане с карта.

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

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

3-та точка 'чрез софтуера/софтуерите по т. 1 не се управляват други продажби, извън продажбите по т. 2'

Тук софтуера на ЕЛМ не трябва да 'управлява други продажби, извън продажбите по т. 2' ^??? Нещо пак е приложено (копирано) от изискванията на друг софтуер //вероятно СУПРО

Как един софтуер за електронен магазин да управлява касови плащания? Не ми стига акъла... //освен ако не е СУПТО

Всичко това в точки 2 и 3 е някаква параноя от страна на НАП, особено на фона на следващите изисквания и контрол на ЕЛМ.

Ето какъв документ трябва да се издаде на клиента при плащане с карта според измененията на наредбата:

„Чл. 52о.
(1) Лицето по чл. 3, ал. 17 е длъжно да регистрира и отчита продажбата на стоки или услуги при неприсъствено плащане с кредитна или дебитна карта чрез издаване на документ за регистриране на продажбата, който трябва да бъде четим и да съдържа най-малко следните реквизити:
1. наименование, номер и дата на документа; номерът на документа трябва да е 10-разряден, да нараства възходящо със стъпка 1 за всяка продажба и да съдържа само арабски цифри; номерът трябва да е уникален за цялата дейност на електронния магазин и търговеца;
2. данни за лицето по чл. 3, ал. 17;
за юридическите лица и едноличните търговци – наименование, ЕИК, седалище и адрес на управление, електронен адрес или телефон;
за физическите лица – имена, адрес, на който се упражнява дейността, електронен адрес или телефон;
3. уникален номер на клиентската поръчка;
4. референтен номер на финансовата трансакция;
5. наименование на стоката/услугата, код на данъчна група, количество и стойност по видове закупени стоки/услуги, единична цена, обща сума за плащане и начин/и на плащане;
6. двумерен баркод (QR код) съгласно приложение № 18а, съдържащ информация за продажбата
– номера, получен от НАП при подаване на информация по чл. 52р съгласно приложение № 33,
- дата и час на продажбата в софтуера на електронния магазин,
- референтен номер на финансовата трансакция,
- сума на продажбата и уникален номер на клиентската поръчка в електронния магазин.
/*========
§ 33. В приложение № 18а накрая се добавя:
„Кодирането на информацията в QR кода за софтуер по чл. 52т се извършва в следната последователност и формат на данните: <номерът, получен от НАП при подаване на информация по чл. 52р съгласно приложение № 33>*< >*<уникален номер на клиентската поръчка>*<референтен номер на финансовата трансакция>*<дата на издаване на документ за продажба във формат ГГГГ-ММ-ДД>*<час на издаване на документ за продажба във формат ЧЧ:ММ:СС>*<обща сума на продажбата>.“
=======*/

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

(3) Когато за продажбата е издадена фактура, се допуска да не се издава документ по ал. 1, ако във фактурата се съдържат данните по ал. 1, т. 3 – 6.

(4) Лицето по чл. 3, ал. 17 трябва да осигури еднозначна идентификация на всяка продажба от всеки електронен магазин.

(5) Лицето по чл. 3, ал. 17 е длъжно да предостави по електронен път на клиента така издадения документ при извършване на плащането с дебитна или кредитна карта/авторизацията на нареждането за плащане от виртуалния ПОС.

(6) Лицето по чл. 3, ал. 17 е длъжно да регистрира всяка продажба на стока или услуга съгласно чл. 27.
/*=======
Чл. 27. (1) Лицата по чл.  3, с изключение на случаите, когато извършват дейност по чл.28, са длъжни да регистрират всяка продажба на стока или услуга по данъчни групи според вида на продажбите:
1. група "А" - за стоки и услуги, продажбите на които са освободени от облагане с данък,за стоки и услуги, продажбите на които се облагат с 0 % ДДС, както и за продажби, за които не се начислява ДДС;
2. група "Б"  - за стоки и услуги, продажбите на които се облагат с  20  % данък върху добавената стойност;
3. група "В" - за продажби на течни горива чрез измервателни средства за разход на течни горива;
4. (изм.  - ДВ, бр.  48 от 2011 г., в сила от 24.06.2011 г.) група "Г"  - за стоки и услуги,продажбите на които се облагат с 9 % данък върху добавената стойност.
(2) Лицето по чл.  3 независимо дали е регистрирано или не по ЗДДС задължително регистрира всички продажби по данъчни групи съгласно ал. 1.
(3) Задължително се програмират и регистрират с наименование и единична цена като отделни артикули стоките или услугите:
1. отнасящи се към данъчна група А;
2. с фиксирани цени в нормативен акт;
3. представляващи горива, продавани чрез одобрени по смисъла на Закона за измерванията средства за измерване на разход
=======*/

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

Атрибутите на документа по Чл. 52о (1) са посочени точно. Неговото издаване и предоставяне на клиента, също.

От написаното по-горе става ясно, че този документ трябва да се генерира автоматично от софтуера на на ЕЛМ и също така автоматично да се предостави на клиента по електронен път, след успешно плащане с карта.

Искам да разгледам част от атрибутите на този документ, защото ние вече сме го реализирали за Hika Shop и това може да бъде в помощ за внедряване и други софтуери за ЕЛМ.

Определено в точка 1 'номер на документа' има стриктни изисквания. Повечето читави ЕЛМ имат възможност за издаване на фактури или т.н. Shipping invoice, които могат да се преработят за целта. Тук трябва да е ясно, че ако номера на поръчката отговаря на тези изисквания, може да се ползва и той. В случая всеки отделен (Име документ) може да се дублира. Например - Поръчка № 0000000001, Фактура № 0000000001, Документ за регистриране на продажба № 0000000001 и няма да сте в нарушение, ако не дублирате еди и същи номера в едно и също име на документ.

Друга част от документа също ще предизвика най-вероятно преработка на плъгините за плащане с карта и това е 4. референтен номер на финансовата трансакция. Тук ще трябва да се изисква обратно от банката или платежния оператор този атрибут и да се запише в базата данни към съответната поръчка. Разговарях вече с ДСК и след малко чудене от тяхна страна за какво точно става дума, намериха решения за този референтен № Предполагам, че и другите ще предоставят тези данни за техните платежни методи.

Малка изненада има и в таблицата с предоставените стоки и услуги. Там се добавя колона 'код на данъчна група'. Явно почва да се мисли за диференцирана ставка на ДДС. То и сега има 9% описана в Чл. 27. (1), но ако се реализират и други, това може да се окаже по-сложно за ЕЛМ продаващи стоки с различни ставки. Вижте дали софтуера на вашия ЕЛМ подържа дефиринцирано ДДС.

QR кода също става задължителен атрибут. Тук вече асно е описано, че 'идентификатор на ИАСУТД (IASUTDID)' е 'номерът, получен от НАП при подаване на информация по чл. 52р съгласно приложение № 33' и се издава еднократно за ЕЛМ. Това поле остава статично, а не както някои мислиха че се генерира при всяка поръчка от НАП.

Тук при вече публикуваните промени ми прави впечатление, че има 1 празно поле след този номер *< >* и се надявам да не е 'печатна грешка'

Както става видно, допуска се и издаването на ел. фактура, която трябва да съдържа данните по ал. 1, т. 3 – 6.

Имаше определени изказвания в facebook групата 'Онлайн магазини', че издаването на фактури ще натовари счетоводството. От написаното става ясно, че този документ също ще се осчетоводява и на практика е едно и също.

Следват още изисквания, от които става ясно:

- Сметката трябва да бъде с титуляр задълженото лице (това, което е регистрирано в НАП).

- 2 изключения (3) 1. и 2. Точка 2 позволява да получите постъпленията си от доставчика по тази сметка или сметки.

Чл. 52п.
(1) Допуска се прилагането на чл. 52о, при условие че лицата по чл. 3, ал. 17 приемат неприсъствено плащане с кредитна или дебитна карта само по платежни сметки в банки и/или други доставчици на платежни услуги с титуляр задълженото лице. Сметките могат да бъдат при доставчик на платежни услуги, установен на територията на ЕС или държава, с която Република България има влязла в сила СИДДО, включваща клауза за обмен на банкова информация. Сметките трябва да са свързани с използваните от лицата по чл. 3, ал. 17 виртуални ПОС, предоставени на лицето от доставчика на платежни услуги, при който е разкрита сметката.
(2) Допуска се постъпленията от плащания чрез виртуален ПОС да постъпват в сметки на доставчици на платежни услуги, предоставили ПОС-а, при условие че впоследствие се превеждат по сметка по ал. 1.
(3) Допуска се постъпленията от продажби да се приемат чрез виртуален ПОС, който е свързан с платежна сметка на доставчик на платежни услуги, различен от доставчика на платежни услуги, при който е разкрита сметката по ал. 1, при условие че:
1. доставчикът, който приема плащането чрез виртуален ПОС, е установен на територията на ЕС или юрисдикция, с която Република България има влязла в сила СИДДО, включваща клауза за обмен на банкова информация; и
2. постъпленията от продажбите се трансферират от доставчика, приел плащането чрез виртуален ПОС, директно до сметката по ал. 1.


Чл. 52р. (1) Лицето по чл. 3, ал. 17 е длъжно да подава за всеки електронен магазин освен информацията по реда на чл. 52м и:
1. методите на плащане, предлагани от електронния магазин;
2. доставчиците на платежни услуги, с които има сключен договор за предоставяне на виртуален ПОС или с които има сключен договор за получаване на плащания чрез виртуален ПОС на доставчик, свързан с платежна сметка на доставчика;
3. платежните сметки, по които получава плащания от продажбите на стоки или услуги, включително тези, с които е свързан виртуален ПОС;
4. изпълнението на условията на чл. 52с;
5. номер на виртуалния ПОС, чрез който се извършват плащанията, включително когато виртуалният ПОС е на доставчик на платежни услуги и е свързан с платежна сметка на доставчика.

Изискванията за регистрация и одиторския файл, който трябва да се подава към НАП ежемесечно. Ето ги и тях (за удобство съм заменил таблицата от Приложение No 38 към чл. 52т, ал. 2 с по-разбираемите на мен тагове)

Чл. 52т. (1) Лице по чл. 3, ал. 1, което извършва продажби на стоки и/или услуги чрез електронен магазин, избрало да издава документ по чл. 52о, е длъжно преди започване на дейност по продажби на стоки или услуги да регистрира електронния си магазин в информационната система на НАП съгласно приложение № 33, като му се присвоява уникален номер.
(2) Лицето по чл. 3, ал. 17 е длъжно за всеки календарен месец да подава към НАП стандартизиран одиторски файл съгласно приложение № 38, съдържащ информация за направените в електронния магазин поръчки, по които са извършени доставки на стоки/услуги през месеца. Информацията се подава до 15-о число на месеца, следващ месеца, за който се отнася.
/*=======
Приложение No 38 към чл. 52т, ал. 2

<EIK> </EIK> //ЕИК на задълженото лице
<MON> </MON> //Календарен месец
<GOD> </GOD> //Календарна година

<ORD_N> </ORD_N> //Уникален номер на поръчка в софтуера на е-магазина No 1
<ORD_D> </ORD_D> //Дата на поръчката Формат: YYYY-MM-DD
<DOC_N> </DOC_N> //Номер на документа по чл. 52о, ал. 1, т.1
<DOC_DATE> </DOC_DATE> //Дата на документа по чл. 52о, ал. 1, т.1 Формат: YYYY-MM-DD

<ART_NAME> </ART_NAME> //Наименование на стоката/услугата No1 Посочва се вида на доставената на клиента стока/предоставена услуга
<ART_QUANT> </ART_QUANT> //Количество Формат: 0.00
<ART_PRICE> </ART_PRICE> //Единична цена (без отстъпка) без ДДС –в лв. Формат: 0.00
<ART_VAT_RATE> </ART_VAT_RATE> //ДДС -ставка Формат: 0.00
<ART_VAT> </ART_VAT> //ДДС –сума, в лв. Формат: 0.00
<ART_SUM> </ART_SUM> // Обща сума –в лв. Формат: 0.00

   <ART_NAME> </ART_NAME> //Наименование на стоката/услугата No2 Посочва се вида на доставената на клиента стока/предоставена услуга
   ...

<ORD_TOTAL1> </ORD_TOTAL1> //Обща стойност на доставените стоки/предоставени услуги –без ДДС
<ORD_DISC> </ORD_DISC> //Отстъпка (сума) -в лв.
<ORD_VAT> </ORD_VAT> //ДДС –сума, в лв.
<ORD_TOTAL2> </ORD_TOTAL2> //Обща стойност на доставените стоки/предоставени услуги –с ДДС
<PAYM> </PAYM> //Начин на плащане на поръчката: 1 –Банков превод; 2 –Виртуален ПОС-терминал; 3 –Наложен платеж с ППП; 4 –Платежен оператор; 5 –Друг

<POS_N> </POS_N> //Номер на виртуален ПОС-терминал В случай че плащането е плащане през виртуален ПОС-терминал
<TRANS_N> </TRANS_N> //Номер на финансовата транзакция В случай че плащането е през виртуален ПОС-терминал
<PROC_NAME> </PROC_NAME> //Наименование на платежен оператор В случай че плащането е извършено чрез платежен оператор
<PROC_MERC_ID> </PROC_MERC_ID> //Идентификатор на търговеца в системата на платежния оператор В случай че плащането е извършено чрез платежен оператор


   <ORD_N> </ORD_N> //Уникален номер на поръчка в софтуера на е-магазина No 1
   ...

<R_ORD> </R_ORD> //Брой изцяло или частично върнати поръчки през периода Формат: 0

<R_ORD_N> </R_ORD_N> //Номер на Върната поръчка No1 (уникален  номер на поръчката в софтуера на е-магазин)
<R_AMOUNT> </R_AMOUNT> //Върната сума на клиента -в лв.
<R_DATE> </R_DATE> //Дата на връщане на сумата Формат YYYY-MM-DD
<R_PAYM> </R_PAYM> //Начин на връщане на сумата 1 –по банкова сметка; 2 –по банкова карта; 3 –в брой; 4 –Друг.

   <R_ORD_N> </R_ORD_N>
   ...
=======*/   

(3) Подаването на данни към НАП се осъществява по електронен път по реда на Данъчно-осигурителния процесуален кодекс.

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

Повечето читави софтуери на ЕЛМ имат експорт на поръчките в csv или xml, които лесно биха се преработели за целта, но ако ЕЛМ са повече от 1 как ще стане? Ако счетоводния софтуер е пригоден за тази работа е лесно на се импортират данните за поръчките, но ако не?

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

За финал, изменението на приложение №33 в което пак се иска 'номер на виртуалния ПОС' въпреки че отпадна от документа по Чл. 52о (1):

§ 34. В приложение № 33 се правят следните изменения и допълнения:
1. Създава се нова т. 7:
„7. Информация по чл. 52р, подавана от лица по чл. 3, ал. 17:
7. 1. методите на плащане, предлагани от електронния магазин;
7.2. доставчиците на платежни услуги, с които има сключен договор за предоставяне на виртуален ПОС или с които има сключен договор за получаване на плащания чрез виртуален ПОС на доставчик, свързан с платежна сметка на доставчика;
7.3. Уникален идентификатор на търговеца в системата на доставчика на платежни услуги (Merchant ID);
7.4. платежните сметки, по които получава плащания от продажбите на стоки или услуги, включително тези, с които е свързан виртуален ПОС;
7.5. изпълнението на условията на чл. 52с;
7.6. номер на виртуалния ПОС, чрез който се извършват плащанията, включително когато виртуалният ПОС е на доставчик на платежни услуги и е свързан с платежна сметка на доставчика.
* При подаване на информация по чл. 52р електронният магазин получава номер от НАП.“
2. Досегашните т. 7 и 8 стават съответно т. 8 и 9.

II. Пощенски паричен превод (ППП)

И тук лека изненада, породена най-вероятно от липсата на придружаваш документ от страна на търговеца към клиента:

§ 3. В чл. 3 се правят следните допълнения:
1. В ал. 1 се създава изречение второ: „Когато плащането се извършва чрез пощенски паричен превод, на клиента се предоставя хартиен или в електронен вид документ, съдържащ най-малко информацията по чл. 26, ал. 1, т. 1, 4, 7 и 8.“
/*=======
Чл. 26. (1) (Доп. - ДВ, бр. 40 от 2013 г., в сила от 30.04.2013 г.) Фискалната касова бележка от ФУ трябва да бъде четима, да съответства на образеца съгласно приложение No 1 и да съдържа задължително следните реквизити:
1. наименование и адрес за кореспонденция на лицето по чл. 3;
4. (изм. - ДВ, бр. 49 от 2010 г., в сила от 29.06.2010 г.) идентификационен номер по чл. 84 ДОПК на лицето по чл. 3;
7. (доп. - ДВ, бр. 76 от 2017 г.) наименование на стоката/услугата, код на данъчна група, количество и стойност по видове закупени стоки или услуги;
8. (доп.  -  ДВ,  бр.  26  от  2019  г.,  в  сила  от  29.03.2019  г.)  обща  сума  за  плащане  и начин/и на плащане;
======*/

Тук само ще поясня, че идентификационен номер по чл. 84 ДОПК е ЕИК. Другото е ясно, може да го пращате на хартия с пратката или на имейла на клиента, освен ако не желаете да автоматизирате процеса от ЕЛМ. Това ще бъде лесно за софтуер справил се с изискванията на наредбата във връзка с приемането на картови плащания.

В заключение искам да подчертая, че основно 2 са най-проблемните пунктове в новите изменения на наредба №18:

Първо и най-важно - ограничаването на българския бизнес, който има реални магазини от възможността да се разплаща с карти в своите ЕЛМ и респективно да продава своите стоки извън територията на България!

Това ще има пагубни последствия за малкия и среден бизнес в БГ.

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

Смятам, че тук трябва да бъдат насочени усилията на електронните търговци, БЕА, БАЕТ и др. асоциации и организации защитаващи тези интереси!

Прочетете и статията на kik-info  по същата тема и забележителния имейл на Данаил Коев свързан с наредбата и публикуван в Капитал

Редакция: 27.02.2020

Искам да благодаря на председателя на БЕА Жанет Найденова за повдигнатите проблеми по време на обсъждането с НАП на въпроси по прилагането на Наредба Н-18.

Вижте видеото по долу с частта касаеща ЕЛМ. Отговора на НАП е в края към 1:11 часа от видеото. https://youtu.be/4p-JJy1VzC4?t=4268

Тук става интересно с тълкуването от страна на агенцията:

1. Как може да се отчитат продажбите на физическия магазин от ЕЛМ и ;

2. как те са на едно и също място?

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

- клиент: Искам да купя това.

- търговец: Момент да намеря продукта в нашият Електронен магазин. (вади смартфона и започва да търси, после го подава към клиента) Ето намерих го и пуснах поръчката от ваше име, моля попълнете задължителните полета (Име, Имейл и тн.)

- клиент: Какво ви става бе хора, вие нормални ли сте??? (и напуска физическия магазин, а търговеца остава и във физическия и в електронния  )

За всички е ясно, че по-глупава случка не може да има и остава въпроса: Как да се отчитат продажбите от физическия магазин в електронен?

А как ще са на едно и също място?  ЕЛМ е на сървър, а не на тротоара и адресите им са различни. Физическия си има физически адрес, електронния - електронен.