Italo Giurizzato Junior

Bom dia a todos, Na pasta: ...\Exemplos\ACBrDFe\Schemas\CTe temos os schemas: cteTiposBasico_v3.00.xsd cteTiposBasico_v3.00_Homologacao.xsd O schema cteTiposBasico_v3.00_Homologacao contempla as mudanças ocorridas na estrutura do XML do CT-e na versão 3.00a, já o outro não contempla. Até o dia 25/08/2019 devemos usar o arquivo cteTiposBasico_v3.00 em nossos clientes uma vez que eles estão emitindo os CT-e em produção. Para aqueles que desejam realizar os testes no ambiente de Homologação deverão seguir os passos abaixo: rename cteTiposBasico_v3.00.xsd cteTiposBasico_v3.00_Producao.xsd rename cteTiposBasico_v3.00_Homologacao.xsd cteTiposBasico_v3.00.xsd A partir do dia 26/08/2019 deveremos enviar para os nossos clientes o arquivo cteTiposBasico_v3.00_Homologacao renomeado para cteTiposBasico_v3.00 Isso se a SEFAZ comprir com as datas publicadas.

Bom dia, É muito simples, você tem uma rotina que lê os dados do conhecimento do banco de dados e alimenta o componente, correto? Na sua rotina tem algo do tipo: with ACBrCTe1.Conhecimentos.Add.CTe do begin (...) end; A propriedade Conhecimentos é uma lista quando executamos o Add.CTe um conhecimento é adicionado a essa lista. Logo para você enviar um lote com 10 conhecimentos (por exemplo) basta executar a sua rotina 10 vez, é obvio que a cada execução ela tem que pegar do banco de dados as informações do próximo conhecimento.

Boa tarde pessoal, Com a versão 3.00a do MDF-e temos um novo evento chamado Inclusão de DF-e. Apesar do nome DF-e, no momento só podemos incluir NF-e e não CT-e. Vale lembrar que o MDF-e só pode conter NF-e ou CT-e, ambos já mais. Para que possamos informar NF-e em um MDF-e o emitente do mesmo tem que ser um transportador de carga própria. Por outro lado para que possamos informar CT-e o emitente do MDF-e tem que ser um prestador de serviço de transporte, ou seja, uma transportadora. Portanto já deu para perceber que esse evento no momento não poderá ser utilizado por uma transportadora. Dito isso vamos ao que interessa: Para que o emitente possa enviar o evento de Inclusão de DF-e no MDF-e tem que constar a tag: indCarregaPosterior com o valor 1. Abaixo temos um fragmento de arquivo INI do MDF-e para quem utiliza o ACBrMonitor mostrando como fazer para que a tag acima seja gerada: [ide] (...) indCarregaPosterior=1 ; se o valor for zero ou essa linha não existir a tag não será gerada. (...) Para quem utiliza o componente como alimenta-lo para emitir o MDF-e com a tag em questão: (...) Ide.indCarregaPosterior := tiSim; // se o valor for tiNao ou não constar essa linha a tag não será gerada. (...) Vamos agora ver como que fica o arquivo INI do evento de Inclusão de DF-e para que usa o ACBrMonitor: [EVENTO] idLote=1 [EVENTO001] chMDFe= chave do MDF-e cOrgao= Codigo da UF CNPJCPF= CNPJ ou CPF do emitente dhEvento=24/07/2019 17:04:00 tpEvento=110115 nSeqEvento=1 ; (sequencial, para o proximo DF-e tem que ser 2 e assim por diante) nProt= numero do protocolo de autorização do MDF-e cMunCarrega= código IBGE do municipio onde ocorreu o carregamento das mercadorias referente ao DF-e a ser incluido xMunCarrega= descrição do municipio ; xxxx pode variar de 0001 até 2000 [infDocxxxx] cMunDescarga= código IBGE do municipio onde ocorrerá o descarregamento das mercadorias referente ao DF-e a ser incluido xMunDescarga= descrição do municipio chNFe= chave da NF-e a ser incluida Para quem utiliza o componente, abaixo temos um exemplo de como enviar o evento em questão: ACBrMDFe1.EventoMDFe.Evento.Clear; with ACBrMDFe1.EventoMDFe.Evento.New do begin infEvento.chMDFe := ChaveMDFe; infEvento.CNPJCPF := CNPJCPFEmitente; infEvento.dhEvento := now; infEvento.tpEvento := teInclusaoDFe; infEvento.nSeqEvento := 1; infEvento.detEvento.nProt := nProtocoloAutorizacao; infEvento.detEvento.cMunCarrega := cCodigoMunicipio; infEvento.detEvento.xMunCarrega := xDescricaoMunicipio; InfEvento.detEvento.infDoc.Clear; // o bloco abaixo poderá se repetir por até 2000 vezes with InfEvento.detEvento.infDoc.New do begin cMunDescarga := cCodigoMunicipio; xMunDescarga := xDescricaoMunicipio; chNFe := ChaveNFe; end; end; ACBrMDFe1.EnviarEvento( 1 ); // 1 = Numero do Lote

Boa tarde, Pela imagem que você anexou a linha que esta ocorrendo erro é a linha de numero 431, correto? Pois bem, essa linha nos fontes que se encontram no repositório é de numero 444. Outra coisa, no seu fonte consta a chamada da função StrToSchemaNFe sendo que no fonte que se encontra no repositório essa função esta com outro nome, ou seja, StrToSchemaDFe. Resumindo, você deve ter copia dos fontes do ACBr em outras pastas e o Delphi os esta encontrando.

Boa tarde Norton, Talvez o nome do parâmetro no método Enviar esteja fazendo confusão. ASincrono -> a letra "A" vem de auxiliar, logo esse parâmetro se refere ao modo Síncrono, como o seu valor padrão é Falso o modo de envio é Assíncrono.

Boa tarde Emerson, Além de copiar os pacotes, você copiou também os fontes do componente?

Boa tarde Cesar, Se você utiliza o ACBrMonitor por favor aguarde mais um pouco que ainda esta semana estaremos disponibilizando no Manual do mesmo um exemplo de como montar o arquivo INI do mesmo. Agora se você utiliza o componente, também iremos publicar em Conhecimentos - CT-e/CT-e OS como passar os dados para o componente.

Bom dia Mateus, Como existe mais de uma SEFAZ-Autorizadora se tratando de CT-e com certeza para a SEFAZ que você esta enviando ela ainda não implementou as mudanças. Favor entrar em contato com a SEFAZ e questione sobre quando será liberado o ambiente de homologação com as mudanças referente a versão 3.00a

Bom dia Eduardo, Os códigos e enumeradores dos eventos do CT-e agora estão na unit pcteConversaoCTe.

Bom dia Eduardo, Favor atualizar os fontes e faça novos testes.

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 Lopes, Simples: 1. Carregue o XML do MDF-e assinado através do método: LoadFromFile; 2. Execute o método Consultar. Se o MDF-e que foi enviado foi autorizado, ao realizar a consulta será retornado o protocolo de autorização e o mesmo será incluído no XML assinado. Agora se ele não foi autorizado, no retorno a consulta temos o motivo da rejeição.

Bom dia Jhonlenon, Na sua postagem você escreveu: "Boa tarde, desde do dia 18 de Julho que não estou conseguindo nem consultar NF-e atraves do Manifesto do Destinatario, já atualizei ACBr e schermas e mesmo assim não funciona...print do erro abaixo. " Vamos fazer algumas pequenas correções: Primeiramente, não existe Manifesto do Destinatário e sim Manifestação do Destinatário. Segundo, você não realiza uma consulta da NF-e através da Manifestação, pelo simples fato da Manifestação do Destinatário ser um evento onde você informa a SEFAZ se comprou ou não, se já recebeu ou não a mercadoria referente a uma nota cuja chave da mesma foi informada nesse evento. Terceiro, a consulta que você se refere é feita através do DistribuicaoDFe que a principio retorna um resumo das notas emitidas contra o seu CNPJ ou o XML completo da nota caso esta tenha sido Manifestada pelo destinatário, ou seja, o evento de Manifestação do Destinatário tenha sido enviado. Agora, que culpa temos nós se o Ambiente Nacional que é o responsável pelos serviços do DistribuicaoDFe e Manifestação do Destinatário estar Inativo? Eu tenho o costume diário de acessar os Portais Nacionais da NF-e, CT-e bem como o Portal da SEFAZ-Virtual do Rio Grande do Sul em busca de algum Manual ou Nota Técnica nova que traga alguma alteração na montagem dos XMLs enviados para os Webservices. E com isso fico informado se vem novidades pela frente ou não. E também, diariamente atualizo todos os fontes de todas as pastas. Para finalizar, a imagem com o erro que você anexou diz que o serviço da SEFAZ esta inativo ou inoperante e pede para tentar mais tarde. Pelo menos para mim essa mensagem não deixa nenhuma duvida do que esta ocorrendo.

Bom dia Alexsandro, Muito obrigado pelos arquivos, ainda não consegui resolver o problema do erro 500. Verifica com o provedor se o RPS e o Lote devem ser assinados? Pois segundo os Schemas eles devem ser assinados e nesses exemplos não consta o grupo <Signature> que se refere a assinatura digital.

Bom dia Chaves, Favor atualizar e reinstalar novamente.

Bom dia a todos, Desculpe pela falha, já esta no repositório a unit que contem a definição do tipo TUnidade. Favor atualizar novamente e fazer a reinstalação.

Bom dia Lopes, Favor anexar o XML de envio do pedido de encerramento.

Boa noite Josenilson, Acredito que esse erro é porque a empresa não esta cadastrada para usar o webservice. Se tratando de NFS-e, alguns provedores exigem um cadastro para que a empresa possa emitir a nota via site e um outro cadastro para poder emitir via webservice.

Boa noite Flavio, A rotina que assina o RPS é a mesma que assina o Lote, consequentemente o certificado digital utilizado é o mesmo nas duas assinaturas. Amanhã vou analisar o que possa esta ocorrendo e vou enviar uma possível correção para o repositório.

Boa tarde Diane, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada. Note que o arquivo INI do provedor contem algumas alterações comparado com o que você anexou. Atualiza tudo e faça novos testes.

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

Alexsandro, Eles podem ter alterado alguma coisa no webservice para essa cidade que esta provocando esse erro. Tenta entrar em contato com o provedor e solicite um XML completo, ou seja, com a tag <Envelope> para que possamos comparar com o que o componente esta gerando. Desta forma da para descobrir o que esta errado.

Boa tarde a todos, A implementação do evento no componente já esta sendo feita, acredito que até o final desta semana eu disponibilizo para vocês possam realizar os testes.

Boa tarde André, O valor de DM.qryManifestociot.AsString não é uma string vazia?