Ir para conteúdo
  • Cadastre-se

mgmobile

Membros Pro
  • Total de ítens

    317
  • Registro em

  • Última visita

Posts postados por mgmobile

  1. Boa tarde, gostaria de saber se foi alterado o código do cnab gerado no layout, nas versões anteriores gerávamos os parâmetros 0 = cnab 240 posições e 1 = cnab 400 posições, ao atualizar os fontes do acbr verifiquei que quando é enviado o parâmetro 0 está gerando a remessa com 400 posições e quando enviado 1 ele gera o layout com 240 posições. 

  2. Boa tarde ,

    Não estou com problemas mas sim uma duvida e gostaria de saber se alguém ja passou por uma situação como esta e o que foi feito para resolver.

    Cliente esta fazendo a primeira emissão de nota no cnpj , empresa nova . Os procedimentos adotados foram :

    A primeira nota foi emitida em ambiente homologação , enviada para o contador e mesmo deu o aval que estava certa , após isso foi realizado a emissão do mesmo pedido porém em ambiente produção. Ao finalizar a emissão a sefaz retornou a mensagem  : "PREZADO CONTRIBUINTE , FINEZA COMPARECER A ADMINISTRAÇÃO FAZENDARIA PARA PRESTAR ESCLARECIMENTOS RELATIVOS A EMISSÃO DE NF-E" . Abaixo segue uma imagem dos logs do acbr .

     

    tela acbr 1.png

  3. 41 minutos atrás, Italo Jurisato Junior disse:

    Bom dia,

    Na chave logo após o CNPJ temos 55 (para NF-e) ou 65 (para NFC-e).

    A chave é composta por: <Código da UF 2 dígitos><Ano da emissão 2 dígitos><Mês da emissão 2 dígitos><CNPJ do emitente 14 dígitos><modelo do documento 2 dígitos><Série do documento 3 dígitos><numero do documento 9 dígitos><Tipo de emissão 1 digito><Código aleatório 8 dígitos><Digito Verificador 1 digito>

     

     

    23 minutos atrás, André Ferreira de Moraes disse:

    Use a função ExtrairModeloChaveAcesso da unit pcnAuxiliar e verifque se é 55 (NF-e) ou 65 (NFC-e).

    Muito Obrigado pela vossa ajuda, conseguir localizar a informação e resolver.

    • Curtir 1
  4. Boa tarde, seria isso, porém não sei se é uma padronização dos bancos, pois verifiquei no da caixa e me parece diferente, porém estou enviando no anexo os layouts que verifiquei essa informação juntamente com a página aonde a informação consta

    Banco do Brasil - página 10 - 36.3P

    Bradesco - página 25 - C026

    Santander - página 15 - Nota 25

    Caixa (que parece ser diferente) - página 68 - C026, C027

    Banco do Brasil.pdf

    Bradesco 240.pdf

    Santander - página 15 - Nota 25

    Santander - CNAB 240.pdf

    Caixa (que parece ser diferente) - página 68 - C026, C027

    Caixa.pdf

    • Curtir 2
  5. Boa tarde, ao gerar a remessa com protesto através de dias úteis o campo do acbr esta preenchido TipoDiasProtesto = 1 - Dias úteis, verifiquei que o layout de alguns bancos (santander, bradesco, banco do brasil) a remessa deve estar preenchido no no campo 221 Código para Protesto como 2 quando for dias úteis e 1 quando for dias corridos, esta sendo gerado na remessa como 1. 

    Segue no anexo print da remessa e do arquivo gerado para o acbr, segue no anexo ambos arquivos, caso seja necessário mais algum me informe por gentileza

    cb230701.rem

    BOLETOS.TXT

    imagem tipo dias protesto.jpg

  6. Boa tarde 

    Recentemente tivemos um erro na leitura do arquivo de retorno do MDF-e para verificar se o MDF-e foi autorizado ou rejeitado, apos analisar identificamos que em versões anteriores do ACBR a tag MDF+numero do manifesto era retornado dentro de um colchete e no ACBR atual esta sendo retornado dentro de dois colchete, com isto esta gerando erro na leitura do arquivo de retorno. Segue em anexo um print da situação relatada. Outro detalhe, nas versões antigas do ACBR a tag [ENVIO] era retornada na resposta e agora não é mais retornada esta tag... se analisarem também a primeira linha do arquivo atual vai ver que a tag [RETORNO] está no final da primeira linha e não sozinha como antes...

    retorno.png

    retorno2.png

  7. Em 03/07/2018 at 12:16, José M. S. Junior disse:

    Bom dia.

    Identificado o problema... Estará corrigido na próxima versão semanal do ACBrMonitor.

    Bom dia, sabe informar quando será lançado a versão com a correção? Pergunto pois para resolvermos o problema no cliente estamos obrigando o cliente a abrir e fechar o acbr sempre que for gerar boleto do santander para evitar erros e o cliente está nos perguntando se vai ter sempre que fazer isso...

    Sabe quando será lançado a versão semanal com a correção?

  8. 1 hora atrás, mgmobile disse:

    Acabei de entrar denovo e não deu o erro e Acabei de conseguir simular para dar o erro... se o ACBRMONITOR está fechado... eu abro ele e dou os comandos acima, dai funciona normal... agora se antes de gerar boletos eu LER UM RETORNO dai ele passa a apresentar o erro apresentado... só volta a dar certo se fechar o acbr e abrir denovo... ou seja, O ERRO APARECE APÓS LER UM ARQUIVO DE RETORNO DO BANCO... anexo um retorno do mesmo cliente... se vc ler esse retorno para gerar o INI de retorno e em seguida tentar imprimir os boletos acima dai dá o erro!

    retorno29062018.TXT

    Complementando os arquivos para testes. Fiz a simulação do erro (li um retorno e depois gerei o boleto) dai gerou o boleto errado... e pedi pra gerar a remessa e ele gera errado tbém... dai depois fechei o acbr, gerei o boleto sem ler um retorno e ele gerou pdf certo e remessa certo. Anexo segue remessa correta (OK.REM) e remessa errada (ERRO.REM)... notem por exemplo na LINHA 63 posicao 196 a 197 ele gera no arquivo correto o numero 72... já no arquivo errado a mesma linha o numero 72 está na 197 a 198 e a linha tem um char a mais que os 240 permitidos no CNAB240... anexo os 2 arquivos para analise

    erro.rem

    ok.rem

  9. 12 minutos atrás, mgmobile disse:

    Mais um detalhe... se vc analisar o PDF vai ver que o DIGITO VERIFICADOR mudou, ou seja, mandamos no BOLETO.TXT NossoNumero=72 e depois 73... imprimiu no PDF apenas o número 7 (cortando o ultimo) mais o DV mudou... ou seja, o DV parece estar sendo calculado corretamente pelo numero informado no TXT mais a apresentação do nossonumero no PDF esta errada... 

    Acabei de entrar denovo e não deu o erro e Acabei de conseguir simular para dar o erro... se o ACBRMONITOR está fechado... eu abro ele e dou os comandos acima, dai funciona normal... agora se antes de gerar boletos eu LER UM RETORNO dai ele passa a apresentar o erro apresentado... só volta a dar certo se fechar o acbr e abrir denovo... ou seja, O ERRO APARECE APÓS LER UM ARQUIVO DE RETORNO DO BANCO... anexo um retorno do mesmo cliente... se vc ler esse retorno para gerar o INI de retorno e em seguida tentar imprimir os boletos acima dai dá o erro!

    retorno29062018.TXT

  10. 13 minutos atrás, mgmobile disse:

    Acabamos de fazer acontecer o erro, gravamos inclusive video no teamviewer e pegamos os arquivos. Anexo o TXT que mandamos para o acbr...  logs, pdf gerado, etc... veja que por exemplo geramos nossonumero 72 e 73 e no pdf imprimiu errado...

    Se vc fizer de modo manual no acbr monitorando os TXT e enviar na sequencia:

    LIMPALISTA.TXT

    CONFIGDADOS.TXt

    INCLTITULOS.TXT

    IMPRIMEBOL.TXT

    usando o arquivo BOLETOS.TXT que enviamos... e o cedente.ini que enviamos vai dar o erro... nossonumero do PDF vai sair diferente do enviado no boletos.txt

    BOLETOS.TXT

    boleto 900010.pdf

    log.txt

    cedente.ini

    Mais um detalhe... se vc analisar o PDF vai ver que o DIGITO VERIFICADOR mudou, ou seja, mandamos no BOLETO.TXT NossoNumero=72 e depois 73... imprimiu no PDF apenas o número 7 (cortando o ultimo) mais o DV mudou... ou seja, o DV parece estar sendo calculado corretamente pelo numero informado no TXT mais a apresentação do nossonumero no PDF esta errada... 

  11. 7 horas atrás, José M. S. Junior disse:

    Bom dia

    Deixe habilitado a opção para gerar log ("Log de Comandos") do ACBrMonitor. Assim que ocorrer o problema com o boleto anexe aqui o log.txt para análise.

    Acabamos de fazer acontecer o erro, gravamos inclusive video no teamviewer e pegamos os arquivos. Anexo o TXT que mandamos para o acbr...  logs, pdf gerado, etc... veja que por exemplo geramos nossonumero 72 e 73 e no pdf imprimiu errado...

    Se vc fizer de modo manual no acbr monitorando os TXT e enviar na sequencia:

    LIMPALISTA.TXT

    CONFIGDADOS.TXt

    INCLTITULOS.TXT

    IMPRIMEBOL.TXT

    usando o arquivo BOLETOS.TXT que enviamos... e o cedente.ini que enviamos vai dar o erro... nossonumero do PDF vai sair diferente do enviado no boletos.txt

    BOLETOS.TXT

    boleto 900010.pdf

    log.txt

    cedente.ini

  12. 19 minutos atrás, José M. S. Junior disse:

    Por aqui não consegui simular, gerou corretamente com seu arquivo, mas vou verificar a geração da remessa devido estar estourando o tamanho da linha...

    O ideal é sempre LimparLista após realizar a leitura do Retorno, antes de gerar outro título... 

    Se tentar imprimir vai dar certo mesmo... como eu disse é exporádico... em alguma situação que não sabemos é gerado o arquivo de remessa com um zero a mais e também impresso faltando um numero conforme expliquei...

    O Comando LIMPARLISTA é sempre realizado antes de imprimir boletos ou gerar remessa...

    Apenas frizando, não estamos tratando de RETORNO e sim de REMESSA... só citei exemplo do RETORNO pois já participei de outro tópico sobre o BANCO SANTANDER que o INI do retorno era gerado com 13 caracteres... mais aqui estamos tratando de IMPRESSAO DO BOLETO FALTANDO O ULTIMO NUMERO, ou seja, gero no INI 46 e imprime 000000000004 (só de vez em quando)

    link do tópico sobre a leitira errada da remessa pelo acbr: 

     

    Também não conseguimos simular pois a maioria das vezes sempre sai certo... é exporádico e nos causa um transtorno enorme pois a LINHA DIGITAVEL é gerada como se o numero do boleto fosse 4 e nao 46... o arquivo de REMESSA gera o 46 mais com um zero a mais... dai o cliente PAGA e o banco não identifica pois paga o boleto nossonumero 4 (gerado errado) e no arquivo de remessa estava o correto que era 46... dai o banco cobra uma taxa do cliente como se fosse boleto sem registro...

    E isso tem acontecido somente com SANTANDER...

  13. 25 minutos atrás, José M. S. Junior disse:

    Por favor, anexe o arquivo completo que esta passando para geração do Boleto, para que possamos verificar...

    Ok, anexo segue o arquivo INI que enviamos para o ACBR e o arquivo de REMESSA.

    Notem que geramos o nossonumero 46 e na imagem ele imprime apenas o 4 e no arquivo de remessa tem o 46 mais com um ZERO A MAIS à esquerda...

    Já tivemos este problema antes com o arquivo de RETORNO onde o acbr lia o retorno e nor retornava um INI om 13 caracteres sendo que SANTANDER são 12 caracteres... na ocasião postei no forum sobre o erro e acabei mudando o programa para ler o arquivo que o acbr gerava pegando as 12 primeiras posições... posteriormente foi lançado nova versão com o erro do RETORNO SANTANDER corrigido

    Creio que esse erro na REMESSA tem a ver com o erro do retorno... pois ao que dá entender é que em alguma parte do fonte do ACBR onde ele coloca os ZEROS A ESQUERDA para completar os 12 caracteres do NOSSONUMERO santander o acbr está colocando um zero a mais.... dai gera uma REMESSA com um zero a mais e o PDF aparece apenas os 12 primeiros caracteres, cortando o ultimo...

    O estranho que isso acontece raramente... geralmente acontece no primeiro boleto que o cliente vai emitir no dia... dai os demais ficam certos...

     

    BOLETOS.TXT

    remessa.rem

  14. Bom dia

    Ao emitir boletos para o banco Santander esta dando erro na hora de gerar o arquivo de remessa e o pdf no campo nosso numero, por exemplo: é enviado o nosso numero 46 porem no pdf apresenta somente o digito 4 e no arquivo de remessa ele grava o nosso numero 46 porem um campo a frente, este erro ocorre aleatoriamente gerando algumas vezes corretamente e outras vezes errado.

    Segue em anexo um exemplo do ocorrido.

    erro 1.png

    erro 2.png

  15. Tenhos duas perguntas:

    1- É possivel desabilitar isto na impressora ou fazer algo para que nao verifique o digito verificador?

    2- Se eu nao tenho um codigo de barras EAN13 valido e queira transformar por exemplo ABC123 em codigo de barras, qual codificação devo utilizar e como devo gravar  ?

  16. Boa tarde

    Estamos imprimindo etiqueta e selecionando o tipo de barras barEAN13, porem o ultimo digito do codigo de barras esta diferente do informado no arquivo enviado para o ACBR, estou anexando o arquivo gerado e um foto da etiqueta gerada, no exemplo estamos enviando "0000000021750" e na etiqueta esta saindo "0000000021753".

    Alguem pode me ajudar e ver se estou fazendo algo de errado, obrigado.

    etiqueta.txt

    ETIQUETA.jpg

  17.  

    1 hora atrás, José M. S. Junior disse:

    Boa tarde. No manual (tecla F1) tem um exemplo junto ao comando ImprimirBarras(). Mas segue anexo um modelo completo de uma etiqueta com código de Barras...

    ENT_etiqueta.TXT

    Realizei um teste baseado no exemplo que me passou e funcionou perfeitamente, estou apenas realizando alguns ajustes para o tamanho da etiqueta. Tentei localizar esta documentação utilizando a tecla F1 e nao consegui locar, talves meu manual esteja desatualizado.

    Muito obrigado mesmo, me ajudou muito.

  18. 42 minutos atrás, José M. S. Junior disse:

    Boa tarde. No manual (tecla F1) tem um exemplo junto ao comando ImprimirBarras(). Mas segue anexo um modelo completo de uma etiqueta com código de Barras...

    ENT_etiqueta.TXT

    Ok, José, agora deu certo!!

    Apenas para funcionar seu exemplo tivemos que tirar os parêntesis do comando ATIVAR/DESATIVAR e Iniciar/Finalizar ficando:

    ETQ.Ativar
    ETQ.IniciarEtiqueta
    ETQ.ImprimirTexto( "0", "2", "2", "2", "3", "3", "BISCOITO MARILAN RECH 335G", "0", "1" )
    ETQ.ImprimirTexto( "0", "2", "2", "1", "8", "3", "CHOC BRANCO")  
    ETQ.ImprimirBarras( "0", "0", "2" , "2", "13", "5", "7896003701685", "10", "1")
    ETQ.ImprimirCaixa( "13", "32", "56", "17", "1", "1");  
    ETQ.ImprimirTexto( "0", "3", "3", "2", "18", "35", "R$")  
    ETQ.ImprimirTexto( "0", "3", "4", "4", "15", "50", "20,59")
    ETQ.Imprimir( "1", "0" )
    ETQ.FinalizarEtiqueta
    ETQ.Desativar

    Agora está funcionando certinho!

    Obrigado!

    • Curtir 1
  19. boa tarde

    Baixamos a nova versão do ACBR onde contempla melhorias na impressão de etiquetas porem mesmo na nova versão nao conseguimos fazer imprimir o codigo de barras, conseguimos imprimir apenas o texto, alguem tem um exemplo ou link que explica os campos onde define o tipo de codigo de barras ?

    Desde ja agradeço.

  20. 3 horas atrás, José M. S. Junior disse:

    Boa tarde @mgmobile, houve algumas modificações recentes no componente etiqueta... estaremos liberando uma versão do ACBrMonitor com alguns ajustes e o manual atualizado, inclusive a passagem de parâmetro para o tipo barCODE...

    Ok, José, sabe quando será liberado a versão do acbrMonitor? obrigado!

  21. 20 horas atrás, Daniel Simoes disse:

    " 111977" não é um EAN13 válido...

    Que tipo de código você quer imprimir ? tente com barCODE39 ou barCODE93

    Quais são as opções disponiveis além de barCODE39, barCODE93 e EAN13?

    tentamos ETQ.ImprimirBarras(0, barEAN13, 2, 2, 26, 1, '111977', 10) .

    tentamos ETQ.ImprimirBarras(0, barCODE39, 2, 2, 26, 1, '111977', 10) .

    tentamos ETQ.ImprimirBarras(0, barCODE93, 2, 2, 26, 1, '111977', 10) .

    Todos no ACBR o retorno é OK mais na impressão sai em branco...

    Olhei no manual e diz:

    ETQ.ImprimirBarras( Orientacao, cTipoBarras, cLarguraBarraLarga , cLarguraBarraFina, nVertical, nHorizontal, cTexto, nAlturaCodBarras );
    Tentamos mudar os parâmetros de nVertical, nHorizontal também mais não deu... sai em branco...

    O Cliente usa uma impressora ARGOX...

    Texto imprime normal, por exemplo: ETQ.ImprimirTexto(0, 1, 2, 1, 6, 1, 'ANTONIO DE OLIVEIRA') imprime normal...

    Só não imprime código de barras...
     

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...