Rodrigo de Carvalho Ribeir
-
Total de ítens
22 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Rodrigo de Carvalho Ribeir
-
-
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 -
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
-
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...
-
-
1
-
-
-
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] -
Isso mesmo
-
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..
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;
endja 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] -
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
-
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.
-
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.
-
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];
Melhoria no ACBrBancoCaixa
em ACBrBoleto
Postado
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)