Italo Giurizzato Junior

Bom dia Josafar, Caso você tenha 5 UF (percurso) entre a UF Origem e UF Destino é simples, basta executar 5 vezes o trecho abaixo (uma para cada UF). with Ide.infPercurso.Add do begin UFPer:= mskUFPer.Text; end; O Add vai acionar a UF cada vez que é executado, portanto o valor de mskUFPer.Text tem que mudar pra cada vez que ele é executado. Exemplo da minha aplicação: j := DM_MDF.Percursos.RecordCount -1; // Checa a quantidade de UF de Percurso na tabela Percursos if j >= 0 then begin DM_MDF.Percursos.First; // Posiciona na primeira UF for i := 0 to j do begin with Ide.infPercurso.Add do begin UFPer := DM_MDF.PercursosUFPerc.AsString; // Lê da tabela Percursos o valor do campo UFPerc end; DM_MDF.Percursos.Next; // Avança para a próxima UF end; end;

Bom dia João, Eu não sei porque tem provedor que não defini o atributo ID como sendo "Id", paciência (para não escrever outra coisa). O grande problema do cancelamento é que temos de forma resumida o seguinte layout: <CancelarNFseEnvio> <=== Nível 1 <Pedido> <=== Nível 2 <InfPedidoCancelamento Id="valor do ID"> <=== Nível 3 (...) </InfPedidoCancelamento> <Signature> <=== Nível 3 (...) </Signature> </Pedido> </CancelarNFseEnvio> Se ID for "id" ocorre erro ao usar o libCapicom, para que o erro não ocorra não podemos atribuir o valor do ID ao atributo URI da assinatura. Por outro lado se usarmos o libWinCrypt o erro não ocorre e o valor do ID é atribuído a URI. Mas ai surge um segundo problema. Note que o grupo <Signature> se encontra no nível 3 da estrutura, com o libCapicom a assinatura é realizada e o grupo <Signature> é inserido no local correto. Por outro lado com o libWinCrypt a assinatura é realizada mas o grupo <Signature> é colocada no nível 2, ou seja ficando abaixo do </Pedido> (fechamento do grupo Pedido). Foi feita uma alteração para contornar isso, mas me parece que essa alteração esta gerando uma assinatura invalida.

Bom dia Felipe, Primeiro: o cliente que rejeitou a carga deve emitir uma NF-e caso ele seja contribuinte ou uma CRM - Carta Remessa de Mercadoria a titulo de devolução. Segundo: a transportadora deverá emitir um novo CT-e e utilizar como documento originário a NF-e ou a CRM emitida por esse cliente que agora vai figurar no CT-e como sendo o remetente da carga e quem era antes o remetente passa a ser o destinatário. Portanto você não vai usar o mesmo CT-e e muito menos emitir uma carta de correção.

Boa noite Renan, É bem provável que seja publicado alguma Nota Técnica ou cada Estado em seu site vai constar algo informando sobre a obrigatoriedade.

Willian, Você tem certeza que atualizou todos os fontes de todas as pastas? Não tem nenhum fonte com uma bolinha vermelha em seu ícone?

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

Boa tarde Marcelo, Favor ler essa postagem:

Claer, Você tem o Fast Report instalado no seu Delphi?

Boa tarde Willian, Após atualizar os fontes, você reinstalou os componentes? Marcou a opção para apagar os arquivos antigos?

Boa tarde Claer, Você atualizou todos os fontes de todas as pastas? Marcou a opção para apagar arquivos antigos ao reinstalar novamente? Pois bem, repita esses 2 passos.

Pessoal, Favor ler essas postagens:

Boa tarde a todos, Renato, é preciso debugar para saber exatamente o momento que essa propriedade não recebe a informação desejada. Almir, você sabia que o WebService DownloadNFe faz um bom tempo que foi desativado? Data de desativação dos Web Services NfeConsultaDest e NFeDownloadNF: 31/05/2017

Boa tarde Almir, Favor atualizar novamente.

Vou analisar os fontes para ver se descubro o motivo desse erro.

Boa tarde Leo, Primeiramente, procure anexar o XML e não postar como parte do texto da postagem. Favor anexar o XML do RPS que foi enviado.

Boa tarde, Favor atualizar todos os fontes, reinstale os componentes através do ACBrInstall selecionando a opção para apagar os arquivos antigos e tente cancelar novamente.

Boa tarde a todos, Vamos cortar mais algumas gorduras, chegou a vez da Consulta ao Recibo. Tanto a unit que gera o XML de consulta bem como a que lê o retorno foram generalizadas e agora se encontram dentro da pasta PCNComum. Como nem tudo são flores, ocorreu quebra de código, abaixo um exemplo de correção a ser feita em suas aplicações: for i := 0 to (ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Count - 1) do begin sDataHora := DateTimeToStr(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items.dhRecbto); sProtocolo := ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items.nProt; sStat := IntToStr(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items.cStat); sMotivo := ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items.xMotivo; sNotaFiscal := Copy(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items.chNFe, 26, 3) + '.' + Copy(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items.chNFe, 29, 3) + '.' + Copy(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtNFe.Items.chNFe, 32, 3); MemoStatus.Lines.Add(' ' + sNotaFiscal + ' ' + sProtocolo + ' ' + sDataHora + ' ' + sStat + ' - ' + sMotivo); end; Alterar para: for i := 0 to (ACBrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Count - 1) do begin sDataHora := DateTimeToStr(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items.dhRecbto); sProtocolo := ACBrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items.nProt; sStat := IntToStr(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items.cStat); sMotivo := ACBrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items.xMotivo; sNotaFiscal := Copy(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items.chDFe, 26, 3) + '.' + Copy(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items.chDFe, 29, 3) + '.' + Copy(ACBrNFe.WebServices.Retorno.NFeRetorno.ProtDFe.Items.chDFe, 32, 3); MemoStatus.Lines.Add(' ' + sNotaFiscal + ' ' + sProtocolo + ' ' + sDataHora + ' ' + sStat + ' - ' + sMotivo); end; Notem que devemos trocar o ProtNFe por ProtDFe e chNFe por chDFe (não coloquei em negrito todos, mas acho que ficou claro).

Boa tarde Henrique, A mensagem de erro diz que o elemento Signature é inesperado, logo algo esta sendo assinado e não deveria. No arquivo Publica.ini que se encontra no repositório a configuração de assinatura é a seguinte: [Assinar] RPS=0 Lote=1 URI=0 Assinar somente o Lote.

Walter, Nesse XML consta o nome da seguradora, o responsável e o numero da apólice? Eu não achei. Sendo assim o DACTE que você anexou que me parece se referir ao XML contem informações que não consta no XML, indo contra o que esta escrito no item 1.1 do Manual do DACTE versão 1.01 O que você deseja fazer? Atender um capricho do seu cliente e rezar para ele não ser pego em uma fiscalização e depois culpar você que fez algo que não podia ou mostrar para ele que essa outra transportadora esta fazendo errado? Deixe claro para ele que agora essa informação tem que constar no MDF-e, logo ele vai ter que emitir o MDF-e também. Se a carga do caminhão compreende 50 CT-e basta emitir somente UM MDF-e, pois este vai relacionar todos os CT-e. Logo imprimir uma folha a mais não vai aumentar tanto assim os custos do seu cliente. Eu prefiro imprimir uma folha a mais do que ter que pagar uma multa por estar emitindo um DACTE com informações que não existem no XML que foi assinado e autorizado pela SEFAZ.

Bom dia a todos, Acabo de enviar para o repositório um schema chamado: tiposBasico_v4.00_OPENSSL que deve ser renomeado para tiposBasico_v4.00 por aqueles que se utilizam do OpenSSL. A alteração que fiz visa resolver o problema da Unidade de Medida com apenas 2 caracteres. Fico no aguardo de um retorno.

Bom dia Arce, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Walter, Peça para o seu cliente conseguir o XML dessa outra transportadora. Pois para que uma informação seja impressa no DACTE precisa constar no XML. Na página 5 do Manual do DACTE versão 1.01 temos: 1.1 Campos do DACTE O conteúdo dos campos do DACTE deverá ter a sua origem nas respectivas TAG XML do CT-e, quando conhecidos no momento da solicitação de autorização de uso. Não poderão ser impressas informações que não constem do arquivo da CT-e. Conforme dito antes o que é impresso no DACTE tem que constar no XML do CT-e. A partir da versão 3.00 o CT-e não contem mais as tags referentes ao seguro, pois elas agora são informadas no MDF-e também versão 3.00 Na página 187 do Manual do CT-e versão 3.00 você vai encontrar o grupo <seg> (#142) Informações de Seguro de Carga, mas note que esse grupo faz parte do grupo <infCTeNorm> (#131) Grupo de Informações do CT-e OS Normal. Na página 167 do mesmo manual temos o grupo <infCTeNorm> (#241) Grupo de Informações do CT-e Normal e Substituto e dentro deste grupo não existe o grupo <seg>. Temos que tomar cuidado com esse manual pois ele contem o layout do CT-e (modelo 57) que se refere ao transporte de carga e o layout do CT-e OS (modelo 67) que se refere a OS = Outros Serviços: Transporte de Pessoas, Transporte de Valores e Excesso de Bagagem. Resumindo: No CT-e versão 3.00 não se informa os dados do Seguro, essas informações devem ser informadas agora no MDF-e 3.00 No CT-e OS versão 3.00 devemos informar os dados do Seguro.

Boa tarde Arce, Acho que você esqueceu da unit pcesS5013.pas

Boa tarde Valdir, Acabei de enviar tudo, favor atualizar os fontes e reinstale usando o ACBrInstall_Trunk2, não esqueça de marcar a opção para apagar os fontes antigos.

Boa tarde, Nesses vários anos que dou manutenção no componente ACBrNFSe notei o seguinte: 1. Os provedores que seguem o layout da ABRASF seja a versão 1 ou 2 não conseguem seguir um padrão. 2. Tem provedor que não consegue manter um padrão entre as cidades que ele atende. Como você pode ver, é uma zorra a NFS-e. Tem um provedor que para uma determinada cidade se faz necessário incluir o NameSpace no inicio do XML do RPS caso contrario o mesmo não é aceito. O pior que essa exigência é só para uma cidade, as demais não precisam. Não vejo a hora da NFS-e Padrão Nacional começar pra valer, assim acaba com toda essa palhaçada.