Italo Giurizzato Junior

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

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 Campos, Você chegou a ver os demais retornos além do Protocolo? Temos cStat o xMotivo, entre outros, esse 2 que mencionei você tem código e a sua descrição. Se a nota for rejeitada você saberá o motivo.

Boa tarde Felipe, Você esta criando os componentes ACBr em tempo de execução? Pelo seu relato também pode ser algum problema na sua rotina ao ler os dados do banco de dados, que na segunda vez que faz a leitura não esta lendo. A minha sugestão é que você "debugue" a sua rotina.

Boa tarde Castro, Desativar a regra não tem, mas a solução é muito simples. Com certeza quando você carrega o XML deve estar passando o valor True no segundo parâmetro do LoadFromFile, correto? Sendo assim mude para False ou simplesmente não informe o segundo parâmetro.

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.

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

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 Marcos, Favor anexar o XML da nota que você esta tentado autorizar na SEFAZ bem como o de retorno que acusa a rejeição da mesma. Para que possamos analisar o problema.

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, Você tentou desta forma: NFE.CancelarNFe("51190700070033030197559200000000011520347402","TESTE DE CANCELAMENTO DE NFE PF","70033030197")

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.