COD_BARRA - SEM GTIN
Closed this issue · 17 comments
No bloco 0, registro 0200, há uma regex com
'regex' => '^[0-9]{8,14}$',
porém estou testando alguns arquivos e alguns deles possuem o valor "SEM GTIN" nesse campo, e alguns outros possuem um hífen.
devemos adicionar esses valores nessa fórmula?
Guilherme, temos que dar uma lida no manual do EFD para confirmar isso, se coloca "SEM GTIN" ou deixa "NULL" (sem essa informação)
Roberto, pela documentação diz que não deve ser preenchido
Campo 04 (COD_BARRA) - Preenchimento: informar o código GTIN-8, GTIN-12, GTIN-13 ou GTIN-14 (antigos códigos
EAN, UPC e DUN-14). Não informar o conteúdo do campo se o produto não possui este código.
Como disse estou trabalhando com alguns arquivos que possuem esse valor, acha que é válido criar uma opção que permite ou não validar os dados?
Digo isso pois encontrei no registro D500 a 'regex' => '^([0-1]{1})([0-9]{1,8})?$', porém na documentação diz:
Campo 09 (NUM_DOC) - Validação: o valor informado no campo deve ser maior que “0” (zero).
E nos arquivos que eu estou usando tem os valores: 77611 e 188391 como exemplo.
Esses arquivos foram assinados.
campo SER que tem que ter 3 posições
Campo 07 (SER) – Validação: campo de preenchimento obrigatório com três posições para CT-e e CT-e OS, COD_MOD iguais a “57” e “67”, respectivamente, de emissão própria ou de terceiros. Se não existir Série para CT-e e CT-e OS, informar 000.
porém nos arquivos que eu tenho eles estão somente com 1 posição. Esses SPEDs são validados que nem a NFe?
eu importei no sistema de validação da receita e exportei novamente, ele sai como o que eu recebi o campo SER com um digito só, por exemplo
Campo 04 (COD_BARRA) - Preenchimento: informar o código GTIN-8, GTIN-12, GTIN-13 ou GTIN-14
O preenchimento é opcional, mas se for preencher deve ter certeza que usar um desses códigos GTIN, o que eu tenho visto no comercio e no fórum é que alguns estão colocando códigos INVÁLIDOS no campo GTIN ou seja códigos em que, apesar do digito de controle ser correto, não pertencem a nenhum pais ou empresa legal são códigos fajutos de produtos piratas.
Campo 07 (SER) – Validação: campo de preenchimento obrigatório com três posições para CT-e e CT-e OS, COD_MOD iguais a “57” e “67”, respectivamente, de emissão própria ou de terceiros. Se não existir Série para CT-e e CT-e OS, informar 000.
porém nos arquivos que eu tenho eles estão somente com 1 posição. Esses SPEDs são validados que nem a NFe?
Ai é que está !! tem coisas escritas no manual que nem sempre refletem a realidade. Pelo que está no manual deveríamos colocar "001" no lugar de "1" e é o que eu faria.
Eu alterei alguns regex para validar os arquivos que já foram enviados. Para testar eu importei esses arquivos e exportei eles novamente usando a biblioteca. Ai com os lançamentos das throw eu não conseguia gerar os arquivos.
O que acha de criarmos um parâmetro para validar ou não os registros? Assim os arquivos antigos que não estejam no formato poderão ser criados com a biblioteca e os novos para serem criados é ativado esse parâmetro para corrigir.
Vamos entender ...
1 - a "merda" do validador da Receita deixa passar um monte de porcarias
2 - podem haver alguns critérios "muito rigidos" ou incompletos nas nossas validações
Ambos os problemas podem ser ajustados.
Mas desabilitar a validação eu realmente acho TEMERÁRIO e INAPROPRIADO
Um de meus cliente tem o sistema da CONTMATIC quando gera o EFD são DEZENAS, se não CENTENAS de erros relatados pelo validador, quando eu gero pela nossa biblioteca cai para quase ZERO pois ela não deixa passar um "monte de bobagem" que o ERP e o contmatic (sistema contábil) deixou passar. Nem o NCM a porcaria do ERP valida!
Você que manda, eu posso voltar os REGEX antigos. Para gerar os arquivos importados desses outros programas eu penso de outra forma.
Para criar essa opção de conferir ou não os dados seria criar um parâmetro novo na construção, que o padrão pode ser ativado, e colocar na standarize um if para validar ou não
Ok pode colocar um método que desativa as validações, não vejo problemas imediatos nisso (apesar de pessoalmente de não gostar muito da ideia), mas acho que isso resolveria alguns problemas por ora.
Uma outra possível solução, seria essa "chave" desativar os exceptions e ativar apenas uma variável (array) que coletaria todas as falhas de validação. Com isso o EFD seria construído, mesmo com erros mas nessa variável teríamos a lista completa de validações que falharam.
E essa variável "errors" poderia ser consultada caso necessário.
O que você acha ?
É uma boa opção.
Como vantagem vejo: listar todos os erros de uma vez só; Permitir a criação do arquivo mesmo com erros; Continuar verificando os arquivos sempre.
Desvantagem: Talvez fique carregado se o arquivo for muito grande e com muitos erros? Teremos que alterar toda a lógica da biblioteca.
Nas minhas bibliotecas geralmente eu trabalho com uma variável booleana erro e outra que conterá as informações. Porém podemos considerar uma variável erro, que se estiver vazia foi tudo Ok, se estiver preenchida os erros, podemos definir ela como um array....
Por ora é epenas uma ideia!
Vamos evoluir com calma e sensatez.
Ok
Com as restrições de movimentação acredito que ficaremos mais em casa e nosso tempo pode aumentar um pouco pois não temos as horas perdidas no transito, ai podemos focar nas coisas mais relevantes.
Sim, se quiser marcar alguma hangout para conversar me avisa.
Tem alguma lista de atualizações a serem feitas?
Nesse momento não tenho nada, pois estou focado em outra coisa. Mas do jeito que estão ficando as coisas "paradas" acho que vamos ter tempo livre. O problema só vai ser ter dinheiro para comprar comida e pagar a internet.
@guicalabria Fiz uma alteração que irá coletar os erros em uma propriedade das classes errors[] é um array publico. Ou seja não haverão mais exceptions sendo disparados devido a inconsistências nos parâmetros informados.
Tem um monte de elementos faltantes no Contribuições se puder ajudar eu agradeço
Legal.
Não sei quando mas irei atualizar e ver os elementos faltantes.
Estou implementado versionamento de layouts