[email protected]

Obrigado amigo. Descobri. Um usuário alterou a pasta schema para a pasta do modelo antigo ... Acabei de acertar e testar, está tudo OK. Desculpe a todos por fazer perder o tempo. Mas houve a instabilidade, pois notas aprovadas antes, foram rejeitadas quando expus ao autenticador oficial.

Boa Noite. Novamente, do nada, a NFE com os impostos notados para a Reforma Tributária, voltaram a ser rejeitados ... Fiquei até em duvida se o problema seria a falha da Schema, mas não a troquei, sendo o mesmo problema que relatei e depois, marquei resolvido. O que me dá certeza que o erro está na Receita é que, quando ela começou a aprovar as notas, passei as notas aprovadas pelo verificador oficial. E agora, que começou a reprovar, peguei as notas que foram aprovadas, na segunda (3 dias atras) e passei no verificador oficial. e pasmem, foram reprovadas ... Exponho isto, pois mutos ficam desesperados pensando que é falha do ACBr, tanto que ontem, a atualização via SNV, levou 30 minutos, de tantos usuarios fazendo (levo geralmente, menos de 2 minutos). Então, acho que nós, Devs, deveríamos ter mais respeito pelo governo, e eles, ,mais responsabiblidades pelo que fazem ... Agradeço ao pessoal do ACBr, pela paciencias, mas desde o princípio, o problema foi a receita.

Acho que vc não prestou atencao. Até printei o SNV, que exclui todo o diretório, fiz o down do truk2 do zero, recompilei ... A menos que o diretório da NFE de origem esteja com problema na origem ... Não existe como ser ele. E outra coisa, a menos que o ACBr tenha modificado, o warning que está apresentado eh o da receita, que aparece depois do "enviando", não no "gerando". Achei ... Foi comida de bola minha !!! Com a tentativa de tirar a tag, na hora de carregar o componentes, havia marcado o Vcbs, como valor zerado, não o valor do DB. Agora, está corrigido e realmente está passando. Muito obrigado a todos !!!

Mas como ficaria ? em que linha e qual o parametro ? Vc sabe como alterar ? me faria o favor de dar corrigido ?

Fiz passo a passo o que vc me orientou ... Não funcionou ... Sei que não é erro da schema local, pois quando isto ocorre, o arquivo .log, não é gerado, (coloquei para ele gerar um log depois que envia, antes de apagar quando há erro para ver).

Atualizei ele tido, exclui o diretório e fiz o down de novo, apaguei o Mdfe, Mas vou fazer como vc me orientou e retorno. Grato !!!

Obrigado pelo empenho, meu amigo, mas tentei agora há pouco. Mas antes, atualizei, na esperança da Receita ter corrigido ... Mas valeu por tudo, acho que ao invez de retrabalhar a XML, vou seguir sua sugestão de marcar a tag como não obrigatória. mas obrigado por tudo !!!

Acho que você não me entendeu. Como relatei (e documentei), o que está na norma técnica .002, não eh o que está acontecendo na prática. Agora, estou em uma reunião, mas voltando, emito uma nota em homologação sem os campos, e público. Eh que, embora consiga contornar o problema, nunca tinha visto isto acontecer no ACBr. Sou de origem europeia, e me causa muito mal estar, "dar jeitinho". Pensei em estar colaborando com o ACBr, como coloquei no começo, como sou usuário ha muuuitos anos, antes mesmo da NFE, quando o foco do projeto era calculadora, balança, periféricos. E o que causa estranheza maior, eh justamente os usuários não relatarem, mas colocarem sua indignação (não contra o projeto, mas contra a Receita) a ponto do Copilot da Microsoft, relatar este erro. Amo de paixão o projeto, pois vim de uma formação de "clippeiros", onde todos ajudavam todos. Desculpe pelo desabafo !!!

Esta eh a resposta do Copilot de uma hora atrás ... Sim, houve alterações nos prazos de obrigatoriedade dos campos da reforma tributária nos documentos fiscais eletrônicos (DFes). Embora estivesse previsto para o início de outubro, o ambiente de produção foi prorrogado para novembro e ainda há flexibilizações em homologação. Aqui vai um panorama detalhado pra você entender o que tá rolando: --- Alterações nos prazos de obrigatoriedade dos campos IBS e CBS - Ambiente de homologação: O preenchimento dos campos do IBS e CBS nos DFes passou a ser obrigatório a partir de 3 de novembro de 2025, conforme a Nota Técnica 2025.001 – RTC v1.09. - Ambiente de produção: A versão 1.30 da Nota Técnica nº 2025.002 alterou o prazo de entrada em produção, que estava previsto para 6 de outubro de 2025 e foi prorrogado para 10 de novembro de 2025. - Validações completas: Só passarão a valer mesmo em 2026, ou seja, ainda há espaço para ajustes e testes sem penalidades formais. --- Situação atual: ainda aceita, mas com ressalvas Apesar da obrigatoriedade técnica, o sistema continua aceitando documentos sem os campos preenchidos corretamente em homologação. Isso tem gerado críticas e dúvidas sobre a seriedade do cronograma — como você bem apontou, muitos contribuintes estão prontos, mas o sistema público ainda não está 100% alinhado. --- Desabafo válido Você não tá sozinho nessa indignação. Especialistas também têm criticado a falta de transparência e a instabilidade na implantação, que afeta diretamente quem quer cumprir as regras. A cobrança de responsabilidade é mais do que justa. Se quiser, posso te ajudar a acompanhar futuras alterações ou montar um checklist de conformidade para sua empresa. Quer que eu faça isso?

Mas eh este o problema ... A calculadora "deve" usar o mesmo processo do SEFAZ. Eu uso o validador do RS, e nele, há um mês atrás, aceitava o Vcbs, e aprovava a nota, mas não adianta nada se a receita rejeita !!! A receita quem está com erro, pois o campo eh obrigatório, mas temos que fazer que passe, e eh isto que estou tendo problema. Para vc ter uma ideia, o homologação está passando sem os campos da reforma, mesmo já tendo quase 1 mês da sua obrigatoriedade .. Estamos perdidos ... Achei muito certa a colocação de um dev no Discord . Não existe mais vida para devs depois da reforma.

Valeu !!! Obrigado. Eh que eu preferiria que viesse já no pacote, pois a cada update, apagaria e teria que ser corrigido. Ou, ele deixaria de atualizar o arquivo ... Ambas péssimas opções. Mas obrigado por me dar o caminho das pedras !! Para conseguir terminar de testar já eh suficiente !!! E o mais engraçado. Ainda hoje, se copiarmos o XML e passarmos pelo verificador oficial da receita, ele aponta o mesmo erro (no calculadora). Obrigado a vcs todos, pela participação !!!

Estou, se usar o ACBr somente. Eu e o Copiloto desenvolvemos uma rotina (ainda não está afinada) que retira o campo manualmente, antes de assinar, e depois assina. Mas acho que isto, deveria ser feito dentro do ACBr, evitando contaminação e, principalmente, por ser uma rotina tão fácil de implementar (if VIbs <> -1 then ... Insere no corpo da NFE)). ...

Todos os dias. Inclusive ontem tive problemas no conversões, e depois saiu a correção. Mas obrigado !!!

Me parece absurdo, mas nem os membros, nem usuários, fizeram menção. Sugeri que o ACBr, quando fosse alimentada a tag <det> <Vibs>, com valor zerado, não incrementasse está tag (como se não fosse obrigatória). Mas não tive resposta, nem escrita, nem em forma programática. Então, criei uma rotina que retirasse está tag antes de assinar. Mas me senti, extremamente zero a esquerda ... Colocar rotinas dentro do processo, ao meu ver, fere a lógica dos componentes. Pensando mais, pensei que, na hora de alimentar está tag, em vez de valor zerado, poderia ser o valor -1, pois não confeitaria em casos que o valor poderia ser 0. Torço para que, moderadores, membros, dêem atenção a está publicação !!!

Olá Alexandre, Obrigado por ter reaberto. Pedi este fafor, para poder dar uma sugestão. Como até hoje a SEFAZ-SP não corrigui este erro, queria que o pessoal que cuida da arquitetura do NFe do acbr, pensasse em, pelo menos enquanto este erro não for sanado, alterasse o pacote para que, o campo vIBS, quando zerado, não fosse cirada a sua Tag, na parte de ótens (hoje, se não declarada, é colocada automaticamente e com valor zerado). Isto ajudaria em muito, a todos Dev's pois, que o estado não apresenta o erro, vai ter a tag colocada "a mão", e no nosso caso que, ela dá como não esperada, o não colocar, não geraria a Tag. Obrigado pela atenção !!!