Painel de líderes

Pesquisando mais um pouco encontrei no stackoverflow um relato do mesmo problema com Python. Mais uma vez a solução está relacionada ao flag XMLSEC_NO_SIZE_T, porém não faço ideia se isso pode ser passado através de alguma função para a DLL ou se seria apenas uma diretiva de compilação. http://stackoverflow.com/questions/13071246/xmlsec1-sign-works-on-command-line-but-fails-on-python-code https://github.com/aricaldeira/pyxmlsec Acredito que esta bandeira precisa ser desativada pra compilação das DLL. Avancei um pouco nos meus testes, conseguindo preencher a tag <DigestValue>, porém o <SignatureValue> e <X509Certificate> ainda ficam em branco. <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#ID2102104116071066568600019355000000000530100015312701"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>yvhVfl3NaLjH6hKThpde0bTN3nw=</DigestValue> </Reference> </SignedInfo> <SignatureValue/> <KeyInfo> <X509Data> <X509Certificate/> </X509Data> </KeyInfo> </Signature> Pra este teste eu criei um projeto novo e chamei os métodos do XMLSec diretamente, sem passar pelo ACBr. Além disso carreguei o certificado com xmlSecCryptoAppKeyLoad ao invés de xmlSecCryptoAppKeyLoadMemory. Aguardo resultado dos seus testes Daniel e demais colegas. Att.

Estou concluindo uma alteração no ACBrMonitorPLUS para resolver este problema. Devo subir no SVN amanhã.

Bom dia Verdade Ítalo. Estou impressionado com o amadorismo desse pessoal da prefeitura de Carazinho.. Tinham me informado via telefone que não havia necessidade de assinar os arquivos xml, que podia usar o método Síncrono e passaram o endereço da página de login do site deles como sendo a URL de homologação.. Pois bem, tudo errado... PRECISA ASSINAR OS XML, NÃO EXISTE MÉTODO SÍNCRONO E A URL... NEM SE FALA ! A luta continua companheiros !! kkkkkkkkkkkkkk

Usa ve100 ou ve300, sendo que a versão 3.00 está liberado somente homologação, liberou dia 05.10. pmdfeConversaoMDFe > TVersaoMDFe = (ve100, ve300); Como eu uso nfe e nfse também, eu precisei colocar a unit junto. MDFe.Configuracoes.Geral.VersaoDF:= pmdfeConversaoMDFe.ve300;

Por favor teste com as Units em Anexo... Modo de uso... procedure TForm1.Button9Click(Sender: TObject); begin with TDFeOpenSSL(ACBrNFe1.SSL.SSLClass) do begin LerX509Info( ConteudoTag_X509Certificate ); end; end; ACBrDFeOpenSSL.pas OpenSSLExt.pas

Boa noite Rogério, Todo CT-e emitido tem que possuir pelo menos um documento originário, que na maioria dos casos é uma NF-e. Antes era possível informar uma NF-e ou NF (papel) ou Outros (Declaração). Acredito que hoje nenhum empresa emiti NF (papel), logo devemos informar uma NF-e ou Outros. Cuidado, não informe o documento originário como sendo Outros de forma indiscriminada, pois o CT-e poderá ser rejeitado pela SEFAZ. Se o Remente da carga for uma empresa obrigada a emitir NF-e, ao emitir o CT-e será obrigatório informar a chave da NF-e, sobe pena do CT-e ser rejeitado.

Outro detalhe importante, pelo menos em Delphi, seriam os Pointer operations: http://docwiki.embarcadero.com/RADStudio/Berlin/en/Converting_32-bit_Delphi_Applications_to_64-bit_Windows http://docwiki.embarcadero.com/RADStudio/Berlin/en/64-bit_Windows_Data_Types_Compared_to_32-bit_Windows_Data_Types Segue cópia dos meus fontes modificados com base nas alterações propostas pelo André. ACBr x64.zip

Importante descoberta... obrigado... Vou fazer alguns testes... No FPC, um Unsigned Int de 4 bits seria o Cardinal, "longword" http://www.freepascal.org/docs-html/ref/refsu5.html

Olá, pessoal. Eu gostaria de poder ao menos o evento AntesdeAssinar do componente, mas não sei como fazer. Eu usei o TProcess pra tentar fazer a assinatura chamando o xmlsec1, porém o nó da assinatura não está no XML e por isso o arquivo não é assinado. Se alguém poder dar uma luz eu agradeço Linha de comando do TProcess: 'xmlsec1 --sign --output assinado.xml --pksc12 certificado.pfx --pwd 123 nota.xml '

Boa tarde, André. Testei conforme sua orientação, porém sem sucesso. Se tiver mais alguma sugestão, pode falar que eu testo aqui. Att.

no svn a correção! Obrigado

Olá pessoal Adicionei os registros do bloco K que estarão em vigor a partir de 01/01/2017.Adicionei os arquivos aqui no post. Não sei se este é o procedimento padrão para submeter as alterações para vossa avaliação e adição no brench principal. Os campos adicionados são os que mencionei no post anterior, com base manual do EFD, versão 2.0.19 K210 e K215: referente a Desmontagem de mercadorias – Item de Origem e Destino K260 e K265: referente a Reprocessamento/Reparo de Produto/Insumo e Mercadorias Consumidas e/ou Retornadas K270 e K275: Correção de Apontamento dos Registros K210, K220, K230, K250, K260, K270 e K215, K220, K235, K255 e K265 K280: Correção de Apontamento – Estoque Escriturado Qualquer procedimento diferente que seja necessário de minha parte, favor me comunicarem. ACBrEFDBloco_K.pas ACBrEFDBloco_K_Class.pas ACBrSpedFiscal.pas

Olá, Utilizo algo parecido para efetuar recebimento de Correspondente Bancário. Acho que pode ajudar: Para iniciar a transação, altero a operação CHQ para '312' (Consulta Pagamento Genérico). Após informar todos os dados dessa transação, o SiTEF aguarda o pagamento, então eu chamo novamente o CHQ, porém dessa vez com Operação '313' (Pagamento Genérico), informando os dados do pagamento em "ACBrTEFD1.TEFCliSiTef.Restricoes" Segue um trecho do código para exemplo: // Altera OperacaoCHQ para "Consulta Pagamento Genérico" ACBrTEFD1.TEFCliSiTef.OperacaoCHQ := 312; // Chama SiTEF informando valor zero no CHQ para pular "VerificarTransacaoPagamento" ACBrTEFD1.CHQ(0, '00|CB', IntToStr(wDocumento)); // Pega valor à ser pago wValorStr := ACBrTEFD1.RespostasPendentes[ACBrTEFD1.RespostasPendentes.Count-1].LeInformacao(609).AsString; // Nesse momento deve ser efetuado o pagamento no Caixa... // Chamando o SiTEF para confirmar o Pagto. (Utilizando Dinheiro) // Usa property Restricoes(ParamAdic.) para enviar Dados do Pagamento ACBrTEFD1.TEFCliSiTef.Restricoes := '{DadosPagamento=1:'+wValorStr+'}'; // Altera OperacaoCHQ para "Pagamento Genérico" ACBrTEFD1.TEFCliSiTef.OperacaoCHQ := 313; // Chama SiTEF novamente, com o mesmo Documento Vinculado(Nesse caso o COO da venda) ACBrTEFD1.CHQ(0, '00|CB', IntToStr(wDocumento));

Ligue no ACBrTEFD, o Log em modo Debug... Será gravado no Log, todas as informações retornadas pelo SiTef, com os respectivos códigos de índice..

Use o Debug e estude os fontes... é fundamental ter domínio dos fontes para conseguir passar na homologação... O componente está fazendo o que ele foi programado para fazer... A classe TACBrTEFDAuttar herda de TACBrTEFDClassTXT, que herda de TACBrTEFDClass... E veja que no final de TACBrTEFDClass.Inicializar... há uma chamada a: CancelarTransacoesPendentesClass ; Provavelmente poucas pessoas usam a classe TACBrTEFDAuttar, ou eles mudaram os testes... Você poderia fazer um override do método Inicializar na classe TACBrTEFDAuttar e escrever o novo comportamento esperado...