Italo Giurizzato Junior

Bom dia Vitor, No meu entendimento, um documento assinado e protocolado pela SEFAZ, não deve ser mais alterado. Dai a idéia de se criar o encerramento e o cancelamento como sendo eventos vinculados ao documento anteriormente enviado. Temos então dois XML: 1. MDF-e 2. Evento Portanto temos duas imagens desses XML em papel: 1. DAMDFE 2. Evento Se você carregar o XML do MDF-e em seguida carregar o XML do Evento e por fim Imprimir o Evento, a folha impressa vai conter alguns dados do MDF-e e mais os dados do Evento indicando se é de Encerramento ou Cancelamento. A minha sugestão é imprimir duas vias do DAMDFE, uma segue viagem com a carga e a outra fica na trasportadora para ser "grampeado" com o Evento Impresso de Encerramento. Por outro lado, após a emissão do MDF-e se por erro ou cancelamento do envio da carga, devemos efetuar o cancelamento do MDF-e, neste caso após imprimir o Evento de Cancelamento devemos "grampear" com o respectivo DAMDFE. Espero ter ajudado.

Bom dia mmcamilo, Se você realiza uma consulta anterior ao dia 28, ocorre o retorno, logo o componente esta funcionando. Normalmente esse tipo de erro 999 - Falha não Tratada ou Erro não Catalogado é problema na SEFAZ. A dica é entrar em contato com eles e expor o problema.

Bom dia jperim, Da forma que você montou esta correta. Veja este outro exemplo: Supondo que o campo a ser alterado é xBairro. Note que existe dentro do grupo rem 2 campos com o mesmo nome, um esta dentro do grupo enderReme e o outro dentro do grupo locColeta, ambos os grupos dentro do grupo rem. Você concorda que se você informar rem como sendo o grupo alterado a SEFAZ não vai saber quais dos dois xBairro que esta errado? Sendo assim se o xBairro que esta errado é da coleta devemos informar como grupo o locColeta.

Bom dia Edilson, Se você atribui zero ao campo Ide.cMDF, isso faz com que o componente gere um código aleatório para compor a chave. Por outro lado se você atribuir um numero diferente de zero, o componente vai utilizar esse numero para compor a chave. Nas minhas aplicações, ao salvar as informações no banco de dados, gero um numero aleatório. Depois utilizo esse numero para atribuir ao campo Ide.cMDF. Veja bem, o numero atribuido é aleatório mas gerado pela minha aplicação e armazenado no banco de dados juntamente com as demais informarções a serem utilizadas para gerar o XML do MDF-e. É exatamente isso que o nosso colega Wislei faz. Outra coisa, tenho também no banco de dados a chave completa gerada pelo componente.

Bom dia, Quais são as TAGs que faltam, não consegui identifica-las.

Bom dia Idez, No manual versão 1.04c do CT-e temos na página 123 as TAGs obrigatórias quando se trata de um CT-e Complementado. Na versão 1.04 me parece que sim, na versão 2.00 vai ser informando somente a chave do mesmo (vide NT 2013/013 Alteração MOC 2.00 - página 147).

Bom dia Stefano, Muito obrigado pela sua colaboração, a alteração ja esta disponivel.

Bom dia Dalvan, A cidade de Guapore/RS esta configurada para o provedor GovBR, o componente esta configurado para usar os schemas do GovBR?

Bom dia Thomas, Correto, mas é preciso saber qual é a fonte do problema. O XML em questão: 1 esta sendo baixado do site; 2 esta sendo realizado o download via webservice; 3 esta sendo enviado pelo emitente por e-mail e depois é salvo em disco e posteriormente enviado novamente por e-mail para a pessoa que vai fazer a sua leitura. O componente ACBrNFe ao gerar o XML não insere quebras de linhas e espaços em branco em lugares onde não devem existir. No meu entendimento, devemos descobrir a causa do problema em vez de ficar fazendo alterações no componente. Realizei um teste uma vez que consistia em enviar um XML por e-mail sem nenhum problema. Ao recebe-lo ele era salvo em disco e o e-mail era encaminhado para uma outra conta. O XML recebido por esta outra conta era salvo e disco. Notei que o mesmo continha quebras de linhas.

Bom dia, Só como ponto de partida. 1. Todos os fontes de todas as pastas estão atualizados? 2. Após gerar o XML e assinar, o mesmo não esta sendo alterado?

Bom dia raosistemas, Quando postar o conteudo de um arquivo XML ou TXT, favor postar como anexo. Da forma que você postou fica dificil em lhe ajudar.

Bom dia Claudio, Estou retornando das férias, pretendo durante esta semana e a que vem colocar as coisas em ordem. Vamos precisar sim, que alguem possa realizar os testes.

Bom dia Maurício, Você esta usando a impressão de eventos em Quick Report, correto? Algum item do passo a passo você não executou, ou os seus fontes não estão atualizados, pois nos meus testes esta tudo OK.

Bom dia mmcamilo, Faça a seguinte alteração na Unit: ACBrNFeWebServices.pas Linha 4484 Alterar de: FConfiguracoes.Geral.Save(FPathArqResp, FRetWS); Para: FConfiguracoes.Geral.Save(FPathArqResp, FRetornoWS); Desta forma o arquivo de retorno vai ser salvo exatamente como ele foi enviado pela SEFAZ. Ai você post ele como anexo aqui no fórum para que possamos checar.

Boa tarde Daniel, Segundo a sua imagem, noto que o PDF esta sendo gerado, correto? Se sim, favor pesquisar no fórum, pois segundo alguns colegas, há necessidade de comentar 2 linhas da Unit: ACBrCTeDACTeQR se não me falha a memória. Comentando essas linhas resolvem o problema de Violação de Acesso.

Boa tarde mmcamilo, Por favor, post como anexo os XMLs de consulta e de retorno para que possamos verificar.

Boa noite Jairo, Primeiramente, evite em escrever em caixa alta, pois da a impressão que você esta gritando. Segundo, infelizmente a SEFAZ-MG não é estavel e lembre-se quando a rejeição é: Erro não Calalogado o problema é na SEFAZ. E você pode observar isso, pois você mesmo diz que o problema é intermitente. A recomendação é uma só, ligar, enviar e-mail, etc para a SEFAZ-MG acusando o problema.

Boa noite Daniel, Utilizei o seu XML juntamente com o programa exemplo, em anexo o PDF gerado após clicar no botão Gerar PDF. 35140305988286000189570020000042361330873570.pdf E não obtive nenhum erro. Me diz uma coisa existe na sua maquina as pastas: C:\ERP\DFe

Boa noite Cezar, Da forma que você esta obtendo o numero do protocolo: WebServices.Retorno.Protocolo Só funciona se o lote tiver apenas 1 CT-e. Aconselho você obter o numero do protocolo de forma diferente. Estude o arquivo exemplo: EnviarLote.txt que encontra-se dentro da pasta: ...\Exemplos\ACBrCTe, mais precisamente o código após a linha 45. Note que é executado uma consulta se utilizando do numero do recibo.

Boa noite Cleverson, Segundo o Portal Nacional do CT-e, Espirito Santo ainda é atendido pela SEFAZ Virtual do Rio Grande do Sul.

Boa tarde Ant. Carlos, Verifique se a function getTextoResumoCanhoto esta definida na Unit: ACBrCTeDACTeQR. Caso negativo, favor excluir o arquivo e baixar novamente.

Boa tarde a todos, Favor atualizar os fontes e testar novamente.

Bom dia 7System, Não basta incluir a cidade na Function CodCidadeToProvedor(), Dependendo do provedor há necessidade de alterar a Unit do provedor correspondente. Favor estudar a Unit; ACBrProvedorISSDigital.pas em especial a function GetConfigURL().

Bom dia Thomas, O XML da NF-e, que você esta tentando ler com certeza não foi gerado pelo componente ACBrNFe ou esse XML foi enviado por e-mail e depois foi reenviado, provocando a quebra do arquivo em 2 ou mais linhas.

Bom dia Jairo, Favor estudar a Nota Técnica 2012/004 que trata sobre o EPEC e a SEFAZ Virtual de Contingência. Nela contem uma tabela informando qual a SVC a usar dependo da UF do emitente.