IvanGoncalves

Oi @Italo Jurisato Junior Perfeito, dessa forma consigo pegar o retorno. Agradeço e parabéns, você sempre paciente e prestativo. Obrigado mesmo.

@Italo Jurisato Junior Referente ainda sobre o retorno, fiz as modificações. Porém, tenho o habito de gravar todos as respostas do WS no banco de dados. Ai fiz um envio que retornou um erro lá do SEFAZ: "760 - Rejeição: INSS deve ser preenchido para tomador pessoa jurídica" Você comentou sobre utilizar da seguinte forma: objACBrCTe.Conhecimentos.Items.CTe.procCTe.cStat Funciona certinho desde que a resposta seja: 100 - Autorizado o uso do CT-e Como eu faria para obter os valores quando há rejeição por parte do SEFAZ, pois nesse caso "objACBrCTe.Conhecimentos.Items.CTe.procCTe.cStat = 0".

Entendi @Italo Jurisato Junior Perfeito, funcionou como você falou, realmente estava fazendo de forma errada. Muito obrigado.

Olá @Cleonir parabéns pelo trabalho, vi o PDF, ficou muito bom. Uma dúvida, como faço para instalar, já que o instalador do ACBr ainda não contempla esse novo layout? Grato.

Olá @Italo Jurisato Junior Muito obrigado pela resposta. Realmente dessa forma consigo obter os valores, desde que ocorra de forma normal, sem erros. Ai me deparei com o seguinte problema, o primeiro CT-e que enviei, foi autorizado, porém, não consegui obter o retorno. Tentando enviar novamente, ocorre o erro 204, duplicidade, normal nessa situação, porém, com o modo assíncrono, consigo mesmo assim obter o número do recibo (objACBrCTe.WebServices.Retorno.CTeRetorno.nRec), a chave de acesso (objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Items.chCTe) e o conteúdo do arquivo XML autorizado (objACBrCTe.Conhecimentos.Items.XML). Poderia fazer uma consulta, porém, não tenho o número do recibo ou a chave de acesso. A questão toda é que tanto na NF-e quanto no CT-e, se ocorre erro de duplicidade, consigo fazer uma consulta e verificar se realmente é duplicidade ou se trata de um outro documento (verificando o digest value) e sigo a emissão normalmente, ficando transparente para o usuário. Minha dúvida é, consigo obter essas informações enviando o CT-e OS? ou por se tratar de envio síncrono isso não é possível? Detalhe: mesmo sendo síncrono, o ACBr salva o arquivo XML de retorno no computador (com o erro 204), apenas não estou conseguindo buscar as informações desse arquivo através dos objetos do componente. Grato.

Olá pessoal, estou nos finalmentes da adaptação do nosso software para atender também o CT-e OS. Minha dificuldade está em obter o retorno através do componente (obs.: o arquivo XML de retorno está sendo salvo no computador normalmente). Bom, para o CT-e modelo 57, consigo (com o mesmo código fonte) obter o retorno, mas para o CT-e modelo 67 não consigo, pois os objetos não estão preenchidos. Segue trecho do código fonte exemplificando como estou obtendo o retorno: for i:= 0 to objACBrCTe.Conhecimentos.Count - 1 do begin ... ... ... ParamByName('RECIBO').AsString := objACBrCTe.WebServices.Retorno.CTeRetorno.nRec; ParamByName('CHAVE').AsString := objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Items[i].chCTe; ParamByName('STATUS').AsInteger := objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Items[i].cStat; ParamByName('MOTIVO').AsString := objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Items[i].xMotivo; ParamByName('PROTOCOLO').AsString := objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Items[i].nProt; ParamByName('DATA_HORA').AsDateTime := objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Items[i].dhRecbto; ParamByName('DIGEST_VALUE').AsString := objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Items[i].digVal; ParamByName('VER_APLIC').AsString := objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Items[i].verAplic; ParamByName('XML').AsMemo := UTF8ToString(objACBrCTe.Conhecimentos.Items[i].XML); // conteudo completo do arquivo XML ... ... ... end; Se eu verificar a propriedade "objACBrCTe.WebServices.Retorno.CTeRetorno.ProtCTe.Count", esta zerado. Existe alguma outra forma que eu não saiba para obter estes campos? Meus fontes estão atualizados. Já estou "debugando" o componente para tentar entender o que pode estar acontecendo, mas até agora nada, agradeço se alguém puder ajudar. Vou continuar a procura. Obrigado.

@Juliomar Marchetti Muito obrigado, já testei e está funcionando certinho.

Não estava conseguindo imprimir o DANFC-e com alguma instrução de cancelamento, mesmo marcando a propriedade "ACBrNFe.DANFE.NFeCancelada" para "True". Estou utilizando o fortes e uma impressora Epson TM-T20. Ao abrir o Form (ACBrDANFCeFortesFr.pas), identifiquei que a "Label" com a instrução de cancelamento, esta com a fonte vermelha, o que para mim não faz muito sentido levando em consideração que na maioria dos casos, a DANFC-e será impresso em impressora térmica. Mas tudo bem, pois identifiquei também que na verdade são 2 layout: um normal e outro para a NFC-e cancelada. O problema que nessa mesma unit, o método ImprimirDANFECancelado esta implementada, mas não foi implementado nas classes que gerenciam a impressão dos DF-e. Sugestão 1) Mudar a fonte da instrução "NF-e Cancelada" para preto e alterar também a própria descrição para "NFC-e Cancelada". Sugestão 2) Implementar o método "ImprimirCancelado" conforme as units em anexo. Sugestão 3) Implementar as sugestões 1 e 2. Se alguém tiver mais alguma sugestão, agradeço. ACBrAlteracoesDANFCe.rar

Por enquanto estou armazenando no banco de dados e buscando no momento de montar o XML. Considerando que dificilmente o nosso cliente terá mais de uma solução TEF no mesmo computador, por enquanto irá resolver o problema, pois também não consegui essa informação do componente ACBr, tendo em vista que não sabemos ao certo se essa informação retorna ou não e se tem como o ACBr buscar essa informação. Espero ter ajudado.

Muito bom Daniel, testei a impressão do DANF-e com CEP iniciado com zero e a formatação de "89140" para "89140-000" e também está certo... mais uma vez obrigado.

Conforme solicitação do Sr. Henrique Leonardo @hleorj, estou criando um novo post referente a melhoria e alterações no método "FormarCEP" sobre post 1 e post 2, onde solicitei para alterar o método para preencher com zeros a direito ao invés de zeros a esquerda. Em meus clientes ocorre o seguinte: como a maioria das pequenas cidades possui apenas 1 CEP e nos casos em que os 3 últimos dígitos é "000", eles estavam acostumados a digitar por exemplo "89140" e o método FormatarCEP formatava para "89140-000". Quando migrei os fontes para o trunk2, este método passou a formatar os zeros a esquerda, ficando "00089-140". Em Dezembro de 2015 solicitei a alteração e o @Daniel Simoes alterou para formatar os zeros a direita, conforme post 1. Porém, essa semana atualizei os fontes e novamente foi alterado para formatar zeros a esquerda, por causa da impressão do DANF-e da NF-e que trata o campo CEP como integer e ocorria problemas com CEPs iniciados com zero, conforme post 2. Sugestão 1) Para tentar contribuir sem comprometer outras funcionalidades, sugeri a principio uma alteração na unit "ACBrValidador.pas", onde existem 2 métodos "FormtarCEP": o primeiro recebe um parâmetro string e o segundo um parâmetro integer. No método que recebe o parâmetro string, sugeri para formatar zeros a direita e no outro método que recebe o parâmetro como integer, formatar zeros a esquerda. Dessa forma não acontece o erro do post 2, porém, ao implementar um teste ( TDD ) que atenda a minha necessidade, a execução falhou no teste "FormatarMenosDeOitoDigitos". Os métodos "FormtarCEP" da unit "ACBrValidador.pas" ficariam da seguinte forma: function FormatarCEP(const AValue: String): String; Var S : String ; begin S := PadRight( OnlyNumber(AValue), 8, '0') ; { Prenche zeros a direita } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; function FormatarCEP(const AValue: Integer): String; Var S : String ; begin S := PadLeft( OnlyNumber(IntToStr(AValue)), 8, '0') ; { Prenche zeros a esquerda } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; Sugestão 2) Uma outra sugestão, seria criar um parâmetro no método "FormatarCEP" da unit "ACBrValidador.pas" para forçar o preenchimento dos zeros a direita, mas que por padrão, caso o parâmetro não seja informado, o valor seja False. A alteração ficaria da seguinte forma: function FormatarCEP(const AValue: String; PreencheZerosADireita: boolean = False): String; Var S : String ; begin if PreencheZerosADireita then S := PadRight( OnlyNumber(AValue), 8, '0') { Prenche zeros a direita } else S := PadLeft( OnlyNumber(AValue), 8, '0') ; { Prenche zeros a esquerda } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; e o teste na unit "ACBrValidadorTest.pas" ficaria assim: procedure TTestCaseACBrValidadorCEP.FormatarString; var ACep: String; begin ACep := '89140'; CheckEquals('89140-000', ACBrValidador.FormatarCEP(ACep, True)); end; Dessa forma, atenderia todos os testes (incluindo o teste que implementei). Segue em anexo os arquivos referente a segunda sugestão de alteração. ACBrValidador.pas acbrvalidadortest.pas

Olá Leonardo, segue em anexo a unit "ACBrValidadorTest.pas" com um novo teste que implementei e a unit "ACBrValidador.pas" com a alteração no método "FormatarCEP" de forma que passe nos testes já implementados anteriormente e que o método faço o que preciso. Aguardo uma avaliação sobre as alterações e desde já agradeço. Sugestão sobre os testes: Acho ótimo a utilização de TDD para evitar alterações equivocadas nos fontes. Acredito que para facilitar uma futura manutenção nos testes, saber por qual motivo tal teste foi implementado, os fontes poderiam estar documentados, ou algum documento para consulta. Quem implementa o teste, poderia justificá-lo. ACBrValidador.pas acbrvalidadortest.pas

Olá Fábio, desculpa desenterrar esse tópico lá de Dezembro, mas foi eu quem solicitou esta alteração (post), para jogar zeros a direita e não a esquerda pelo seguinte motivo: antigamente o ACBr já fazia desta forma, como a maioria dos CEPs de cidades pequenas, onde há apenas 1 CEP para toda a cidade, completam com "000" após o hífen (89140-000), facilita para o usuário digitar apenas "89140" e a função formata para "89140-000", entendeu. Porém, não estava a par desta situação na impressão do DANF-e. Gostaria de sugerir então a seguinte melhoria aos moderadores, para tentar agradar a todos e sem ter impacto negativo para todos do fórum... Na unit ACBrValidador, existem dois métodos com o mesmo nome "FormatarCEP", porém, um recebe o parâmetro string e o outro integer. Quando é feita a impressão do DANF-e, é solicitado o método que recebe o parâmetro integer, que por sua vez, chama o outro método que recebe o parâmetro string. function FormatarCEP(const AValue: String): String; Var S : String ; begin S := PadLeft( OnlyNumber(AValue), 8, '0') ; { Prenche zeros a esquerda } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; function FormatarCEP(const AValue: Integer): String; begin Result := FormatarCEP(IntToStr(AValue)); end; Minha sugestão então, seria formatar zeros a esquerda quando passado o parâmetro integer (dessa forma não afetaria a impressão do DANF-e) e a direita quando passado o parâmetro string (dessa forma não afetaria os meu clientes, pois passo como parâmetro uma string). Ficaria da seguinte forma: function FormatarCEP(const AValue: String): String; Var S : String ; begin S := PadRight( OnlyNumber(AValue), 8, '0') ; { Prenche zeros a direita } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; function FormatarCEP(const AValue: Integer): String; Var S : String ; begin S := PadLeft( OnlyNumber(IntToStr(AValue)), 8, '0') ; { Prenche zeros a esquerda } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; Em anexo a unit... ACBrValidador.pas

OK Daniel, testei e esta tudo certo, obrigado!!

Estou com o mesmo problema, porém, apenas atualizei os fontes do ACBr que já estavam no trunk 2. Para conseguir compilar tive que alterar as units ACBrDFeOpenSSL.pas e ACBrHTTPReqResp.pas conforme anexos. Tive que remover as verificações {$IFDEF DELPHI2009_UP} Na linha 756 da unit ACBrDFeOpenSSL.pas De {$IFDEF DELPHI2009_UP}AnsiStrings.{$ENDIF}StrPas( PAnsiChar(notAfter^.data) ); Para StrPas( PAnsiChar(notAfter^.data) ); Na linha 828 da unit ACBrDFeOpenSSL.pas De {$IFDEF DELPHI2009_UP}AnsiStrings.{$ENDIF}StrPas( PAnsiChar(SN^.data) ); Para StrPas( PAnsiChar(SN^.data) ); Na linha 213 da unit ACBrHTTPReqResp.pas De FHTTPResultCode := StrToIntDef( {$IFDEF DELPHI2009_UP}AnsiStrings.{$ENDIF}StrPas(aBuffer), 0); Para FHTTPResultCode := StrToIntDef( StrPas(aBuffer), 0); Alguém poderia explicar o porque do erro? Um chute, seria porque quem alterou deve estar utilizando o delphi 7 e o erro só ocorre quando a versão do delphi é superior a 2009 (no meu caso é 2010). ACBrDFeOpenSSL.pas ACBrHTTPReqResp.pas

Vá até a pasta do componente ACBr e utilize os arquivos schemas que está em: "...\Exemplos\ACBrDFe\Schemas\NFe" Lembrando que tem que estar com os fontes do trunk2

Concordo com o Igor... e o campo vICMSUFDest fica 40,00 (20,00 referente aos 40% + 20,00 do FCP) e o campo vICMSUFRemet fica 30 (referente a 60% da partilha) Vale lembrar sobre a base de cálculo, considerando que a última NT liberada (2015.003 - v 1.40) tem o exemplo utilizado o cálculo por dentro (páginas 13 e 14) e agora o cálculo utiliza a base simples.

Testei e está tudo certo, obrigado Daniel...

José Carlos, verifica no arquivo XML, se o valor total do ICMS está incluindo o somatório dos itens que tem CST 51 (campo "vICMS" do grupo "ICMSTot"). Pelo que me lembro, o valor do ICMS apurado pelo CST 51, não compõe o campo valor total do ICMS...

Sim, isso mesmo, funcionava assim antes da migração para o trunk2... No fonte do trunk, está sendo utilizada a função "padL", que deveria ter sido migrada para "padRight" no trunk2...

Somente a unit ACBrValidador. ACBrValidador.pas

Bom dia a todos. Fiz a migração para o trunk2 e até o momento, não encontrei dificuldades, realmente ficou muito bom. Encontrei apenas esta divergência na função FormatarCEP (unit ACBrValidador, linha 430), onde deveria estar colocando zeros a direita, porém, está colocando a esquerda. Modificar de PadLeft para PadRight. Agradeço desde já. Att. Rosemir

Também testei e está OK para SC. Muito obrigado!!!

Também estou com este problema, porém, realizando os teste para SC, confirmei que preenchendo apenas a origem e o CST, autoriza sem problemas. Embora a NT oriente a preencher de forma completa, mas a SEFAZ não valida, minha sugestão é manter a compatibilidade, alterando a linha 1301 da unit pcnNFeW, onde o campo vICMS é preenchido quando o CST é o 51, da seguinte forma: De Gerador.wCampo(tcDe2, 'N17', 'vICMS ', 01, 15, 1, nfe.Det.Imposto.ICMS.vICMS, DSC_VICMS); Para if (nfe.Det.Imposto.ICMS.pICMS = 0) and (nfe.Det.Imposto.ICMS.pDif = 0) then Gerador.wCampo(tcDe2, 'N17', 'vICMS ', 01, 15, 0, nfe.Det.Imposto.ICMS.vICMS, DSC_VICMS) else Gerador.wCampo(tcDe2, 'N17', 'vICMS ', 01, 15, 1, nfe.Det.Imposto.ICMS.vICMS, DSC_VICMS); Dessa forma, quem não preencher a alíquota do ICMS e o percentual diferido, a TAG vICMS não é preenchida. Caso informe os respectivos campos e o percentual diferido seja 100%, a TAG vICMS será gerada com zero. Será que mais alguém concorda com a sugestão...

Atualizei os fontes e o problema foi resolvido... Muito obrigado!!!