koplin
-
Total de ítens
23 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por koplin
-
-
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.
-
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.
-
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) thenCampoLivre := Copy(aCodCedente, 7, 5) + RightStr(ACBrTitulo.ACBrBoleto.Cedente.Agencia, 4) + '87' + RightStr(ANossoNumero, 14)elseCampoLivre := ANossoNumero + RightStr(ACBrTitulo.ACBrBoleto.Cedente.Agencia, 4) + aCodCedenteAtt,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;usesVcl.Forms,Unit2 in 'Unit2.pas' {Form2};{$R *.res}{$R UAC.res}beginApplication.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.
-
4
-
-
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.........beginversaoPafECF := 0;//aqui ele define zero como padrão......Aqui me deparei com o problemaif (not Assigned(AInfoPafECF)) then //AInfoPafECF existe e ele pula este trechobeginif Assigned(fsAAC) thenbeginAInfoPafECF := fsAAC.IdentPAF.Paf;versaoPafECF := StrToInt(OnlyNumber(fsAAC.IdentPAF.VersaoER));//onde deveria obter o valor da versãoendelseraise EACBrECFErro.Create( ACBrStr('Parâmetros de configuração do Paf-ECF não informados') ) ;end;...Relatorio := TStringList.Create;tryRelatorio.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ãoif versaoPafECF >= 201 thenRelatorio.Add('Perfil de Requisitos Configurado: ' + AInfoPafECF.PerfilRequisitos)elsebegin...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 KoplinPS: 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);beginTestaSeE_MFD ;ComandoLOG := 'ArquivoMF_DLL( ' + NomeArquivo + ' ) ';if fsECF.Ativo thenfsECF.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.
-
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:
-----------------------------
vararquivo: string;beginArquivo := 'teste.mf' ;if not InputQuery('Arquivo da MF DLL','Nome Arquivo:', Arquivo ) thenexit ;ACBrECF1.ArquivoMF_DLL(Arquivo);end;------------------------------Na tela do ECFTeste segue:COMANDO ENVIADO:#29#8#13RESPOSTA:- + - + - + - + - + - + - + - + - + - + - + -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.
-
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 LinhaDigitadaFindReplace('%linhadigitada', Boleto1.Banco.LinhaDigitada, AStringList);//envio o e-mail com a mensagem contendo a linha digitadaAcbrBoleto1.EnviarEmail(QvwBoletomail_host.AsString,QvwBoletomail_port.AsString,QvwBoletomail_user.AsString,QvwBoletomail_password.AsString,QvwBoletomail_from.AsString,'[email protected]', //toQvwBoletomail_assunto.AsString,AStringList,//mensagem...
Cordialmente,
Alfredo Koplin.
-
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') <> '' thenbegin(*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 tributadaif NFe.ide.tpNF = tnEntrada thenNFe.Det.Imposto.IPI.CST := ipi53;if NFe.ide.tpNF = tnSaida thenNFe.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 thenNFe.Det.Imposto.IPI.CST := ipi53;if NFe.ide.tpNF = tnSaida thenNFe.Det.Imposto.IPI.CST := ipi03;if Leitor.rExtrai(3, 'IPI') <> '' thenbegin...
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>
Banco DayCoval - NFe
em ACBrBoleto
Postado
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