Türkiye e-Fatura интеграция за ERP система

За работа в Türkiye една ERP система обикновено трябва да поддържа e-Fatura и e-Arşiv, а в някои сектори и e-İrsaliye, чрез Приходната администрация (GİB), най-често с частен интегратор. ERP създава документа във формат UBL-TR, продавачът го подписва с финансовия печат (mali mühür), интеграторът го предава за валидиране от GİB, а данъчно задълженото лице остава отговорно за съхранението.

Какво трябва да поддържа ERP система в Türkiye?

Türkiye използва електронно фактуриране като clearance система: продавачът създава документа, той се предава по оторизиран канал, валидира се от Приходната администрация и едва тогава придобива правен ефект. За фирма, която работи в ERP, това има последици в 4 точки:

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

Цифрово подписване. Документите се подписват с финансовия печат, издаден на данъчно задълженото лице. Стъпката за подписване трябва да е част от потока, а управлението на ключа да съответства на правилата за съхранение на печата.

Двупосочен обмен. При e-Fatura регистрацията на контрагента определя вида документ. Получените фактури, отговори и разрешените анулации трябва да се върнат в ERP с оригиналните идентификатори, иначе счетоводството губи връзката между системата и официалния запис.

Архивиране и извличане. Изпратените и получените документи трябва да могат да се намерят за законовия срок на съхранение. Дали ги пази интеграторът, ERP или и двете, се решава преди пускането, а не при първото искане за одит.

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

При clearance системата фактурата не е готова, когато ERP я отпечата. Тя е готова, когато обменът приключи и отговорите се върнат. Затова състоянието трябва да включва не само „създадена“ и „изпратена“, а и приета, отхвърлена и коригирана. Иначе в края на месеца екипът съгласува ръчно две версии на истината: счетоводната книга и официалния запис.

Времето също е важно. Отхвърлянето може да пристигне, докато екипът още работи, а поправката често засяга основните данни, не самия документ. Човекът, който може да отстрани причината, трябва да получи известие веднага; отчет за грешки без собственик превръща системата в нещо, което постоянно трябва да се наблюдава.

e-Fatura, e-Arşiv и e-İrsaliye

Документ	Използва се за	Типичен повод	Бележка
e-Fatura	B2B и фактури към държавни организации между регистрирани данъкоплатци	И двете страни са регистрирани за e-Fatura	Структуриран документ между регистрирани страни; статусът на контрагента определя маршрута
e-Arşiv	Фактури, при които купувачът не е регистриран за e-Fatura: retail, B2C и някои B2B случаи	Продавачът е в обхвата, а купувачът е извън режима e-Fatura	Купувачът обикновено получава PDF, но документът се генерира и декларира по същата верига
e-İrsaliye	Електронни стокови разписки за секторите и сделките, определени от правилата	Експедиция на стоки в обхванатия поток	Свързва се с фактурата: разписката и фактурата препращат една към друга
e-Defter	Счетоводни книги и записи, подадени по електронен път	Данъкоплатци в обхвата според приложимите правила	Отделно задължение от електронното фактуриране, но обикновено се планира в същия проект

Кой попада в дадено задължение се определя от правилата и комюникетата на GİB, които се променят. Праговете и секторите се задават от властите и могат да бъдат обновени. Проверете регистрационния си статус със счетоводител или данъчен съветник по актуалните правила, преди да проектирате интеграцията.

Варианти за интеграция

Вариант	Подходящ за	Усилие от ERP	Какво да се следи
Портал на GİB	Много малък обем и ръчно издаване	Няма в ERP	Ръчен и бавен; не е цел за бизнес със собствена ERP, а резервен вариант
Частен интегратор (özel entegratör)	Обичайният маршрут за повечето фирми	Връзка към API или формат на интегратора плюс съпоставяне	Сравнете поддръжката и качеството на API, както и кой поддържа обновяването на схемата
Директен достъп до GİB	По-големи операции, които искат пълен контрол	Високо: фирмата поема техническата и оперативната отговорност	По-сложен за получаване и експлоатация; приемайте го като изключение, което трябва да се обоснове

Частният интегратор предоставя техническия канал, предаването и услугата за съхранение, но не поема данъчните задължения на данъкоплатеца. Отговорността за точността, издаването и съхранението по Tax Procedure Law остава във фирмата. Ако идентификаторът на клиента е грешен в основните данни, системата на интегратора може да е работила напълно правилно, а поправката пак е ваша.

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

Стъпки за внедряване и тестове

Работещата последователност от страна на ERP е:

Определете обхвата на задълженията. Потвърдете с счетоводителя кои документи се прилагат: e-Fatura, e-Arşiv, e-İrsaliye и e-Defter.

Изберете канал. Повечето фирми избират частен интегратор. Качеството на API, sandbox средата, езикът и часовете за поддръжка, обновяването на схемата и препоръките са отделен кратък списък за сравнение.

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

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

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

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

Планирайте архива и достъпа. Определете къде се съхраняват документите, кой може да ги извлече и как се отговаря на одиторско искане в срока за съхранение.

Успехът се решава не от интерфейса, а от стъпки 3, 6 и 7: качество на данните, собственик на грешките и извличане. Те продължават и след като проектният екип приключи.

Въпроси за чуждестранно дружество

При чуждестранна компания майка или при влизане в Türkiye без пълен местен финансов екип някои въпроси принадлежат на данъчен съветник, не на IT проекта:

Регистрация. Как дружеството става обект на задълженията, кой подписва заявленията и кой представител се признава? Това са данъчни, не софтуерни въпроси.

Финансов печат. Как се получава mali mühür и как се организира съхранението му, когато подписващите са извън Türkiye.

Представители и подписи. Кой има право да подписва даден документ и какво трябва да записва ERP за подписващия в одитната следа.

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

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

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

Често срещани проблеми

Отказ при валидиране. Почти винаги е проблем със съпоставянето: данъчен код, формат на идентификатор или поле на реда. Поправете основните данни, не логиката за повторно изпращане.
Дублирана номерация. Повече от една система създава номера или ги генерира повторно след отказ. Номерацията има един собственик и документирано правило за възстановяване.
Грешен статус на контрагента. Издава се грешен тип документ заради кеширан или предполагаем статус. Проверявайте статуса по правилата на интегратора, не по памет.
Изгубени входящи документи. Документите са получени, но не се връщат в ERP и доставчиците се обработват в отделен екран. Посоката на обмена е част от интеграцията.
Пропусната промяна в схемата. Структурата се променя; отговорникът трябва да знае кога и как промяната влияе на съпоставянето.
Пропуснат тест заради срок. Всеки от горните проблеми е по-евтин в тестова среда. Натискът за пускане ги превръща в инциденти.

Често задавани въпроси

Каква е разликата между e-Fatura и e-Arşiv?

e-Fatura обхваща фактури между данъкоплатци, регистрирани в режима, като структурирани документи между регистрирани страни. e-Arşiv обхваща купувач извън режима — retail, B2C и някои B2B случаи — и купувачът обикновено получава PDF от същата официална верига. Приложимият вид следва статуса на контрагента, затова интеграцията трябва да го проверява.

Нужен ли е частен интегратор?

За повечето фирми да. Това е обичайният маршрут, а директният канал е сложен и рядък. Частният интегратор осигурява техническия канал до GİB и съхранението, но задълженията на данъкоплатеца остават ваши. Сравнете API, sandbox, поддръжката и обработката на промените в схемата, а не само марката.

Какво представлява финансовият печат (mali mühür)?

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

Може ли всяка ERP система да издава турски e-invoices?

Не. ERP трябва да генерира правилната UBL-TR структура с коректни основни данни или да се свърже с двигател/интегратор, който го прави. Стандартният изглед на фактура не е достатъчен. Попитайте доставчика кои интегратори поддържа конекторът, какво съпоставя и къде е документацията.

Как се тества преди пускане?

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

Кой съхранява фактурите?

Данъкоплатецът остава отговорен за съхранението по Tax Procedure Law. Интеграторът обикновено предоставя технически архив, а много фирми пазят документите и в ERP за ежедневна работа. Решете схемата преди пускане, определете кой може да представи документ в срока за съхранение и тествайте извличането преди одитор да го поиска.

Източници и стандарти

GİB — Gelir İdaresi Başkanlığı публикува правилата, комюникетата и техническата документация за e-Fatura, e-Arşiv, e-İrsaliye и e-Defter. Актуалните версии там имат предимство пред това резюме.
Регистрационният статус, праговете, секторите и сроковете се определят от властите и се променят. Потвърдете ги със счетоводител или данъчен съветник по действащите правила. Страницата не е данъчен съвет и не твърди партньорство, интегратор или сертификат за WorldwideTradeX.

Свързани страници

Разработка на софтуер · Odoo ERP за търговски компании · ERP по поръчка или готов продукт · IT одит и консултации · Поискайте оферта