JLuis

Como vcs. estão atribuindo os valores dos campos NR_TOT e DESCR_NR_TOT? Estão capturando da impressora ou atribuindo um sequencial? Obrigado

Obrigado pelo retorno... também cheguei a esta conclusão... O vai ajudar é a captura dos dados da Redução Z que já é meio caminho e já tinha no BD, esta é fundamental, o que ainda tá pegando é bater o valor dos totalizadores parciais do C420 com o C490 que totaliza o movimento do dia agrupado por CST, CFOP e alíquota pois aí tenho que tomar como base os dados dos ítens dos cupons fiscais que tenho no banco. Se chegar a alguma solução melhor posta aí, vamos compartilhar.... Alguém mais teria alguma dica pra encurtar o caminho...?

Bom dia, Além do ACBrSPED(Fiscal), estou também utilizando a função Bematech_FI_GeraRegistrosSpedMFD da DLL da Bematech para gerar os registros referentes ao movimento da ECF e após importar o TXT para o componente e assim gerar o TXT final já unificado/completo, porém, fiquei em dúvida quanto ao cálculo de PIS e COFINS que a função faz pois me parece que aplica as alíquotas passadas por parâmetro para todos os ítens o que no meu ver poderá gerar divergência em relação aos produtos com CST 04 para os quais a alíquota é zero. Já solicitei esclarecimentos junto à Bematech mas ainda n ão obtive retorno. >> Alguém utiliza esta função e poderia compartilhar sua experiência com ela? Será que é confiável? Desde já agradeço.

Isaque, obrigado pela sua atenção... Acabei de descobrir o problema, não tem nada a ver com o ACBr... acho que já torrei muitos neurônios com o SPED... o que ocorreu foi que precisei alterar o tamanho de um campo no banco de 2 para 6 caracteres e possuia um objeto DataSet com um campo pesistente o qual não havia sido alterado. O AV ocorria em pontos aleatórios da minha rotina de geração do PIS/COFINS, algo meio fantasmagórico.. rsrs.. mas parece que era esta a fonte do problema, ajustei o dito cujo e sumiu o AV De qualquer forma obrigado, tenho o PVA pela frente ainda... Abraço

Olá Elton, Isolei as chamadas à rotina de validação de CPF/CNPJ e peguei o erro novamente em: function TACBrTXTClass.DFill(Value: Double; Decimal: Integer = 2; Nulo: Boolean = false): String; begin /// Se o parametro Nulo = true e Value = 0, será retornado '|' if (Nulo) and (Value = 0) then << breakpoint aqui mas não executou o código do if... begin Result := FDelimitador; Exit; end; Result := FDelimitador + FormatCurr('#0.' + StringOfChar('0', Decimal), Value); << após executar esta linha com F8, ao dar F8 nalinha abaixo (end;) a aplicação trava end; >>> executei o código FDelimitador + FormatCurr('#0.' + StringOfChar('0', Decimal), Value) com CTRL+F7 antes de executar a linha com F8 e o reultado foi '|10,00000' que é o correto porém, o valor de Result após a execução da linha pode ser visto na imagem em anexo. Já esgotei minhas possibilidades e nada... Mais uma vez agradeço a vc. e a quem puder dar alguma dica.

Estou tendo dificuldades na geração do PIS/COFINS devido a um erro de Violação de Acesso que ocorre sempre na linha 760 da unit UCBBrSpedUtils.pas >>> Base_3 := Copy(('0000000000000000' + Trim(Base_2)), Length(('0000000000000000' + Trim(Base_2))) - 13, 14); O erro ocorre em momentos diferentes, na validação de CNPJ ou CPF. Já percebi inclusive que valida um determinado CPF e em chamadas posteriores para validar novamente o mesmo CPF gera o AV. Não consegui achar nada de errado nos meus fontes, gero todos os blocos normalmente e quando chamo a gravação do bloco zero no qual todos os "participantes" do registro 0150 passam pela validação do CPF/CNPJ ocorre o problema. Alguém pode me dar alguma dica?? Já passou por isso?? Seria bug do ACBr? Estou com o ACBr 100% atualizado. Desde já agradeço.

Bom dia, Eu já assinei. Pessoal, vamos nos mobilizar e apoiar!

Bom dia, Estou com algumas dúvidas em relação à utilização das tabelas de "Natureza das Receitas" para a geração dos registros M400/410 e M800/810. Não estou vendo outra alternativa a não ser fazer o usuário codificar os produtos, um a um, com o Código da Natureza da Receita, deixando que o mesmo faça o enquadramento de cada produto na respectiva tabela (4.3.10, 4.3.11, 4.3.12, ...) e preencha o campo no cadastro de produtos. O que me deixa um pouco inseguro em relação a esta solução é o fato de que as diferentes tabelas repetem os códigos! Pelo leiaute, cada registro M400 e M800 deve se referir a um código de CST PIS/COFINS e os registros M410 e M810 os registros de detalhamento (filhos) de acordo com o código da Natureza da receita. Isso dá a entender que poderá haver repetição de um mesmo código para produtos diferentes, de tabelas diferentes, e há uma relação do CST com o código da natureza da receita......!? Está correta esta interpretação? >> Uma outra possibilidade seria atrelar o Código da Natureza da Receita ao código NCM. Isso diminuiria bastante o trabalho do usuário pois faria a codificação (com auxílio da contabilidade) a nivel de NCM uma vez que sempre há vários produtos com mesmo NCM. Ex.: Um cliente meu tem em seu cadastro de produtos 6180 prod. cadastrados, utilizando um total de 304 códigos NCM distintos. Alguém estaria utilizando uma solução parecida? Alguém poderia dar uma dica de como está tratando/montando a geração destes registros? Desde já agradeço.

Obrigado pelo retorno Daniel, Como precisava devolver logo a impressora para o cliente acabei compilando o ACBrETQ com a minha versão, resolvendo o problema por enquanto. Assim que possível farei novos testes seguindo inclusive a sua dica, valeu...

Bom dia, Estou utilizando uma impressora Zebra TLP 2844 (epl2) e a cada impressão enviada, antes de iniciar a impressão a mesma avança cerca de 12 linhas de atiquetas (form. 3 colunas)..... alguém sabe o motivo e/ou solução para o problema???? Eu até iniciei o desenvolvimento da classe para epl2 e na minha versão estava ok, após, outro(s) fizeram melhorias no código, porém, ao atualizar com a versão do SVN passou a apresentar este problema. Testei também com o aplicativo que vem nos exemplos e o problema ócorreu da mesma forma. Se alguém puder ajudar, desde já agradeço.

Olá pessoal, Tenho um cliente para o qual estou implantando sistema que ainda possui duas impressoras Bematech ECF-IF MP-20 FI, para as quais não consegui cadastrar as formas de pagamento e demais comprovantes não fiscais conforme é feito com as impressoras mais novas. Andei pesquisando e me parece que é necessário programar estes parâmetros a cada inicio de dia. O pior é que elas ainda tem um bom tempo de vida útil pela frente o que dificulta convencer o cliente a trocar agora. Alguém ainda utiliza impressoras deste modelo com o ACBr e teria um exemplo de como proceder para programar as formas de pagamento e comprovantes não fiscais ?? Alguém teria um manual de programação deste modelo pra me enviar? Só consegui da MP-20 FI "II"! Desde já agradeço.

Vc. precisa passar os parâmetros de posicionamento corretamente (x,y) de cada texto a ser impresso. Abaixo código modificado do ETQTeste com testes que fiz. procedure TFPrincipal.bEtqSimplesClick(Sender: TObject); begin with ACBrETQ1 do begin Modelo := TACBrETQModelo(cbModelo.ItemIndex); Porta := cbPorta.Text; LimparMemoria := ckMemoria.Checked ; Ativar; ImprimirTexto(orNormal, 2, 2, 2, 190, 5, 'BISCOITO MARILAN RECH 335G'); ImprimirTexto(orNormal, 2, 2, 1, 158, 5, 'CHOC BRANCO'); //ImprimirBarras(orNormal, 'F', '2', '2', 32, 0, '7896003701685', 90); ImprimirTexto(orNormal, 3, 3, 2, 15, 300, 'R$'); ImprimirTexto(orNormal, 3, 4, 4, 15, 450, '20.59'); Imprimir(StrToInt(eCopias.Text), StrToInt(eAvanco.Text)); Desativar; end; end; procedure TFPrincipal.bEtqCarreirasClick(Sender: TObject); begin with ACBrETQ1 do begin Modelo := TACBrETQModelo(cbModelo.ItemIndex); Porta := cbPorta.Text; Avanco := StrToInt(eAvanco.Text); LimparMemoria := ckMemoria.Checked ; Ativar; // P/ formulário de 3 colunas ImprimirTexto(orNormal, 2, 1, 2, 4, 30, 'BISCOITO REC 335G'); ImprimirTexto(orNormal, 2, 1, 1, 38, 30, 'CHOC BRANCO'); ImprimirCaixa(58,25,135,248,2); ImprimirBarras(orNormal, 'E30', '2', '2', 62, 33, '7896003701685', 55); //ImprimirLinha(65,45,160,5); ImprimirTexto(orNormal, 2, 1, 2, 4, 287, 'BISCOITO RECH 335G'); ImprimirTexto(orNormal, 2, 1, 1, 38, 287, 'CHOC BRANCO'); ImprimirCaixa(56,281,140,508,4); // ImprimirBarras(orNormal, 'E30', '2', '2', 64, 290, '7896003701685', 55); ImprimirLinha(70,295,150,15); ImprimirTexto(orNormal, 2, 1, 2, 4, 547, 'BISCOITO RECH 335G'); ImprimirTexto(orNormal, 2, 1, 1, 38, 547, 'CHOC BRANCO'); ImprimirCaixa(56,538,144,767,8); //ImprimirBarras(orNormal, 'E30', '2', '2', 66, 546, '7896003701685', 55); ImprimirLinha(80,550,145,25); Imprimir(StrToInt(eCopias.Text), StrToInt(eAvanco.Text),16,203); Desativar; end; end; Att.

Olá Daniel, Dede já agradeço a sua atenção.... mas é o seguinte... fiz tudo muito na corrida e algumas inconsistências se devem em parte ao famoso "copy/paste" hehe Mas vamos às dúvidas: 1 - O método: ImprimirBarras recebeu uma sobrecarga apenas por causa da mudança dos Parâmetros: LarguraBarraLarga, LarguraBarraFina: Char -> String... Acho que podemos modificar o método original, pois não quebraria as aplicações existentes uma mudança de Char para String... e tratamos nas classes já existente usando algo como: LarguraBarraLarga[1]. Ref. ao método ImprimirBarras deixo a teu critério pois não quis mexer muito nos métodos originais com receio de bagunçar o que já está funcionando. 2 - O que vem a ser: VerticalY1, HorizontalX1, VerticalY2, HorizontalX2 no método ImprimirCaixa ? (porque precisamos de Y1 e Y2 e X1 e X2 ?) Quanto ao método ImprimirCaixa, no EPL2 difere um pouco dos demais, sendo que requer apenas dois pontos com coordenadas X e Y e a espessura da linha que é aplicada tanto para horiz. qto. para vert., cfe. pode ser obsevado no manual: Syntax Xp1,p2,p3,p4,p5 Parameters p1 = Horizontal start position (X) in dots. p2 = Ver ti cal start po si tion (Y) in dots. p3 = Line thick ness in dots. p4 = Horizontal end position (X) in dots. p5 = Ver ti cal end po si tion (Y) in dots. Example: N¿ X50,200,5,400,20¿ X200,50,10,20,400¿ P1¿ Até acho que poderíamos aproveitar alguns parâmetros do Ppla (ex.) mas sobrariam parâmetros que não estão definidos com valores default. Talvez fosse o caso de flexibilizar a parametrização desse método no Ppla e ZplII para poder omitir alguns. 3 - AvancoEtq e EspacoEtq não seriam a mesma coisa ? Essa impressora não lê o GAP da etiqueta ? Talvez eu tenha interpretado mal mas utilizei AvancoEtq como sendo a altura da etiqueta. EspacoEtq seria o espaçamento vertical entre uma etiqueta e outra. A impressora detecta o GAP sim, porém, não obtive sucesso nos meus testes usando o automático, sempre o espaçamento entre uma linha de etiquetas e outra ficava diferente bagunçando a impressão. 4 - O Parâmetro Resolucao do método Imprimir, parece estar mais relacionado ao Espaço da etiqueta do que com a Resolução... pois ele não compoem a String do comando enviado... Este parâmetro é utilizado com o comando "Q" que seta o GAP e a altura da etiqueta. No caso do GAP, dependendo da resolução da impressora o valor mínimo tem uma pequena variação cfe. trecho do manual: p2 = Gap length or thick ness of black line Range: 16-240 (dots) for 203 dpi printers [18-240 (dots) for 300dpi printers] O objetivo foi consistir o valor mínimo para o GAP e para isso precisei da resolução da impresora. 5 - Notei alguns inconsistências de validação como por exemplo: Eis o problema do copy/paste rsrs... na verdade não encontrei no manual os valores máximos para estes parâmetros e acabou ficando como está. Daria pra remover estas consistências ou então setar para 999 como já ocorre no Ppla, e serviria apenas para evitar valores absurdos, apesar de que, acho que 999 já é absurdo para a altura. Permaneço à disposição. Att.

Olá Pessoal, Conclui a implementação de uma nova classe para o ACBrETQ para impressão em impressoras Zebra / EPL2, com os principais métodos para impressão de texto, código de barras, caixas e linhas. Pelos testes que realizei está funcionando e atende a minha necessidade neste momento. Peço ao Daniel que na medida do possível analise o código para inclusão no projeto e assim poder disponibilizar aos demais. Aos que quiserem testar fiquem à vontade , com certeza dá pra melhorar. Precisei redeclarar alguns métodos com overload devido à necessidade de parâmetros com tipos diferentes dos atuais e em outros acrescentar alguns parâmetros (com valores default). Não sou muito bom em OOP mas quebra o galho e acredito que as alterações feitas não afetarão o funcionamento para o padrão Ppla ou o ZPLII. Att. ETQEpl2.zip