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.