Implementação do Belgium Peppol B2B E-Invoicing Compliance no Odoo: um caso do início ao fim

A empresa do caso e o que pretende

Exemplo Caso ilustrativo: a empresa e os seus dados são inventados para explicar o fluxo.

A Distribuciones Kessel SRL é uma empresa inventada que vende material de escritório a outras empresas na Bélgica e fatura a partir do Odoo 18. Acabou de instalar o Belgium Peppol B2B E-Invoicing Compliance e quer enviar as suas faturas por Peppol sem perder de vista o que saiu, o que chegou e o que falhou. A responsável administrativa, Marta, dedica a primeira semana a pôr tudo em ordem. O que se segue é o que ela faz e o que vai vendo em cada lista.

Primeiro dia: o perfil de conformidade da empresa

A Marta começa por Compliance Profiles, dentro da Faturação. Na animação mais abaixo, com dados de demonstração, vê-se um perfil da empresa Acme Belgium SPRL com o seu ID Peppol, o estado Completed, o modo Test / SMK e a caixa de saída assinalada.

Entre os estados que o módulo define há um campo state com os valores Draft, In Progress e Completed. O módulo tem ainda campos de estado por passo, de step_1_state a step_7_state, e cada um pode estar em Not Started, In Progress ou Completed. A Marta aponta estes nomes para os reconhecer quando aparecerem e não dá a implementação por concluída enquanto vir passos em Not Started ou In Progress.

Segundo dia: os IDs Peppol dos clientes

Antes de enviar o que quer que seja, a Marta verifica a quem vai enviar. O módulo guarda um peppol_id_status com estes valores: Not Yet Resolved, Resolved, Not Found, Non-Belgian Scheme e Lookup Failed. Existe também um inbound_endpoint_status com Unknown, Resolvable e Not Resolvable.

O critério dela é simples: os clientes em Resolved avançam; os que aparecem em Not Found, Lookup Failed ou Non-Belgian Scheme revê-os um a um antes de lhes faturar por Peppol, e os que continuam em Not Yet Resolved ficam pendentes. As etiquetas são literais do módulo e convém lê-las tal como estão, sem as traduzir mentalmente para outra coisa.

Terceiro dia: as regras de validação antes da primeira fatura

Em Invoicing › Belgium Peppol › Validation Rules a Marta encontra a lista de regras. As colunas são Rule Name, Rule Code, Severity, FR Reference e Active. Na lista, quase todas bloqueiam a transmissão e uma é apenas um aviso, por isso ela sabe que regras vão travar uma fatura e qual apenas a vai avisar.

Não mexe na coluna Active sem saber o que faz cada regra. Se uma fatura não passar, o texto exato do aviso está explicado em as mensagens de erro e avisos do módulo.

A primeira semana: ler o Transmission Log

Com as primeiras faturas enviadas, a lista que a Marta abre todas as manhãs é o Transmission Log. Aí vê a referência da fatura, a direção, o ID Peppol do destinatário, a data de transmissão e o estado.

O campo status pode assumir estes valores: Draft / Validation, Sent, Delivered, Acknowledged, Failed, Received e Manual. Há ainda um transmission_status com Sent, Delivered e Failed. A rotina da Marta na primeira semana:

• Filtra por Failed e não fecha o dia com nenhum por verificar.
• Revê os que continuam em Draft / Validation.
• Abre os que estão em Manual e verifica cada um.
• Confirma que os documentos recebidos aparecem como Received.

Outros estados que a Marta aprende a reconhecer

O módulo usa mais dois conjuntos de estados. Um com New, Acknowledged, Resolved e Dismissed, e outro com Open, Resolved e Past Deadline. A regra que a Marta impõe a si própria é não deixar nada em New no fim da semana e tratar qualquer Past Deadline como prioridade.

Encontra também um registo com os campos company_id (Company), field_name (Field Name), old_value (Old Value), new_value (New Value), user_id (User), timestamp (Timestamp) e notes (Notes). A Marta fixa os nomes das colunas para os ler quando precisar e usa Notes para deixar os seus comentários.

Arquivo e pacotes de evidências

Em Archive Scans cada registo mostra a data da análise, o resultado Pass ou Fail, o total de ficheiros e colunas de ficheiros em falta e alterados. A Marta repara em qualquer Fail e nessas duas últimas colunas.

Em Invoicing › Evidence Packs está a lista de pacotes de evidências, com o botão New e a coluna Pack Name.

O módulo define os estados Draft, Generating, Done e Error para um campo state, e Draft, Running, Done e Partial Success para outro. A Marta não dá por terminado nada que esteja em Error ou Partial Success.

A lista 2028 Readiness

Por fim, abre Invoicing › 2028 Readiness. É uma lista com código, título, estado de preparação, tipo e responsável. O estado de preparação assume os valores Ready, Partial e Gap.

A primeira coisa que faz é atribuir um responsável a cada elemento, porque na lista aparecem vazios.

O que aprender com o caso

• Revê o perfil de conformidade antes de tudo e aprende os estados por passo.
• Consulta o peppol_id_status dos clientes antes de enviar, não depois.
• Lê as regras de validação para saber quais bloqueiam e qual apenas avisa.
• Na primeira semana, o Transmission Log filtrado por Failed é a tua lista diária.
• Atribui responsáveis em 2028 Readiness desde o primeiro dia.

Se quiseres ver como encaixam menus e registos por dentro, tens como funciona o módulo no Odoo.

Como a FlexigoTech te ajuda

A FlexigoTech implementa Odoo 17, 18, 19 e 20 e desenvolve conectores e integrações à medida, por isso podemos acompanhar-te nesta implementação ou adaptar o fluxo à tua empresa. Na Odoo Apps, o módulo custa 9 € por versão do Odoo (17, 18, 19 e 20), pagamento único e sem IVA; cada versão do Odoo compra-se aí em separado. O serviço local custa 29 €/mês ou 290 €/ano sem IVA (Pro: 58 €/mês ou 580 €/ano), e com a subscrição o módulo para as novas versões do Odoo está incluído se o compraste em flexigotech.com. Sem subscrição, ou com o serviço suspenso, para o que a subscrição proporciona, mas os dados ficam no teu Odoo; tens os detalhes em a página do módulo e em a ficha da Odoo Apps.

Continue a ler