MasterFiles - основните данни на бизнеса

Основните данни зад всяка операция

MasterFiles е "речникът" на файла - всички идентификатори, използвани в GeneralLedgerEntries и SourceDocuments (сметки, клиенти, доставчици, данъчни кодове, продукти), се дефинират именно тук. Ако елемент липсва или е грешен в MasterFiles, всяка операция, която го цитира някъде другаде във файла, се проваля на кръстосана проверка - затова тази секция е фундаментът, не просто поредната таблица.

Дванадесетте подсекции - и кой вид файл всяка от тях среща

MasterFiles като цяло е задължителна и в трите вида файл - но това не важи автоматично за всяка от дванадесетте ѝ подсекции. Диаграмата показва точно разпределението.

Сметкопланът - началните салда се пишат само в едната посока

За всяка сметка от GeneralLedgerAccounts подавате начално и крайно салдо - но не и двете страни на всяка двойка едновременно.

Клиенти и доставчици - идентична структура, различна посока

Customer и Supplier споделят практически идентична вътрешна структура (CompanyStructure - идентификатор, име, адрес, банкова сметка, данни за контакт) - логично, защото и двете описват контрагент, само в различна посока на паричния поток. Разглеждаме подробно префиксната система на идентификаторите (CustomerID/SupplierID) в глава 7 - тук е достатъчно да знаете, че двете структури не се различават съществено по съдържание, само по това в коя от двете подсекции живее конкретният контрагент.

Мапиране към SAF-T номенклатури - обобщение

Четирите най-чести "преводачи" между вашата вътрешна номенклатура и тази на НАП, на един поглед.

TaxTable - не са само ставките на ДДС

TaxTable описва не само процента на данъка, но и типа му (TaxType) и приложимостта (TaxCode) - едно и също число "20%" може да означава различни неща в зависимост от кода, с който е обвързано (стандартна ставка ДДС, намалена ставка, освободена доставка, данък при източника). Мапирането тук не е просто "числото ми съвпада", а "кодът ми съответства на точното значение в номенклатурата на НАП" - виж глава 8 за пълния списък номенклатури.

Products - два малки, но конкретни детайла

• GoodsServicesID приема само две стойности: 01 (стока) или 02 (услуга) - прост бинарен избор, но важен за всеки артикул.
• ValuationMethod декларира как оценявате наличностите: FIFO, LIFO, среднопретеглена цена или стандартна себестойност. Изберете стойността, която реално отразява метода ви на осчетоводяване - не подразбиращата се опция.

Ако продукт няма съответствие в номенклатурата NC8_TARIC (митническа номенклатура на стоки), ProductCommodityCode не остава празен и не гадаете най-близкия код - схемата изрично позволява стойност "0" за този случай. За артикули, декларирани изрично като услуга (GoodsServicesID = "02"), кодът е различен - "00000000", не "0" - защото услугите структурно нямат митнически код, за разлика от стоки, за които просто липсва съвпадение.

Owners - собственост върху материални запаси, не върху фирмата

Както видяхме в глава 3, Owners тук няма нищо общо с корпоративна собственост - това е незадължителна подсекция за случаи, в които стока на склад принадлежи на друго лице, не на подаващата фирма (напр. консигнация). Ако нямате такива случаи, просто я пропускате - тя не е "забравена" задължителна секция.

Assets - две паралелни оценки на всеки актив

Всеки дълготраен актив носи две отделни дървовидни структури за оценка: ValuationSAP (счетоводна амортизация - по вашата счетоводна политика) и ValuationDAP (данъчна амортизация - по данъчните норми на ЗКПО). Всяко дърво носи над 20 полета - диаграмата показва представителна извадка от всяко, не пълния списък (пълният е в речника).

Вътре във всяко от двете дървета има едно допълнително правило: живот на актива в години или в месеци - схемата ги моделира като истински xs:choice, никога и двете полета едновременно. Изберете мерната единица, която реално ползвате в амортизационния план, и се придържайте към нея за целия актив.

Как да проверите себе си преди подаване

Кратък списък неща, специфични за MasterFiles, преди да минете нататък:

• Всяка сметка има само едно от двете начални салда попълнено (не и двете, не и "0.00" за неприложимото) - и същото за крайното салдо. Подадени са само сметки с реално салдо или оборот през периода, не целият сметкоплан.
• Контрагент с разчети в няколко счетоводни сметки има отделна Customer/Supplier структура за всяка сметка; контрагент, който е едновременно клиент и доставчик, има запис и в двете подсекции, без нетиране.
• Всеки продукт има валиден GoodsServicesID (01/02) и реалистичен ValuationMethod, дори да не са XSD-мандаторни.
• Продукти без NC8 съответствие имат ProductCommodityCode = "0"; услуги имат "00000000" - не измислен код в нито единия случай.
• Всеки актив има последователен избор години/месеци във всяко от двете дървета за оценка - не смесица - и попълнени и двете дървета (ValuationSAP и ValuationDAP).

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

• MasterFiles е речникът - грешка тук чупи всяка операция, която го цитира другаде.
• 12-те подсекции не принадлежат еднакво на трите вида подаване - вижте диаграмата в началото на главата, не приемайте по подразбиране.
• Начално и крайно дебитно/кредитно салдо са взаимно изключващи се двойки (xs:choice), не стойност/нула - и се подават само сметки с реално салдо или оборот, не целият сметкоплан.
• Контрагент с разчети в няколко сметки получава отделна структура за всяка; контрагент, който е и клиент, и доставчик, получава запис в двете подсекции, без нетиране.
• TaxTable мапира не само процента, но и типа/кода на данъка - две еднакви на пръв поглед ставки може да значат различни неща.
• Products носи два кратки избора (GoodsServicesID, ValuationMethod), които са практически важни, дори да са XSD-незадължителни.
• Липсващ NC8 код се декларира изрично с "0" за стоки и "00000000" за услуги.
• Owners тук е за материални запаси, не за корпоративна собственост (виж глава 3).
• Assets изисква и двете дървета за оценка (счетоводна и данъчна амортизация), всяко с последователен избор години/месеци (xs:choice).

Следващата глава е GeneralLedgerEntries - самите счетоводни записи зад числата.