Italo Giurizzato Junior

Boa tarde Carlos, Muito obrigado pela contribuição, fiz alguns ajustes no arquivo INI do provedor e enviei para o repositório. Favor atualizar tudo e fazer novos testes.

Bom dia a todos, Quanto ao Refactoring do componente ACBrNFSe, algumas propriedades de configuração vão deixar de existir pois estavam em duplicidade. Mas isso é muito tranquilo de resolver em uma aplicação que já esta rodando. Não vai mais existir os arquivos INI dos provedores e nem o Cidades.ini O conteúdo do Cidades.ini vai para o ACBrNFSeServicos.ini que é convertido em um arquivo .RES que por sua vez é incorporado ao executável. Ainda não há uma previsão de termino do Refactoring, sendo assim não fique esperando. Estude o programa exemplo do ACBrNFSe atual. E passe a utilizar o componente ACBrNFSe na sua aplicação. Como o Juliomar disse, as grandes mudanças são internas no componente.

Bom dia Heronim, Uma vez que o provedor não segue o layout da ABRASF e esta ocorrendo esse problema, a minha sugestão é analisar a unit que gera o XML do RPS desse provedor e ver o motivo pelo qual ele não esta extraindo a hora do campo DataEmissao para colocar na tag referente a hora.

Boa tarde Caique, Você na verdade tem dois problemas: 1. Duplicidade de NF-e. 2. Diferença na chave. Vou começar pelo segundo. Quando ocorre a diferença na chave? A chave de um DF-e Documento Fiscal Eletrônico (no caso NF-e) entre outras coisas possui o valor de cNF = Código da Nota Fiscal que por orientação da SEFAZ tem que ser um código aleatório. O seu problema é que você esta atribuindo o valor zero ao campo cNF, isso faz com que o componente gere um código aleatório, sendo que o correto seria a sua aplicação gerar esse código e guardar no banco de dados no mesmo registro que contem os demais dados da nota. Desta forma ao ler os dados da nota para preencher os campos do componente o valor de cNF também seria lido, se essa informação não sofrer alteração toda vez que você gerar o XML da respectiva nota o cNF sempre será o mesmo. Com essa alteração que estou lhe propondo você não terá mais uma rejeição com diferença de chave. Agora vamos ao seu primeiro problema. Se esta tendo problema de Duplicidade é porque a nota esta sendo enviada para a SEFAZ mais de uma vez. Tenho certeza absoluta que quando ocorre algum erro de internet o procedimento adotado é enviar a nota novamente, correto? Pois bem esta errado. Se ocorrer um erro de internet não devemos enviar a nota novamente, pois quem disse a você que o erro ocorreu no envio? O erro pode ter ocorrido no retorno, logo o procedimento correto é carregar o XML assinado através do método LoadFromFile e em seguida executar o método Consultar. Se a nota foi enviada com sucesso e foi autorizada o método Consultar vai retornar o protocolo de autorização, como o XML assinado esta carregado, ele será atualizado, ou seja, vai receber o protocolo de autorização, desta forma o XML passar a ter validade jurídica e você pode imprimir o DANFE e enviar por e-mail para o cliente. Agora se o erro ocorreu no envio da nota, o Consultar vai retornar uma rejeição acusando que a nota não consta na base de dados, ai sim você envia novamente. Para saber mais sobre a chave de um DF-e leia o artigo abaixo: Leia também: e esse outro:

Bom dia Deivid, Favor anexar o XML de pedido de cancelamento para que possamos analisar.

Boa noite Heronim, Se para esse provedor ele aceita a data de emissão como sendo data e hora, porque não utilize a função Now? DataEmissao := Now;

Boa tarde Rodrigo, Quando algo é enviado para o webservice o componente sempre fica a espera de um retorno. O que você pode fazer é colocar o Timeout em 5000 assim no máximo o tempo de espera para ocorrer o TimeOut vai ser de apenas 5 segundos.

Boa tarde a todos, Quanto a contribuição do Eliezer, já inclui na minha lista de tarefas, ainda esta semana vou analisar.

Boa tarde Uillian, O método ConsultarLoteRps deveria retornar os XMLs das NFS-e cujos RPS foram processados com sucessos ou a lista de rejeições e não a situação. A situação igual a 4 segundo o manual da ABRASF (uma vez que o provedor ABase segue o layout da ABRASF) significa que o Lote de RPS foi processado com sucesso. Você me informar se os RPS enviados foram processados com sucesso? Essa verificação acredito eu que possa ser feita através do site ou usando o método ConsultarNFSePorRPS.

Boa tarde Carlos, Inclui na minha lista de tarefas. Assim que possível vou ver esta semana.

Boa tarde, Maravilha, assim que você finalizar a implementação de todos os métodos que o provedor disponibilizou, por favor anexa somente as units alteradas para que possamos analisar. Estando tudo OK, enviaremos para o repositório. Desde já muito obrigado pela colaboração.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Frederico, Muito obrigado pela colaboração, já se encontra no repositório o arquivo INI atualizado.

Bom dia Willian, Se não me falha a memória a cidade de Camboriú contratou um provedor que não segue o layout da ABRASF, logo a sua implementação se torna demorada.

Bom dia Marcos, O que tudo indica esse provedor segue a versão 2 do layout da ABRASF. Logo será tranquilo a inclusão desse provedor no componente. Esta faltando os schemas para validar o XML antes do seu envio e as URLs dos ambientes de homologação e produção.

Bom dia Leonardo, Você esta com todos os fontes de todas as pastas atualizados? Se não me falha a memória na versão 2.00 do GNRE é possível informar a chave da NF-e.

Boa tarde Thiago, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde a todos, Futuramente ao emitir o MDF-e a SEFAZ vai se encarregar de gerar o CIOT, mas até agora não disse como e quando isso vai ocorrer. Logo devemos usar o componente ACBrCIOT para obter o numero do CIOT que deve ser informado ao emitir o MDF-e através do componente ACBrMDFe.

Boa tarde Marcio, Muito obrigado pela contribuição, já inclui na minha lista de tarefas, assim que possível vou analisar e estando tudo OK, vou enviar para o repositório.

Boa tarde, Já pensou na possibilidade de gerar PDF de lotes de 500 CT-e por vez em vez de 5000 de uma única vez?

Boa tarde Heronim, Com relação a assinatura digital, como ficou essa questão?

Bom dia Frederico, Tente com esse INI em anexo. Fiorilli.ini

Boa noite, Se você envia o XML seja ele da NF-e ou do CT-e se ocorre algum erro de internet o mesmo fica sem o protocolo de autorização. Primeiro não se deve enviar o XML novamente, pelo simples fato de você não saber onde o erro ocorreu, se foi no envio ou no retorno. Portanto a atitude mais correta é realizar uma consulta. Você já tem o XML assinado e validado, salvo em disco ou no banco de dados. Os passos que devemos tomar após a ocorrência do erro são: 1. carregar o XML através dos métodos LoadFromFile (XML salvo em disco) ou LoadFromStream (XML salvo no DB). 2. executar o método Consultar. Se o erro foi no retorno e o documento (NF-e ou CT-e) foi autorizado com o procedimento a cima você terá o XML com o protocolo de autorização. Por outro lado se o erro foi no envio a SEFAZ vai retornar uma rejeição na consulta acusando que o documento não consta na base de dados dela. Neste caso, ai sim você envia o documento novamente. O correto com apenas 3 linhas: acbrct1.Conhecimentos.Clear; acbrct1.Conhecimentos.LoadFromFile(xArquivo); // xArquivo contem o Path e o nome do XML ou acbrct1.Conhecimentos.LoadFromStream(xCampo); // xCampo contem o XML salvo no DB acbrct1.Consultar;

Boa tarde Daniel, Neste caso altere o valor de Validar para zero no arquivo INI do provedor, assim não vai ocorrer erro de validação e consequentemente os arquivos serão salvos. Com os arquivos (XML) vai ser possível identificar o problema.