Everton M Gava

O NCM tem relação sim com os cClassTrib. Conforme o colega comentou acima: "Nos anexos da LC 214/2025 é possível verificar os NCMs que sofrem redução de alíquota e relacionar com o cClassTrib " Determinados NCM , como os dos produtos da cesta básica por exemplo, usarão o cClassTrib 200003 por exemplo. Alguém tem alguma noção de preenchimento do XML em operações não onerosas? Por exemplo uma transferência de um produto que seria tributado integralmente ( cClassTrib 000001) em uma operação onerosa. Qual cClassTrib eu informaria? Estou entendendo que o CST do IBS CBS seria obrigatório, no entanto, o cClassTrib não seria obrigatório. Não encontrei nenhuma regra de rejeição caso não informar o cClassTrib, apenas se não informar o CST

Bom dia, Estou enfrentando um problema relacionado à configuração manual do fuso horário no componente ACBrNFe. Utilizo as propriedades ACBrNFe.Configuracoes.WebServices.TimeZoneConf.TimeZoneStr := '-04:00' e ACBrNFe.Configuracoes.WebServices.TimeZoneConf.ModoDeteccao := ACBrUtil.DateTime.tzManual para definir o fuso GMT-4 (Mato Grosso) manualmente. Também faço uma verificação antes de atribuir a data do evento (como no caso de uma CCe), onde, se o campo NR_FUSO da UF for maior que zero, aplico o modo manual com o fuso adequado. O problema é que essa configuração só surte efeito após a transmissão de uma NFe. Ou seja, se o sistema for iniciado e o usuário tentar diretamente registrar um evento (como uma carta de correção ou cancelamento), o fuso horário ainda não foi considerado corretamente, e a data do evento é gerada com o fuso padrão do sistema (por exemplo, -03:00). Com isso, recebo a rejeição: "Rejeição: A data do evento não pode ser menor que a data de emissão da NF-e." No meu caso específico, a nota foi emitida em 03/06/2025 às 15:45:23-04:00, mas como o componente ainda está assumindo -03:00, o evento acaba sendo enviado com, por exemplo, 15:52:36-03:00, o que faz com que a SEFAZ interprete que o evento ocorreu antes da emissão, gerando a rejeição. O maior problema é que nem sempre o usuário terá uma NFe para transmitir antes de emitir uma CCe, e muitas vezes os perfis dos usuários são distintos (quem transmite a nota não é quem gera a CCe ou cancela a NFe). ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Percebi que o problema parece estar na unit ACBrUtil.DateTime, especificamente na função GetUTC(UF: string; const dataHora: TDateTime): string. Essa função utiliza um case com base no valor de TimeZoneConf.ModoDeteccao para definir qual fuso utilizar. Se o modo estiver configurado como tzManual, ele deveria simplesmente retornar o valor de TimeZoneConf.TimeZoneStr. Obs: fiz o teste setando a configuração diretamente no componente e ocorre a mesma coisa, ou seja, o componente é alimentado corretemente somente depois de transmitir alguma nota. O meu ERP é utilizado por filiais que estão em GMT-3 e também em GMT-4, por isso precisa ser dinâmico esse timezone.

Pode ocorrer de eu estar interpretando incorretamente também e as reduções se concentrarem somente no cClassTrib. Nesse caso, operações com os regimes diferenciados e específicos utilizariam cClassTrib distintos. Ainda estou tentando entender melhor também essa situação

Entendo que não. Estou imaginando que no cClassTrib terá um % de redução possível, conforme a última tabela divulgada: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=erlbqr5k7FE= A LEI COMPLEMENTAR Nº 214 fala sobre regimes diferenciados e regimes específicos e é a isso que me refiro. Aqui estão descritos de uma maneira simplista: https://www.reformatributaria.com/governo-iva-tera-6-aliquotas-diferentes-entenda/

Creio que como existirão regimes especiais, determinados setores terão redução na alíquota, além das reduções vinculadas ao cClassTrib

Boa tarde. Perfeitamente, o cClassTrib não pode ficar simplesmente vinculado ao produto e sim relacionado com a operação. Dependendo da operação o cClassTrib é diferente. No cClassTrib também ficará vinculado o % de redução de alíquota ,conforme divulgado aqui: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=erlbqr5k7FE= Entendo também que cada ente da federação poderá ter alíquotas acima da de referência, portanto poderão existir 5569 alíquotas de IBS distintas + 27 (uma para cada UF) + alíquota de CBS. Estou entendendo que inclusive poderão existir mais de uma alíquota para cada município, pois existem diversos regimes especiais (ao menos 6). Resumindo: a) Uma tabela de alíquotas por ente, onde serão definidas as alíquotas próprias b) Uma tabela de cClassTrib, com o possível % de redução de alíquota c) Uma tabela de operações, onde o cClassTrib seria vinculado em cada operação

Entendo que somente CClassTrib vinculando ao produto: CST vinculado ao CClassTrib e CClassTrib vinculado ao produto. Vai da organização de cada sistema. Teria que organizar os produtos em "estruturas" e depois , criar tabelas relacionando CFOP a estruturas e alíquotas, tipo de operação, CST, etc, conforme destino final da operação, pois IBS vai variar conforme UF e Município. A não ser que no seu sistema para cada venda realizada para cada cidade distinta você tenha um produto específico, o que acho que não é o caso.

Estou entendendo que essa tabela de CST é "acessória", visto que os três primeiros dígitos do CClassTrib são justamente o CST. Exemplo: 000001 - CST 000, tributado integralmente. Também entendo que a serão três alíquotas: CBS, IBS Estadual e IBS Municipal. Logo, como as aliquotas irão variar conforme CClassTrib, UF Destino e Município Destino, existirá outra estrutura nos sistemas vinculando CClassTrib a essas outras informações da operação.

E com relação ao IS? O CClassTrib aplicado será o mesmo? Pelo que estou entendendo sim. Entendo que a tabela de CClassTrib também ficará vinculada a outra tabela interna, vinculando CCLassTrib x Estrutura do Produto x Tipo de Operação x Município Destino x Alíquota IBS Mun x Alíquota IBS UF

Com relação a mandar zerado, OK. O meu problema é NÃO enviar as tags zeradas para determinados estados.

Bom dia, já li o tópico acima e entendi que manter as tags enviadas, mesmo com valor zero, não impede a autorização da NF-e. No entanto, alguém encontrou uma solução para evitar o envio dessas tags? Meu cenário é o seguinte: tenho um cliente que, em algumas UFs, precisa enviar as tags para evitar erro, mas em outras, onde essa informação zerada não é obrigatória, ele quer ter a opção de marcar um checkbox "UF Exige tags para diferimento total". Não quero alterar a unit pcnNFeW localmente para não ficar diferente do ACBr e buscar uma solução para não enviar essas tags quando o diferimento for total e a UF não exigir.

Isso, foi o que eu fiz , atualizei o Acbr hoje pela manhã para a ultima revisão e assim a tag IndDeduzDeson passou a não ser mais informada no XML com valor padrão 0. A principio dessa maneira resolveu.

O valor padrão na release atual já não é tieNenhum ? Pelo que eu entendi, basta atualizar o componente que por padrão a tag não será preenchida.

Atualizei o componente no dia 16/04/2024 Pelo que percebi, o problema está no review: 33215

Bom dia, ao tentar autorizar NF-e no Rio de Janeiro em produção está ocorrendo esse erro após atualização do componente. Vi que o prazo para a NT 2023.004 (atualização dos schemas) 06/05/2024.