Everton M Gava

Boa tarde, pessoal. Os schemas que o ACBr distribui junto com o fonte ainda não estão atualizados para o alfanumérico certo?

Pessoal, fiz a adição dessas tags e alterei no GinfesProvider para DadosCabecalho := '<ns2:cabecalho versao="301" xmlns:ns2="http://www.ginfes.com.br/cabecalho_v03.xsd">' + '<versaoDados>301</versaoDados>' + '</ns2:cabecalho>'; Agora meu erro mudou,: <?xml version="1.0" encoding="UTF-8"?> -<EnviarLoteRpsResposta xmlns:ns3="http://www.ginfes.com.br/servico_enviar_lote_rps_resposta_v03.xsd" xmlns:ns2="http://www.ginfes.com.br/tipos_v03.xsd"> -<ListaMensagemRetorno> -<MensagemRetorno> <Codigo>S63</Codigo> <Mensagem>Erro ao consultar rps. Data da consulta: 15/05/2026 16:14:36</Mensagem> <Correcao>Entre em contato com o atendimento.</Correcao> </MensagemRetorno> </ListaMensagemRetorno> </EnviarLoteRpsResposta>

Boa tarde, veja os meus ajustes como ficaram, seguindo as dicas dos colegas acima: Ainda estou obtendo o mesmo erro...

As empresas que utilizam o Web Service do Ginfes para conversão de RPS no GissOnline V2 podem optar pelo novo modelo da NT 007. Para essa transição, é necessário atualizar a URL de comunicação (WSDL) para o novo padrão municipalizado: https://ws-[MEUMUNICIPIO].giss.com.br/service-ws/nf/nfse- ws?wsdl (exemplo: para o município "Fictício", utiliza-se [https://ws- ficticio.giss.com.br/service-ws/nf/nfse-ws?wsdl](https://ws- ficticio.giss.com.br/service-ws/nf/nfse-ws?wsdl)). exemplo: https://ws-rioclaro.giss.com.br/service-ws/nf/nfse-ws?wsdl em anexo o material que recebi Método de Preenchimento por Variação do Valor Próprio ou Retido PIS-COFINS e CSLL.pdf

Até dia 12 era Ginfes

Em Rio Claro/SP, ainda não autorizou.

Bom dia, ontem (13/05/2026) o erro passou a ocorrer em Rio Claro/SP. O mesmo padrão de arquivo que foi autorizado normalmente no dia 12/05/2026 passou a simplesmente ser rejeitado no dia posterior Alguém tem alguma solução para isso?

Verifiquei que o problema é um XML específico retornado pelo serviço de distribuição. Ocorre a exceção nessa function, ao fazer o TACBrNFSeX(FAOwner).NotasFiscais.LoadFromString(aXml, False): function TACBrNFSeXProvider.CarregarXmlNfse(aNota: TNotaFiscal; const aXml: string): TNotaFiscal; begin if Assigned(ANota) then ANota.XmlNfse := aXml else begin TACBrNFSeX(FAOwner).NotasFiscais.LoadFromString(aXml, False); ANota := TACBrNFSeX(FAOwner).NotasFiscais.Items[TACBrNFSeX(FAOwner).NotasFiscais.Count-1]; if (aNota.XmlRps <> '') and (ANota.XmlNfse = '') then ANota.XmlNfse := aNota.XmlRps; end; Result := aNota; end; A única diferença visivel no XML para os demais é a seguinte linha: Não dispara exceção ao fazer o load : -<NFSe versao="1.01" xmlns="http://www.sped.fazenda.gov.br/nfse"> Dispara exceção ao fazer o load: -<NFSe xmlns="http://www.sped.fazenda.gov.br/nfse" versao="1.01">

Bom dia, Estava executando o comando ACBrNFSeX.ConsultarDFe(StrToIntDef(ultNSU, 0)) para obter os XML das notas de serviço emitidas. No dia 16/04/2026 passei a receber o seguinte erro ao executar esse comando: X999-Erro de Conexão: StartTag: invalid element name. Alguém sabe como se resolve essa situação, está passando pela mesma situação, ou se é algum problema do lado do serviço?

Problema resolvido. Podem encerrar o tópico. Estava enviando valor bruto zerado em um dos eventos

Olá, alguem mais passou a receber erro na validação dos schemas do REINF? passei a receber o seguinte: evt4020PagtoBeneficiarioPJ-v2_01_02 --> 1871 - Element '{http://www.reinf.esocial.gov.br/schemas/evt4020PagtoBeneficiarioPJ/v2_01_02}indJud': This element is not expected. Expected is ( {http://www.reinf.esocial.gov.br/schemas/evt4020PagtoBeneficiarioPJ/v2_01_02}vlrBruto ). Não me recordo de modificações recentes no REINF. Os schemas também estão atualizados.

Boa tarde, 2026 será "alíquota fixa": 0,9 para CBS e 0,1 para IBS UF. No entanto, já deixa preparado o seu sistema com tabelas para vincular as alíquotas de cada ente, pois futuramente não serão fixas.

Fizemos isso ai e não conseguimos sucesso. Precisamos emitir na versão 1.0. A versão 2.02 não contempla todas as regras de negócio

No final das contas, é como se fosse um novo provedor: "Betha Cloud" Algumas prefeituras utilizarão como atualmente, versão 1.0 e 2.02. Outras prefeituras passarão a utilizar o "Betha Cloud", com os novos schemas , nas versões 1.0 e 2.02 e suas adequações. No caso desse cloud aí, a versão 1.0 tem que contemplar os ajustes que eles impuseram.

Não será mais possível emitir na versão 1.0 pelo ACBr para Criciúma?

Você utilizou o 1.0 ou a versão 2.02 ?

Irei fazer os meus testes e anexo aqui as modificações que surgirão.

Bom dia, pessoal. Sei que ainda há muitas definições em andamento e que provavelmente ainda haverá mudanças nos schemas, NTs e demais especificações. Durante uma simulação de venda para um ente governamental, preenchendo a tag gCompraGov/pRedutor em uma operação com CST 000 (tributação integral), estou recebendo o seguinte retorno:"CST do IBS/CBS informado não permite informação de redução de alíquota municipal." Verificando a NT, me deparo com a seguinte situação: CST possui indicador que não permite o uso de redução de alíquota (ind_gRed = 0) (grupo: gIBSUF/gRed) Exceção: Se Percentual de redução de alíquota em compra governamental (tag:gCompraGov/pRedutor) informado, este grupo é exigido e pRed deve ser igual a 0. Percebam que a rotina Gerar_IBSCBS_gIBSCBS_gIBSUF só preenche o grupo de redução quando o valor de pRedAliq é maior que zero, o que não ocorre nas compras governamentais (nos casos que seriam tributados integralmente), onde esse valor é exatamente zero:

Boa tarde, verifiquei que o ACBr foi atualizado para gerar o CST 410. Fiz um teste e agora está gerando no XML CST e CClassTrib, só que está gerando todo o restante das tags do grupo gIBSCBS, o que está incorreto. Desse modo iremos tomar rejeição : "1021 - Rejeição: Grupo IBS/CBS não deve ser preenchido para o CST informado".

Acredito que você deveria inutilizar todas essas notas. Uma observação: não é mais necessário informar no SPED essas numerações inutilizadas. Portanto, creio que você não teria grandes problemas com isso.

Boa tarde, efetuando testes de envio de XML com as novas tags da reforma tributária, me deparei com o CST 410 - Imunidade e não incidência onde eu não devo encaminhar as tags do grupo <gIBSCBS>.no entanto, ainda preciso encaminhar as tags para informar que aquela operação é imune/não incidente. <CST>410</CST> <cClassTrib>410001</cClassTrib> Ocorre que o ACBr somente está levando CST e cClass quando vBC > 0. Entendo que isso está incorreto, pois em muitas situações não irá existir um vBC mesmo. Alguem mais se deparou com essa situação?

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/