verProc na NF-e: versão do aplicativo e limite de 20 caracteres

O verProc registra a versão do aplicativo utilizado no processo de emissão da NF-e ou NFC-e. É um campo obrigatório de ide, com 1 a 20 caracteres. Seu valor vem do emissor que gerou o documento; não existe um número universal a copiar do MOC para todas as notas. MOC, B27 Schema de verProc

Versão do aplicativo que gerou o documento

A finalidade é identificar tecnicamente a versão do emissor. Em uma investigação, esse texto pode ser correlacionado com a release instalada, o momento da geração e os registros da aplicação.

Se um sistema usa uma identificação como “EmissorDemo 2.7.1”, ela pode expressar a versão adotada por aquele aplicativo. O exemplo não significa que esse seja o nome ou a versão real do Fiscal Pro. A integração deve obter a identificação do próprio emissor, mantendo-a coerente com a versão que produziu o XML.

O campo não informa número da nota, protocolo de autorização, versão tributária ou nome do responsável fiscal. Definição do B27

Formato e espaços no schema

O schema consultado restringe o tipo TString e determina:

A expressão de TString é [!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}. Não há uma exigência de versão semântica como “1.2.3”, nem obrigação de conter apenas números. Ao mesmo tempo, não se deve pressupor que qualquer caractere Unicode esteja nesse intervalo. Tipo TString do pacote oficial consultado Restrições locais de verProc

A contagem diz respeito ao conteúdo textual, não ao tamanho em bytes do arquivo. Se o texto contiver um caractere reservado do XML, como &, ele precisa ser representado com o escape XML correspondente, &; o conteúdo resultante continua sendo o caractere “&”. Não adicione uma sequência de escape ao nome da versão como se fosse texto literal do aplicativo.

Quatro versões e códigos que não se substituem

O nome do pacote de schema, por exemplo PL_010d v1.03, também é outra identificação: organiza os arquivos XSD utilizados na integração. Ele não se torna automaticamente o valor de verProc. MOC, B26/B27 MOC Visão Geral, pp.72 e 76

Um aplicativo pode manter o leiaute 4.00 e ter várias releases próprias. Também pode mudar a versão do autorizador sem que o emissor tenha sido atualizado. Por isso, comparar números sem identificar a origem de cada campo pode levar a uma conclusão errada sobre o software que gerou a nota.

Exemplo parcial

Este recorte é sintético e mostra somente a relação entre processo e versão do aplicativo:

<ide xmlns="http://www.portalfiscal.inf.br/nfe">
  <!-- Os demais campos de identificação foram omitidos. -->
  <procEmi>0</procEmi>
  <verProc>EmissorDemo 2.7.1</verProc>
</ide>

procEmi=0 indica aplicativo do contribuinte. O texto ilustrativo em verProc tem 17 caracteres, cabe no limite e não tem espaço nas pontas. O recorte não representa uma nota completa ou pronta para transmissão, nem comprova que uma aplicação real está atualizada.

Rastreabilidade e diagnóstico

Para um problema de schema, examine o elemento original: existe exatamente uma vez, está vazio, excede 20 caracteres, contém espaços nas pontas ou caracteres fora do tipo? Use a mensagem real do validador e o pacote XSD aplicável; a fonte não define uma rejeição exclusiva de verProc que possa ser atribuída a todo erro de versão. Leiaute e tipo de verProc

Para investigar comportamento do emissor, compare o verProc do XML gerado com a versão instalada na ocasião, os registros de geração e a release esperada. A versão atual exibida pelo sistema pode ser posterior àquela que produziu um documento antigo. Um texto correto em verProc não comprova, por si só, que a aplicação implementou determinada nota técnica.

Se o retorno aponta uma regra fiscal de outro campo, verProc ajuda a rastrear a implementação, mas não corrige a causa. Preserve o XML e o retorno originais, identifique a regra e sua data de implantação e confira o dado efetivamente produzido por aquela versão. Não altere verProc num XML assinado para aparentar uma release diferente. O campo não decide CFOP, CST, regime ou tributação.