Intelliware

Bom dia @José M. S. Junior, a alteração sugerida seria conforme descrita em anexo. ACBrCMC7.pas

Entendi Daniel, é que havíamos deduzido, que no caso a variável ContaDC, por exemplo, seria o dígito 3 ao invés do dígito 6, conforme o exemplo abaixo: E na mesma linha, a variável AgenciaDC, deduzimos erroneamente que seria o dígito da agência(caso exista), ao invés do C1 que é o dígito verificador dos campos (Comp + Banco + Agencia). O documento que você me passou, a documentação do TEF segue exatamente a sequência estipulada. Agradeço a orientação.

Boa tarde pessoal, na unit 'ACBrCMC7.pas', na função: function TACBrCMC7.DigitosaIgnorarConta(Banco: String) : integer; Quando trocamos a linha: 33: Result := 4; // 033 - Santander / Banespa Por: 33: Result := 2; // 033 - Santander / Banespa Corrigiu para a gente o retorno dos valores de C1, C2 e C3 para o SANTANDER, conforme citado pela Andréia Cristina Giusti Franco. Apenas uma observação, não sei se poderia dar algum outro tipo de problema para o BANESPA.

Bom dia pessoal, estamos tendo um pequeno problema em relação ao componente ACBrCMC7. Um cliente nosso utiliza o leitor de CMC7 para agilizar a obtenção de dados do cheque. A princípio a implementação foi tranquila, mas recentemente, o cliente reportou o seguinte erro: Em contato com a software express, foi nos passada a informação que o envio dos dados do cheque estão incorretos no fluxo. Analisando o source da ACBr, surgiu uma dúvida na unit 'ACBrTEFDCliSiTef.pas', mais especificamente na function CHQ, segue: if CMC7 <> '' then Respostas.Values['517'] := '1:'+CMC7 else Respostas.Values['517'] := '0:'+FormataCampo(Compensacao,3)+ FormataCampo(Banco,3)+ FormataCampo(Agencia,4)+ FormataCampo(AgenciaDC,1)+ FormataCampo(Conta,10)+ FormataCampo(ContaDC,1)+ FormataCampo(Cheque,6)+ FormataCampo(ChequeDC,1) ; Pelo documento SiTEF - Interface Simplificada com a aplicação(VRS-195), na página 21, temos o comando 31, que dita as regras definidas para o source acima: A dúvida é: As variáveis AgenciaDC, ContaDC e ChequeDC correspondem, no cabeçalho do cheque, aos valores impressos nos campos C1, C2 e C3 no caso do operador digitar? Desde já agradeço o retorno.

Entendi. Agradeço a resposta.

Bom dia. Mas no caso, não existe algum estado que possibilite a gente de Minas Gerais testar a versão 4.0 da NFC-e para homologação assim como o AM possibilita para a 3.10?

Boa tarde Daniel, vamos tentar simular utilizando um emulador da Epson. Qualquer novidade retorno para você. Agradeço a resposta.

Temos um cliente que possui uma EPSON TM-T81 FBIII e o mesmo reporta que está tendo vários problemas. Analisando os logs do ecf, encontramos as seguintes entradas: -- 27/03 12:45:03:474 RX <- ACK = 6 -- 27/03 12:45:04:020 RI+ -- 27/03 12:45:04:020 Resposta Incompleta -- 27/03 12:45:04:020 Pacote Inv[225]lido, NACK enviado: [STX][128][ETX]0085 -- 27/03 12:45:04:347 RI- -- 27/03 12:45:04:472 RX <- [STX][129][16][NUL][FS][192][129][FS][FS][NUL][NUL][FS][ETX]0247 -- 27/03 13:00:36:961 RX <- ACK = 6 -- 27/03 13:00:37:834 RI+ -- 27/03 13:00:37:834 Resposta inválida. CheckSum da Resposta não está correto. -- 27/03 13:00:37:834 Pacote Inv[225]lido, NACK enviado: [STX][128][ETX]0085[STX][236][NUL][NUL][FS][192][129][FS][FS][NUL][NUL][FS][ETX]02A2 -- 27/03 13:00:37:943 RX <- [STX][236][NUL][NUL][FS][192][129][FS][FS][NUL][NUL][FS][ETX]02A2 -- 27/03 13:09:25:955 ----------------- ERRO ----------------- Erro retornado pela Impressora: Epson Erro: 0A26 - Mensagem promocional já impressa. ---------------------------------------- -- 27/03 13:09:28:607 Estado Os erros de checksum ocorrem várias vezes ao longo do dia e o erro da mensagem promocional após uma sequência de erros. Anexei uma parte do log com informações mais detalhadas. Gostaríamos da opinião de vocês, sobre o que pode estar ocasionando estes problemas. Desde já agradecemos a ajuda. Log_ACBr_20170328.TXT

Boa tarde pessoal, Entramos em contato com a Elgin, conversamos com o pessoal que efetua a intervenção e não foi encontrado nenhum problema com a configuração da guilhotina ou até mesmo um problema mecânico. Utilizamos o programa Asgaard e o Logg2 e não detectamos nenhuma configuração não setada ou desabilitada. Tive que adicionar no final de cada método na unit 'TACBrECFFiscNet' a instrução 'CortaPapel', são eles: CancelaCupom, FechaCupom, FechaRelatorio, LeituraX e ReducaoZ. Temos 3 clientes que utilizam a Elgin K, uma deles comprada recentemente e nenhuma delas efetua o corte, embora analisando as configurações da mesma esteja habilitada. Iremos acompanhar agora no cliente se a solução realmente funcionou. Acredito que não seja a solução ideal, mas foi a única que encontrei para o momento.

Entendi Daniel, vou ver junto com o suporte se conseguimos habilitar esta flag. Caso contrário, vou modificar o source para atender o cliente. Agradeço mais uma vez o retorno.

Bom dia pessoal, Estamos com um caso singular em um cliente nosso. O mesmo utiliza uma impressora Elgin K e nos reportou problema no corte de papel. Pedimos para enviar o ECF para intervenção. Segundo a intervenção, o corte de papel ocorre normalmente pelo programa de testes deles, portanto concluiram que não possui nenhum problema e nos enviaram novamente. O problema persiste da seguinte forma: Utilizando o ECFTeste, pelo protocolo FISCNET, quando abrimos 3 relatórios gerenciais, 2 o corte de papel é realizado com sucesso, o terceiro não corta (Arquivo: "sem corte-acbrlog.txt"). No ECFTeste, pelo menu, selecionamos 'CortePapel', ocorre normalmente o corte do papel. Quando pedimos para emitir uma Leitura X ou efetuamos a venda de um cupom fiscal, em nenhum caso, ocorre o corte. (Arquivo: "acbrlog_leitura x_sem corte.txt") Já analisamos os seguintes posts: Mas estamos sem idéia do que poderia estar ocorrendo. Pois uma hora funciona, emite o relatório gerencial com corte e nos outros momentos não efetua o corte. Gostaria da opinião de vocês a respeito deste problema. sem corte-acbrlog.txt acbrlog_leitura x_sem corte.txt

Bom dia Luciano, acredito que você esteja procurando a informação contida neste post: Em contato com a Software Express eles irão te passar um módulo chamado 'Módulo SAT-NFCE', que até em Abril estava na versão 1.0.0.15. Junto com as explicações que eles te passarem você terá uma tabela no gerenciador do TEF para fazer a referência cruzada que o Daniel citou acima. Espero ter interpretado corretamente a sua dúvida e ter ajudado.

Bom dia Daniel. Fiz o teste com a versão 0.9.8.14 e com a versão mais atual 1.0.2.8 e depois comparei os dois XML gerados. Ambos são exatamente iguais e não ocorre mais a referida mensagem do tópico. Logo, problema solucionado. Mais uma vez agradeço.

Show. Vou testar e retorno um feedback para você. Agradeço mais uma vez Daniel.

Testei somente com a 0.9.8a e 0.9.8n que são as DLL que estão no repositório. Em outro computador de desenvolvimento, sem ser o que utilizo o mesmo erro procede ao atualizar a ACBr para a última versão.

Boa tarde pessoal, Fizemos a atualização da ACBr para uma das últimas versões (26/12/2016) e ao executar o comando: ACBrEAD.GerarXMLeECFc(RemoveAcento(dm.RazaoSocial), AddSlash(dm.ExePath)); Recebemos a mensagem: Método CalcularModuloeExpoente ainda não é compatível com OpenSSL 1.0.0 ou superior Efetuei uma pesquisa e esta validação o Daniel implementou no commit revision 12726 do dia 23/12/2016. Em debug, verifiquei que na função: function TACBrEAD.VerificaVersaoCompativel: Boolean; Temos: 1) A função 'GetOpenSSL_Version' retorna 'OpenSSL 0.9.8n 24 Mar 2010' 2) A comparação '(CompareVersions(Ver, '1.0.0') < 0)' retorna FALSE Gostaria da opinião de vocês, se é algum problema na minha máquina ou se é a comparação de versões que está equivocada. Desde já agradeço.

Daniel, na unit ACBrECF.pas, temos: property LinhasEntreCupons : Integer read GetLinhasEntreCupons write SetLinhasEntreCupons default cACBrLinhasEntreCupons ; Ela é utilizada em: procedure TACBrECF.TraduzirTag(const ATag: AnsiString; var TagTraduzida: AnsiString); Pra ser sincero, não conheço totalmente qual seria a função da mesma, mas esta propriedade foi setada pela programadora que homologou o TEF.

Bom dia Daniel, desculpa a demora. Realmente é muito estranho. A princípio parece que estabilizou aqui, vou monitorar e qualquer coisa reporto se algo diferente acontecer. Na procedure: procedure TdmVendaECF.TEFComandaECFImprimeVia(TipoRelatorio : TACBrTEFDTipoRelatorio; Via : Integer; ImagemComprovante: TStringList; var RetornoECF : Integer); No começo dela eu coloco: with ecf.ACBrECF do begin {*** Se estiver usando ACBrECF - Lembre-se de configurar *** MaxLinhasBuffer := 3; //Os homologadores permitem no máximo impressao de 3 em 3 linhas LinhasEntreCupons := 7; //Ajuste conforme o seu ECF } MaxLinhasBuffer := 3; LinhasEntreCupons := 7; ReTentar := False; end; Pois realmente os homologadores pediram para efetuarmos esta alteração. Existe algum outro lugar que temos que setar esta propriedade?

Bom dia pessoal, o conteúdo da variável ImagemComprovante.Text na procedure: procedure TdmVendaECF.TEFComandaECFImprimeVia(TipoRelatorio : TACBrTEFDTipoRelatorio; Via : Integer; ImagemComprovante: TStringList; var RetornoECF : Integer); É o seguinte: ' '#$D#$A'.....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....'#$D#$A'SI Rede 124'#$D#$A'MU Codigo transacao: 200'#$D#$A'LA Codigo operacao: 930030'#$D#$A'DO Valor: 5,89'#$D#$A'.....S...I...M...U...L...A...D...O....'#$D#$A'SI NSU SiTef: 10007'#$D#$A'MU 01/11/16 07:11'#$D#$A'LA ID PDV: SE000001'#$D#$A'DO Estab.: 000000000000001'#$D#$A'.....S...I...M...U...L...A...D...O....'#$D#$A'SI Host: 000010007'#$D#$A'MU Transacao Simulada Aprovada'#$D#$A' (SiTef)'#$D#$A O que fiz foi: 1) Retirar os seguintes caracteres do começo: ' '#$D#$A 2) Retirar os seguintes caracteres do final: #$D#$A 3) Após isso executei a função: ImagemComprovante.Text := StringReplace(ImagemComprovante.Text, '#$D#$A', '#10', [rfReplaceAll, rfIgnoreCase]); A princípio parece que resolveu, consigo agora imprimir 10 comprovantes seguidos sem problema algum. Será que o ECF não estava conseguindo interpretar algum caractere enviado no relatório gerencial?

Boa tarde pessoal, Estamos implementando correspondente bancário e pagamento de fatura SIGACRED no nosso PDV. Está acontecendo um fato estranho. No módulo da SIGACRED quando retorna o relatório gerencial para impressão, ocorre erro de impressão e o ECF mostra a mensagem para tentarmos novamente. Se escolhemos SIM, o processo tenta novamente, ocorre erro de impressão e entra em loop. Só sai se escolhemos a opção NÃO. Pelo que analisei, o problema ocorre na procedure: procedure TACBrECFSwedaSTX.LinhaRelatorioGerencial(Linha: AnsiString; IndiceBMP: Integer); Especificamente na linha: EnviaComando( '25|' + Buffer, Espera ) ; O valor da variável Espera está sendo 4 no caso. No log, temos a seguinte situação: -- 31/10 14:58:34:262 -- Ativando a porta: COM1 -- 31/10 14:58:34:263 LinhaRelatorioGerencial( " [LF].....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....[LF]SI Rede 124[LF]MU Codigo transacao: 200[LF]LA Codigo operacao: 930030[LF]DO Valor: 7,69[LF].....S...I...M...U...L...A...D...O....[LF]SI NSU SiTef: 310022[LF]MU 31/10/16 13:54[LF]LA ID PDV: SE000001[LF]DO Estab.: 000000000000001[LF].....S...I...M...U...L...A...D...O....[LF]SI Host: 000310022[LF]MU Transacao Simulada Aprovada[LF] (SiTef)[LF][CR][LF]", 0 ) -- 31/10 14:58:34:264 TX -> [STX][207]25| [LF].....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....[LF]SI Rede 124[LF]MU Codigo transacao: 200[LF]LA Codigo operacao: 930030[LF]DO Valor: 7,69[LF].....S...I...M...U...L...A...D...O....[LF]SI NSU SiTef: 310022[LF]MU 31/10/16 13:54[LF]LA ID PDV: SE000001[LF]DO Estab.: 000000000000001[LF].....S...I...M...U...L...A...D...O....[LF]SI Host: 000310022[LF]MU Transacao Simulada Aprovada[LF] (SiTef)[LF][LF][ETX][164] -- 31/10 14:58:34:829 14:58:34:829 RX <- ACK = 2 Falha: 0 -- 31/10 14:58:34:933 TX -> [STX][207]25| [LF].....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....[LF]SI Rede 124[LF]MU Codigo transacao: 200[LF]LA Codigo operacao: 930030[LF]DO Valor: 7,69[LF].....S...I...M...U...L...A...D...O....[LF]SI NSU SiTef: 310022[LF]MU 31/10/16 13:54[LF]LA ID PDV: SE000001[LF]DO Estab.: 000000000000001[LF].....S...I...M...U...L...A...D...O....[LF]SI Host: 000310022[LF]MU Transacao Simulada Aprovada[LF] (SiTef)[LF][LF][ETX][164] -- 31/10 14:58:35:498 14:58:35:498 RX <- ACK = 2 Falha: 1 -- 31/10 14:58:35:602 TX -> [STX][207]25| [LF].....S.O.F.T.W.A.R.E.E.X.P.R.E.S.S....[LF]SI Rede 124[LF]MU Codigo transacao: 200[LF]LA Codigo operacao: 930030[LF]DO Valor: 7,69[LF].....S...I...M...U...L...A...D...O....[LF]SI NSU SiTef: 310022[LF]MU 31/10/16 13:54[LF]LA ID PDV: SE000001[LF]DO Estab.: 000000000000001[LF].....S...I...M...U...L...A...D...O....[LF]SI Host: 000310022[LF]MU Transacao Simulada Aprovada[LF] (SiTef)[LF][LF][ETX][164] -- 31/10 14:58:36:186 14:58:36:186 RX <- ACK = 6 Falha: 2 -- 31/10 14:58:39:026 TimeOut estendido -- 31/10 14:58:39:027 Alteração de Estado: 0- -- 31/10 14:58:39:027 14:58:39:027 RX <- (Bloco) = [STX][207]00!0000AI[128][128][146][128][128][ETX]1 -- 31/10 14:58:39:027 TX -> ACK = 6 Falha: 0 -- 31/10 14:59:09:262 RespostaComando: -- 31/10 14:59:09:267 RX <- -- 31/10 14:59:09:267 -- Desativando a porta: COM1 -- 31/10 14:59:09:285 ----------------- ERRO ----------------- Impressora SwedaSTX não está respondendo ---------------------------------------- O estranho é que em testes com a Daruma FS600/FS700 e Bematech 2100 não tivemos problema e em alguns casos até mesmo na Sweda conseguimos imprimir, 1 em cada 8 tentativas. Gostaríamos da opinião de vocês para este caso. O log completo eu anexei abaixo. Desde já agradeço. 20161031.ecflog

Realmente Daniel, Observamos, por exemplo, que a Daruma FS700 quando efetuamos Sangria e Suprimento não totaliza esses valores no meio de pagamento DINHEIRO. A Sweda ST120 e a Bematech MP-2100 não computam a sangria no meio de pagamento DINHEIRO, mas em contrapartida o suprimento é computado. A idéia que tive ao ver os índices de entrada e saída de recurso era que o comprovante ESTORNO não fosse computado no meio de pagamento ou até mesmo ter seu valor abatido do mesmo, mas em conversa com o pessoal da Daruma não é possível. Agradeço a resposta.

Bom dia pessoal, Fizemos no nosso sistema o tratamento para pagamento de fatura de cartão da SIGACRED e da CONDUCTOR além do correspondente bancário. Até neste ponto perfeito. Foi realizado também uma implementação para caso o operador efetue um cancelamento de pagamento ou estorno de pagamento de conta, sendo emitido um comprovante não-fiscal que foi chamado de ESTORNO. Na Daruma, temos um source que efetua a seguinte validação: ecfDaruma : if not InputQuery('Comprovantes NAO Fiscal '+ACBrECF1.ModeloStr, 'Entre com a String do parametro "Tipo".'+sLineBreak+ 'V Comprovante Vinculado'+sLineBreak+ '+ Entrada de Recursos'+sLineBreak+ '- Saida de Recursos'+sLineBreak+sLineBreak+ 'Se vazio assume Default = "V"'+sLineBreak+ 'Informe Apenas uma das Opçoes', cTipo ) then exit ; Programamos utilizando a opção '- Saída de Recursos', mas em debug observei que a variável 'fpMFD' entra como TRUE no procedimento, logo entrando no bloco abaixo: else if fpMFD then begin if AchaCNFDescricao(Descricao, True) <> nil then raise EACBrECFERRO.Create(ACBrStr('Comprovante não fiscal ('+Descricao+') já existe.')) ; if (ProxIndice < 3) or (ProxIndice > 20) then { Indice passado é válido ? } begin For ProxIndice := 3 to 20 do { Procurando Lacuna } begin if AchaCNFIndice(IntToStrZero(ProxIndice,2)) = nil then break ; end ; end ; if ProxIndice > 20 then raise EACBrECFERRO.create(ACBrStr('Não há espaço para programar novas CNFs')); EnviaComando( FS + 'C' + #204 + IntToStrZero(ProxIndice,2) + PadRight(Descricao,15) ) ; CarregaComprovantesNaoFiscais ; end Com isso, o valor(-) que digitei é desconsiderado. Na Bematech não temos esta opção e é incrementado o valor do comprovante na forma de pagamento de qualquer modo. A Sweda leva em consideração o tipo, conforme o bloco: procedure TACBrECFSwedaSTX.ProgramaComprovanteNaoFiscal(var Descricao : String; Tipo: String; Posicao : String); begin { Argumento(s): sinal: Ascii Dec Sinal + 43 Positivo - 45 Negativo Opcional, se omitido é assumido o valor padrão do sinal: + operação Denominação da operação não-fiscal. Alfanumérico - Extensão máxima: 15 caracteres Poderão ser cadastradas, em um único comando, um conjunto de até 30 operações. Nota(s): Operações com sinal negativo não admitem os seguintes registros: - Pagamento; - Identificação do consumidor; - Acréscimo; - Desconto. } EnviaComando('37|'+Tipo+Descricao); end; A dúvida seria: Este indicador de entrada ou saída de recurso quando setado indica se o valor referido no comprovante não-fiscal será acumulado ou não no meio de pagamento utilizado no mesmo? Ou seja, qual seria o impacto deste indicador no meio de pagamento utilizado no comprovante não-fiscal? Ou estou interpretando de maneira equivocada os mesmos? Desde já agradeço a todos.

Bom dia pessoal, No site da SEFAZ existe o seguinte texto referente a atualização da versão 0.07: ATENÇÃO – INSTRUÇÕES PARA ATUALIZAÇÃO DO SOFTWARE BASICO DO SAT (...) Observar o prazo fornecido pela SEFAZ para a realização da atualização após o qual a mesma será realizada de ofício a qualquer momento. Vocês sabem me informar que prazo seria este? Procurei em vários lugares mas não encontrei até quando posso ainda utilizar o layout 0.06.

Bom dia, nos testes que fizemos em debug e posteriormente guardando em tabela os valores do SAT não encontramos divergência. Basicamente, utilizamos o rateio da forma que o ECF executa para desconto ou acréscimo. Segue um link para você ter uma base: https://www.totvs.com/mktfiles/tdiportais/helponlineprotheus/portuguese/loja701_rateio_de_desconto.htm

Show Elias. Ajudou bastante aqui. Clareou em termos técnicos de programação. Agradeço imensamente.