[FEATURE] Validação das Informações conforme Layout do SPED #86
Replies: 4 comments 3 replies
-
Eu penso ser muito utilt, pois se para gerar dentro dos parâmetros está no manual, creio que para este o componente pode tranquilamente fazer.esta validação, de forma a ter um retorno com os erros, blocos e campos que ocorreram, que poderatser validado pelo dev, assim naotcausa impacto para quem está montando o arquivo. Ou seja, iremos trabalhar com domain notifications, ficaria top.. Vou pedir aos devs da empresa para passar como usamos. |
Beta Was this translation helpful? Give feedback.
-
Boa tarde senhores, eu penso que algumas coisas mais simples são positivas de se fazer esse trabalho. Porém, a legislação que envolve os speds são muito interpretativas, há normas diferentes em cada estado, há situações em que o contribuinte tem alguma particularidade devido a um processo judicial e coisas do tipo. |
Beta Was this translation helpful? Give feedback.
-
@marcosgerene penso ser útil também, de qualquer forma ficaria como é determinado no layout não temos outro caminho, ficaria mais claro na hora de preencher. Como comentado pelo @marcianobandeira. |
Beta Was this translation helpful? Give feedback.
-
Acredito que TODA E QUALQUER validação deva ser opcional, até mesmo as obvias (campo X é obrigatório). Tenho casos onde preciso gerar um arquivo, importar em outra aplicação, adicionar informações e exportar. Um exemplo de validação que só me atrapalha: O usuário não configurou os dados do contador. O componente me retorna erro porque o nome dele está vazio. Ou seja, hoje eu iria no caminho inverso, removeria o que já existe ao invés de adicionar mais informações. Na minha visão de uso de componentes tudo que for regra de negócio é problema meu, não gosto quando o componente "se mete onde não é chamado" hahaha Agora sobre a sugestão, acho válido, mas acredito que deva ser opcional. E neste caso eu desligaria TUDO quando a opção fosse por não validar. |
Beta Was this translation helpful? Give feedback.
-
Galera,
Recentemente tivemos uma issue sobre validação das informações na lib (vide issue #85).
O que vocês acham da ideia de incluir a validação conforme o layout exemplifica?
Exemplo:
C500 na EFD Fiscal
Para operações de ENTRADA o Indicador Destinatário / Acessante não deve ser informado. Porém, para operações de SAÍDA é obrigatório, ou seja, como pode ser usado nas duas operações se o valor não for informado a lib não vai acusar a falta deste campo mesmo que a operação seja saída (e nesse caso é obrigatório).
Atualmente não temos esse tipo de validação na lib, tem validação estrutural para informar caso algum campo esteja mal formatado.
Para validar esse tipo de situação conforme o layout exemplifica teríamos que ter um método de validação classe a classe (vai tempo para incluir isso).
Alguém já fez algo do tipo? Vocês fazem validação a moda antiga (if isso else aquilo)? Alguém pode sugerir algo diferente?
@marcosgerene @marcianobandeira @adrianotrentim @ebitencourt @ThalyaAutocom @PGama-Rodrigo @hbdbim @EderWillian @eduarda80
Beta Was this translation helpful? Give feedback.
All reactions