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