Контрагенти и подаващото лице

Кой е кой във файла

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

Идентификаторите носят префикс, не са голото ЕИК

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

ЕС контрагент - 11 или 14, според наличието на ДДС номер

Най-честата грешка сред седемте префикса не е объркване на цифрите, а грешна преценка кога контрагентът "заслужава" префикс 11. "Партньор от ЕС" не означава автоматично 11 - 11 изисква конкретно контрагентът да има активен ДДС номер към момента на операцията. ЕС контрагент без такъв номер получава 14 (държава + вътрешен номер), не 11 с празен или измислен код накрая. Същият избор (реален регистрационен номер срещу "знам държавата, но нямам номер") важи идентично и за контрагенти извън ЕС между префикси 12 и 14.

Невалиден код на държава - чия отговорност е да го хване

SAF-T изисква валиден двубуквен ISO 3166-1 код на държава винаги, когато идентификатор носи префикс 11, 12 или 14 (т.е. декларирате чужд контрагент). Ако кодът на държавата във вашите вътрешни данни е грешен, неразпознат или липсва, идентификаторът е невалиден - независимо какъв софтуер го генерира.

Как точно се хваща това зависи изцяло от инструмента, с който подготвяте файла, не от самата схема:

• Софтуер, който изобщо не проверява кода на държавата, ще го препише директно в идентификатора - рискът за грешка или отхвърляне от НАП е изцяло върху вас, ще трябва ръчно да проверите кода, контрагент по контрагент, преди подаване.
• Друг софтуер може да ви върне конкретна грешка за поправяне вместо да генерира файла директно с невалидни данни.
• Magi проверява всеки код на държавата спрямо номенклатурата на ISO 3166 при мапирането и, ако не разпознае валиден код, автоматично прекодира идентификатора към резервния префикс 15 (само-вътрешен номер), вместо да остави невалидна референция във файла - и изрично показва каква корекция е направил, за да проверите източника на грешката в собствените си данни.

TaxRegistration - кога един контрагент "заслужава" повече данни

Обичайно контрагент се идентифицира само с горния префикс+код. Но ако един и същ контрагент се е появявал под различни идентификатори в различни периоди (например сменил е ДДС регистрацията си, или сте го въвели веднъж по ЕИК и веднъж по друг код по грешка), елементът TaxRegistration става задължителен - той служи за изрично свързване на множеството идентификатори с едно и също реално лице. Ако мапирането ви е последователно от самото начало, рядко ще имате нужда от него - но е добре да знаете кога се задейства.

Проверките преди подаване - "зеленото" не проверява всичко наведнъж

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

Един контрагент, един идентификатор - навсякъде във файла

Свързан капан с горното: ако един и същ клиент се появи в MasterFiles с CustomerID 10123456789, но в GeneralLedgerEntries по невнимание е записан с различно изписване на същия код (например с различен брой водещи нули, или изобщо без префикса), кръстосаната проверка не разпознава двата записа като едно и също лице. Резултатът е същият, като че ли клиентът изобщо липсва - файлът се отхвърля, макар данните "по същество" да са верни. Последователността на изписването на идентификатора във всички секции на файла е също толкова важна, колкото и самото му съществуване в MasterFiles.

Чести грешки при контрагентите

• Подаване на гол ЕИК/ЕГН без префикс.
• Един и същ клиент с различен CustomerID в различни секции на файла - трябва да съвпада навсякъде, до последната цифра.
• Пропуснат TaxRegistration, когато контрагент реално е сменял идентификатора си във времето.
• Невалиден или непроверен код на държава при чуждестранен контрагент - открива се късно, само ако софтуерът ви изобщо го проверява.
• Разчитане само на "зеленото отметче" на XSD валидатора, без проверка на кръстосаните препратки към MasterFiles.

Какво да запомните от тази глава

• Идентификаторите носят задължителен двуцифрен префикс (10=ЕИК, 11=VIES ДДС номер, 12=извън ЕС с регистрационен номер, 13=ЕГН, 14=държава+вътрешен номер (без официален номер), 15=само вътрешен номер, 16=служебен номер на НАП по СИДДО), не гол код.
• Префикс 11 изисква активен ДДС номер - ЕС контрагент без такъв получава 14, не 11 с невалиден код накрая.
• Невалиден код на държава при префикс 11/12/14 прави идентификатора невалиден - проверете кодовете на държавата ръчно, освен ако сте сигурни, че софтуерът ви прави тази проверка вместо вас.
• TaxRegistration става задължителен, когато един контрагент е бил под различни идентификатори в различни периоди.
• XSD валидация ("зеленото") и кръстосаните проверки между секции са две отделни проверки - минаването на едната не гарантира минаването на другата.
• Липсващ или несъвпадащ CustomerID/SupplierID между секциите отхвърля файла на бизнес ниво, независимо от чиста XSD валидация.

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