giulianon

Bom dia Juliana. Atualizei para última versão do ACBRBoleto e realmente não existem os campos. Segue o form alterado com os campos incluidos. Att. ACBrBoletoFCFortesFr.zip

Eu gero codigos de barra EAN válidos para um número qualquer. Na verdade gero o dígito verificador. Não sei se é isso que você precisa. Segue a rotina. Function geraEAN13(Code: String): String; var CheckSum, EANCode : String; Tmp2, Tmp, VerifyDigit : integer; begin //EANCode := '613'+DupeString('0',9-length(intToStr(code)))+intToStr(code); EANCode := DupeString('0',12-length(code))+code; CheckSum := '131313131313'; Tmp2 := 0; For Tmp := 1 to Length(EANCode) do Tmp2 := Tmp2 + (StrToInt (Copy (EANCode, Tmp, 1)) * StrToInt (Copy(CheckSum, Tmp, 1))); Tmp2 := Tmp2 mod 10; Tmp2 := 10 - Tmp2; VerifyDigit := StrToInt (Copy (IntToStr(Tmp2), Length(IntToStr(Tmp2)),1)); EanCode := StringReplace(TrimLeft(StringReplace(EanCode,'0',' ',[rfReplaceAll ])),' ','0',[rfReplaceAll]); result := EANCode + intToStr(Verifydigit); end;

Estou utilizando o Fortes sim. Mas quando me solicitaram esses campos a mais eu atualizei conforme a Juliana recomendou e esses campos não existiam e a parte do calculo do digito que tava certa ficou errada. Ai voltei a versão pro calculo do digito ficar certo, alterei o form e enviei pra homologar. Ai passou. De qualquer forma vou dar update agora e comparar com o meu. Se os campos não existirem eu dou um post do form aqui. Abraço!

Bom dia Juliana e Jéter! Meus boletos foram homologados, mas pra isso tive que usar uma versão mais antiga da classe que atendia ao siscob, e também alterar o form do boleto pra incluir os campos Outros Acréscimos e Outras Deduções. A parte da classe já vi que resolveram, então gostaria de saber se no form já foram incluidos os campos que citei. Se não foram ainda, posso enviar o que eu e fiz para que seja atualizado no svn. Att.

Eh consultado diretamente na impressora Ramom. Inclusive o ideal é que informações que não mudam durante o processo de registro dos itens, como no caso do número do equipamento, coo, etc sejam consultadas uma vez e armazenadas em variáveis, justamente pra não ficar fazendo acesso ao ecf o tempo todo. Att.

Giuliano, muito obrigado! Você resolveu parte do meu problema (: Mas vamos a segunda parte dele então: Tenho dois caixas: Um possui impressora Elgin X5 recem comprada. Nele beleza, achei um gerador de Sintegra no site da Elgin. O segundo caixa, tem rodando uma impressora Quattro QZ1000. Pra quem não lembra >> Não achei nem imagem maior ¬¬' Ela opera com bobina com segunda via e não achei nada parecido no site do fabricante igual no site da Elgin. Inclusive, a impressora nem aparece mais no site do fabricante... Meus amigos, será que alguém tem alguma solução? Porque seria horrível fazer o Sintegra desta Impressora na mão... Talvez algum programa do próprio fórum? Grato, Bruno Bruno acho que nesse caso será um problema pois as ecfs matriciais não tem memória fiscal, ou seja, não tem como consultar os dados nela. Nessa caso sim teria que ter isso gravado na base de dados. Eu desconheço alguma maneira de vc obter isso. Vamos deixar o post em aberto aqui e ver se algum outro colega tem alguma idéia ou dica pra te ajudar. Att.

Bruno, se não estou enganado tem algumas ecfs que fornecem programas tanto pra gerar as informações do paf quanto para gerar o arquivo do sintegra. Ve no site do fabricante da ecf se tem algo do tipo. Att

Psé eu também tinha gerado os boletos e o tanto o nosso número quanto o dígito verificador estavam conforme o solicitado pela caixa. O que faltava eram só os campos (+) Outros Acréscimos e (-) Outras Deduções na impressão do boleto. Eu inclui esses campos e em seguida atualizei o componente e ai o nosso número voltou a começar com 24 e o dígito verificador do cendente está incorreto. Mandei pra homologar e não passou de novo. Segue o que o pessoal da caixa me retornou Vou voltar a versão da Unit da caixa que fazia o cálculo correto e incluir o form com os campos solicitados e ver se passa. Att.

Psé, era o certo já que a base concentradora está em um servidor com capacidade e segurança pra mantê-la. E pra todos os caixas ficarem off-line teria que ser uma pane das grandes. Se um ta off vai no outro. Vou aguarda a opinião de mais colegas e depois fazer essa mudança. Obrigado! Att.

Boa tarde colegas! Estou enfrentando um problema ocasionado pela estrutura que tive que montar no meu sistema, para atender alguns requisitos do paf sugeridos (não exigidos) pelo homologador quando fiz a minha homologação. O homologador me passou que para gerar os arquivos de vendas no período (Sintegra/Sped), movimento por ecf, etc eu teria que poder gerar os mesmos em qualquer caixa da loja, ou seja, deveria haver um sincronismo das informações de cada caixa com os demais. Pra isso meu sistema se utilizada de uma base de dados "concentradora", onde todos os caixas exportam seus dados e importam dos demais caixas (dados do dia). Bom e ai que começou o meu problema, já que o volume de dados é enorme, e alguns caixas com configurações de hardware não muito boas estão começando a penar pra manter (espaço em disco) tudo isso. Conversei com alguns colegas e a maioria me disse que gera os arquivos diretamente da base de dados do sistema de gestão ou base concetradora como no meu caso, ou seja, não mantém esses dados em cada caixa. Bom esse questionamento eu fiz ao homologador e o mesmo me disse que apesar de não existir teste na homologação para saber a origem dos dados (no caixa ou no sistema de gestão), caso o fiscal chegasse na loja e o caixa estive off-line eu deveria ter nele os dados atualizados até o dia anterior. Bom como eu disse essa foi uma sugestão dele e que eu implementei, mas que agora está me causando problemas. Gostaria de saber como vcs implementaram isso, se alguém também questionou isso ao homologador e se realmente isso pode ser cobrado apesar de não estar no roteiro de testes. Obrigado! Att.

Boa tarde phulano! Vou te sugerir não usar o índice da forma de pagamento para enviar a mesma pera a ecf. Uma pq teu sistema vai exigir que todas as ecfs que forem trabalhar com ele tenha os índices iguais e já te adianto que por exemplo esse índice -2 tem ecf que não aceita. Outra é que algumas ecfs tens que passar o índice como 0 e algumas 00. Ou seja, vais ter que colocar "ifs" para diferenciar o formato de cada ecf. Então o ideal pesquisar a forma de pagamento pelo nome e ai sim enviar pelo índice. Desse jeito se for necessário cadastrar uma nova forma vc mesmo faz sem intervenção técnica. Exemplo: var forma: TACBrECFFormaPagamento; forma := ecf.AchaFPGDescricao('dinheiro',true,true); if forma <> nil then ecf.EfetuaPagamento(forma.Indice, 1.50); Abraço!

Também estou homologando e me pediram o mesmo (Outras deduções / Outros acréscimos). Esses campos tem que aparecer na impressão do boleto (Convênio SICOB). Notei que os campos existem na classe mas não saem na impressão, pois realmente não estão no form. Vou tentar corrigir aqui a impressão e ai posto pro pessoal analisar. Abraço!

Esse parâmetro descontoAcrescimo tu passa 'D' para desconto ou 'A' para acréscimo. O comando DescontoAcrescimoItemAnterior pelo menos na versão do acbr que eu tenho aqui (não é a última) não está implementado para essas duas ecfs. Acho que o melhor lugar pra vc ver como funciona e se está ou não implementado é no exemplo ECFTeste que acompanha o ACBR. Att.

Tem sim. ACBrECF1.VendeItem( codigo, descrição, aliquota, quantidade, preço, valorDescontoAcrescimo, unidadeMedida, tipoDescontoAcrescimo, descontoAcrescimo) Percentual tipoDescontoAcrescimo = '%' Valor tipoDescontoAcrescimo = '$' Sugiro que de uma olhada no exemplo ECFTeste que acompanha o ACBR. Nele você poderá tirar essas e outras dúvidas e ainda testar os comandos. Att

Na verdade fiz na minha aplicação Daniel, e fiz comparando o número de item só pra impedir que aconteça esse problema novamente. Mas vou dar uma estudada com mais calma e implementar esse controle do retorno de comandos na classe SWEDA. De qualquer forma vc saberia me dizer o que é esse .+P005 ? O pessoal da sweda não me respondeu ainda. Abraço! Att.

Boa noite colegas! Hoje um cliente me relatou que em uma venda de 35 itens somente 17 foram impressos no cupom fiscal e os 35 foram gravados no sistema, sendo que a partir do 18 todos os itens tinham o mesmo número. Achei um tanto quanto estranho já que isso nunca tinha acontecido. Bom, depois constatar que isso realmente tinha acontecido, fui no log do acbr pra ver se achava algo que me indicasse o problema. E ai notei que a partir do 17o item a ecf passou a retornar RX <- .+P005.+0018} para cada item enviado a ecf. Como conheço um pouco do protocolo ESC, sei que que retorno .+ são comandos enviados com sucesso e por isso os itens foram gravados, já que nenhum erro foi retornado. Não sei o que é o status .+P005 pois pra mim até então o P000 só retornaria erro como por exemplo .-P555 no caso de pouco papel. O número do item permaneceu o mesmo justamente porque os itens não foram impressos. Já enviei um email pra sweda pra tentar descobrir que status é esse .+P005 e tentar tratar esse retorno. Ah antes que eu esqueça. Isso aconteceu em uma ecf Sweda ST 1000 e eu ainda estou utilizando o "driver" SWEDA em vez do SWEDASTX que é o recomentado, pois ainda não testei completamente o meu sistema no SWEDASTX. De momento coloquei uma verificação comparando o número do item anterior e o atual, e bloqueando caso não haja o incremento do mesmo na ecf. (Mais ou menos o que recomenta o manual do protocolo ESC para o envio de comandos). Mas se alguém já passou por isso e puder me dar alguma dica. Obrigado! Segue o log: -- 14:55:52 VendeItem( 7896361714761 , OVOS TREVO C/12 VERMELHO , I , 1 , 2,77 , 0 , UN , $ , D ) TX -> [ESC].0178963617147610001000000002770000000000277~OVOS TREVO C/12 VERMELI } 14:55:53 RX <- .+0017} -- 14:55:53 NumUltimoItem TX -> [ESC].28} 14:55:54 RX <- .+0017016P VENDAS 01N000000004306000000004306!1306111455N 001NN000000004306000000000000SNNN0 } -- 14:55:54 DataHora TX -> [ESC].28} 14:55:54 RX <- .+0017016P VENDAS 01N000000004306000000004306!1306111455N 001NN000000004306000000000000SNNN0 } -- 14:55:55 VendeItem( 7896011127422 , REFRESCO TRINK 35G MORANGO , F , 1 , 0,59 , 0 , UN , $ , D ) TX -> [ESC].0178960111274220001000000000590000000000059~REFRESCO TRINK 35G MORAF } 14:55:57 RX <- .+0018} -- 14:55:57 NumUltimoItem TX -> [ESC].28} 14:55:58 RX <- .+0018017P VENDAS 01N000000004365000000004365!1306111455N 001NN000000004365000000000000SNNN0 } -- 14:55:58 DataHora TX -> [ESC].28} 14:55:58 RX <- .+0018017P VENDAS 01N000000004365000000004365!1306111455N 001NN000000004365000000000000SNNN0 } -- 14:55:59 VendeItem( 7896011127767 , REFRESCO TRINK 35G COCO VERDE , F , 1 , 0,59 , 0 , UN , $ , D ) TX -> [ESC].0178960111277670001000000000590000000000059~REFRESCO TRINK 35G COCOF } 14:55:59 RX <- .+P005.+0018} -- 14:55:59 NumUltimoItem TX -> [ESC].28} 14:56:00 RX <- .+0018017P VENDAS 01N000000004365000000004365!1306111455N 001NN000000004365000000000000SNNN0 } -- 14:56:00 DataHora TX -> [ESC].28} 14:56:00 RX <- .+0018017P VENDAS 01N000000004365000000004365!1306111455N 001NN000000004365000000000000SNNN0 } -- 14:56:01 VendeItem( 7891000022016 , BISC.NESTLE 165G P.TEMPO CHOC.CHOC. , F , 1 , 2,48 , 0 , UN , $ , D ) TX -> [ESC].0178910000220160001000000002480000000000248~BISC.NESTLE 165G P.TEMPF } 14:56:01 RX <- .+P005.+0018} -- 14:56:01 NumUltimoItem TX -> [ESC].28} 14:56:02 RX <- .+0018017P VENDAS 01N000000004365000000004365!1306111455N 001NN000000004365000000000000SNNN0 } -- 14:56:02 DataHora TX -> [ESC].28} 14:56:02 RX <- .+0018017P VENDAS 01N000000004365000000004365!1306111455N 001NN000000004365000000000000SNNN0 } -- 14:56:03 VendeItem( 7892840222543 , SALG.CHEETOS 50G ONDA REQUEIJAO , F , 1 , 1,29 , 0 , UN , $ , D ) TX -> [ESC].0178928402225430001000000001290000000000129~SALG.CHEETOS 50G ONDA RF } 14:56:04 RX <- .+P005.+0018}

Vou testar em uma máquina com uma porta serial mesmo, pq aqui pra desenvolver eu uso um cabo usb -> serial na comunicação com a ecf, e talvez seja isso, pois já troquei inclusive esse cabo, o cabo da ecf e a porta usb que ele está conectado. De qualquer forma seria interessante essa alteração que vc sugeriu, pois quando o problema acontece o sistema fica parado nesse loop infinito. Um "timeout" resolveria. Obrigado pela ajuda Fernando. Abraço!

Psé! Foi o que o pessoal do suporte me informou. Que isso poderia ter sido programado na lacração a ecf. De qualquer forma obrigado pela ajuda! Abraço!

Boa tarde colegas! Apesar da recomendação em vários tópicos aqui do fórum, para que com ecfs térmicas se utilize o protocolo SWEDASTX em vez de SWEDA, eu inicialmente não tendo conhecimento dessa recomendação, configurei em todos os meus clientes (todos tem ecf mfd) o protocolo SWEDA. Agora que me sobrou um tempo, resolvi alterar o meu sistema aqui para trabalhar com o protocolo SWEDASTX como recomendado. Bom e no primeiro teste (EcfTeste.exe) que fui fazer emitindo uma leitura X, aconteceu que a impressão foi feita normalmente mas ao fim da impressão a impressora continuou ocupada de forma permanente. Fiz o mesmo teste várias vezes e o mesmo aconteceu. Troquei a ecf e não teve jeito. Mesmo "problema". Bom ai resolvi olhar o log do ACBR que segue abaixo -- 13:28:53 LeituraX SwedaSTX VerificaFimLeitura: Verificando Bloco: 115+0000AE‚€‚€€‘ SwedaSTX VerificaFimLeitura: Seq:49 Tarefa:15 Tipo: + ACK:6 Result: True SwedaSTX VerificaFimImpressao: Pedindo o Status. Seq:50 SwedaSTX VerificaFimImpressao: ACK = 6, OK... Aguardando Bloco SwedaSTX VerificaFimImpressao: I: 1 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 2 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 3 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 4 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 5 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 6 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 7 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 8 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 9 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 10 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 11 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 12 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 13 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 14 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 15 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 16 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 17 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 18 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 19 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 20 Bloco Lido: SwedaSTX VerificaFimImpressao: Pedindo o Status. Seq:51 SwedaSTX VerificaFimImpressao: ACK = 6, OK... Aguardando Bloco SwedaSTX VerificaFimImpressao: I: 1 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 2 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 3 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 4 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 5 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 6 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 7 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 8 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 9 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 10 Bloco Lido: SwedaSTX VerificaFimImpressao: I: 11 Bloco Lido: 2 SwedaSTX VerificaFimImpressao: I: 12 Bloco Lido: 23 SwedaSTX VerificaFimImpressao: I: 13 Bloco Lido: 234 SwedaSTX VerificaFimImpressao: I: 14 Bloco Lido: 234+ SwedaSTX VerificaFimImpressao: I: 15 Bloco Lido: 234+0 SwedaSTX VerificaFimImpressao: I: 16 Bloco Lido: 234+00 SwedaSTX VerificaFimImpressao: I: 17 Bloco Lido: 234+000 SwedaSTX VerificaFimImpressao: I: 18 Bloco Lido: 234+0000 SwedaSTX VerificaFimImpressao: I: 19 Bloco Lido: 234+0000AA SwedaSTX VerificaFimImpressao: I: 20 Bloco Lido: 234+0000AA‚ SwedaSTX VerificaFimImpressao: Pedindo o Status. Seq:52 SwedaSTX VerificaFimImpressao: ACK = 6, OK... Aguardando Bloco Me parece que alguma leitura continua sendo feita depois da impressão. É assim mesmo? Tem alguma configuração que pode ser feita? Se alguém puder me dar alguma dica agradeço desde já. Att.

Eu particularmente achei ótima essa sugestão do strago. Um valor inicial financiaria a estruturação desse suporte (SAC) e o valor mensal manteria tudo. Sobre os valores eu achei de bom tamanho também, mas ai caberia ao pessoal do projeto avaliar pra ver se realmente seria o suficiente. Também concordo que o ACBR já faz muito pelos usuários só no fato de existir e conter ótimos exemplos do seu funcionamento. Exigir do pessoal respostas pra dúvidas, e como foi citado em algum post "pra ontem", realmente acho que sem remuneração alguma já é demais, até pq tem muitas dúvidas realmente são pertinentes, mas tem muitas que é pura falta de interesse das pessoas buscarem a solução. Então nada mais justo que o projeto tenha o suporte oficial cobrado. Os demais fóruns (yahoo,msdn) ficariam pra quem não quiser pagar. Se essa idéia for aderida pelo pessoal do projeto, eu acho que seria legal fazer uma pesquisa pra saber qual das 3 sugestões de "planos" seria mais interessante para os futuros usuários. Eu particularmente pagaria qualquer um deles. Abraço!

Dae galera! Saiu o novo roteiro de homolgação e o pessoal da UNOCHAPECÓ fez um post legal sobre o assunto. Fala sobre os prazos e as diferenças pro roteiro anterior. Segue o link pra quem quiser dar uma olhada. http://pafunochapeco.blogspot.com/ Abraço!

Eu fiz essa implementação para a Dataregis e acredito que seja a mesma para Urano. Só não postei ainda o fonte alterado, porque estou aguardando uma solução do suporte da dataregis para a geração do Arquivo MFD que não está funcionando com o Delphi 2010. Assim que eu resolver esse problema do Arquivo MFD vou postar o fonte pro pessoal analisar e se estiver ok colocar no SVN. Att.

Beleza Daniel! Vou testar e depois posto aqui se funcionou. []s Att.

Blz então Elton! Vou alterar aqui e testar. Qualquer dúvida posto aqui e se funcionar corretamente anexo a classe pra vocês analisarem. []s Att.

Conferido Elton. Tudo funcionando corretamente Obrigado!! []s