Rodrigo de Carvalho Ribeir

No meu caso não guardo a modalidade.. apenas nosso numero .. porque a modalidade vai depender tipo de emissão: CC = 11 (título Registrado emissão pela CAIXA) CC = 14 (título Registrado emissão pelo Cedente) CC = 21 (título Sem Registro emissão pela caixa CAIXA) CC = 00 (título Registrado emissão pela CAIXA mas com nosso numero do cliente)

Bom dia ... To disponibilizando umas alteração que fiz no ACBrBancoCaixa conforme necessidade que tive em cliente 1) Geração de nosso numero para remessa quando banco emite e entrega, neste casso o nosso numero tem que ir zerado: "G069 Identificação do Título no Banco Número adotado pelo Banco Cedente para identificar o Título. Para Código de Movimento (posições 16-17 do Segmento P) igual a '01' (Entrada de Títulos): 1) Se a CAIXA for responsável pela emissão do bloqueto, o campo Carteira/Nosso Número (posições 41- 42/43-57) pode ser preenchido com zeros (‘0’), nesse caso, a numeração será feita pelo Banco." fiz uma alteração na linha 172: onde era: else ANossoNumero := '11'+PadLeft(ANossoNumero, 15, '0') passou a : else if (StrToIntDef(ANossoNumero,0)) <> 0 then ANossoNumero := '11'+PadLeft(ANossoNumero, 15, '0') else ANossoNumero := '00'+PadLeft(ANossoNumero, 15, '0') 2) Adicionei os código de retorno na cobrança 240 ‘23’ Remessa a Cartório ‘24’ Retirada de Cartório ACBrBancoCaixa.pas

Boa tarde .. Fiz inclusão das URL NFC-e MS .. fiz os testes... está funcionado 100 % so tive que alterar o ACBrNFe.pas linha 537 para colocar hex dEmi em minusculo, para não dar erro na consulta do QR-CODE " Rejeição: Parâmetro do QR-Code divergente da Nota Fiscal (dhEmi) " era assim] if CUF = 41 then begin sdhEmi_HEX := LowerCase(sdhEmi_HEX); sdigVal_HEX := LowerCase(sdigVal_HEX); end; ficou assim if (CUF = 41) or (CUF = 50) then begin sdhEmi_HEX := LowerCase(sdhEmi_HEX); sdigVal_HEX := LowerCase(sdigVal_HEX); end; Segue em anexo o ACBrNFeServicos o .ini e o .res e unit ACBrNFe.pas ACBrNFe.pas ACBrNFeServicos.ini ACBrNFeServicos.res

Ops... eu esqueci dizer o que implementei é da cidade de Três lagoas.. O italo ja esta analisando.... e só aguardar.

Em Castilho-SP usa Fiorilli mas opção de web service não esta liberada ainda.. Eu ja passei a implementação para o Italo, esta sobre analise para ser disponibilizado.

eu to esperando vir uma atualização do evento consultaloterps... porque no trunk 1 esse evento retornava a situação do lote... e no trunk 2 ainda não tem... e ele precisa desta opção que tinha no trunk...

Boa Tarde... Gostaria de saber se vai ser implementado no trunk 2 campo Situação do lote no evento ConsultaLoteRPS. Porque to implantado um novo provedor que usa a versão 2.01 que retorna essa tag nesse evento. ---descrição do manual--- tsSituacaoLoteRps 1 – Não Recebido 2 – Não Processado 3 – Processado com Erro 4 – Processado com Sucesso http://www.abrasf.org.br/arquivos/files/NFSE-NACIONAL_Manual_De_Integracao_versao_2-01.pdf

Boa tarde... Estou Implementado para esse município.... já esta funcionado no trunk 2.. to usando produção... to esperando terminar a migração NFSE para trunk 2 ficar estavel ...ai vou disponibilizar...

Bom dia, eu fiz teste aqui... esta OK LOGECF.TXT

LOGECF.TXT

a aplicação entra em loop.... igual acontecia com as impressoras bematech

Olha Amigos vem compartilhar mais uma melhoria que fiz no ACBrECFEscECF.pas Em teste com Daruma FS800i percebi que ela entra em loop comando 26... -- 13:37:13:611 NumCupom TX -> [SOH][25][26][NUL][4][NUL]1|1|[145] RX <- [ACK] Status TX -> [ENQ][NUL] Falha: 1 Reenvio TX -> [SOH][25][26][NUL][4][NUL]1|1|[145] RX <- [WAK][16][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][16][STX][NUL][NUL][NUL][SOH][25][26][NUL][NUL][SOH][NUL][NUL]@[ENQ][NUL]1|48|[14] Status TX -> [ENQ][NUL] RX <- [WAK][16][4][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][16][4][NUL][NUL][NUL] ....... Com teste, consegui identificar isso acontecia porque o comando 26 na daruma as vezes demora mais que outro comando para responder. Mesmo aumentado timeout, o comando atingia o tempo limite. Com base nestas informações eu fiz uma alteração para quando ele atingir o timeout no camando 26 pela primeira vez, em vez de reenviar o comando, ele pedira o status novamente.. 14:31:03:823 NumCupom TX -> [SOH]"[26][NUL][4][NUL]1|1|[154] RX <- [ACK] Status TX -> [ENQ][NUL] Status TX -> [ENQ][NUL] *** Daruma em possível loop: 1 respostas de Ocupada. Reenviando pedido de status RX <- [WAK][16][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][16][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] Resposta: SEQ:34 CMD:26 EXT:0 CAT:0 RET:[SOH][NUL][NUL]@ TBR:5 BRS:"1|54|" CHK:20 14:31:05:983 RX <- [SOH]"[26][NUL][NUL][SOH][NUL][NUL]@[ENQ][NUL]1|54|[20] ACBrECFEscECF.pas

Isso mesmo

Não compreendi muito bem a sua lógica... Como isso irá trazer a resposta esperada, ao comando enviado ao ECF ? Então como eu falei o loop acontece sempre no comando 26 que serve para Captura Eletrônica de Dados... percebi q na impressora bematech ... as vezes com esse comando a impressora fica respondendo em processamento Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Ai que eu fiz ... determinei um tempo para que componente espere essa resposta ... caso tempo seja atingido ele pede comado 26 outra vez.... percebi que segunda chamado do comando ai impressora responde corretamente... porque na verdade ela não esta em processamento. isso algum bug do ecf... isso tem tando na bematech mp-4200th fi e bematech mp-4200th fi II... não sei. se minha logica esta escrita na melhora maneira... mais deu certo aqui para min não to tendo mais problema nos cliente... outra coisa que ta acontecendo com meus cliente é o bematech mp-4200th fi morrer .. ai tem mandar para fabrica... pq nem autorizada consegue arrumar... ai fabrica manda um ecf novo no modelo bematech mp-4200th fi II. isso ja aconteceu com 4 clientes meus, incluível com minha ecf de teste aqui.

Boa tarde Depois alguns teste...Verifiquei o problema de loop sempre dava no comando 26.. Ai eu fiz uma modificação no fonte do ACBRECFEscECF.pas Criei uma variável para armazenar hora de inicio do comando.. depois antes de enviar o comando no evento EnviaComando_ECF eu peguei a hora.. Depois no VerificaFimLeitura eu adicionei esse código depois do sleep(50) if (IsBematech) and (IncSecond(Now, TimeOut) > IncSecond(fsHoraInicioComando, TimeOut)) and (EscECFComando.fsCMD = 26) then begin GravaLog(' Reenvio TX -> ' + fpComandoEnviado, True); fpDevice.EnviaString(fpComandoEnviado); Retorno := ''; Result := False; TempoLimite := IncSecond(Now, TimeOut); end else begin PedeStatus; Result := False; end ja esta rodando a uns 2 meses nos clientes não tive mais esse problema de loop Segue em anexo a unit no trunk 1 e trunk 2 Aceito sugestão para melhorar esse ideia... Eu tenho uma impresso aqui para teste. ACBrECFEscECF.pas - Trunk 1 ACBrECFEscECF.pas - Trunk 2

Ola gostaria de saber se alguém esta tendo problema com mp-4200 th fi. Em certo momentos depois do "comado 26 grupo 4" o ecfs entra loop aguardado a ECF responder; Analisando o logs percebi que componente pende o status(ENQ) do ecf ele sempre retorna ocupado(WAK) e isto fico ate eu aborta aplicação. TX -> [SOH][164][26][NUL][4][NUL]4|2| RX <- [ACK] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] Status TX -> [ENQ][NUL] RX <- [WAK][NUL][SOH][NUL][NUL][NUL] LOGECF.TXT

Tipo depois da 00:00 o status que o ecf retorna é "estRequerZ" , mas o ecf ainda continua imprimindo ate as 02:00 ai ela bloquea ate fazer a redução... crie essa condição acima na pressão da homoloção... mas seguindo a dica do daniel. eu tratei da situação no evento OnInfoECF , quando o status do ecf for estRequerZ ele estiver no intervalo da 00:00 as 01:59 ele vai setar a variável RetornoECF:='L'; fica dica para quem esta tendo o mesmo problema.. No meu caso estava tendo o problema direto, porque trabalho no seguimento de bares e Restaurantes. .com isso tem teste no ER PAF com essa situação

Desculpa demora para responder com mudança no fórum parei de receber email de notificação... mas... segue em anexo o arquivo ACBrTEFD.pas

Ola pessoal... tive que fazer uma mudança no ACBrTEFD.pas na linha 849. Porque quando ia finalizar uma venda cartão depois da meia noite sem fazer redução (Teste do PAF vender até 02:00 da manhã) dava erro para imprimir o comprovante, porque o status do ECF não e mais Livre... Segue e anexo o fonte modificado.

Terminei o processo de homologação da caixa SIGCB tive que fazer mas uma altera no componente agora é na formatação do nossonumero da careteira sem registro SR . Na carteira SR esta sempre colocando o numero "21" no nossonumero . O Homologador me passou que 21 quando a caixa emite, quando o cedente emite tem usar numero "24" Estou disponibilizado a unit com alteração feita. ACBrCaixaEconomica.pas

ola...eu estava passando pelo processo de homologação de boleto da caixa tive que fazer umas alteração fonte. 1º Alteração : foi na Espécie do Título na hora de gerar remessa ele estava colocando a sigla da especie invés do código.Fiz alteração para adicionar o código 2º Alteração : foi adicionar o método TipoOcorrenciaToDescricao que não tinha. Em anexo segue a alteração que eu fiz. ACBrCaixaEconomica.pas

esta dado de erro access violation na linha 544 do ACBRDANFECBRave.pas na hora de imprimir a carta de correção... eu fiz uma alteração para poder funcionar onde era EventoRave.SystemSetups:=DANFERave.SystemSetups - [ssAllowSetup]; eu mudei para EventoRave.SystemSetups:=EventoRave.SystemSetups - [ssAllowSetup];