Español
English
Català
Deutsch
Français
Italiano
Nederlands
PolskiA tabela
| Versão do Odoo | Envio para o KSeF | De onde vem o FA(3) validado | Revalidação na nuvem |
|---|---|---|---|
| 17 | Sem módulo nativo: envia-se fora do Odoo | Carregado já feito, gerado noutro sítio | Sem envio nativo para revalidar |
| 18 | l10n_pl_edi | O que o l10n_pl_edi gera ou enviou | Sim, a cada hora |
| 19 | l10n_pl_edi, com certificado KSeF na empresa | O que o l10n_pl_edi gera ou enviou | Sim, a cada hora |
| 20 | l10n_pl_edi | O que o l10n_pl_edi gera ou enviou | Sim, a cada hora |
O módulo da FlexigoTech está publicado para as quatro versões. Em nenhuma delas envia para o KSeF: valida e prepara.
Se está no Odoo 17
Na 17 não há envio nativo, por isso o fluxo tem mais um passo: a fatura emite-se no Odoo, o FA(3) gera-se com outra ferramenta e carrega-se na fatura para ser validado. O validador de migração, em Migration › Run Validator, ajuda a encontrar as lacunas nos seus dados mestre antes de dar o salto.
É uma boa razão para planear a mudança de versão: a partir da 18, a validação trabalha sobre o que o Odoo gera, sem ficheiros para mover à mão.
Uma nota prática: a versão do módulo não muda o que se valida. Os campos FA(3), os códigos de erro e a política legal são os mesmos nos quatro ramos, por isso uma empresa com duas bases de dados em versões diferentes vê os mesmos avisos em ambas.
Se está na 18, 19 ou 20
O fluxo é direto. O l10n_pl_edi gera e envia o FA(3), e o módulo valida-o no FlexigoTech Cloud com um relatório assinado. O que já foi enviado volta a ser validado a cada hora, e cada fatura mostra o seu estado: válida, não válida, não validada ou expirada.
Na 19 verificámos no código do Odoo que a autenticação nativa usa um certificado KSeF guardado na empresa e renova os tokens com uma ação agendada.
O validador de migração, em qualquer versão
Se vem de outro programa ou de uma versão anterior, o validador de migração revê os seus dados antes de começar a emitir no KSeF. Lança-se em Migration › Run Validator e cada execução fica em Validation Runs, para poder comparar umas com as outras. O útil é executá-lo duas vezes: uma no início, para ver a lista de lacunas, e outra mesmo antes da mudança, para confirmar que não resta nenhuma. E Operations › Compliance Export extrai o que foi validado quando o seu contabilista o pedir.
O que compra em cada caso
O mesmo nas quatro versões: o módulo, com um pagamento único de 9 € por versão do Odoo, e o serviço local do FlexigoTech Cloud desde 29 € por mês, sem IVA, que é onde corre a validação. Se mudar de versão, depende de onde o comprou: com a subscrição, o módulo para as novas versões está incluído se o comprou em flexigotech.com; na Odoo Apps, cada versão compra-se lá.
As validações FA(3) não dependem da versão do Odoo: dependem do esquema. O que muda é quem gera o ficheiro.
Continue a ler
Verificado no código do módulo (versão 20.0) e nas fontes indicadas
Fontes
- github.com/odoo/odoo/tree/18.0/addons/l10n_pl_edi
- Código do módulo: flexigo_poland_ksef_2_0_e_invoice_connector_and_migrati (cbca26e): models/account_move.py
- Código do módulo: flexigo_poland_ksef_2_0_e_invoice_connector_and_migrati (cbca26e): models/ksef_session.py
- Código do módulo: flexigo_poland_ksef_2_0_e_invoice_connector_and_migrati (cbca26e): models/ksef_cloud.py
- github.com/odoo/odoo/blob/19.0/addons/l10n_pl_edi/models/res_company.py
- Código do módulo: flexigo_poland_ksef_2_0_e_invoice_connector_and_migrati 20.0 (ba7c60f1): data/ksef_cron.xml
- Código do módulo: flexigo_poland_ksef_2_0_e_invoice_connector_and_migrati 20.0 (ba7c60f1): views/ksef_menus.xml
- Código do módulo: flexigo_poland_ksef_2_0_e_invoice_connector_and_migrati 20.0 (ba7c60f1): models/account_move.py
- apps.odoo.com/apps/modules/20.0/flexigo_poland_ksef_2_0_e_invoice_connector_and_migrati
- Código do módulo: flexigo_poland_ksef_2_0_e_invoice_connector_and_migrati 20.0 (ba7c60f1): __manifest__.py
- flexigotech.com/precios.html