Porque derruba o envio inteiro
O documento de validações da AEAT distingue três tipos de verificação: estruturais, sintáticas e de negócio. As estruturais verificam que o XML cumpre o esquema, com as suas etiquetas obrigatórias, e se falharem a rejeição é de toda a mensagem. Essa rejeição chega como um SoapFault e não fica registada nenhuma fatura do pedido, nem sequer as que estavam corretas.
O texto da lista oficial diz exatamente: «El XML no cumple el esquema. Falta informar campo obligatorio.» Está no primeiro apartado, o dos códigos que rejeitam o envio completo.

O que faz o módulo para que não chegue
Um único registo mal formado arrastaria todos os outros do mesmo envio. Para o evitar, o módulo valida cada registo contra o esquema oficial da AEAT antes de o enviar. Traz dentro uma cópia desse esquema, o ficheiro SuministroLR.xsd com as suas dependências, e o percurso é este:
- Ao publicar a fatura Cria-se o seu registo de faturação, que já não muda.
- Na seguinte passagem da fila Cada registo pendente converte-se em XML e valida-se contra o esquema.
- Se um registo não cumprir Fica marcado como rejeitado no Odoo com a mensagem do esquema, sem código da AEAT, e não sai.
- O resto Segue para a AEAT no mesmo pedido, sem o registo defeituoso.
Assim, um registo defeituoso não arrasta consigo as faturas boas que viajam com ele.
Como o vai ver no Odoo
Na fila de envio, o registo parado aparece em Failed com a mensagem do validador no último erro, em vez de um código de quatro algarismos. Essa mensagem indica o elemento que falta ou que sobra, que é precisamente o que precisa para saber de onde vem. Na lista de registos de faturação, o seu estado é «Rechazado AEAT», embora a AEAT nunca o tenha visto.

Antes mesmo do esquema, há dados sem os quais o módulo nem sequer constrói o XML, e avisa-o com a sua própria mensagem:
Company … has no NIF for Veri*Factu.quando a empresa não tem NIF.Record … has no tax breakdown (Desglose) to declare.quando o registo não tem discriminação de impostos.
Se o 4102 vier da AEAT
Se a resposta com o 4102 vier da própria AEAT, o registo passou a validação local e a AEAT rejeitou-o com o seu esquema. A explicação razoável é que o esquema da AEAT e a cópia que o módulo traz já não coincidem. Nesse caso, reenviar não serve de nada: escreva para comercial@flexigobe.com com a resposta completa, o campo Raw Response da fila, para revisarmos a cópia do esquema.
Posso corrigir o dado e tentar de novo?
Depende de onde está o dado. O cabeçalho monta-se em cada envio com os dados da empresa desse momento: se a falha estava no nome, corrija-o e use Reintentar Selección em Errores AEAT. Se estava no NIF, corrigi-lo não basta, porque o NIF também entrou na impressão digital de cada fatura ao publicá-la e o reenvio volta com o 2000. Se o dado está no registo da fatura, a nova tentativa envia o mesmo e voltará a falhar. Nesses dois casos, escreva-nos.
Perde-se a fatura?
Não. O registo continua no Odoo, encadeado, e a fila processa o pendente a cada 1 minuto assim que o problema estiver resolvido.
Continue a ler
Verificado no código do módulo (versão 20.0) e nas fontes indicadas
Fontes
- www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validacione
- Código do módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_aeat_client.py
- Código do módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): data/verifactu_crons.xml
- Código do módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cola_envio.py
- Código do módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_registro.py
- prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/err
- Código do módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cadena.py
