EMBarbosa

Olá pessoal, Com a NT 2018.005 foi introduzida uma nova rejeição para NFe: 938 - Rejeição: Não informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet. Os detalhes dessa rejeição foram alterados nas várias versões da NT, mas infelizmente isso já está causando algum problema (como podem ver nesse tópico aqui). Como é uma rejeição facultativa e cada UF tem uma legislação, tivemos que adicionar uma nova propriedade no componente ACBrNFe para lidar com a situação. A nova propriedade se chama ForcarGerarTagRejeicao938. Após atualizar os componentes, não esqueça de reinstalar. Vamos a uma explicação mais longa... O problema Como a descrição da rejeição explica, algumas UFs podem exigir a informação de algumas tags, como vICMSSubsituto, isso mesmo quando o valor da tag for zero. Por padrão o ACBrNFe não gera tags facultativas que são informadas com valor zero. E esse é o caso da tag vICMSSubstituto. Mas como essa é uma tag facultativa, não devia ser obrigatório para algumas UFs informá-la. E por isso, não podemos obrigar o ACBrNFe informar sempre. Assim a ideia é termos uma configuração que você possa alterar. Poderemos com essa propriedade forçar gerar a tag de acordo com a necessidade de seu cliente ou da UF dele. A solução A propriedade (ou configuração) criada ForcarGerarTagRejeicao938 foi adicionada no ACBrNFe de modo que pode ser acessada como no código abaixo: ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca; Ou talvez no Object Inspector como abaixo: Importante: Embora a propriedade esteja disponível para ser alterada no Object Inspector, você provavelmente vai querer parametrizar isso no seu aplicativo. Afinal, talvez você precise alterar essa propriedade de um cliente para outro, ou de uma data para outra. As opções são: fgtNunca -> Se o valor for zero, não vai forçar a geração da tag nunca; fgtSomenteProducao -> Força a tag ser gerada no ambiente de produção mesmo que o valor seja zero; fgtSomenteHomologacao -> Força a tag ser gerada no ambiente de homologação mesmo que o valor seja zero; fgtSempre -> mesmo que o valor seja zero, a tag será gerada sempre; A configuração padrão é fgtNunca conforme o comportamento do componente antes dessas alterações. Qual opção eu devo escolher? Como explicado, essa configuração foi necessária por causa de problemas em certas UFs. Então para escolher a melhor opção você precisa saber o que está sendo exigido no Webservice que você está acessando. Por exemplo, se você não está recebendo a rejeição, não há necessidade de alterar a configuração. Mas se está recebendo somente em homologação, quer dizer, a tag está sendo exigida somente em homologação, use a opção fgtSomenteHomologacao. E assim por diante.

Desculpe eu não entendi nem o que não funcionou e nem onde poderia ter uma alteração necessária... Poderia explicar melhor?

Olá Antônio, por favor, assim que tiver um posicionamento dos dois ambientes, (produção e homologação), queira nos dar um retorno.

O que eu posso informar é o seguinte, talvez ajude: "Communication error %d: %s" ---> Esse é um erro retornado pela Synapse, o framework que utilizamos para acessar portas de comunicação "1450: Não existem recursos de sistema suficientes para concluir o serviço solicitado" ---> Esse é um erro do sistema operacional. Ele diz que algum recurso do sistema não foi suficiente. Infelizmente essa mensagem é muito vaga. Há muitos tipos de recursos que podem se tornar insuficientes. Para saber qual, precisaríamos entender exatamente qual o contexto do erro (que comandos foram executados, quais processos estavam sendo executados, qual o código, etc...) Mas esses dois pontos parecem apontar para um erro no driver virtual da porta... Sendo assim, porque não tenta usar a sugestão de USB?

A pedido do usuário, tópico fechado. Relacionado: https://www.projetoacbr.com.br/forum/topic/50635-nfce-com-acbrecf-emitindo-forçadamente-redução-z/

Analisando o código dessa região do relatório notei o seguinte: Onde está circulado na sua imagem pode aparecer as informações do campo NaturezaOperacao. Mas esses dados só aparecem caso esteja de acordo com as opções da função NaturezaOperacaoDescricao da unit pnfsConversao.pas; O campo ExigibilidadeISS não é exibido no DANFSe em nenhum lugar. Assim, se for realmente necessário, precisamos alterar esse comportamento. Você tem realmente necessidade desse campo ser exibido?

Como eu disse no post, você deve configurar de acordo com a UF. Veja: fgtNunca -> Se o valor for zero, não vai forçar a geração da tag nunca; fgtSomenteProducao -> a tag será gerada no ambiente de produção mesmo que o valor seja zero; fgtSomenteHomologacao -> a tag será gerada no ambiente de homologação mesmo que o valor seja zero; fgtSempre -> mesmo que o valor seja zero, a tag será gerada sempre; Então se está exigindo a tag somente em homologação, use a opção fgtSomenteHomologacao.

Obrigado pela confiança e paciência. Leonardo, muito obrigado pelas sugestões. Eu fiz algumas alterações e já enviei ao SVN na revisão 16904. Achei melhor renomear a propriedade de configuração para ForcarGerarTagRejeicao938. Isso vai impedir qualquer confusão com os outros pontos da NT 2018.005. Também achei prudente criar um tipo enumerado permitindo a configuração de forçar a geração de tags em homologação, produção, ambas ou nunca. Alterei um pouco a ordem das validações com o objetivo de deixar o código mais claro. Mas posso ter falhado em alguma coisa, por isso peço a ajuda de todos que atualizem e verifiquem o funcionamento. Notem que vocês precisam utilizar a configuração ForcarGerarTagRejeicao938 de acordo com o WebService da sua UF.

Se esse for o caso, também estou de acordo. Você teria condições de fazer a implementação?

Mas quando o tamanho do CNPJ for 0, será que não vai ser exigido o CPF? Porque se for, então a validação atual continuaria correta.

Legal. Não vejo muitos projetos usando. Sugiro avaliar o uso da DWScript. https://www.delphitools.info/dwscript/ Suporta classes, interfaces, records, type inference, meta-classes, classes parciais, “case of” and “in […]” de formas generalizadas, e muito mais...

Apresente a resposta da SEFAZ/RJ. Me parece furada. É melhor você entrar em contato com a SEFAZ mais uma vez. Em MG só podia isso se o computador ficar fora do ambiente de atendimento.

Talvez esteja faltando algum arquivo que está presente na sua máquina.

Regra geral, use mais de uma thread apenas se necessário.

Conflito acontece quando os arquivos foram alterados tanto localmente, (na sua máquina), quanto no remotamente no SVN por nós. Você precisa saber se você fez essas alterações intencionalmente. Caso você não tenha feito intencionalmente, é necessário fazer revert nos arquivos relacionados. Você pode clicar com o botão direito na pasta do ACBr e escolher no menu de contexto TortoiseSVN -> Revert... Daí marque todos os arquivos que você não alterou. Isso não deve funcionar porque o instalador não vai fazer o Revert automaticamente, mesmo marcando para remover arquivos antigos. Mas depois de fazer o Revert, talvez seja necessário marcar para remover arquivos antigos.

Na verdade, desde que essa propriedade foi criada em 11/01/2016 na revisão 10840, o valor padrão era True. Veja: Além disso, se eu não estou enganado, colocar esses valores como False poderia gerar um problema em computadores que não tem as fontes mencionadas no PDF. Há alguns relatos do fórum mencionando que, por exemplo, clientes não conseguem abrir o arquivo PDF de uma nota enviada por email no navegador. Esses problemas resolveram quando alteraram essa propriedade para True. Assim, acho melhor não alterar, a menos que tenhamos um bom motivo pra isso.

Agradecemos o retorno.

Você tem toda a razão. O componente estava ignorando e em alguns casos até alterando por si mesmo o padrão dessas duas propriedades. Enviei uma correção no SVN na revisão 16894. Queira por favor atualizar, testar e reportar qualquer problema.

Provavelmente é a falta de algumas dlls como a openSSL.

Há alguma necessidade de utilizar essa opção sem o CNPJ/CPF? Em caso positivo, poderia exemplificar?

Olá Dércio, Esse tipo de dúvida, geralmente você precisa tirar com o contador da empresa que vai gerar o SPED. Ou, no caso mais extremo, contratar um contador para sua empresa para ajudar a fazer os cálculos e a gerar esses arquivos no seu sistema. Depende muito da UF, da empresa e de diversos fatores que nós talvez por falta de formação contábil poderíamos ajudar. Mas eu entendo sua frustração, porque já passei muito por isso... Esses registros foram adicionados antes de 2011 para serem utilizados para outras apurações de ICMS. Não necessariamente de ICMS ST Retido ou Efetivo. Só devem usar esses registros os contribuintes de UF cuja Administração Tributária Estadual exige por meio de legislação específica essas apurações. Nesse caso a UF vai instituir e disponibilizar a a Tabela 5.3 com códigos que contenham “3”, “4” e 5” no quarto caractere (“Tipos de Apuração de ICMS”). Ela está disponível para download no site do SPED. Você precisa consultar a tabela 5.3 mencionada acima da UF do contribuinte e a legislação estadual para saber se realmente isso é necessário e qual código utilizar. Importante notar que o guia prático versão 3.01 na página 229, diz que os valores válidos para esse campo estão relacionados com os registros C197 e D197 que você deve estar gerando de acordo com legislação específica do estado. Não sei dizer se corresponde ao ICMS ST Retido. Mas posso responder que está relacionado ao C197 (ou D197) porque todo registro 1900 é baseado na geração do C197 e D197 conforme escrito acima. Note que esse campo também tem explicação de validação do seu valor no guia prático (pág. 231). O Valor deve bater com somatório do C197. Agora você entrou numa parte da legislação que eu realmente, ou pelo menos a princípio, não saberia dizer nada. Em especial porque não estou ciente da legislação do RS. Apenas posso informar que ambos os campos tem validação nesses registros e que o campo VL_TOT_AJ_DEBITOS_OA está relacionado com o Registro 1921. Espero ter ajudado de alguma forma.

Olá Fabiano, Vamos por partes. Realmente. Eu fui até conferir, mas essas classes específicas e suas propriedades não foram afetadas pelos ajustes recentes. Pelo menos desde 2015 elas já estavam desse modo. Eu entendi que você gostaria que o projeto publicasse essas propriedades. Até discutimos sobre essa possibilidade. Mas isso é desnecessário. Desde o Delphi 2010 quando a RTTI foi reescrita, é possível acessar as propriedades que não são published. É por isso e por outros motivos, (cof, cof, generics, cof), que frameworks avançados como o Spring4D e DSharp funcionam apenas com o Delphi 2010 em diante. Colocar essas propriedades como published gera um warning no compilador que queremos evitar: W1055 PUBLISHED caused RTTI ($M+) to be added to type 'TACBrSacado' Mas como as propriedades estão acessíveis por RTTI, você não está sem saída. Com eu disse acima, você não precisa mudar seu código para não usar o RTTI. Talvez você precise usar o seu código para acessar o RTTI de forma atualizada. Ou talvez você deva verificar algum framework para fazer isso. Mas enfim, isso é uma decisão de acordo com o seu projeto. Veja nesse artigo em português como a RTTI pode acessar propriedades não published. Há vários outros artigos na net que estão em inglês. Eu gosto dessa série aqui porque ele segue uma linha de raciocínio e dessa coleção de posts que fala de assuntos diferentes. Achei interessante o que você fez. Mas não é o que eu recomendaria de uso do RTTI no entanto. Tenho impressão que, a menos que você tenha um teste unitário para isso, se alguém alterar um campo do Dataset você só perceberia isso rodando o programa. Acho melhor quando esse tipo de problema gere erro na compilação. Mas enfim, essa é mais uma opinião pessoal. Bom trabalho por aí.

Suspeitei desde o princípio... Se quiser anexar essas alterações, poderemos analisar. Pensamos em algo semelhante ao discutirmos entre os devs sobre esse problema. Vejam a mensagem acima.

Olá Walter, É necessário que você mencione exatamente qual configuração está utilizando e qual mensagem de erro está aparecendo.