dalpiaze

Na verdade a alteração que fiz continua enviando o valor na tag normalmente, a única coisa que muda é que ele sempre gera essa tag com essa alteração, mesmo quando a variável está igual a zero, pois antes essa tag não era gerada quando o valor igual a zero. Desta forma o WS está aceitando o envio do CT-e...

Senhores, boa tarde, Aqui tínhamos o mesmo problema até então com nosso clientes que utilizam CT-e OS. Apesar do manual informar que o campo vINSS é opcional, parece que ele sempre precisa ser informado para que não ocorra o erro 760. Desta, forma alterei no fonte do arquivo pcteCTeW.pas para que gere sempre a tag vINSS mesmo com valor zerado, e desta forma os xml's estão sendo autorizados normalmente. Anexo arquivo alterado para análise do pessoal do ACBr. Muito obrigado. pcteCTeW.pas

Correto, mas neste caso pego os valores conforme a tributação original e vejo quais os itens foram cancelados, para somar o montante cancelado de cada tributação.

Sim, na verdade resolvi analisando e deduzindo pela seguinte ideia: No Layout do XML da Redução Z, os dados dos produtos são informados dentro de um determinado totalizador. Então, pressupõe-se que seria estranho ter por exemplo os dados do mesmo produto no Totalizador T1700 quando o produto foi tributado e ter o mesmo produto informado em Can-T quando esse mesmo produto foi cancelado. (Teríamos diversos produtos com todos os dados de cadastro repetidos nos totalizadores e mais no totalizador de Cancelamento - além disso teríamos apenas no totalizador de Cancelamento se tivéssemos o produto apenas cancelado naquele determinado dia) Por isso é de se pressupor que isso não faria muito sentido. Sendo assim deduzi que deve-se informar o totalizador "original" (que é o que determina a tributação do produto, exemplo T0700, T1200,...), e então nesse mesmo totalizador informar o valor relativo a cancelamentos - por isso que existe esse campo de cancelamento por totalizador, senão também não faria sentido ter o valor de cancelamento já que informaríamos o valor do totalizador Can-T por exemplo. Também não encontrei mais informações sobre isso em outros lugares, por isso resolvi desta forma. Comentem aí suas ideias também. Obrigado.

Pessoal, Agora com a nova publicação do Bloco X (DESPACHO 45/2017 - de 4 de Abril de 2017), foram acrescentados no Layout do XML da Redução Z alguns campos que compreendes o valor acumulado por totalizador. São eles: ValorDesconto, ValorAcrescimo, ValorCancelamento e ValorTotalLiquido. Antes dessa publicação, já tínhamos o Bloco X implementado em nosso sistema (inclusive homologado) seguindo o seguinte critério: Os totalizadores eram agrupados da mesma forma que são agrupados nos registros do PAF, exemplo: - T0700 - T1200 - I - Can-T (Cancelamento de ICMS) Agora com esses novos campos, como surgiu o campo do ValorCancelamento, deu a entender que na verdade o agrupamento faria mais sentido da seguinte forma: - T0700, incluindo os cancelamentos que eram de produtos originalmente de 7% de ICMS (declarando o valor dos itens cancelados no campo ValorCancelamento) ??? - E assim por diante, mas não declarando um Totalizador com o "Can-T" por exemplo, pois não faria sentido ??? O que vocês acham dessa análise. Também pensam da mesma forma? Quem já implementou com essas alterações, qual o critério utilizou para o agrupamento dos Totalizadores?

Bom dia a todos, Acabo de atualizar o svn e recebi a modificação no arquivo DACTE_RETRATO.fr3, porém parece que o layout continua da versão antiga do CT-e. Baixei o arquivo .fr3 anexo aqui neste tópico e então o layout ficou correto conforme a versão 3.00 Juliomar, essa alteração que você fez no svn também faz parte esse arquivo da versão 3.00 ? Obrigado desde já.

Pessoal do ACBr, bom dia, Está ocorrendo erro de compilação na unit ACBrNFeWebServices na linha 709: FPDFeOwner.SSL.SSLType := LT_TLSv1_2; O tipo "LT_TLSv1_2" está contido na unit "blcksock". Porém essa unit é excluída da uses quando definido DFE_SEM_OPENSSL, gerando erro de compilação. {$IfNDef DFE_SEM_OPENSSL} blcksock, {$EndIf} Fiz uma alteração na unit apenas removendo o IFNDEF para que a unit seja incluída em ambos os casos. Anexo a unit alterada. Obrigado. ACBrNFeWebServices.pas

Ficou show! Blz, Daniel, igualmente muito obrigado.

Opa, me desculpe, achei que queria as units com as alterações para carregamento todo dinâmico... Fiz o acerto aqui nas 3 units com base nos arquivos baixados agora do SVN (apenas incluído freelibrary no finalization para funcionamento do delayed corretamente) Segue: libxml2.pas libxmlsec.pas libxslt.pas De acordo com os testes aqui, funcionando corretamente com o delayed desligado e também com ele ligado.

Exato, concordo, por isso testei a suas alterações aqui, usando o recurso do delayed, o qual não alterou a declaração dos métodos... e funcionou desta forma... apenas fazendo aquele ajuste no final da unit. Assim não precisaria reestruturar as units para carga dinamica por variável.

Daniel, exato... realmente observando melhor notei que a dependência ao inicializar o objeto TDFeOpenSSL é apenas para a DLL libeay32.dll que contém métodos diretos external. Blz. Fiz os testes aqui nas várias funções com o delayed desabilitado para ver se tudo continua funcionando, e, a princípio, tudo certo. Daí fiz o teste com o delayed ativado, mas ocorreram erros em algumas funções... então fiz aquele ajuste que você havia sugerido do FreeLibrary no finalization, e então deu certo! O ajuste fiz nas três units: libxmlsec, libxml2 e libxslt (todas iguais no final da unit, comentando o freelibrary no Init e deixando para o finalization): ... //FreeLibrary(libHandle); end; end; initialization libHandle := 0; finalization if libHandle<>0 then FreeLibrary(libHandle); end. Com isso funcionaram as funções com o delayed habilitado.

Daniel, nas alterações que você fez na unit ACBrDFeOpenSSL, faltou chamar o InitXmlSec no Create do TDFeOpenSSL, pois as inicializações do OpenSSL estão separadas em duas etapas: aquelas que eram no initialization e as das externals. Veja que no ACBrDFeOpenSSL existem funções (exemplo carga do Certificado) que não usa a InitXmlSec, porém usa funções que eram carregadas na initialization, por isso já precisam estar disponíveis quando o componente chamar essas funções.

Daniel, blz, Sim alterei a estrutura das 4 units todas (são milhares de métodos....) (libeay32.pas, libxmlsec.pas, libxml2.pas, libxslt.pas) Coloquei inclusive o FreeLibrary no finalization das units. Mas foi preciso fazer o carregamento dinâmico dos métodos que antes estavam como "external", exatamente por dois motivos: 1- Como a carga acontecia em duas etapas (external e no loadlibrary), ficavam duas handles da dll separadas que dava problema de comunicação entre a dll 2- O delayed além de não funcionar no Lazarus e não ser compatível com todos os Delphi's, li na documentação da Embarcadero que ele não é recomendado utilizar quando houverem muitas funções (que é o caso - milhares de funções), pois tornará o carregamento dinâmico lento. Dessa forma o carregamento ficou todo dinâmico por LoadLibrary e funcionando em todos os Delphis / Lararus. PS: Para alterar as units escrevi um programinha para fazer isso automatizadamente, para não ter que alterar linha por linha na mão.

Bom dia, Descobri qual é o problema: existem as duas partes que carregam a mesma DLL: - A parte do initialization (onde está dinamicamente com LoadLibrary) - E a parte do external que carrega estaticamente direto O fato é que, se observar no LoadLibrary, o carregamento dos ponteiros é feito e depois liberada a DLL, o que faz com que o endereçamento correspondente a ponteiros que se comunicam com função usada no external e que tenha propriedades que foram carregadas pelo LoadLibrary estourem a memória pois essa última não está mais acessível. O que fiz aqui: Transformei as 3 units (libxmlsec.pas, libxml2.pas e libxslt) com todas as funções em carregamento dinâmico (LoadLibrary). Ou seja, tirei todos os externals, e agora tudo é por LoadLibrary, assim não dependendo mais de versão do Delphi e nem do Delayed (que não iria funcionar mesmo por causa dos ponteiros). Estou testando nas diversas rotinas (carregamento de certificado, envio de nota, assinatura, validação) e tudo funcionou normalmente até agora. Agora o caso é: Existe esse porém de que realmente não é interessante alterar essas units. E esse carregamento por LoadLibrary fez com que eu tivesse que reescrever toda a estrutura dessas units. Por isso, como você falou (Daniel), não sei até que ponto isso é seguro! Então deixo aqui apenas como sugestão, para quem quiser conferir e dar uma garantia maior do funcionamento... pois caso contrário melhor deixar como estava para não haver problemas. Obrigado.

Daniel, realmente, estive fazendo testes em todas as rotinas que envolvem o uso do OpenSSL e algumas delas falham, exemplo a Validação da Assinatura. Usando no método tradicional antigo funciona normalmente. Então, essa implementação do "delayed" realmente não funciona corretamente. Acredito que podemos descartar essa ideia.

PS: Tranquilo, quanto a modificação mínima possível das units também concordo, por isso deixo apenas como sugestão para avaliação, pois também não tenho garantia de que funcionará corretamente. Por enquanto estou usando aqui dessa forma e está funcionando normal.

Daniel, blz, Quanto às diretivas, coloquei diretamente nas units por se tratar de algo muito específico para elas, pois vi que ainda não havia chamada ao ACBr.inc nelas também. Essas diretivas garantirão que o delayed seja usado apenas nos Delphi's que suportem essa função e removendo assim os warnings de função específica de plataforma. Segui a mesma ideia que já havia no libeay32.dll (já havia uma diretiva para ser ativada manualmente para delayed), apenas fiz ela ficar automática conforme o Delphi mais novo (poderia também ser colocada para ser ativada manualmente no ACBr.inc, porém acredito que quem tem suporte a delphi com delayed deveria preferir que sempre tivesse esse recurso sendo utilizado). Quanto a procedure Init, é justamente aí é que está o ajuste que torna o carregamento dinâmico, pois antes nesse lugar estava o "initialization" da unit, o que fazia que todas as funções ali carregadas fossem sempre carregadas na inicialização do executável, independente do uso. Por isso criei uma procedure chamada Init, que é chamada manualmente lá da unit ACBrDFeOpenSSL.pas, que é de onde vem toda a requisição referente as units: libxmlsec, libxml2 e libxslt. Veja que lá na unit ACBrDFeOpenSSL tive que fazer uns pequenos ajustes pois, antes, como o carregamento era estático na inicialização da aplicação, nas diversas funções presentes nessa unit, exemplo "carga do certificado digital", não dependia da inicialização secundária da função "InitXmlSec", pois já haviam os ponteiros das funções das DLLs carregadas. Agora como o carregamento passa a ser dinâmico, coloquei para efetuar a carga dos ponteiros ao criar o objeto TDFeOpenSSL, pois a partir dele todas as funções necessitarão da carga dos ponteiros e, subsequentemente, da carga da InitXmlSec. Obrigado pelo retorno.

Juliomar, boa tarde, Exato, porém o delayed estava implementado apenas na libeay32.pas O que fiz foi implementá-lo em todas as outras units do OpenSSL, as quais não tinham esse recurso. Além disso existem outros carregamentos no initialization que também tiveram que ser reestruturados.

Pessoal do ACBr, boa tarde a todos. Tenho visto aqui no fórum diversos questionamentos sobre o carregamento das DLLs do OpenSSL que agora por motivos do funcionamento automático/simultâneo, passaram no Trunk2 a serem requisitos também para o carregamento de qualquer aplicativo que tenha a dependência destes no projeto. OK Estive nos últimos dias estudando as units do OpenSSL, e percebi que é possível realizar o carregamento dinâmico destas, de forma que não fique com essa dependência travada no aplicativo. Aí vem a pergunta: porque precisaria disso se ao utilizar OpenSSL vai precisar necessariamente das DLLs...? A resposta é simples: no exemplo de nosso software, é composto de vários aplicativos, e a maioria deles utiliza algum componente do ACBr. Então, por exemplo se eu colocar um componente TACBrNFe em um projeto, simplesmente para poder carregar arquivos XMLs (ler arquivos XMLs e ver as propriedades dele), assim já terei que ter as DLLs do OpenSSL corretamente disponíveis ao abrir esse EXE, pois o ACBrNFe faz menção ao ACBrDFeSSL, que faz menção ao ACBrDFeOpenSSL, que depende diretamente dessas DLLs. E em alguns casos o aplicativo não faz uso necessariamente das funções OpenSSL, apenas usa outros recursos dos componentes do ACBr que possuem o OpenSSL. Blz, para muitos isso pode não ser problema, mas no nosso caso, e como já pude ver aqui no fórum, é o caso também de outros, seria interessante que essa dependência não fosse tão travada a ponto de carregar as DLLs no início do carregamento do EXE, até mesmo por uma questão de acelerar a abertura do programa (claro que a carga das funções da DLL são muito rápidas, mas é mais um passo que o programa tem que fazer ao iniciar). Então pensando nisso, passei a estudar a fundo essas units: - ACBrDFe\ACBrDFeOpenSSL.pas - ACBrOpenSSL\libeay32.pas - ACBrOpenSSL\libxmlsec.pas - ACBrOpenSSL\libxml2.pas - ACBrOpenSSL\libxslt.pas O carregamento das funções das DLLs de modo geral estão utilizando o padrão "external" que faz o link com a função já no início. Além disso existe a carga de outras variáveis no initialization da unit. O que eu fiz: Utilizei o recurso de carregamento atrasado (delayed) em todas as units e alterei o initialization das units trocando-a para uma procedure que é chamada através da unit principal apenas ao criar o objeto OpenSSL (ACBrDFeOpenSSL). Dessa forma, a dependência das DLLs só ocorre quando realmente as funções do OpenSSL são chamadas dentro dos componentes. Exemplo, se eu criar um componente ACBrNFe (deixando o SSLLib no padrão Capicom) e apenas usá-lo para abrir XMLs, as DLLs do OpenSSL nunca serão chamadas. Por isso, deixo aqui como sugestão as units alteradas para contribuir com o projeto, se caso o pessoal do ACBr considerar válido: ACBrDFeOpenSSL.pas libeay32.pas libxml2.pas libxmlsec.pas libxslt.pas Muito obrigado. PS: Lembrando que esse recurso iria tornar mais prático o carregamento apenas para quem utiliza o Delphi 2010 em diante, pois foi implementado nele o suporte ao "delayed" Além disso os recursos estão com diretivas de compilação para compatibilizar corretamente com todas as versões do Delphi

Blz, Juliomar, Muito obrigado! Até.

Pessoal, boa noite, Gentileza, poderiam acertar o código seguinte (ACBrNFeWebServices.pas): Na Linha 2586 existe um ponto-e-vírgula logo após o "then" fazendo com que ele não funcione como deveria... procedure TNFeEnvEvento.SalvarResposta; begin inherited SalvarResposta; if FPConfiguracoesNFe.Arquivos.Salvar then; //<---------------------- FPDFeOwner.Gravar(GerarPrefixoArquivo + '-' + ArqEnv + '.xml', FPDadosMsg, GerarPathEvento); end; Desde já, muito obrigado!

Blz, Ítalo, entendo... Lanço uma sugestão rápida e fácil para contornar este caso e não precisar re-gerar o XML para incluir o protNFe: Na unit "pcnProcNFe.pas", existe a função TProcNFe.GerarXML, que faz exatamente isso que estávamos falando: inclui a protNFe depois do XML da nota sem reconstruir nada, apenas incrementando as strings. Existe um objeto desse criado já dentro do TNFe.procNFe..., bastando apenas chamarmos a funçao GerarXML, porém se olharmos nessa função ela sempre tenta abrir um XML de nota de um arquivo: 127: function TProcNFe.GerarXML: Boolean; function PreencherTAG(const TAG: String; Texto: String): String; begin result := '<' + TAG + '>' + RetornarConteudoEntre(Texto, '<' + TAG + '>', '</' + TAG + '>') + '</' + TAG + '>'; end; var XMLNFe: TStringList; XMLinfProt: TStringList; XMLinfProt2: TStringList; wCstat: String; xProtNFe: String; nProtLoc: String; LocLeitor: TLeitor; i: Integer; ProtLido: Boolean; //Protocolo lido do arquivo begin ProtLido := False; XMLNFe := TStringList.Create; XMLinfProt := TStringList.Create; XMLinfProt2 := TStringList.Create; xProtNFe := ''; // Arquivo NFe if not FileExists(FPathNFe) then Gerador.wAlerta('XR04', 'NFE', 'NFE', ERR_MSG_ARQUIVO_NAO_ENCONTRADO) else 156: XMLNFE.LoadFromFile(FPathNFe); // <-------------------------------------------- Na linha 156, poderíamos alterar isso para permitir que seja lido o XML de uma string, ou daquele que já está carregado na nota... (pegando do Owner do TProcNFe, que é a NFe, por exemplo). Aí sim, eu apenas chamaria ACBrNFe.NotasFiscais.Items[0].NFe.procNFe.GerarXML, que iria gerar o XML com o protNFe mantendo o xml íntegro. Comentem o que acham. Muito obrigado.

Pois é Régys, tens razão... passei a manhã verificando tudo de novo, atualizei os fontes de novo e nada... Mas como você disse que aí está funcionando, pensei: como pode... aí tentei apagar o SVN e baixar novamente... e não é que deu certo... percebi que mudou a unit pcnNFeW, que é justamente esta unit que gera o XML... Claro que ainda assim tenho que chamar a função "GerarXML" para re-gerar o xml com a tag "protNFe", mas agora a assinatura é mantida! Falando nisso, Ítalo: acha que poderia fazer aquela alteração para que não dependa de estar habilitado a propriedade "Salvar" para que internamente o componente já chame a função "GerarXML" ao salvar? (Isso para NF-e / CT-e / MDF-e também). Inclusive, estive analisando a função de GerarXML na unit pcnNFeW: Percebi que, depois da nota gerada, assinada, enviada, autorizada... ao salvar (quando habilitado salvar), é chamada essa função automaticamente para reconstruir o XML com a "protNFe", ok. Agora veja o seguinte cenário: um cliente possui uma nota a qual gerou o XML e enviou... e por motivos de queda de internet/rede/luz, por exemplo, não chegou a obter o retorno e gravar o protNFe. Blz, basta ele depois disso consultar o status dessa nota, que já temos implementado no sistema para atualizar o xml com o protNFe. Mas aí que vem o porém: digamos que nesse intervalo atualizei a versão de meu cliente, o qual também sofreu alterações no ACBr, digamos o formato de um campo numérico foi acrescido em mais uma casa decimal (exemplo). Então nesse momento em que for reconstruir o XML apenas para incluir a tag protNFe, iria reconstruir também todas as tags que estão carregadas nos objetos do ACBr, e reformatar essa tag numérica com mais um zero (exemplo), fazendo com que na verdade o xml seja diferente do original, não concorda!? (Invalidando a assinatura)... claro que isso só seria percebido muito mais tarde em um momento que fosse validar a assinatura do arquivo por exemplo. Não sei se me fiz ententer, mas acredito que isso pode acontecer facilmente, por exemplo em nossos clientes, em que atualizamos constantemente o sistema, e sempre mantenho o repositório do ACBr atualizado também, e também considerando que volta e meia ocorre caso de queda de luz / rede nos clientes. Sugestão: Claro que a ideia é contribuir para melhoria do componente, então para isso sugeriria a seguinte proposta: Nesse momento de incluir a tag protNFe no XML original, não executar essa função de re-gerar o xml todo de novo, apenas fazer a inclusão da tag manualmente colocando a string do xml da nota dentro da string do "nfeProc" (que é a tag geral que comporta a NFe e protNFe). Assim garantiria a integridade da nfe e assinatura original criada, apenas acrescentando o protocolo ao xml. Isso claro, deveria acontecer ao autorizar a nota, e ao consultar situação da nota. O que me dizem? Desde já obrigado a todos deste tópico pelos retornos e pela ajuda.

Daniel, o que falta é a tag "protNFe" - isso sem chamar nenhuma função... agora se eu chamar manualmente a função GerarXML (que monta novamente o XML) depois de autorizado, aí a tag protNFe é incluída, porém é retirada a assinatura. Ou seja, no momento em que a nota está autorizada, a situação do conteúdo do xml é: - XML normal da NFe + Assinatura Digital (falta o protNFe) Se eu chamar GerarXML a situação fica: - XML normal da NFe + protNFe (falta a assinatura) Em qualquer caso sempre fica faltando uma parte. A não ser que eu chame manualmente a função "Assinar". Mas claro que isso não deve ser feito novamente depois de enviado o XML. Régys, estranho então... pois aqui ocorre isso com o NF-e e MDF-e... CT-e não testei ainda Sendo que no NF-e eu leio a propriedade "XML". Já no MDF-e está habilitado para salvar direto em arquivo. Em todos os casos isso ocorre igual. Não entendo como aí funciona... ?

Bom dia a todos, Apenas para registro, fiz mais um teste agora, desta vez usando a função GravarXML - para salvar o XML em disco... e também ocorre o mesmo caso (é gravado o XML contendo a assinatura, porém sem a tag "protNFe") Acredito então que todos devem ter esse mesmo problema, pois salvando o xml em disco ou lendo a propriedade xml para salvar em banco de dados, em ambos os casos não irá conter a autorização de uso.