koplin

Saudações: Disponibilizo Alterações na Unit ACBrBancoDaycoval.pas para incluir a geração de arquivos NFe. Uma alteração que fizemos na empresa para permitir o uso com o banco. Foi incluída a procedure: procedure TACBrBancoDaycoval.GerarRegistrosNFe(ACBrTitulo: TACBrTitulo; aRemessa: TStringList); Em Anexo, o .pas alterado + o manual do banco, em arquivo compactado. BancoDayCoval.zip

Fico feliz em ajudar. Ainda mais neste caso que a ajuda foi recíproca. Resolveu para ambos. Já que resolveu, segue ai a unit para apreciação dos desenvolvedores. Att, Alfredo. ACBrCaixaEconomicaSICOB.pas

Saudações: Eu havia sugerido uma propriedade para a leitura da linha digita do boleto gerado. A implementação foi iniciada mas ficou inacabada. Eu completei as rotinas e está funcionando. Segue a Unit para sua apreciação. Att, Alfredo Koplin. ACBrBoleto.pas ACBrBoleto.pas

Aqui mesmo no forum o colega Luiz Carlos Silvestrini apresentou esta solução: que, segundo ele foi testado para 15 posições. Estranhamente, ninguém disse se aprovou e o componente não apresenta esta mudança. Por favor, faz um teste (eu não tenho o app da caixa) e retorna se deu certo pra você. eu só mudei um trecho para garantir que ele faça com SR e 15 posições, não interferindo nos demais. if (UpperCase(ACBrTitulo.Carteira) = 'SR')and(CalcularTamMaximoNossoNumero(ACBrTitulo.Carteira,ANossoNumero)=15) then CampoLivre := Copy(aCodCedente, 7, 5) + RightStr(ACBrTitulo.ACBrBoleto.Cedente.Agencia, 4) + '87' + RightStr(ANossoNumero, 14) else CampoLivre := ANossoNumero + RightStr(ACBrTitulo.ACBrBoleto.Cedente.Agencia, 4) + aCodCedente Att, Alfredo koplin.

Olá, O componente está fazendo correto, pelo menos pelo manual que tenho em mãos: ESPECIFICAÇÃO DO CÓDIGO DE BARRAS PARA BLOQUETOS DE COBRANÇAS RÁPIDA E SEM REGISTRO SICOB - NOSSO NÚMERO 11 POSIÇÕES. Não consegui baixar no site da CEF, mas vi que tem manual para tamanhos diferentes de nosso numero. Infelizmente o que tenho está em papel e as páginas de download da caixa estão off. Mas, em relação ao nosso número, este manual, na pag 5 diz: cobrança sem registro : 82NNNNNNNN-DV COBRANÇA RÁPIDA: 9NNNNNNNNN-DV Eu solicitei que um boleto fosse enviado e pago ao banco e vou aguardar o retorno e posto aqui. Mas de antemão, creio que a caixa tem várias formas de fazer a codificação dos boletos. Me parece que o componente adotou a sistemática deste manual. Provavelmente o app da caixa usa outra forma. O que vai bater o martelo será o pagamento do boleto. Tomara que dê certo. Também estou na busca da solução. Se alguém puder ajudar a resolver este embate, agradecemos. Att, Alfredo Koplin.

Saudações: Eu tive o mesmo problema e creio que descobri a causa, pelo menos no meu caso (SICOB). Para o caso do boleto da caixa, formate o NOSSO NÚMERO com 8 dígitos. Percebi que se o nosso numero for menor do que 8, o componente formata com 15 e no processo da geração do código de barras, suprime os 5 dígitos finais do código cedente. Por consequência o boleto é aceito mas não cai em conta alguma. Ainda vou enviar um boleto para pagamento, mas o código do cedente apareceu na linha digitada corretamente, após este procedimento. Da forma como está, é necessário enviar o nosso número formatado com tamanhos diferentes para boletos de bancos diferentes. Por exemplo: o BANCOOB só aceita 7 dígitos no nosso número. Uma sugestão aos desenvolvedores do componente é que no mesmo seja feita uma formatação mínima, para prevenir que o nosso número fique fora do padrão mínimo de tamanho, o que eliminaria este problema. Aqui estou enviando o código do cedente sem o numero da agencia. O componente obriga a informar o código da agencia e se informar o mesmo código no cedente o numero se repete. assim: código do cedente informado pelo banco: 1822870000000999 (1822 - 870000000999) informo no código do cedente apenas 870000000999. 10498.20002 02565.182082 70000.009994 2 63020000000100 - linha correta 10490.00001 00000.025627 18208.700007 1 63020000000100 - linha incorreta Att, Alfredo Koplin.

Grato pelas respostas. Eu me adiantei colocando aqui, devido ao fato de meu ECF já rodar com data de fevereiro de 2014 e não conseguiria validar o SPED na versão 007. Vou atualizar e testar. Grato mais uma vez pela atenção e sempre meus parabéns a todos os colaboradores ACBR.

Saudações: Estou gerando um arquivo SPED com data referente a fev / 2014, isto devido ao fato de meu ECF estar adiantado no seu relógio interno. Ao validar, me deparei com o erro: "A versão de leiaute não é valida para o período informado." Analisando os fontes, vi que a ultima versão é a vlVersao106 (007). O ACBR aqui, está atualizado. Existe alguma previsão para a inclusão da nova versão? Eu mudei internamente no arquivo gerado a versão de 007 para 008, para continuar meus testes. Estou usando o PVA 2.0.3.3 (a última versão do validador). Att, Alfredo Koplin.

Saudações a todos: O problema: Sob Windows 8, o bloqueio de teclado/mouse não funciona. Testei, inclusive a função BlockInput em um aplicação simples, sem ACBR e realmente não funciona. O problema está no nível de privilégio requerido para que o Windows processe a função. Uma forma de fazer com que o aplicativo funcione é mudar o nível de privilégio do arquivo .exe manualmente (marcando a opção Executar este programa como administrador). O desejável é que o aplicativo não requeira esta mudança. A solução: Ao pesquisar na NET encontrei este artigo bem explicado.(http://www.cesarromero.com.br/embutindo-o-manifesto-na-aplicao-com-delphi/). Lá tem uma boa explicação do mecanismo de permissões. Fiz os simples procedimentos e embuti o RES na minha aplicação. abaixo um exemplo .dpr simples com a adição do RES program Project1; uses Vcl.Forms, Unit2 in 'Unit2.pas' {Form2}; {$R *.res} {$R UAC.res} begin Application.Initialize; Application.MainFormOnTaskbar := True; Application.CreateForm(TForm2, Form2); Application.Run; end. Vá em Project/Options/Application e coloque "none" em runtimes themes. Se estiver diferente de None, não funciona. Após a compilação o bloqueio passou a funcionar normalmente. Uma dica: o Delphi deve estar rodando com privilégios administrativos, do contrário ele compila e gera o exe mas não o roda, além de exibir uma mensagem informando que necessita de elevação. O arquivo compilado (.RES) deve estar junto aos principais arquivos do projeto, ou ao compilar, o Delphi informará que o .RES não foi encontrado. Eu testei o executável na minha maquina de desenvolvimento (W8) e em outras duas, rodando W8 e W8.1. Não testei no W7 com o UAC ativo. Espero que a dica ajude aos colegas que possam ter a mesma dificuldade.

Juliomar, Bom dia. Grato pelas explicações. Liguei lá e foi como você disse. O manual está realmente incorreto. Muito obrigado.

Juliomar, grato por sua resposta. No manual do PAY&Go Demo diz: Acata desfazimento: Não utilizar esta opção. Ao marcar, o emulador ele pede uma senha que é diferente das que estão no manual (tentei as duas listadas nele). Entendi que ao marcar, esta opção, o emulador não vai apresentar a tela. Mas e nos testes? Se for usada esta opção ainda assim o problema surgirá. Se o amigo puder acrescentar algo, agradeço. Att, Alfredo Koplin.

Saudações: Ao fazer um teste de desligamento do ECF, a automação procede o cancelamento TEF corretamente. Ocorre que, quando a automação exibe a tela com o NSU e o botão OK, o aplicativo da PAyGO abre junto, uma segunda tela de confirmação da anulação. Esta nova tela bagunça o foco, porque ela fica abaixo do Application message da automação. Desta forma não dá pra fazer o OK com a tecla ENTER. Fiz o mesmo procedimento com o demo e resultou igual. Os fontes do ACBR e os aplicativos TEFS são os mais recentes. Na rotina de controle de foco estou usando: Application.ProcessMessages; Application.BringToFront; Application.NormalizeAllTopMosts; Tratado := False; Lembro que, no demo esta fazendo da mesma forma. Estou desligando o ECF e mantendo-o desligado até o fim do processo. Att, Alfredo Koplin

Fala Regys! Obrigado pelo reply. Esta funcionalidade atende MG somente, até onde eu sei. Mas pode ser feito via WebService, conforme o manual em http://portalnfe.fazenda.mg.gov.br/downloads/Manual_do_Registro_de_Saida_100512.pdf O SIARE é realmente utilizado para este fim. Mas a implementação desta funcionalidade no ACBR seria útil. Como não vi postagens recentes a respeito, quero saber se já tem alguém fazendo algo neste sentido. Abc.

Saudações: Existe já, algum trabalho no sentido de implementar o Registro de Saída de NF-e no ACBR? Att, Alfredo Koplin.

Valeu, Regys, pela informação. Detalhe, não tem a opção RESOLVIDO para marcar. Att, Alfredo Koplin.

Saudações: Li em um tópico sobre a mudança no layout do RG Param. de configuração onde, se a versão é >= 201 ele imprime Perfil de Requisitos Configurado: <Letra do perfil> Ao implementar as mudanças (que são: a informação da versão e a letra do requisito), me deparei com algo estranho: Aqui, a forma como configuro as informações na minha aplicação: AAC.AbrirArquivo; AAC.IdentPAF.Paf.RecompoeGT := True; AAC.IdentPAF.Paf.RecompoeNumSerie := True; AAC.IdentPAF.VersaoER := '0201'; AAC.IdentPAF.Paf.PerfilRequisitos := 'F'; Mesmo informando ao AAC a versão 0201 ele não mudou a impressão do RG. Assim, analisando o código na unit AcbrECF, a partir da linha 6155, me deparei com a seguinte situação: (omiti alguns trechos da rotina para simplificar a visualização) procedure TACBrECF.PafMF_RelParametrosConfiguracao(AInfoPafECF: TACBrECFInfoPaf; const AIndiceRelatorio: Integer); var ... versaoPafECF: Integer;//a var obtém a versão da ER ... ... ... begin versaoPafECF := 0;//aqui ele define zero como padrão ... ... Aqui me deparei com o problema if (not Assigned(AInfoPafECF)) then //AInfoPafECF existe e ele pula este trecho begin if Assigned(fsAAC) then begin AInfoPafECF := fsAAC.IdentPAF.Paf; versaoPafECF := StrToInt(OnlyNumber(fsAAC.IdentPAF.VersaoER));//onde deveria obter o valor da versão end else raise EACBrECFErro.Create( ACBrStr('Parâmetros de configuração do Paf-ECF não informados') ) ; end; ... Relatorio := TStringList.Create; try Relatorio.Clear; Relatorio.Add('</linha_dupla>'); Relatorio.Add('<ce>PARÂMETROS DE CONFIGURAÇÃO</ce>'); Relatorio.Add('</linha_dupla>'); Relatorio.Add(''); //e aqui esta sempre como zero e nao muda o processamento da impressão if versaoPafECF >= 201 then Relatorio.Add('Perfil de Requisitos Configurado: ' + AInfoPafECF.PerfilRequisitos) else begin ... Existe aqui um erro ou estou fazendo algo errado nas configurações? Eu chamo a impressão da seguinte forma: ECF.PafMF_RelParametrosConfiguracao(ECF.AAC.IdentPAF.Paf, indice); Att, Alfredo Koplin PS: Após pensar um pouco, fiz o seguinte: ECF.PafMF_RelParametrosConfiguracao(nil, indice); e funcionou, mas ainda assim cabe a dúvida: a rotina do ACBRECF nao deveria prever que AInfoPafECF está presente e proceder de acordo?

Beleza, Daniel. Vou colocar o post como resolvido e aguardar atualização. Aproveitando, eu postei um tópico sobre o ACBR Boleto e não houve um feedback. Se puder, dê um toque na galera responsável pelo ACBRBoleto para dar uma olhada. Parabéns a todos pelo ótimo trabalho com o ACBR. Att, Alfredo Koplin. Alfredo Koplin.

Daniel, você matou a charada! Fiz isso aqui: na unit ACBrECF linha 3985 procedure TACBrECF.ArquivoMF_DLL(NomeArquivo: AnsiString); begin TestaSeE_MFD ; ComandoLOG := 'ArquivoMF_DLL( ' + NomeArquivo + ' ) '; if fsECF.Ativo then fsECF.Desativar; fsECF.ArquivoMF_DLL( NomeArquivo ) ; end; e a função funcionou. Como acredito que exista uma rotina que centralize a desativação da serial, vou deixar ao seu encargo. Quando tiver uma correção me informe. Att, Alfredo Koplin.

Daniel, Grato pela resposta: O Erro -1, retornado pela dll tanbém não é muito claro: A resposta extendida é "Erro do Método.". Andei debugando para acompanhar o código e a unica diferença que vi: xrEfetuarDownloadMF_ECF_Daruma: function(pszNomeArquivo:String): Integer; {$IFDEF LINUX} cdecl {$ELSE} stdcall {$ENDIF} ; Nas demais funções, os parâmetros estão declarados como AnsiString. Claro que eu mudei o tipo do parâmetro na função e não resultou também. Tenho a impressão que em algum lugar o fato de ser string ou ansistring esta fazendo isso. Também comparei o xml da daruma e não vi nada diferente entre o xml que configura o DarumaFramework e o ACBR. Inclusive fiz a troca de ambos. Sempre pelo DarumaFrameWork, o arquivo é gerado e o retorno é [1] (sucesso). As dlls da Daruma são as mesmas em ambas aplicações. Coloquei inclusive o DarumaFramework junto ao ECFTeste. Não tenho réplica das dlls em nenhum outro local. Sempre trabalho com as dlls junto ao exe. Fiz o seguinte: Ativei o modo auditoria no XMl, executei o comando e to mandando os logs, gerado pela dll. Talvez ajude a entender o erro. Vou continuar pesquisando pra ver se acho o gato. Mas se Vocês conseguirem algum progresso, vamos conversando. Att, Alfredo Koplin. 72392Auditoria_ECF.txt Auditoria_ECF.txt

Saudações: Estou com um problema ao implementar a rotina ArquivoMF_DLL(): Ela sempre retorna erro -1. - ECF utilizado FS600 - Baixei as versões mais recentes das DLLs no site da DARUMA. - ACBR Atualizado HOJE. - Testei com o aplicativo DarumaFrameWork.exe e gerou o arquivo normalmente. - Testei sob XE2 e XE4. - Utilizo Windows 8. testei a função ArquivoMFD_DLL e esta rodou normalmente. Como não havia no ECFTeste um menu com esta opção, implementei no ECFTeste um menu "ARQ MF" com o código abaixo: ----------------------------- var arquivo: string; begin Arquivo := 'teste.mf' ; if not InputQuery('Arquivo da MF DLL', 'Nome Arquivo:', Arquivo ) then exit ; ACBrECF1.ArquivoMF_DLL(Arquivo); end; ------------------------------ Na tela do ECFTeste segue: COMANDO ENVIADO: #29#8#13 RESPOSTA: - + - + - + - + - + - + - + - + - + - + - + - Erro ao executar rEfetuarDownloadMF_ECF_Daruma. Cod.: -1 Erro do Método. :#13 - + - + - + - + - + - + - + - + - + - + - + - Em anexo o log do ACBR. Agradeço a atenção. Att, Alfredo Koplin. acbrlog.txt

Saudações: Fiz uma alteração no ACBRBoleto para permitir a recuperação da Linha digitada. Esta funcionalidade eu já usava com outro componente, que modifiquei, para permitir que eu possa enviar o texto da linha por e-mail. Ao migrar para o ACBRBoleto, senti falta desta funcionalidade e em virtude dela ser útil para outros e evitar que eu fique com um código diferente, envio as units modificadas para sua apreciação. Se julgarem procedente, fiquem a vontade para implementar. A ideia é ter uma propriedade LinhaDigitada, que é preenchida sempre que uma geração de boleto ocorra. Assim Após a geração, recupero a informação para posterior uso. trecho exemplificando o uso: AcbrBoleto1.GerarPDF; //troco '%linhadigitada' pelo texto da propriedade LinhaDigitada FindReplace('%linhadigitada', Boleto1.Banco.LinhaDigitada, AStringList); //envio o e-mail com a mensagem contendo a linha digitada AcbrBoleto1.EnviarEmail(QvwBoletomail_host.AsString, QvwBoletomail_port.AsString, QvwBoletomail_user.AsString, QvwBoletomail_password.AsString, QvwBoletomail_from.AsString, '[email protected]', //to QvwBoletomail_assunto.AsString, AStringList,//mensagem ... Cordialmente, Alfredo Koplin. ACBrBoleto.pas

Boa noite: Não sei se o amigo já resolveu o problema, mas comigo vem ocorrendo o mesmo problema relatado. O site da SEFAZ MG esta em contingencia desde o dia 18/4/2013, como informado pelo Kiko. Desde então, os problemas tem ocorrido com certa intermitência. Eu orientei aos meus clientes que mudassem para o modo SCAN. E os envios tem sido normais. Até hoje a tarde (sábado - 18/05), ainda não consegui fazer um envio decente pelo modo normal. Creio que enquanto o SCAN estiver liberado, devemos utilizar este meio para envio em produção. No ambiente de homologação não registrei problemas. Lembrando que nessa modalidade o XML é enviado diretamente para o ambiente nacional que repassa para a SEFAZ de origem, não sendo necessária a retransmissão dos XML's.

Saudações a todos: Eu utilizo os componentes ACBR para NF-e, SPED entre outros e no meu banco de dados eu uso obter o Índice de algumas propriedades: algo como: cdNF_ItemIPI_CST.Value := Integer(NFE1.NotasFiscais.Items[x].NFe.Det.Items.Imposto.IPI.CST); Assim, para o CST IPI = 49 eu gravo o índice 1 (ipi49). O que ocorre é que quando o XML não possui a informação (exemplo abaixo) o componente retorna Imposto.IPI.CST = ipi00 (indice 0); Assim, eu não tenho como saber se o cst IPI é realmente ipi00 ou não existe no XML. 18/05 - Melhorando o tópico: Analisando os códigos percebi o seguinte: Unit pcnNFeR - function TNFeR.LerXml: boolean; ... if Leitor.rExtrai(3, 'IPI') <> '' then begin (*O02*)NFe.Det.Imposto.IPI.clEnq := Leitor.rCampo(tcStr, 'clEnq'); (*O03*)NFe.Det.Imposto.IPI.CNPJProd := Leitor.rCampo(tcStr, 'CNPJProd'); (*O04*)NFe.Det.Imposto.IPI.cSelo := Leitor.rCampo(tcStr, 'cSelo'); (*O05*)NFe.Det.Imposto.IPI.qSelo := Leitor.rCampo(tcInt, 'qSelo'); (*O06*)NFe.Det.Imposto.IPI.cEnq := Leitor.rCampo(tcStr, 'cEnq'); // Inicializa CST com sendo Não tributada e conforme o TIPO entrada ou saida // Caso a Tag não seja informada sera gravada com sendo não tributada if NFe.ide.tpNF = tnEntrada then NFe.Det.Imposto.IPI.CST := ipi53; if NFe.ide.tpNF = tnSaida then NFe.Det.Imposto.IPI.CST := ipi03; Este trecho resolve o problema. O que ocorre é que o valor default da propriedade é ipi00. Se não existe a tag no XML a função <Leitor.rExtrai(3, 'IPI')> retorna '' e o código é pulado. Creio que a resolução está em colocar a rotina acima antes do if: if NFe.ide.tpNF = tnEntrada then NFe.Det.Imposto.IPI.CST := ipi53; if NFe.ide.tpNF = tnSaida then NFe.Det.Imposto.IPI.CST := ipi03; if Leitor.rExtrai(3, 'IPI') <> '' then begin ... Dessa forma, mesmo que não ocorra a tag no XML, a propriedade será corretamente setada. Ocorre o mesmo com outras propriedades (PIS e COFINS ate onde eu vi). Att, Alfredo Koplin Trecho do XML sem tag IPI: <imposto> <ICMS> <ICMS40> <orig>0</orig> <CST>40</CST> </ICMS40> </ICMS> <PIS> <PISNT> <CST>06</CST> </PISNT> </PIS> <COFINS> <COFINSNT> <CST>06</CST> </COFINSNT> </COFINS> </imposto>