Съдържание8
Накратко
- Първата валидна тестова фактура се очаква два работни дни, след като и седемте точки са налице, а не след подписването.
- Повечето точки са при Вашия екип. Интеграцията на маршрута е при нас.
- Присъединяването, упълномощаването и Вашият приемателен тест текат по собствен график.
Целта ни е първа валидна тестова фактура в рамките на два работни дни. Хората чуват това и питат кога започват двата дни. Честният отговор е: когато седем неща са налице. Този чеклист за електронно фактуриране съдържа именно тези седем неща. Докато не са налице, никой не може да обещае дата, включително ние, защото работата, която отнема време, чака нещо, което само Вие можете да осигурите.
Тази бележка минава през седемте точки: защо всяка е важна, кой отговаря за нея и къде проектите обикновено засядат. Отмятайте ги по-долу, докато четете. Срокът започва да тече, когато и седемте са отметнати.
0 / 7 налице. Срокът още не е започнал.
Защо срокът започва с готовността
Подписът ни казва, че искате работата да бъде свършена. Той не ни дава фактурите, достъпа или решенията, от които работата се нуждае. Ако започнем да броим от деня на подписването, двата дни ще отидат в чакане на експорт или на тестов вход, и целта няма да означава нищо.
Затова целта е обвързана с готовността. Готовността е кратък списък, един и същ за всеки маршрут, и всяка точка има един отговорник. Когато пристигне последната точка, имаме всичко нужно, за да съпоставим, валидираме и изпратим тестова фактура, и спазването на двата работни дни е наша отговорност. В речника същият списък се нарича пакет за готовност (readiness package).
Така се говори лесно и за забавянията. Ако тестовата фактура закъснява, въпросът не е „кой е бавен?“, а „коя точка липсва и кой отговаря за нея?“. И двете страни виждат отговора.
Чеклист за електронно фактуриране, точка по точка
1. Представителен набор от фактури
Нуждаем се от реални фактури от Вашата ERP система, които покриват всеки вариант в обхвата: стандартни фактури, кредитни известия и необичайните случаи, като редове с обратно начисляване, фактури в чуждестранна валута или фактури, които посочват поръчка. Съпоставянето се изгражда от тях. Вариант, който никога не виждаме, е вариант, който не можем да тестваме.
Отговорник: Вашият екип. Обичайният пропуск е набор, в който са само лесните случаи.
2. Работещ достъп до източника
Четем данните за фактурите там, където Вашата ERP система ги създава. Това може да е работещ достъп до изходната система или стабилно предаване: един и същ файл или едно и също API извикване всеки път, с тестови данни в него. Еднократна таблица, направена на ръка, не се брои, защото в реалната среда данните няма да изглеждат така.
Отговорник: Вашият екип. Обичайният пропуск е експорт, който все още се променя от седмица на седмица.
3. Тестови данни за достъп, сертификати и упълномощаване от данъкоплатеца, издадени на Вас
Всеки маршрут има свой начин да допусне една фирма: токен, сертификат, упълномощаване в данъчен портал, акаунт при точка за достъп или платформа. Те се издават на Вашата фирма, на Ваше име, в маршрута, който сте избрали.
Отговорник: Вашият екип. Обичайният пропуск е заявка, която все още стои при платформата.
4. Избраният маршрут с активна тестова среда
Маршрутът е пътят, по който Вашата фактура стига до купувача в една държава: Peppol, френска платформа, KSeF, RO e-Factura и т.н. Вие го избирате и тестовата му среда трябва да бъде включена за Вашата фирма. Ние го свързваме.
Отговорник: Вие избирате, ние свързваме. Обичайният пропуск е тестова среда, която съществува на хартия, но още не е активна.
5. Технически отговорник от Ваша страна, на разположение през периода
Някой от Ваша страна трябва да отговаря на въпроси, докато работим: откъде идва дадено поле, защо даден код изглежда така, дали може да се изпрати тестова фактура. Два работни дни не издържат тридневно чакане на отговор.
Отговорник: Вашият екип. Обичайният пропуск е име без отделено време.
6. Писмени решения за данъчните кодове, освобождаванията, данните за плащане и идентификаторите
Някои въпроси не са технически. Коя категория ДДС се прилага за този ред? Кое основание за освобождаване се посочва на онзи? Кой идентификатор използваме за продавача и за купувача? Това са данъчни решения и те принадлежат на Вас и на Вашия счетоводител. Нужни са ни писмено, за да следва съпоставянето Вашите решения, а не нашите предположения.
Отговорник: Вашият екип заедно с Вашия счетоводител. Обичайният пропуск е решение, взето на среща и така и не записано.
7. URL адрес на webhook за върнатия статус
Всеки маршрут отговаря различно. Превръщаме всеки отговор в едно събитие, което Вашата ERP система може да прочете, като запазваме и собствения код на маршрута. За това ни трябва място, където да го изпращаме: URL адрес на webhook от Ваша страна или договорка, че ще четете статуса през API.
Отговорник: Вашият екип. Обичайният пропуск е URL адрес, който все още никой от страната на ERP системата не следи.
Какво се случва през двата работни дни
Щом пристигне седмата точка, работата върви в определен ред. Изграждаме съпоставянето от Вашите фактури към EN 16931 [1] и формата на държавата, проверяваме всеки вариант спрямо официалните правила и изпращаме фактури през тестовата среда на маршрута. Статусът се връща при Вас така, както ще се връща в реалната среда. Натиснете „Пусни“, за да проследите една фактура по пътя ѝ.
Статусът се връща чрез webhook или API: приета, отхвърлена с код или отказана от купувача.
Експорт от ERPДанни от ERP
Вашата ERP система създава данните за фактурата: отчет, файл или API извикване.
Какво може да се объркаОт експорта липсва поле, например ДДС номерът на купувача.
Целта е първа валидна тестова фактура в рамките на тези два работни дни. Валидна тестова фактура е тази, която тестовата среда на маршрута приема. Тя е първото доказателство, че Вашите данни, нашето съпоставяне и маршрутът си съответстват.
Къде попадат седемте точки в шестте стъпки
Списъкът за готовност не е отделен процес. Той е онази част от нашите шест стъпки, която само Вие можете да започнете. Ето как се разпределя работата, след като обхватът е подписан:
| Стъпка | Какво правите Вие | Какво правим ние |
|---|---|---|
| Обхват | Представяте казуса и данните на юридическото лице | Проверяваме го спрямо стандартния пакет |
| Съпоставяне | Давате достъп и представителни фактури | Изграждаме таблицата за съпоставяне |
| Валидиране | Решавате данъчните кодове и идентификаторите | Прилагаме наборите от правила и поправяме съпоставянето |
| Тест | Осигурявате тестовите данни за достъп | Изпращаме, потвърждаваме и съпоставяме статуса |
| Пускане в експлоатация | Провеждате приемателния тест и давате одобрение | Наблюдаваме първите реални фактури |
| Наблюдение | Поправяте данните при източника, когато Ви помолим | Първичен преглед, поправки в съпоставянето и месечният отчет |
Точки 1, 2 и 6 захранват стъпките за съпоставяне и валидиране. Точки 3, 4 и 7 захранват стъпката за тест. Точка 5, техническият отговорник, поддържа всички тях в движение.
Какво означават точки 3 и 4 при три маршрута
Думите в списъка са едни и същи навсякъде, но работата зад тях зависи от маршрута: токен за KSeF в Полша [2], Peppol ID в Белгия, регистрация при Plateforme Agréée във Франция [3].
KSeFPL
- Точка 3: достъп, издаден на Вас
- Токен или сертификат за KSeF с право за издаване на фактури за Вашия NIP
- Точка 4: тестовата среда
- Тестовата среда на KSeF
- Внимавайте за
- Токен без правото InvoiceWrite не може да отвори сесия за изпращане, така че KSeF изобщо не вижда фактурата
PeppolBE
- Точка 3: достъп, издаден на Вас
- Акаунт при сертифицирана точка за достъп и Peppol ID, под който е регистрирана Вашата фирма
- Точка 4: тестовата среда
- Тестовата настройка на Вашата точка за достъп
- Внимавайте за
- Без Вашия Peppol ID като електронен адрес на продавача правило на Peppol отхвърля фактурата
Plateforme AgrééeFR
- Точка 3: достъп, издаден на Вас
- Регистрацията Ви при платформата, с активен SIREN в националния указател
- Точка 4: тестовата среда
- Тестовата среда на платформата, отделна от реалната
- Внимавайте за
- Тестовата и реалната среда са отделни: настройката в едната не е настройка в другата
Два от трите проблема спират теста, преди който и да е купувач да го види. KSeF няма да отвори сесия за изпращане за токен без правото InvoiceWrite [4], а в Peppol правилото PEPPOL-EN16931-R020 отхвърля фактурата, преди тя да излезе [5]. Затова и двете точки са в списъка за готовност, преди срокът да започне, а не в рамките на двата работни дни.
Във Франция националният указател работи в двете посоки. Фирма, която не е избрала платформа за получаване, липсва в него и фактурите, адресирани до тази фирма, не могат да бъдат доставени [6].
Какво не покрива срокът
Някои стъпки са извън двата дни, защото никоя от страните не ги контролира. Фигурата показва къде стоят спрямо срока.
- Срокът започва: и седемте точки са налице
- Първа валидна тестова фактура
- Присъединяване към платформата и KYC
- Упълномощаване от данъкоплатеца за реалната среда
- Трети страни, например доставчик на ERP, който променя експорт
- Присъединяването към платформата и KYC, които точката за достъп или платформата провежда със собствено темпо.
- Упълномощаването от данъкоплатеца за реалната среда, което дава данъчната администрация.
- Вашият приемателен тест, който Вашият екип провежда и одобрява.
- Наличността на трети страни, например доставчик на ERP система, който трябва да промени експорт.
Нито едно от тях не е причина да чакате, преди да започнете седемте точки. Повечето могат да текат успоредно с готовността, а ранното им започване е най-добрият начин целият проект да остане кратък.
Част от работата е извън самия стандартен пакет. Повече юридически лица или държави, входящи потоци, електронно отчитане, архивиране, работа по интерфейса на ERP системата и таксите на платформите се оферират отделно. Когато това е ясно от самото начало, двудневната цел остава насочена към едно нещо: първата валидна тестова фактура.
Когато липсва точка
Това се случва в повечето проекти и е нормално. Когато липсва точка, казваме коя е, кой отговаря за нея и какво точно е нужно. Срокът чака. Не се губи нищо освен време, а списъкът за готовност показва къде отива времето.
Съобщение от нас за липсваща точка изглежда така: „Точка 3 все още е отворена. Платформата още не е активирала Вашия тестов акаунт. Отговорник: Вашият екип. Щом бъде активиран, изпратете ни идентификатора на акаунта и срокът може да започне.“ Кратко, конкретно и с един отговорник.
Ако се окаже, че липсващата точка е от наша страна, например интеграцията на маршрута, казваме го по същия начин. Списъкът важи и за двете страни и е един и същ, независимо дали купувате директно от нас или чрез Вашия ERP партньор.
Чеклист, който да изпратите на екипа си
Копирайте това в имейл до човека, който отговаря за ERP системата:
- Представителен набор от анонимизирани фактури, всеки вариант в обхвата.
- Достъп до източника или стабилно предаване на файл или чрез API с тестови данни.
- Тестови данни за достъп, сертификати и упълномощаване от данъкоплатеца за избрания маршрут, издадени на Вашата фирма.
- Избраният маршрут с активна тестова среда.
- Един технически отговорник с отделено време през периода.
- Писмени решения за данъчните кодове, освобождаванията, данните за плащане и идентификаторите.
- URL адрес на webhook за върнатия статус.
Когато и седемте са готови, кажете ни и двата работни дни започват.
Въпроси
Започва ли срокът да тече в деня на подписването?
Не. Започва, когато и седемте точки са налице, а първата валидна тестова фактура се очаква два работни дни по-късно.
Кой издава тестовите данни за достъп?
Платформата или мрежата ги издава на Вашата фирма. Ако изпращаме от Ваше име, ги съхраняваме криптирани, никога не ги показваме обратно и можете да ги оттеглите.
Какво не покрива срокът?
Присъединяването към платформата и KYC, упълномощаването от данъкоплатеца, Вашия приемателен тест и наличността на трети страни.
Източници
- Директива 2014/55/ЕС относно електронното фактуриране (EUR-Lex)eur-lex.europa.eu
- KSeF: подкрепа за интегратори, тестова и Demo среда (Министерство на финансите)ksef.podatki.gov.pl
- Facturation électronique et plateformes agréées (DGFiP)impots.gouv.fr
- KSeF 2.0 API: отварянето на сесия изисква InvoiceWrite (Министерство на финансите)api.ksef.mf.gov.pl
- Peppol BIS Billing 3.0, правило PEPPOL-EN16931-R020docs.peppol.eu
- Tout savoir sur la facturation électronique, FAQ: националният указател (DGFiP)impots.gouv.fr
Налично и на: Čeština · Dansk · Deutsch · Ελληνικά · English · Español · Eesti · Suomi · Français · Gaeilge · Hrvatski · Magyar · Italiano · Lietuvių · Latviešu · Malti · Nederlands · Polski · Português · Română · Slovenčina · Slovenščina · Svenska