Cintia Zago

Alguem enfrentando o mesmo problema em Minas Gerais e Goiás?

Também estamos tendo diversas rejeições, mesmo o NCM sendo alterado pelo que consta na tabela, dos clientes de Minas Gerais.

Então, sendo assim, acho melhor atualizar tudo mesmo não ainda a obrigatoriedade.

Boa tarde, Estou efetuando a migração para o trunk2. No entanto, ao iniciar o delphi 2007 após a instalação do AcBr obtenho o erro "Caractere invalido na codificação fornecida". Alguem passou por esse problema, ou teria alguma ideia do que possa ser?

Boa tarde, Para quem ainda não iniciou a alteração do novo campo CEST, seria interessante aguardar mais alguns dias para iniciar a mudança, ou já torna-se necessária devido às mudanças nos schemas?

Ao gerarmos o numero da nota, caso haja a rejeição e a nao autorização da nota, removemos a numeraçao na nota, pra evitar a inutilização, fazendo com a proxima nota a ser gerada utilize essa numeração que foi rejeitada.

Obrigada por compartilhar seu fonte. Fazemos algo parecido também, mas acredito que o maior problema. no meu caso, ocorre com a reversão do numero da nota, zerando o mesmo no caso da rejeição. No meu ponto de vista, essa reversão não deveria ser feita, mas como não depende apenas de mim, tenho que fazer dessa forma.

Justamente, o fato de não ser retornada a chave correta em alguns casos faz com que o cliente tenha que consultar e avaliar se deve ou não atualizar tal chave para a nota. No entanto, esse trabalho está gerando stress no cliente, que não quer ter esse trabalho. Isso que está sendo complicado. Acredito, então, que infelizmente não há como fugir desse procedimento.

Bom dia, Estou tendo um constante problema com duplicidade de chave nfe quando há oscilação na resposta do webservice da receita federal. Foi solicitado há algum tempo que eu implementasse uma forma de reverter a numeração da NFe gerada cuja tentativa de envio retornasse uma rejeição, para minimizar o problema de inutilização de numeração, no entanto, essa solução gerou um grande transtorno, pois, quando há oscilação na receita e o retorno da receita não é recebido pela minha aplicação, na próxima tentativa de envio há a duplicidade de chave. Alguém sabe uma forma mais inteligente de contornar este problema? Fiz uma busca nos tópicos existentes e não encontrei nenhum assunto relacionado. OBS: Estou utilizando ainda o trunk antigo.

Não Juliomar, ainda estamos usando a trunk. Efetuarei a alteração e farei novos testes. Obrigada.

Não Julioma, ainda estamos usando a trunk. Efetuarei a alteração e farei novos testes. Obrigada.

Também estamos enfrentando esse problema. De alguns dias pra cá o envio das notas fiscais em Minas estão gerando diversos erros provenientes de arredondamento, diferenças de apenas 2 centavos, o que antes não ocorria. Alguém já encontrou alguma solução?