Italo Giurizzato Junior

Boa tarde Snoopyfael, Muito obrigado pela colaboração, fiz uma pequena mudança, o novo tipo de forma de pagamento bem como as suas funções coloquei na unit pcnConversaoBPe. Já enviei para o repositório.

Boa tarde Otimizy, Chegou a testar no ambiente de produção?

Boa tarde Josenilson, Esse provedor ele esta implementado com o nome de NFSeBrasil, no arquivo Cidades.ini temos as cidades: Matozinhos, Conselheiro Lafaiete, Curvelo, Três Marias, entre outras. Procure a cidade em questão no arquivo Cidades.ini que utiliza o provedor, caso ela não consta acrescente aos modelas das citadas acima. Faça os testes utilizando o programa exemplo do componente ACBrNFSe. Se tudo funcionar a contento favor anexar o arquivo Cidades.ini com a cidade que você acrescentou caso houve a necessidade.

Bom dia Juliano, A rotina de tratamento de resposta da consulta que você alterou no ACBrMDFeWebServices é a mesma na NF-e e CT-e. Note que podemos dividir o XML de retorno a consulta em 3 partes. Na primeira temos a situação atual do documento que segundo o seu exemplo acusa que o mesmo esta cancelado. Na segunda temos o grupo <protMDFe> que contem as informações referente ao protocolo de autorização. A terceira parte só vai constar se o MDF-e possuir eventos vinculados a ele, logo podemos ter uma lista, ou seja, o grupo <procEventoMDFe> pode aparecer diversas vezes. No seu exemplo como o MDF-e foi cancelado temos apenas um evento que é o de cancelamento e suas informações estão dentro do grupo mencionando acima. Pela rotina atual temos o seguinte: // Na linha abaixo temos o protocolo da situação atual do MDFe, // esse protocolo pode ser de autorização ou de cancelamento ou de encerramento numProtAtual := ACBrMDFe1.WebServices.Consulta.Protocolo; // Na linha abaixo temos o protocolo de autorização numProtAutor := ACBrMDFe1.WebServices.Consulta.protMDFe.nProt; // Abaixo temos um loop onde temos o numero do protocolo dos eventos vinculados ao MDFe for i := 0 to ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Count -1 do numProtEvento[ i ] := ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Items[ i ].RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt; No meu entendimento ao realizar a consulta, dependendo do que deseja você vai ter que escolher uma das 3 formas acima para obter o numero do protocolo (por exemplo).

Bom dia Sergio, Muito obrigado pela colaboração, já enviei para o repositório.

Eduardo, Favor atualizar os fones, fiz uma alteração no arquivo INI do provedor.

Leo, Favor atualizar os fontes e faça novos testes.

Bom dia Vinício, Na seção XML altere o valor dos campos abaixo: Cabecalho=0 Dados=0

ALA, Você já escreveu a unit que vai gerar o XML? Depois dessa unit pronto, você parte para o arquivo INI. No arquivo INI é preciso informar as URLs dos SoapAction, as URLs de homologação e de produção bem como os layout dos Envelopes de cada serviço (Enviar, Consultar, Cancelar, etc). Tendo as URLs de homologação e de produção no WSDL descobrimos as URLs do SoapAction e as vezes até o layout dos Envelopes.

Bom dia Leandro, No XML gerado pelo componente consta o Id e não consta o xmlns que você disse que removeu.

Bom dia, Fiz uma alteração no arquivo Recife.ini, favor atualizar os fontes e faça novos testes.

Bom dia ALA, Por favor vamos seguir as regras do fórum. Não poste conteúdo de arquivos como parte do texto e sim como anexo. O que você postou não é um XML e sim um WSDL. Esse WSDL apresenta a estrutura do XML que ele espera receber. Na falta de um manual que apresente o layout legível de como é o XML, você pode usar o WSDL para escrever a unit pnfseNFSeW_SigISS, que é a responsável por gerar o XML.

Bom dia Eduardo, O problema com o cancelamento esta ocorrendo com a sua aplicação, correto? Se sim, verifica se a sua aplicação esta utilizando o arquivo BHISS.ini atualizado.

Boa tarde Eduardo, Favor atualizar os fontes.

Boa tarde Guerreiro, Pela minha analise, esse provedor segue a versão 2 do layout da ABRASF, menos mau. O problema acredito ser a questão da tag chamada Integridade que em vez de ser uma assinatura digital é feito um hash do XML. A geração do XML já temos pronta, o que precisa ser feito é criar um arquivo INI para esse provedor e fazer com que o componente reconheça ele. Sugestão para o nome do enumerador: proiiBrasil

Boa tarde Raylan, Favor atualizar os fontes e faça novos testes. Note que fiz alterações no arquivo INI do provedor.

Boa tarde Sergio, Me envia no privado um XML que sem a sua alteração estava imprimindo 2 folhas.

Boa tarde Doni, Favor atualizar os fontes.

Bom dia Nicolas, Entre na nossa biblioteca pelo link: http://svn.code.sf.net/p/acbr/code/tools/DFe/CTe/NT/2019/ E leia atentamente a Nota Técnica que trata sobre o Comprovante de Entrega. Um breve resumo: Quem emite esse evento é a transportadora, latitude e longitude é opcional. Leia com muita atenção a descrição do campo: hashEntrega.

Boa noite Raylan, O problema é no envio ou na consulta? Na postagem anterior você anexou arquivos referente a consulta, favor anexar o arquivo soap referente a consulta da NFS-e por RPS.

Boa noite Doni, Favor atualizar os fontes, reinstalar a suíte ACBr e faça novos testes.

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

Igor, veja essa rotina: OpenDialog1.Title := 'Selecione o CTe'; OpenDialog1.DefaultExt := '*-cte.xml'; OpenDialog1.Filter := 'Arquivos CTe (*-cte.xml)|*-cte.xml|Arquivos XML (*.xml)|*.xml|Todos os Arquivos (*.*)|*.*'; OpenDialog1.InitialDir := ACBrCTe1.Configuracoes.Arquivos.PathSalvar; if OpenDialog1.Execute then begin ACBrCTe1.Conhecimentos.Clear; ACBrCTe1.Conhecimentos.LoadFromFile(OpenDialog1.FileName); end; OpenDialog1.Title := 'Selecione o CTe'; OpenDialog1.DefaultExt := '*-cte.xml'; OpenDialog1.Filter := 'Arquivos CTe (*-cte.xml)|*-cte.xml|Arquivos XML (*.xml)|*.xml|Todos os Arquivos (*.*)|*.*'; OpenDialog1.InitialDir := ACBrCTe1.Configuracoes.Arquivos.PathSalvar; if OpenDialog1.Execute then begin ACBrCTe1.Conhecimentos.LoadFromFile(OpenDialog1.FileName); ACBrCTe1.Conhecimentos.ImprimirPDF; end; Inicialmente ela pede o primeiro XML, limpa o componente e carrega o XML. Depois pede o segundo XML (chave diferente do primeiro), carrega o XML e executa o método ImprimirPDF. Desta forma essa rotina gerou o PDF dos dois DACTE e salvou eles na pasta definida em PathPDF. A única diferença é que não gera um único PDF com os dois DACTE que acredito que é o que você deseja. Mas talvez seria possível criar uma rotina para gerar um ZIP com todos os PDF.

Boa tarde Igor, Analisando o código abaixo que se encontra na unit ACBrCTeDACTeRLClass, o componente deveria salvar em disco os PDF de cada CT-e carregado no componente. O local onde será salvo é definido na propriedade de configuração PathPDF e os nomes dos PDF seguem o seguinte formato: <chave>-cte.pdf for i := 0 to TACBrCTe(ACBrCTe).Conhecimentos.Count - 1 do begin FPArquivoPDF := PathWithDelim(TACBrCTe(ACBrCTe).DACTE.PathPDF) + OnlyNumber(TACBrCTe(ACBrCTe).Conhecimentos.Items[i].CTe.infCTe.ID) + '-cte.pdf'; TACBrCTe(ACBrCTE).Conhecimentos.Items[i].NomeArqPDF := FPArquivoPDF; // if i < TACBrCTe(ACBrCTe).Conhecimentos.Count - 1 then // FPArquivoPDF := FPArquivoPDF + sLinebreak; case TamanhoPapel of tpA5: TfrmDACTeRLRetratoA5.SalvarPDF(Self, TACBrCTe(ACBrCTe).Conhecimentos.Items[i].CTe, FPArquivoPDF); else TfrmDACTeRLRetrato.SalvarPDF(Self, TACBrCTe(ACBrCTe).Conhecimentos.Items[i].CTe, FPArquivoPDF); end; end;

Boa tarde Dercide, Realmente parece que não esta obedecendo a configuração. Vou analisar o problema.