Wdrożenie Belgium Peppol B2B E-Invoicing Compliance w Odoo: przykład od początku do końca

Firma z przykładu i jej cel

Przykład Przypadek poglądowy: firma i jej dane są zmyślone, żeby pokazać przebieg.

Distribuciones Kessel SRL to fikcyjna firma, która sprzedaje artykuły biurowe innym firmom w Belgii i wystawia faktury w Odoo 18. Właśnie zainstalowała Belgium Peppol B2B E-Invoicing Compliance i chce wysyłać faktury przez Peppol, nie tracąc z oczu tego, co wyszło, co dotarło i co się nie powiodło. Kierowniczka administracji, Marta, poświęca pierwszy tydzień na uporządkowanie wszystkiego. Poniżej opisujemy, co robi i co widzi na każdej liście.

Dzień pierwszy: profil zgodności firmy

Marta zaczyna od Compliance Profiles w module Fakturowanie. Na animacji niżej, z danymi demonstracyjnymi, widać profil firmy Acme Belgium SPRL z identyfikatorem Peppol, statusem Completed, trybem Test / SMK i zaznaczonym polem wysyłki.

Wśród statusów zdefiniowanych w module jest pole state z wartościami Draft, In Progress i Completed. Moduł ma też pola statusu dla poszczególnych kroków, od step_1_state do step_7_state, a każde może mieć wartość Not Started, In Progress lub Completed. Marta zapisuje sobie te nazwy, żeby je rozpoznać, gdy się pojawią, i nie uznaje wdrożenia za zakończone, dopóki widzi kroki w Not Started lub In Progress.

Dzień drugi: identyfikatory Peppol klientów

Zanim cokolwiek wyśle, Marta sprawdza, do kogo będzie wysyłać. Moduł przechowuje peppol_id_status z wartościami: Not Yet Resolved, Resolved, Not Found, Non-Belgian Scheme i Lookup Failed. Jest też inbound_endpoint_status z wartościami Unknown, Resolvable i Not Resolvable.

Jej zasada jest prosta: klienci w Resolved przechodzą dalej; tych w Not Found, Lookup Failed lub Non-Belgian Scheme sprawdza po kolei, zanim wystawi im fakturę przez Peppol, a tych, którzy wciąż są w Not Yet Resolved, zostawia na później. Etykiety pochodzą wprost z modułu i warto czytać je dosłownie, bez tłumaczenia ich sobie w głowie na coś innego.

Dzień trzeci: reguły walidacji przed pierwszą fakturą

W Invoicing › Belgium Peppol › Validation Rules Marta znajduje listę reguł. Kolumny to Rule Name, Rule Code, Severity, FR Reference i Active. Na liście prawie wszystkie reguły blokują transmisję, a jedna jest tylko ostrzeżeniem, więc Marta wie, które reguły zatrzymają fakturę, a która jedynie ją ostrzeże.

Nie rusza kolumny Active, dopóki nie wie, co robi każda reguła. Jeśli faktura nie przejdzie, dokładna treść komunikatu jest wyjaśniona w komunikatach o błędach i ostrzeżeniach modułu.

Pierwszy tydzień: czytanie Transmission Log

Po wysłaniu pierwszych faktur listą, którą Marta otwiera każdego ranka, jest Transmission Log. Widzi tam numer faktury, kierunek, identyfikator Peppol odbiorcy, datę transmisji i status.

Pole status może przyjmować wartości: Draft / Validation, Sent, Delivered, Acknowledged, Failed, Received i Manual. Jest też transmission_status z wartościami Sent, Delivered i Failed. Rutyna Marty w pierwszym tygodniu:

• Filtruje po Failed i nie kończy dnia, zostawiając któryś bez sprawdzenia.
• Przegląda te, które wciąż są w Draft / Validation.
• Otwiera te w Manual i sprawdza każdy z nich.
• Sprawdza, czy dokumenty przychodzące mają status Received.

Inne statusy, które Marta uczy się rozpoznawać

Moduł używa jeszcze dwóch zestawów statusów. Jednego z New, Acknowledged, Resolved i Dismissed, oraz drugiego z Open, Resolved i Past Deadline. Marta przyjmuje zasadę, że na koniec tygodnia nic nie zostaje w New, a każdy Past Deadline traktuje priorytetowo.

Znajduje też rejestr z polami company_id (Company), field_name (Field Name), old_value (Old Value), new_value (New Value), user_id (User), timestamp (Timestamp) i notes (Notes). Marta zapamiętuje nazwy kolumn, żeby móc je odczytać, gdy będą potrzebne, a w Notes zostawia swoje komentarze.

Archiwum i pakiety dowodowe

W Archive Scans każdy rekord pokazuje datę skanowania, wynik Pass lub Fail, łączną liczbę plików oraz kolumny z brakującymi i zmienionymi plikami. Marta zwraca uwagę na każdy Fail i na te dwie ostatnie kolumny.

W Invoicing › Evidence Packs znajduje się lista pakietów dowodowych z przyciskiem New i kolumną Pack Name.

Moduł definiuje statusy Draft, Generating, Done i Error dla jednego pola state oraz Draft, Running, Done i Partial Success dla drugiego. Marta nie uznaje za zakończone niczego, co jest w Error lub Partial Success.

Lista 2028 Readiness

Na koniec otwiera Invoicing › 2028 Readiness. To lista z kodem, tytułem, statusem gotowości, typem i osobą odpowiedzialną. Status gotowości przyjmuje wartości Ready, Partial i Gap.

Najpierw przypisuje osobę odpowiedzialną do każdego elementu, bo na liście to pole jest puste.

Czego uczy ten przykład

• Zacznij od przeglądu profilu zgodności i poznaj statusy poszczególnych kroków.
• Sprawdzaj peppol_id_status klientów przed wysyłką, a nie po niej.
• Przeczytaj reguły walidacji, żeby wiedzieć, które blokują, a która tylko ostrzega.
• W pierwszym tygodniu Transmission Log przefiltrowany po Failed to Twoja codzienna lista.
• Przypisz osoby odpowiedzialne w 2028 Readiness od pierwszego dnia.

Jeśli chcesz zobaczyć, jak menu i rekordy łączą się od środka, przeczytaj jak działa moduł w Odoo.

Jak pomaga FlexigoTech

FlexigoTech wdraża Odoo 17, 18, 19 i 20 oraz tworzy konektory i integracje na zamówienie, więc możemy towarzyszyć Ci w tym wdrożeniu albo dopasować proces do Twojej firmy. W Odoo Apps moduł kosztuje 9 € za wersję Odoo (17, 18, 19 i 20), płatność jednorazowa, netto (bez VAT); każdą wersję Odoo kupuje się tam osobno. Usługa lokalna kosztuje 29 €/mies. lub 290 €/rok netto (bez VAT) (Pro: 58 €/mies. lub 580 €/rok), a w ramach subskrypcji moduł dla nowych wersji Odoo jest wliczony, jeśli kupiłeś go na flexigotech.com. Bez subskrypcji lub przy zawieszonej usłudze przestaje działać to, co zapewnia subskrypcja, ale dane zostają w Twoim Odoo; szczegóły znajdziesz na stronie modułu i na karcie w Odoo Apps.

Czytaj dalej