xEnder do transportador na NF-e: endereço em texto e integração

xEnder registra o endereço completo do transportador em um único campo textual. Ele fica em /nfeProc/NFe/infNFe/transp/transporta/xEnder. Não é o endereço de entrega da mercadoria, o local de retirada ou o endereço do destinatário.

A diferença afeta integrações: os endereços de emitente e destinatário usam grupos com vários filhos; transporta/xEnder é um texto. Inserir ali um bloco xLgr, nro ou xBairro cria uma estrutura que não corresponde ao campo.

Como obter e conferir a informação

A origem é o cadastro/documentação da pessoa identificada em transporta. Compare endereço, CNPJ/CPF, nome, município e UF para confirmar que a integração não misturou dados de outra pessoa.

Quando o cadastro separa logradouro, número e complemento, a geração pode precisar compor a representação textual. Essa composição deve preservar as informações reais necessárias à identificação; o leiaute não autoriza criar número inexistente ou substituir tudo pelo endereço da entrega. xMun e UF possuem filhos próprios para município e sigla e devem ser conferidos em conjunto com o texto.

O MOC X08 prevê 1 a 60 caracteres, com até uma ocorrência opcional no grupo. MOC, p.60. Isso não equivale a uma instrução para truncar automaticamente um endereço maior ou inventar abreviações que mudem sua identificação. Se o conteúdo não cabe, revise a representação com a origem preservada e confirme que ela continua identificando o mesmo endereço.

Exemplo do endereço e dos campos vizinhos

Fragmento parcial e sintético, não pronto para transmissão:

<transporta xmlns="http://www.portalfiscal.inf.br/nfe">
  <xNome>TRANSPORTADORA EXEMPLO</xNome>
  <xEnder>RUA DEMONSTRATIVA, 100, GALPAO A</xEnder>
  <xMun>Curitiba</xMun>
  <UF>PR</UF>
</transporta>

O endereço vem depois da IE, quando ela existe, e antes de município e UF. O exemplo omite documentos e inscrição para concentrar a explicação no endereço, sem estabelecer dispensa desses dados em toda operação. Não há cMun ou CEP dentro de xEnder: esse filho é apenas texto.

Caracteres especiais não são conteúdo a apagar

O campo deriva do tipo TString no PL_010c. Além do limite, o padrão não admite texto formado apenas por espaços nem espaços de preenchimento nas extremidades. Há restrições de caracteres; quebras de linha, controles e símbolos fora do tipo não devem ser confundidos com um endereço válido.

Uma vírgula que separa número e complemento no texto não é separador decimal nem problema de endereço. Para caracteres reservados de XML, a serialização deve escapar o conteúdo: se o texto contiver &, sua representação lexical é &. Usar uma biblioteca de XML evita transformar conteúdo em marcação. Não remova partes verdadeiras do endereço só porque a serialização foi inadequada.

Ausência da tag é diferente de <xEnder/>: quando o elemento é enviado, ele precisa satisfazer o mínimo de texto. A opcionalidade estrutural não comprova completude cadastral para qualquer contexto.

Diagnóstico de endereço errado ou erro de schema

Se a falha é estrutural, compare tamanho, tipo textual, espaços e ordem. Um objeto de endereço serializado como vários filhos dentro de xEnder aponta erro de mapeamento, não necessidade de alterar o cadastro do transportador.

Se o texto é válido, mas descreve o local de entrega, compare os objetos de origem da integração. Verifique se a seleção de transportador mudou sem atualizar endereço, ou se houve herança do destinatário. São hipóteses a confirmar com o XML enviado e os dados da operação.

Na NFC-e, 754/786 tratam o grupo transporta e indPres, e não a validade textual do endereço. Corrigir a rua não resolve presença do grupo fora de entrega em domicílio ou ausência do grupo na condição exigida. MOC X03-10/20, p.124.

Corrija a origem ou a serialização demonstradamente incorretas, preserve a identidade e confira o novo texto. Não troque endereço para obter autorização nem edite XML assinado. Veja município do transportador e transporta para a conferência contextual.