Campo CEP na unit ACBrDFeComum.RetConsCad deveria ser um String e não Integer

[joao vitor bogo]

Bom dia, na unit ACBrDFeComum.RetConsCad existe a propriedade 'CEP' como um Integer, mas na verdade deveria ser uma String (pois existem CEPs com zero à esquerda)

Exemplo do problema que está acontecendo:
ObterConteudoTag(AuxNode.Childrens.FindAnyNs('CEP'), tcInt) me retorna 7094000

O ideal seria ser uma String e fazer a chamada ObterConteudoTag(AuxNode.Childrens.FindAnyNs('CEP'), tcStr) para retornar '07094000'

Eu publiquei essa dúvida no Discord porém me foi dado a seguinte resposta:

 

Ao meu ver isso não faz sentido pois ao definir um campo que contém números com 7 a 8 dígitos, é importante considerar sua natureza e propósito. Se o valor pode começar com zero — como acontece frequentemente com códigos, identificadores ou CEPs — o campo deve ser armazenado como uma string, e não como um integer.

Quando armazenado como integer, o zero à esquerda é removido automaticamente, comprometendo a integridade dos dados. Por exemplo, o código 01234567 se tornaria 1234567, alterando significativamente sua representação.

Além disso, esse campo não se destina a operações matemáticas, mas sim à identificação ou classificação, o que reforça o uso de string. Assim, garantindo consistência e clareza no armazenamento desses valores.

Essa mesma lógica se aplica ao CPF ou CNPJ, que podem começar com o dígito zero e, por esse motivo, é corretamente armazenado como string (mesmo que na NT esteja como Númerico), preservando sua estrutura original.

[Juliomar Marchetti]

No caso ele trata como numero já no manual então e seguido ele.

mas também pensando numerico se forma da direita pra esquerda portanto os demais espaços são zeros.

[joao vitor bogo]

Agora, Juliomar Marchetti disse:

No caso ele trata como numero já no manual então e seguido ele.

mas também pensando numerico se forma da direita pra esquerda portanto os demais espaços são zeros.

Eu ainda não vejo sentido esse argumento, pois no mesmo bloco do manual os campos CPF e CNPJ também são numéricos e variam de 3-14 e 3-11, porém ainda sim devido à natureza deles que permite começar com zero, eles são tratados como String em vez de Integer

[Juliomar Marchetti]

15 minutos atrás, joao vitor bogo disse:

Eu ainda não vejo sentido esse argumento, pois no mesmo bloco do manual os campos CPF e CNPJ também são numéricos e variam de 3-14 e 3-11, porém ainda sim devido à natureza deles que permite começar com zero, eles são tratados como String em vez de Integer

No caso é seguido o manual. está como inteiro e está tratando como inteiro

[joao vitor bogo]

11 minutos atrás, Juliomar Marchetti disse:

No caso é seguido o manual. está como inteiro e está tratando como inteiro

Qual manual seria esse? pois na Nota Técnica onde descreve tanto o campo do CEP quanto o CPF/CNPJ, os 3 estão descritos da mesma maneira

[BigWings]

20 minutos atrás, joao vitor bogo disse:

Qual manual seria esse? pois na Nota Técnica onde descreve tanto o campo do CEP quanto o CPF/CNPJ, os 3 estão descritos da mesma maneira

Realmente, lendo os fontes, no caso do CPF e CNPJ foi adicionado o tratamento pra adicionar os zeros a esquerda, tem um comentário explicitando isso.

E para o CEP está seguindo o manual/NT.

Se quiser faça a alteração aí, e anexe aqui os fontes alterados, que será analisado.

[joao vitor bogo]

Aqui está a modificação que eu fiz, alterei de Integer para String.

ACBrDFeComum.RetConsCad.pas

[joao vitor bogo]

deixando um up aqui só pro tópico não cair no esquecimento

[Juliomar Marchetti]

pronto, agora não precisa de UP

#TK-6806 

tarefa para analise

[Italo Giurizzato Junior]

Bom dia @joao vitor bogo,

Já esta no SVN.