Édipo Rauber

Enquanto eu digitava a resposta vi um commit alterando a condição na unit ACBrNFe.XmlWriter.pas, eu estava pra mandar o arquivo com a mesma alteração aqui. A alteração teve origem no seguinte post: Refiz o teste com tpNFDebito = 07 e ICMS no item e agora está autorizando. Acredito que interpretamos corretamente, só estava pendente a receita ajustar a validação no lado deles. Porém, a nota autoriza tanto com ICMS quanto sem ICMS no item, o mesmo para PIS/Cofins. Aparentemente é opcional a geração dos impostos para esses casos. Tem alguma ideia de como poderíamos controlar isso? Tentei alimentar 'Imposto.ICMS.CST = cstVazio' pra não gerar o ICMS, mas ele ainda gera parte das tags e acaba rejeitando.

Olá, pessoal. Estamos implementando a emissão de NF-e com finalidade 5 - Crédito e 6 - Débito (Ajustes SINIEF 47/25 e 49/25, Reforma Tributária) e chegamos a uma dúvida sobre a geração dos grupos de imposto no item. Do jeito que está, quando a finalidade é 5-Crédito ou 6-Débito, a ACBr só gera os grupos de imposto (ICMS/IPI/PIS/COFINS/etc.) no item quando tpNFCredito = tcRetorno. Para os demais tipos, os grupos não são gerados. A nossa dúvida está na regra de validação B25-80 (rejeição 1001 – "NF-e com finalidade de débito ou crédito somente para IBS/CBS") da NT 2025.002 v1.50. A regra proíbe informar ICMS/ISSQN/IPI/II/PIS/COFINS/etc. quando `finNFe = 5 ou 6`, mas abre exceção para quatro casos: `tpNFCredito = 03` - Retorno por Recusa Total na Entrega ou Por Não Localização do Destinatário; `tpNFCredito = 04` - Redução de valores; `tpNFCredito = 06` - Retorno por recusa parcial na entrega; `tpNFDebito = 07` - Perda em estoque. Ou seja, pela NT, nesses quatro casos o destaque de ICMS (e dos demais impostos) é permitido, enquanto hoje contempla apenas pra `tpNFCredito = 03`. Porém, ajustei a validação para que sejam gerado ICMS em uma NF-e `tpNFDebito = 07` e ocorreu a rejeição 'COD:1001 MSG:Rejeicao: NF-e com finalidade de débito ou crédito somente para IBS/CBSB'. Minha dúvida é, o nosso entendimento da regra está errado a exceção só para `tpNFCredito = 03` estaria correto? Ou essa condição ainda deve ser ajustada? Se estiverem de acordo em adicionar a exceção para os demais casos, posso fazer a alteração e postar o fonte aqui.

Ótimo! Só um detalhe, acredito ser necessário atualizar o schema também para que ele aceitei o novo código: Acredito que esse seja o mais recente: http://sped.rfb.gov.br/item/show/8186

Na nota técnica EFD-Reinf 02/2026 foi incluído um novo código para o campo tpIsencao do registro R-4010. Em anexo está o fonte com a alteração no enumerador. Link da nota técnica: http://sped.rfb.gov.br/arquivo/download/8180 Schema do R-4010: http://sped.rfb.gov.br/arquivo/download/8186 pcnConversaoReinf.pas

Vi no SVN que a minha sugestão foi comitada junto na revisão 41268. Obrigado.

Estamos realizando alguns testes em ambiente de homologação e vimos que quando criamos uma NF-e com dois item, sendo que o primeiro item possui dados do IBS/CBS e o outro não (produto sem cClassTrib), a tag referente aos totais não é gerada. Sei que todos os produtos deveriam ter o CST e cClassTrib informados, porém em ambiente de homologação está permitindo autorizar dessa forma. Fiz uma alteração no fonte que fez gerar a tag dos totais caso tenha pelo menos um item com a tag IBSCBS. A alteração foi na unit ACBrNFe.XmlWriter.pas, no método Gerar_IBSCBS a variável FpGerarGrupoIBSCBSTot estava sendo setada para False em cada um dos itens gerados, porém se o último item não possui CST ou cClassTrib a variável ficava como False e não gerava o IBSCBSTot. Movi o local onde seta false pra FpGerarGrupoIBSCBSTot para o início do método GerarXml, mas não sei se seria o melhor local. Em anexo está o fonte alterado para validação. ACBrNFe.XmlWriter.pas

Analisei parte da documentação, mas em nenhum lugar destaca que estaria retornando o R9001 ao consultar o protocolo do R2099. Como eu já disse acima, achei estranho esse comportamento pro R2099, sendo que pro R4099 sempre retorna o R9015, indiferente se há inconsistência ou não. Mas consegui contornar o problema aqui. Analisei a forma como o programa de exemplo do Reinf trabalha e adaptei meu fonte pra ler as inconsistências do R9001 também nesses casos. Obrigado pela ajuda.

Boa tarde A consulta dos demais registros está 100%, só usei como exemplo o R4099 que é parecido com o R2099: Mas no programa de exemplo, o comportamento é parecido: Consulta do R4099 sem erro: Consulta do R2099 sem erro: Consulta do R4099 com erro: Consulta do R2099 com erro: O R4099 com ou sem erro, retorna o R9015. Já o R2099 está retornando registros diferentes (R9011 ou R9001), oq eu acho estranho. Eu imaginei que sempre estaria retornando o R9011 ao consultar um protocolo do R2099, indiferente se tivesse erro ou não.

Identificamos uma situação e não sabemos se é problema na forma como estamos utilizando o componente da ACBr ou se pode ser algum problema no serviço da receita. Por exemplo: Ao enviar o evento de fechamento R4099, recebemos um protocolo o qual usamos para consulta. Nessa consulta, recebemos de retorno o evento R9015 que contém a tag <evtRetCons>. Correto. O mesmo para o R2099, onde ao consultar o protocolo recebemos de retorno o evento R9011 que contém a tag <evtTotalContrib>. Correto. Caso houver alguma inconsistência no evento de fechamento R4099, recebemos o R9015 com as informações dos erros que ocorreram, acessamos elas dessa forma: AACBrReinf.WebServices.Consultar.RetConsulta_R9015.evtRetCons.IdeStatus.regOcorrs; Correto. Agora quando está ocorrendo algum inconsistência no evento de fechamento R2099, não parece estar retornando o evento R9011. Inicialmente achei que fosse algum problema no componente quando estava sendo lido o XML, mas depois vi que o XML salvo não contém a tag <evtTotalContrib> com as inconsistências, mas sim a <evtTotal>. Incorreto. Ou seja, não está carregando as informações do retorno em AACBrReinf.WebServices.Consultar.RetConsulta_R9011.evtTotalContrib. Para simular a situação, no envio do R2099/R4099 informei um nome inválido no campo "Nome do responsável", tag <nmResp>. Em anexo segue XMLs da requisição do protocolo dos eventos de fechamento de cada um dos registros. Meu entendimento está correto? O WebService deveria retornar dessa forma pro R2099? Teria alguma maneira de contornar isso além de ler manualmente o XML pra buscar as informações que eu preciso? R2099.rar R4099.rar

Boa tarde. Estou adaptando nosso processo de envio do Reinf para a versão 2.1.2 e tentei aproveitar a informação da tag fechRet do InfoRecEv do R-9015, porém vi que não havia sido implementado. No manual da versão 2.1.2 esse campo ainda não está adicionado, porém na nota técnica publicada em 30/06/2023 foi documentada a inclusão dele no R-9015: http://sped.rfb.gov.br/estatico/76/AA9A434BB906C84F95694CBF3A13F4445CBDD9/Nota técnica EFD-Reinf 2-2023.pdf Segue XMLs de testes que usei para confirmar se a informação estava sendo retornada e o fonte alterado para aprovação. pcnReinfRetConsulta_R9015.pas fechamento_ID9015000000000000000000001233414379-R9015.xml reabertura_ID9015000000000000000000001840260796-R9015.xml

Bom dia Na versão 1.4 do "Manual de Orientação ao Desenvolvedor da EFD-Reinf" publicado mês passado vimos que a URL do método de consulta do evento de Totalizações (que retorna o R5011) foi alterado: De: https://reinf.receita.fazenda.gov.br/WsREINF/ConsultasReinf.svc e https://preprodefdreinf.receita.fazenda.gov.br/wsreinf/ConsultasReinf.svc Para: https://reinf.receita.fazenda.gov.br/WsREINFConsultas/ConsultasReinf.svc e https://preprodefdreinf.receita.fazenda.gov.br/WsREINFConsultas/ConsultasReinf.svc Acredito que foi feito devido a criação dos métodos de consulta dos recibos de entrega. Testei ambas URLs do ambiente de homologação e também a URL nova do ambiente de produção e todas funcionaram ao consultar o evento de totalizações. Como as antigas URLs ainda estão funcionando, não somos obrigados a alterar agora... mas acho interessante deixar conforme o manual. Em anexo estão os arquivos ACBrReinfServicos.ini e ACBrReinfServicos.res com as novas URLs na versão 1.40. ACBrReinfServicos.ini ACBrReinfServicos.res

Boa tarde Vi que no layout 1.4 do Reinf o campo evtPgtos do R2099 passou a ser opcional. Nas descrição do campo está assim: "Validação: Só preencher este campo se {perApur} <= [2018-10]." Acredito que esse campo deixou de existir porque era o indicador do R2070 que foi excluído nesse último layout. Pelo que eu entendi, não devemos mais gerar o evtPgtos a partir de 2018-11. Anexei o fonte onde adicionei uma condição verificando se o (perApur <= '2018-10') para somente assim gerar o evtPgtos. pcnReinfR2099.pas

Boa tarde Segue alteração na montagem do xml do registro R2099. A informação do campo compSemMovto estava sendo alimentada na tag errada. pcnReinfR2099.rar

Certo. Obrigado Rafael!

Humm. Certo. Perguntei isso pq fiz um teste com o ACBrNfe e lá consigo utilizar o certificado sem essa opção marcada. Mas se realmente não é possível utilizar dessa forma pro Reinf terei que verificar se os clientes instalaram o certificado dessa forma. Obrigado!