Italo Giurizzato Junior

Bom dia Juliano, Por favor anexe o retorno da consulta de um MDF-e apenas autorizado, um outro que foi cancelado e por fim de outro que foi encerrado para que eu possa analisar como esta vindo esses retornos.

Bom dia Marcos, Eu orientei ao pessoal responsável pelo ACBrMonitor fazer com que durante a instalação os schemas fossem salvos em pastas diferentes. Preciso confirmar se foi feito esse ajuste. Agora me diga, qual versão do ACBrMonitor você esta usando?

Boa tarde Melissa, Favor atualizar e fazer novos testes.

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.