Отхвърлен одиторски файл: какво да провериш и какво да направиш

Порталът на НАП проверява одиторския файл още при подаването. Ако открие несъответствие, файлът се отхвърля и трябва да бъде подаден отново. Тук е какво да провериш според текста на Приложение № 38 и стъпките, с които да откриеш и поправиш причината навреме.

Какво проверява порталът

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

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

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

Сумите

Приложение № 38 описва сумите на две нива.

На ниво артикул всеки ред има единична цена без отстъпка и без ДДС (ART_PRICE), количество (ART_QUANT), ставка на ДДС (ART_VAT_RATE), сума на ДДС за реда (ART_VAT) и обща сума на реда с ДДС (ART_SUM). Сумата на ДДС трябва да отговаря на ставката, а общата сума на реда на цената, количеството и ДДС.

На ниво поръчка има стойност без отстъпка и без ДДС (ORD_TOTAL1), отстъпка (ORD_DISC), ДДС (ORD_VAT) и стойност с ДДС (ORD_TOTAL2). Четирите суми трябва да се връзват помежду си и с артикулите в поръчката.

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

Месецът и датите

Файлът е за един календарен месец и една година, посочени в полетата MON и GOD. Освен тях във файла има дата на създаване на файла, дата на всяка поръчка, дата на документа по чл. 52о, когато е издаден, и дата на всяко връщане на сума.

Провери две неща:

• За кой месец е изготвен файлът. Файлът за даден месец се изготвя след края на месеца и се подава до 15-о число на следващия. Повече: Срок за подаване.
• Дали датите в него са верни. Датите на поръчките, на документите и на връщанията трябва да са истинските дати от магазина. Връщането на сума се отразява във файла за месеца, в който сумата е върната на клиента. Повече: Връщания.

Задължителните полета

Приложение № 38 отбелязва повечето полета като задължителни, а за някои незадължителни указва кога все пак се попълват:

• Номерът на документа по чл. 52о (DOC_N) се попълва задължително, когато за продажбата е издаден такъв документ.
• Начинът на плащане (PAYM) е задължителен за всяка поръчка: код от 1 до 6.
• Референтният номер на трансакцията (TRANS_N) е задължителен, когато плащането е извършено чрез виртуален ПОС.
• Номерът на виртуалния ПОС (POS_N) е задължителен, когато ПОС-ът е свързан директно с платежна сметка на търговеца.
• Идентификаторът на доставчика на платежни услуги (PROC_ID) е задължителен, когато плащането е извършено чрез такъв доставчик.

Провери дали за всяка поръчка е посочен правилният начин на плащане и дали полетата, които той изисква, имат стойност. Какво означава всеки код: Начини на плащане.

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

Данните за магазина

Заглавната част на файла съдържа уникалния номер на магазина (E_SHOP_N), уеб адреса му (DOMAIN_NAME) и типа му (E_SHOP_TYPE). Това са данните, с които магазинът е регистриран по Приложение № 33, затова ги сравни с регистрацията:

• Номерът е този, който НАП е присвоил на магазина. Той се получава при подаване на т. 7 от Приложение № 33. Ако тази точка не е попълнена, магазинът няма номер, с който да подава файл.
• Адресът е домейнът на магазина, а при онлайн платформа линкът към магазина в платформата.
• Типът е „1“ за собствен или нает домейн и „2“ за продажба чрез онлайн платформа.

Ако данните в регистрацията са се променили, актуалната информация се подава в 7-дневен срок по чл. 52м, ал. 3. Повече: Регистрация на електронен магазин.

Не редактирай XML файла на ръка

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

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

Какво да направиш, когато файлът е отхвърлен

1. Прочети причината в резултата от проверката в портала.
2. Открий я в данните на магазина: поръчки, цени, количества, отстъпки, ставки на ДДС, начин на плащане, издадени документи, върнати суми и данни от регистрацията.
3. Поправи данните там, където са въведени.
4. Изготви файла отново със софтуера, който го е създал.
5. Подай отново преди изтичането на срока, тоест до 15-о число на месеца след отчетния. Не оставяй това за последния ден.

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

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

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