andepunk

ok, realmente ja est corrigido na revisão 21462, Obrigado.

Atualizei a versão do acbr hoje dia 04/03/2021 e ficou com este erro: Compiling package D:\fontesTokyo\Componentes\ACBR\Pacotes\Delphi\ACBrTXT\ACBrPAF\ACBr_PAF.dpk "C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\dcc32.exe" "D:\fontesTokyo\Componentes\ACBR\Pacotes\Delphi\ACBrTXT\ACBrPAF\ACBr_PAF.dpk" Embarcadero Delphi for Win32 compiler version 32.0 Copyright (c) 1983,2016 Embarcadero Technologies, Inc. D:\fontesTokyo\Componentes\ACBR\Fontes\ACBrTXT\ACBrPAF\ACBrPAF_W_Class.pas(149) Error: E2035 Not enough actual parameters D:\fontesTokyo\Componentes\ACBR\Fontes\ACBrTXT\ACBrPAF\ACBrPAF_W_Class.pas(234) Error: E2250 There is no overloaded version of 'IfThen' that can be called with these arguments D:\fontesTokyo\Componentes\ACBR\Fontes\ACBrTXT\ACBrPAF\ACBrPAF_W_Class.pas(235) Error: E2250 There is no overloaded version of 'IfThen' that can be called with these arguments D:\fontesTokyo\Componentes\ACBR\Fontes\ACBrTXT\ACBrPAF\ACBrPAF_W_Class.pas(237) Error: E2250 There is no overloaded version of 'IfThen' that can be called with these arguments D:\fontesTokyo\Componentes\ACBR\Fontes\ACBrTXT\ACBrPAF\ACBrPAF.pas(2341) Fatal: F2063 Could not compile used unit 'ACBrPAF_W_Class.pas' Compilation failure Erro ao compilar o pacote "ACBr_PAF.dpk". Abortando... Ocorreram erros na compilação dos pacotes. ACBrPAF_W.pas ACBrPAF_W_Class.pas

Favor avaliar a geração do digito no nosso numero. Conforme manual 3.11 Cálculo do Dígito Verificador Geral O módulo 11 de um número é calculado multiplicando cada algarismo pela sequência de multiplicadores 2,3,4,5,6,7,8,9,2,3, ... posicionados da direita para a esquerda. A soma dos algarismos do produto é dividida por 11 e o DV (dígito verificador) será a diferença entre o divisor ( 11 ) e o resto da divisão: DV = 11 - (resto da divisão) Observação: quando o resto da divisão for 0 (zero) ou 10 (dez), o DV calculado é o 1 (um). Visto que conforme CalcularDigitoVerificador esta jogando 'P' quando o dígito for 1.

Tem alguma situação ou que seja por UF que o dados da cobrança e formas de pagamentos sejam obrigados a serem informados? Pelo que li era para forma de pagamento boleto, mais como nao tem mais nao precisa informar mais? Se for por UF tem a lista de UFs que são obrigatórios?

Bom dia Juliana. Sim, conforme o leiaute cnab 240 do Santander Nota 41 "25 protestado e baixado ( baixa por ter sido protestado) " Conforme o próprio arquivo ACBRBancoSantander na procedure TACBrBancoSantander.LerRetorno240(ARetorno: TStringList); ... else if AOcorrencia = '25' then Tipo := toRetornoBaixaPorProtesto e na função function TACBrBancoSantander.TipoOcorrenciaToDescricao(const TipoOcorrencia: TACBrTipoOcorrencia): String; var CodOcorrencia: Integer; begin ... 25: Result := '25-Protestado e Baixado'; Porém na função o retorno da ocorrência 25 esta function TACBrBancoSantander.TipoOCorrenciaToCod  ... toRetornoProtestado : Result := '25'; Ou seja, o correto seria seguir o mesmo valor de LerRetorno240 e TipoOcorrenciaToDescricao Lembrando que falo do leiaute Cnab 240.

na função function TACBrBancoSantander.TipoOCorrenciaToCod o retorno da ocorrencia 25 esta toRetornoProtestado : Result := '25'; Acredito que o correto seria toRetornoBaixaPorProtesto : Result := '25';

Tem varias regras que ainda nao estao implementadas pelo menos em SP. Essa alteração do vDesc so funciona em homologação, coloquei em produção e não autorizou vai ser somente depois do dia 03/09 mesmo (Testado em SC).

Atualizei hoje o ACBR e continua com esse problema.

Favor avaliar o retorno do arquivo CNAB 400 do Cecred. Leiaute ("09", "039 a 063", "Alfa", "Número de Controle do Participante") Arquivo SeuNumero := copy(Linha,38,25); correto seria SeuNumero := copy(Linha,39,25);

Conseguiu resolver o problema? Estamos com a mesma situação em um cliente...

Boa tarde. Já existe algo desenvolvido para o Acbr com Caixa/Siacc? Smart Sistemas

Nesse caso a segunda transação já se iniciou e ocorreu algum eventual problema. Com isso a primeira transação já recebeu o CNF. Ao cancelar a operação envio o NCN da segunda transação e o CNC da primeira. Nesse ponto, o cliente do Pay&Go solicita o DOC ORIGINAL: Como não foram impressos os comprovantes, como o cliente vai saber o doc original?

Bom dia Estou implementando o TEF múltiplos cartões com NFC-e, e estou em duvida com o comportamento do TEF. Ex: Realizo uma venda de 100,00 Pago a metade em um cartão TEF 50,00 ACBRTEFD.CRT(mValor, mIndice, mNroVenda); Se o cliente desistir da venda em cartão, emito o comando de ACBRTEFD. CancelarTransacoesPendentes; Nesse ponto, o cliente do Pay&Go solicita o DOC ORIGINAL: Como não foram impressos os comprovantes, como o cliente vai saber o doc original? Ou o que eu estou fazendo errado?

Com relação as quantidades do registro E2, como meu sistema é voltado para confecção, todas as quantidades são inteiras. Notei que no relatório sempre gera com 3 casas após o valor, isso é padrão do documento? Ex: Tenho 85 peças no estoque, no arquivo fica assim: E200000000000000BL0000101 BLUSA FEM. AD. C/ BOLSO PC +000085000

Deixa eu ver se entendi Se o estado obriga a geração do cupom fiscal a partir da nota manual devo considerar somente o cupom fiscal no SPED? Se o estado NÃO obriga a geração do cupom fiscal a partir da nota manual devo considerar somente a nota fiscal manual no SPED? É isso? Outra coisa, quais os códigos que devo gerar no SPED e onde encontro a lista das UFs que obrigam a geração do cupom?

Se meu ECF der problema no dia 27, retornando somente no dia 2 do próximo mês, como fica a contabilização das notas no SPED, sendo que já foi contabilizado a nota manual, devo gerar cupom fiscal das notas do mês anterior também?

Depois de muitos testes constatei que o maior problema era na leitura do estado da impressora, leva cerca de 0,800, ou seja quase 1 segundo para retorna o estado, então fiz alguns ajustes na aplicação para ler apenas 1 vez o estado e assim melhorou um pouco.

Resolvido, faltava instalar o componente ACBRSped.dpk

Ao instalar o componente ACBRPAF, me deparei com o seguinte erro: Fontes atualizados dia 29/07/2014

Segue medição, disparei 4 vezes o comando abrecupom e cancela em seguida

Sim estou tentando entrar em contato fiz uma simulação de abertura e cancelamento de cupom e realmente a velocidade entre DLL e ACBR estao bem proximas. Acredito que seja algo da própria impressora

Bom dia, ninguém mais relatou este problema de lentidão com a MP4200?

Lento

Testei sim, e também é lento.