Jump to content

Fernando Amado

Membros
  • Posts

    133
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

2,354 profile views

Fernando Amado's Achievements

Collaborator

Collaborator (7/14)

  • Reacting Well Rare
  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done

Recent Badges

25

Reputation

6

Community Answers

  1. Bom dia Jefferson, desde 2020 o SmaraPD passou a trabalhar com padrao Abrasf, e eu acabei descartando as modificações realizadas no meu fonte e seguindo com o ACBr oficial sem alterações
  2. Boa tarde José, Muito obrigado pelas orientações. Deu certo aqui! Estava fazendo os testes em uma impressora da rede e quando fui verificar o rate vi que ela havia sido instalado como generic, instalei pelo drive e deu certo. Desculpa pela falha e mais uma vez obrigado.
  3. Bom dia, Essas configurações foram a primeira que testei e sai mais quebrado que a primeira, segue foto:
  4. Bom dia Pessoal, se alguém puder me ajudar com as configuração do cupom da NFCe eu agradeço muito. Estou com a ultima versão dos fontes e eu mesmo comilo o monitor no Lazarus, assim garanto sempre a versão do monitor atualizada. Uso uma Elgin I9 e estou tendo problemas com a impressão no formato Forte/Bobina, segui as orientações que estavam no tópico de impressoras homologadas que usava 280 na largura e as margens com o padrão do monitor, ela saia cortando algumas linhas e desposicionando, ai fui testando várias configurações mas não consegui chegar a nenhuma funcional. A melhor que consegui foi com 280 na largura 0 na margem superior, 0 na esquerda, 0 na direita e mesmo eu colocando o máximo 100 na inferior ele corta o lSistema na impressão. Segue uma foto de como esta saindo o cupom. PS: EscPOS está saindo certinho, mas queria usar pelo fortes por causa da geração do PDF, além da impressão do fortes ser mais bonita que a EscPOS Se alguém tiver uma luz para me direcionar vai ajudar muito. Obrigado
  5. Pessoal, o erro está no ..\Fontes\ACBrDFe\ACBrDFeReport.pas foi alterado na revisão 17729 de: procedure TACBrDFeReport.SetPathPDF(const Value: String); begin FPathPDF := PathWithDelim(Trim(Value)); end; para: procedure TACBrDFeReport.SetPathPDF(const Value: String); begin FPathPDF := PathWithDelim( ExtractFilePath(Trim(Value)) ); end; Voltei e funcionou perfeitamente. ACBrDFeReport.pas
  6. Bom dia, Segue a Unit corrigida. Obrigado DoACBrMDFeUnit.pas
  7. Boa tarde pessoal, Identifiquei uma diferença no bloco Condutor do MonitorPLUS e do componente. No MonitorPLUS na unit DoACBrMDFeUnit.pas na função GerarMDFeINI geramos o bloco condutor com o nome CONDUTOR: for y := 1 to Rodo.veicTracao.condutor.Count - 1 do begin sSecao := 'condutor' + IntToStrZero(y + 1, 3); IniRec.WriteString( sSecao, 'CPF', Rodo.veicTracao.condutor.Items[y].CPF); IniRec.WriteString( sSecao, 'xNome', Rodo.veicTracao.condutor.Items[y].xNome); end; Já no componente na unit ACBrMDFeManifestos.pas na função LerArqIni lemos o bloco condutor como MOTO: while true do begin sSecao := 'moto' + IntToStrZero(I, 3); sFim := INIRec.ReadString(sSecao, 'xNome', 'FIM'); if sFim = 'FIM' then break; with rodo.veicTracao.condutor.New do begin xNome := sFim; CPF := INIRec.ReadString(sSecao, 'CPF', ''); end; Inc(I); end; Onde devo realizar a correção, alterar o MonitorPLUS para MOTO ou no ACBrMDFeManifestos para CONDUTOR? Abraços
  8. Italo, Minha solução foi criar uma propriedade no DFeConfiguracoes que nos componentes DFe acabou ficando em Configurações->Geral->CharSetXML, onde o default é UTF-8 mas dei a opção da mudança do charset que vai refletir na montagem do XML nas Units do DFeWebServices e seus dependentes. Acabei fazendo somente para o Charset UTF-8 e o ISO8859-1 mas se achar interessante para o projeto ter essa propriedade como oficial faço os ajustes necessários para englobar todos os TMimeChar do synalist (synachar.pas), caso não seja interessante manter como oficial sigo a vida com um branche do oficial. Obrigado pelo auxilio.
  9. Isso mesmo Italo, é o servidor próprio que não segue o ABRASF, é para cidade de Birigui-SP de fato, o mundo inteiro padronizou no UTF-8 e eles inventaram essa moda agora. Fora que não faz sentido nenhum fazr a busca pelo nome da cidade se todo resto do arquivo se baseia no código do IBGE, mas o fato é que correto ou não terei que mudar de alguma forma o encoding do XML. Isso não é configurável no ACBr? está fixo na geração do arquivo? Se não vou ter que fazer uma "manobra" para salvar esse arquivo editado
  10. Bom dia pessoal, Estou implementando uma nova tag implementada pelo servidor SmaraPD onde temos que informar a cidade em que o serviço foi prestado quando o serviço é realizado fora do município e por incrível que pareça não é pelo código do IBGE e sim pelo nome e UF da cidade. As Tags são <servicoCidade> e <servicoEstado> no entanto quando envio cidades sem acentuação na tag <servicoCidade> recebo o retorno que a cidade não foi encontrada na base de dados do servidor e se envio com acentuação da erro na estrutura do XML. O suporte do SmaraPD me passou que devo obrigatoriamente enviar no XML do RPS o Encoding ISO-8859-1 e nosso arquivo está sendo passado como UTF-8. Não estou conseguindo localizar onde altero o Encoding do XML, alguém poderia auxiliar? Assim que eu validar o arquivo envio a Unit com as alterações das novas tags do servidor Obrigado
  11. Pessoal não estou com acesso aos fontes agora, mas tive que realizar mais um ajuste no contador de registro pois a ultima disponibilizada passou a multiplicar tudo por 4 linhas ao invés de 3, no entanto as mensagens (segmento S) não são obrigatórias, então ajustei para quando há seguimento S multiplica por 4, quando não há multiplica por 3. Assim que conseguir acesso aos fontes mando a correção. Abraços
  12. Pessoal, O problema da sujeira do arquivo foi resolvido, vou colocar aqui para deixar registrado caso alguém venha a ter problemas com isso: -No Lazarus fui no menu "Ferramentas -> Converter Codificação dos Projetos/Pacotes"; -Nessa tela marquei os checkbox "Arquivos em ASCII ou codificação UTF-8" e "Arquivos Não está em ASCII nem na codificação UTF-8"; Ali lista todas as units do projeto, lá tinha algumas em CP1252 e outras em UTF-8, tudo misturado, então: -No combo "Nova Codificação" eu alterei para CP1252 e converti tudo, depois abri novamente e coloquei todas em UTF-8 (Pois se deixar em CP1252 os acentos dos label no form ficam com ?). Depois de padronizados todos em um unico formato compilei novamente e os arquivos estão sendo gerado sem sujeira.
  13. Boa tarde Senhores, No monitor está sim marcado a opção "ANSI". Faço o envio das informações por socket mas coloquei anexo o log do monitor para verificar. Com relação ao banco utilizado estamos validando em 3 bancos, Banco do Brasil, Itau e Santander, os três bancos geram o mesmo problema na estrutura do arquivo. Esse exemplo foi gerado para o banco Itaú 400 colunas. PS: O cliente que está exigindo a acentuação é do banco do brasil LOG.TXT logboleto.txt
  14. Amarildo, Como eu disse anteriormente fica difícil tratar direto na aplicação pois cada banco/layout tem uma quantidade de caracteres diferente, assim teríamos que criar um tratamento específico para cada banco dentro da aplicação, redundante já que existe todo esse tratamento dentro do monitor. Quanto a enviar os dados sem acentuação, estou tendo uma rejeição do cliente com relação a isso, já que o banco aceita acentuação nos arquivos e no sistema antigo ele gerava os boletos com nomes acentuados. O ideal é conseguirmos uma solução para que funcione no monitor de forma correta e efetiva. Agradeço bastante sua ajuda e atenção. Seria legal se alguém aqui do fórum que tenha mais experiencia com o Lazarus pudesse ajudar, pois eu não tenho experiência na IDE, uso apenas para compilar e ajustar o Monitor, mas não tenho muita afinidade com a IDE, tendo alguém com mais experiencia nela para auxiliar provavelmente chegaremos a uma solução.
  15. Segue os arquivo, O "439 cortada.rem" está com 398 colunas de 400 na linha 2, perdeu um digito na razão social e um digito no bairro, o "439 OK.rem" é a mesma remessa gerado sem acentuação nas strings. 439 OK.rem 439 cortada.rem
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.