Matheus

Boa Tarde Sincronizei os fontes aqui e vi que já adicionou minhas alterações, porém precisei fazer mais uma alteração nesse trecho de código //Linha 1829 if TipoViagem = Padrao then Gerador.wCampo(tcStr, 'AP258', 'CodigoTipoCarga', 01, 01, 0, TipoCargaToStr(CodigoTipoCarga)) else Gerador.wCampo(tcStr, 'AP258', 'CodigoTipoCarga', 01, 01, 1, TipoCargaToStr(CodigoTipoCarga)); Por mais que no manual esteja específico que o campo CodigoTipoCarga seja obrigatório somente para as viagens que não sejam padrão, estava recebendo rejeição do webservice caso enviasse a tag vazia. Se puder avaliar e commitar também esta alteração.

Boa Tarde. Estou desenvolvendo a intergração com a eFrete e tive alguns problemas ao realizar o envio utilizando o componente, fiz algumas alterações no fonte pcnCIOTW_eFrete.pas as alterações são as seguintes: Contratante -> RNTRC : retirar obrigatoriedade, conforme layout campo 0-1 FilialCNPJ: retirar obrigatoriedade, conforme layout campo 0-1 NotasFiscais -> Data: retirar obrigatoriedade, conforme layout campo 0-1 Ajuste no método GerarPagamentos para fechar a tag /pagamentos como adic:Pagamentos Se puderem por favor avaliar as alterações e disponibilizar para sincronização Matheus. pcnCIOTW_eFrete.pas

Boa Tarde. Gostaria de verificar a possibilidade de alteração no fonte ACBrTEFDCliSiTef.pas quanto ao retorno da informação do código de autorização da transação. Recebemos a reclamação de alguns clientes que ao conciliar o extrato da operadora com as informações do sistema o código da autorização não coincidia com as informações do extrato. Avaliando o manual de integração do SiTef, neste indica que o código de autorização é retornado como TipoCampo 135, porém na implementação atual o código é lido do TipoCampo 133, que pelo manual corresponde a informação de NSU do Host autorizador. Anexo deixo a alteração que fiz no fonte para avaliação, bem como o trecho do manual que exemplifica os campos, se puderem verificar e subir a alteração caso não tenha maiores problemas. Matheus. ACBrTEFDCliSiTef.pas

Olá a todos. também estava com esta rejeição na sefaz RS. Mas a partir de hoje a tarde começou autorizar os documentos. Acredito que acertaram algo no ws.

Bom dia. Ainda não existe essa implementação no componente, alterei meus fontes aqui para gerar esta tag, mas encontrei um problema que nem nos xsds disponibilizados pela receita não existe ainda esta tag. Acredito que teremos que esperar ser disponibilizados novos xsds também.

Bom dia. Mesmo atualizando o windows não consegui autorizar o CTe, o cliente em questão que estava reportando o erro era Windows Server 2012 R2. Configurando o componente da maneira abaixo consegui fazer a autorização: CryptLib := cryWinCrypt; HttpLib := httpOpenSSL; XMLSignLib := xsLibXml2; Valeu.

No componente estou configurando libCapicomDelphiSoap

Bom dia. Estou fazendo testes da NFCe versão 4.0 em hambiente de homologação na sefaz do PR. Nos testes obtive rejeição devido a tag urlChave estar sendo mandada com o valor http://www.fazenda.pr.gov.br/ Consultando o site http://nfce.encat.org/consumidor/consulte-sua-nota/ a URL para o PR seria http://www.fazenda.pr.gov.br , ou seja, está sobrando uma "/" no final da URL. Alterei o arquivo ACBrNFeServicos.ini informando o valor URL-ConsultaNFCe=http://www.fazenda.pr.gov.br e autorizou. Se puderem avaliar a alteração e disponibilizar para sincronização.

Valeu, Obrigado!

Bom dia. segue os fontes alterados para avaliação. A propriedade alterada foi a fpCodigoAutorizacaoTransacao da classe TACBrTEFDResp, consequentemente alguns outros fontes tiveram que ser adequados. Respondendo a pergunta do daniel é o campo 13 segundo a procedure TACBrTEFDRespTXT.ConteudoToProperty. ACBrTEFDBanese.pas ACBrTEFDClass.pas ACBrTEFDCliDTEF.pas ACBrTEFDCliSiTef.pas ACBrTEFDTicketCar.pas ACBrTEFDVeSPague.pas

Boa Tarde. Verificamos no layout da NTK que o campo autorização é alfanumérico, porém na classe TACBrTEFDResp a propriedade é tratada como inteiro. Com o tratamento dado quando recebido retorno com caracteres alfanuméricos está ficando zerado. Poderiam avaliar para que seja alterado essa propriedade no componente? ou se existe uma outra maneira de contornar este caso?

Argument out of range.

Bom dia. Ao realizar a consulta de um recibo, caso seja recebido um status diferente de 104, está ocorrendo erro na procedure TNFeRecibo.GerarMsgLog (ACBrNFeWebServices.pas) pois a collection ProtNFe não possui nenhum elemento e nessa procedure é acessado a propriedade FRetorno.ProtNFe.Items[0].xMotivo. Acredito que esteja errado acessar essa propriedade nesse método. Ao invés de acesar FRetorno.ProtNFe.Items[0].xMotivo deveria ser FRetorno.xMotivo, Caso seja essa a implementação correta, deveria ser verificado se existem itens na collection ao acessar a propriedade. Em minha alteração deixei a procedure da seguinte maneira: function TNFeRecibo.GerarMsgLog: String; begin {(*} Result := Format(ACBrStr('Versão Layout: %s ' + LineBreak + 'Ambiente: %s ' + LineBreak + 'Versão Aplicativo: %s ' + LineBreak + 'Recibo: %s ' + LineBreak + 'Status Código: %s ' + LineBreak + 'Status Descrição: %s ' + LineBreak + 'UF: %s ' + LineBreak), [FNFeRetorno.versao, TpAmbToStr(FNFeRetorno.TpAmb), FNFeRetorno.verAplic, FNFeRetorno.nRec, IntToStr(FNFeRetorno.cStat), FNFeRetorno.xMotivo, CodigoParaUF(FNFeRetorno.cUF)]); {*)} end;

segue... ACBrValidador.pas

Bom dia.. Estou utilizando a funcao modulo11 do fonte ACBRValidador e ela não esta funcionando corretamente, debugando o código aqui vi que na função a propriedade Documento não está sendo carregada para a propriedade fsDocto da classe TACBrValidador. Para resolver tive que alterar o nome do parametro da funcao para um nome diferente de "Documento", ou ainda pode ser retirado o with deixando ela da seguinte maneira: function Modulo11(const Documento: string; const Peso: Integer; const Base: Integer): String; Var ACBrVal : TACBrValidador ; begin ACBrVal := TACBrValidador.Create(nil); try ACBrVal.Modulo.Documento := Documento ; ACBrVal.Modulo.MultiplicadorInicial := Peso ; ACBrVal.Modulo.MultiplicadorFinal := Base ; ACBrVal.Modulo.FormulaDigito := frModulo11 ; ACBrVal.Modulo.Calcular ; Result := IntToStr( ACBrVal.Modulo.DigitoFinal ) ; finally ACBrVal.Free; end; end; Estou utilizando o componente no Delphi XE7. Se puderem avaliar e colocar no repositório a alteração.

Cara, acho que abandonamos as tentativas, a única diferença para o meu ambiente é que utilizo capcom. A princípio vou manter o fonte alterado adicionado em meus projetos, nas próximas versões que sincronizar o ACBr eu refaço os testes. Obrigado pela ajuda.

Segue projeto em anexo.. Dentro do projeto tem a ACBRDFeWebServices.pas com um comentário na função EnviarDados; o funcionamento é simples, soh é necessário preencher informações de certificado e senha na unit1.pas e ao rodar a aplicação informar o cnpj para executar a chamada ao webservice. utilizar o delphi XE7. TesteMDFe.rar

Concordo com você Daniel, o xml era montado corretamente, na função EnviarDados ele adicionava o cabeçalho e convertia a string para UTF-8, não faz muito sentido mesmo a alteração que fiz, mas é como se na função ConverteXMLToUTF8 fosse alterado algo na string que causasse o erro, enfim. Outra forma de ajustar sem precisar comentar as diretivas DefinirEnvelopeSoap é alterar a função EnviarDados da seguinte maneira. if not XmlEstaAssinado(FPEnvelopeSoap) then begin if not XmlEhUTF8(FPEnvelopeSoap) then begin FPEnvelopeSoap := '<' + ENCODING_UTF8 + '>' + FPEnvelopeSoap; // Envelope já está sendo montado em UTF8 FPEnvelopeSoap := ConverteXMLtoUTF8(FPEnvelopeSoap); end; end; Continua não fazendo muito sentido, rsrs, mas enfim. Não sei se ajuda alguma coisa no diagnóstico mas as minhas rotinas estão em um servidor de aplicação multicamadas datasnap.

Boa Tarde, Realizei a atualização dos componente hoje a tarde. Continuo encontrando problemas com a chamada para este webservice no Delphi XE 7. Porém fiz uma alteração para teste em um fonte e consegui fazer a consulta com sucesso. Caso no fonte ACBRDfeWebService eu comente os IFDEFS que existem nela e force com que o xml seja montado já com o cabeçalho utf-8 a consulta é realizada com sucesso. procedure TDFeWebService.DefinirEnvelopeSoap; var Texto: String; begin { Sobrescrever apenas se necessário } // {$IFDEF FPC} Texto := '<' + ENCODING_UTF8 + '>'; // Envelope já está sendo montado em UTF8 // {$ELSE} // Texto := ''; // Isso forçará a conversão para UTF8, antes do envio // {$ENDIF} Debugando o código, percebi que com o código dessa maneira, ao executar a procedure EnviarDados, a string não é reformatada ao chamar a função ConverteXMLtoUTF8, somente é retornada a procedure que é passada por parâmetro. if not XmlEstaAssinado(FPEnvelopeSoap) then FPEnvelopeSoap := ConverteXMLtoUTF8(FPEnvelopeSoap); Caso eu descomente o IFDEF na procedure DefinirEnvelopeSoap ao chamar a funcao ConverteXMLtoUTF8, será adicionado o cabeçalho <?xml version="1.0" encoding="UTF-8"?> na string, após isso ao tentar executar o enviardados retorna o erro de falha no schema xml. Provavelmente este IFDEF não possa ser comentado, porém gostaria de uma idéia de vocês caso tenham alguma alternativa para resolver essa encrenca.

Bom dia Ítalo, Nada feito, continua dando falha no schema xml. Uma coisa que percebi abrindo os arquivos gerados no trunk e no trunk2, é que no trunk2 o arquivo está com codificação UTF8, enquanto no arquivo que é salvo pelo componente na versão do trunk, está com codificação ANSI. 20150923150603-ped-cons-soap.xml

Opa, obrigado pelo ajuste. Segue os xmls. 20150922161214-cons-soap.xml 20150922161209-ped-cons-soap.xml

Boa Tarde. Atualizei os fontes pela última vez hoje pela manhã. Estou realizando alguns testes no trunk2 nesse método de consulta de MDFes não encerrados e para mim está retornando o status 215 (Falha no schema XML). Fazendo a mesma consulta na versão do trunk está funcionando normal. Analisando o xml de solicitação que o componente no trunk2 gera, percebi duas situações: 1º - Não está sendo montado a tag versão no cabeçalho do xml, para resolver isso tive que alterar a função DefinirDadosMSG para que sete a propriedade Versao, como segue: procedure TMDFeConsultaMDFeNaoEnc.DefinirDadosMsg; var ConsMDFeNaoEnc: TConsMDFeNaoEnc; begin ConsMDFeNaoEnc := TConsMDFeNaoEnc.create; try ConsMDFeNaoEnc.TpAmb := FPConfiguracoesMDFe.WebServices.Ambiente; ConsMDFeNaoEnc.CNPJ := FCNPJ; // TMDFeConsultaMDFeNaoEnc(Self).CNPJ; ConsMDFeNaoEnc.Gerador.Opcoes.RetirarAcentos := FPConfiguracoesMDFe.Geral.RetirarAcentos; ConsMDFeNaoEnc.Versao := VersaoServico; ConsMDFeNaoEnc.GerarXML; FPDadosMsg := ConsMDFeNaoEnc.Gerador.ArquivoFormatoXML; finally ConsMDFeNaoEnc.Free; end; end; 2 º - Na versão do trunk2, está sendo enviado no cabeçalho do xml a declaraçao "<?xml version="1.0" encoding="UTF-8"?>", o que não ocorre no xml do componente no Trunk, não fiz alteração nisso pois não achei o local que ele está adicionando isso ao xml, mas talvez seja esse o motivo da rejeição. Outro problema que encontrei foi na unit ACBrMDFeWebServices na function GerarMsgLog, a função format que existe nela está passando %s para o código da UF, mas essa propriedade é inteiro, portanto alterei a mesma para ficar como abaixo, se puderem avaliar e jogar a alteração para o SVN. Result := Format(ACBrStr('Versão Layout: %s ' + LineBreak + 'Ambiente: %s ' + LineBreak + 'Versão Aplicativo: %s ' + LineBreak + 'Status Código: %s ' + LineBreak + 'Status Descrição: %s ' + LineBreak + 'UF: %s ' + LineBreak), [FRetConsMDFeNaoEnc.versao, TpAmbToStr(FRetConsMDFeNaoEnc.tpAmb), FRetConsMDFeNaoEnc.verAplic, IntToStr(FRetConsMDFeNaoEnc.cStat), FRetConsMDFeNaoEnc.xMotivo, CodigoParaUF(FRetConsMDFeNaoEnc.cUF)]); Vou anexar os dois xmls gerados no trunk2 e no trunk. Trunk2_20150922151900-ped-cons.xml Trunk_20150922144455-ped-cons.xml

Boa Tarde, Ao chamar a função NotasFiscais.ValidaAssinatura(Msg) também estava retornando o erro "CoIitialize Nao Foi Chamado", alterei a função ValidaAssinaturaMSXML para chamar os procedimentos CoInitialize(nil); e CoUninitialize e resolveu; Se puderem avaliar e subir para o repositório a alteração, ou ainda souberem uma maneira alternativa de evitar esse erro, minha rotina está num servidor datasnap com rest.

Boa Tarde, Acredito que alguns erros que estão ocorrendo ao fazer o decode da string seja devido a versão do indy, a versão que utilizo é a versão 10, Utilizo o delphi 7 e a um tempo atrás tive que atualizar devido alguns problemas com a versão nativa do delphi 7 estar desatualizada para se trabalhar com IMAP, talvez tenha algum bug também nessa versão no componente TIdDecoderMINE, pois para mim está ok o processo de fazer o decode da string e descompactar. Para quem utiliza as versões mais recentes do delphi, o indy já deve estar atualizado.

É exatamente deste site ai que baixei ela.