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.

Boa noite, alguém com problema de autorização de notas na SEFAZ SP? Estou com problemas para autorização de notas em São Paulo

Boa tarde, No layout CNAB 400 do Banco do Brasil, existe o comando para alterar o valor do titulo: 47 – Alteração de Valor Nominal do Boleto Porém, no fonte do "ACBrBancoBrasil.pas", não é considerado essa ocorrência. Acredito que falta implementar a linha abaixo: toRemessaAlterarValorTitulo : ATipoOcorrencia := '47'; {Alteração de Valor Nominal do Boleto}

Problema resolvido, notas autorizadas. Era alguma manutenção na SEFAZ. Pode encerrar o tópico.

Boa tarde, em base de homologação do RS, passou a ocorrer o erro a partir de hoje a tarde: "Tipo autorizador do recibo diverge do orgao Autorizador". Alguém mais passando por essa situação? Segue arquivo: <?xml version="1.0" encoding="UTF-8"?> -<retConsReciNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <tpAmb>2</tpAmb> <verAplic>RS202312211427DR</verAplic> <nRec>432000020198491</nRec> <cStat>553</cStat> <xMotivo>Rejeicao: Tipo autorizador do recibo diverge do orgao Autorizador.</xMotivo> <cUF>43</cUF> <dhRecbto>2023-12-22T16:47:59-03:00</dhRecbto> </retConsReciNFe> 432000020198491-pro-rec.xml Informações adicionais: enviada apenas 1 NF-e, modo síncrono.

a senha do certificado do cliente estava incorreta, eu estava fazendo a tratativa errada. Pode encerrar esse tópico

Boa tarde, ao efetuar a consulta do status do serviço, chamando ACBrNFe1.WebServices.StatusServico.Executar eu não tenho nenhum tipo de resposta, nem mensagem de erro, nada. Alguem mais já passou por essa situação?

Boa noite, estou com um "problema" que aparentemente parece uma dúvida boba, no entanto , por minha falta de conhecimento em trabalhar com REST ainda não consegui solucionar. Necessito efetuar uma requisição do tipo POST e a mesma requer que seja passado em um dos parâmetros um array de objetos. A minha dúvida é essa: de que modo posso fazer isso? Para adicionar um parâmetro simples, uso TRESTRequest.AddParameter('api_token', xxxxxx ) por exemplo. Como poderia passar um array se AddParameter não me deixa utilizar dessa forma?

O manual fala em "Tributação com Diferimento (a exigência do preenchimento das informações do ICMS diferido fica a critério de cada UF).". Ou seja, a critério de cada UF, pode ou não ser exigido o preenchimento das tags. No manual, no CST 51, as tags não precisam ser encaminhadas, não é exigência. Eu resolvi modificando a chamada de Gerador.wCampo de 1 para 0.

Até consigo transmitir sem enviar as tags nesse caso, no entanto , precisei modificar a pcnNFeW no CST 51 o parametro da procedure Gerador.wCampo de 1 para 0. Não consegui identificar o motivo de essas tags estarem como obrigatórias no componente.

Boa tarde, estou gerando notas fiscais com o CST 51 - Diferimento, e conforme o manual , as tags relativas ao ICMS são opcionais, a critério de cada UF, no caso do diferimento de 100% do ICMS. Pelo que verifiquei na unit pcnNFeW, as tags relativas ao ICMS no CST 51 são sempre encaminhadas, não existindo a opção de não encaminhar essas tags. Alguem já fez algo parecido? como contornaram a situação? Obrigado!