Valdir Dill

Boa tarde, Sempre pensei em utilizar o Lazarus. Mas nunca havia feito nada de prático nesse sentido. Depois que vi um aqui no fórum uma afirmação do @Daniel Simoesdizendo que todo o DJSystem é feito em Lazarus, aí me animei, afinal é uma indicação e tanto, rs... Muito bem, iniciei a instalação do Lazarus para fazer alguns testes e, quem sabe, passar a utilizá-lo. - Instalação do Lazarus -> Tudo ok; - Teste de alguns projetos simples -> ok; Instalação de componentes - Fortes -> ok; - Alguns do Acbr, como Boleto e outros -> 0k; - Ao iniciar a instalação dos pacotes DFe, deu erro e é aqui que gostaria de uma ajuda. - Iniciei pelo MDFe. Instalou tudo certo e fez o procedimento de reinicialização do Lazarus. Quando foi abrir novamente, deu erro pedindo a libxml2-2.dll. Copiei ela para a pasta \System do Windows. Aí passou a dar o erro anexo e não consigo sequer mais entrar no Lazarus. Se excluo a libxml2-2.dll e tento entrar no Lazarus, novamente dá o erro de falta dessa .dll e também não abre o Lazarus. 1 - Alguma dica? 2 - Alguém presta consultoria em instalação do Lazarus e migração de sistema Delphi -> Lazarus? Procurei na aba de consultorias aqui do fórum, mas não encontrei ninguém lá; 3 - Há tão pouca gente assim usando o Lazarus? Em princípio me parece um excelente opção. Porque me parece que poucos utilizam? Obrigado!

Boa noite, Tenho algumas dúvidas sobre as tags relativas às configurações de fonte para o acbrPosPrinter. 1 - Qual a diferença das tags "<c> - Liga Condensado" e "</fb> - Liga Fonte Tipo B (condensada)"? Não seriam ambas para a mesma função? 2 - Qual a diferença das tags "</fn> - Fonte Normal" e "</fa> - Liga Fonte Tipo A (normal)"? 3 - Se na impressão não for incluída nenhuma dessas tag de fontes, qual delas será utilizada como padrão pelo acbrPostPriner? Sei que poderia fazer um teste na impressão e tentar ver, mas não tenho impressora para isso no momento. Obrigado.

Boa tarde, Não sei se vai ser igual para todas as UFs, mas estamos iniciando alguns testes com NFe para CPF em MG. Nessa UF é preciso que o emitente faça um cadastro especial para poder emitir a nota. Ainda não conseguimos fazer nenhum teste porque a liberação desse cadastro não saiu. Demora alguns dias. Talvez aí na sua UF também precise desse cadastro e, por isso, esteja ocorrendo a rejeição. Abraços.

Boa tarde @José M. S. Junior, Realmente os bancos normalmente não analisam isso, até porque o que importa são os valores informados no arquivo remessa. Nesse texto não tem a menor importância no registro dos títulos. Mas esse banco/agência analisou. O problema maior é que a impressão do boleto também fica errada. Uma outra solução que talvez seja mais simples e não afete a geração do arquivo remessa seja esta abaixo: Na linha 2064 da AcbrBoleto.pas eu mudei De if DataMulta <> 0 then AStringList.Add(ACBrStr('Cobrar Multa de ' + FormatCurr('R$ #,##0.00', IfThen(MultaValorFixo, PercentualMulta, ValorDocumento*( 1+ PercentualMulta/100)-ValorDocumento)) + ' a partir de '+FormatDateTime('dd/mm/yyyy',ifthen(Vencimento = DataMulta, IncDay(DataMulta,1),DataMulta)))) Para if DataMulta <> 0 then AStringList.Add(ACBrStr('Cobrar Multa de ' + FormatCurr('R$ #,##0.00', IfThen(MultaValorFixo, PercentualMulta, ValorDocumento*( 1+ PercentualMulta/100)-ValorDocumento)) + ' após '+FormatDateTime('dd/mm/yyyy',ifthen(Vencimento = DataMulta, IncDay(DataMulta,1),DataMulta)))) Só alterado o "a partir de" por "após". Isso diminuiu alguns caracteres e resolveu o problema. Em anexo a unit alterada caso queiram aplicar essa mudança oficialmente nos fontes. Obrigado ACBrBoleto.pas

Boa tarde, Resposta SEFAZ-MS. " Devido a problemas de fornecimento de energia (pane elétrica ocorrida na região do Parque dos Poderes) alguns computadores da SGI foram afetados. Todo o esforço de reestabelecimento dos sistemas informatizados está sendo realizado, a previsão de normalização que nos foi repassada será a partir das 12:00h de hoje, 31/08/18. Os cancelamentos de NF-e estão sendo prejudicados em função de checagem em sistemas paralelos. Tão logo estes sistemas paralelos estejam normalizados, as solicitações de cancelamento de NF-e também estarão normalizadas. Informamos que todos os pedidos de cancelamento de NF-e que tenham sido solicitados dentro do período da pane elétrica serão liberados, assim que a situação esteja normalizada. Portanto, favor aguardar. Atenciosamente, Equipe NF-e" Aberaços

Boa tarde, Estou tendo problema de rejeição de homologação no Santander. A causa é um corte que o acbr acaba fazendo no texto de uma das mensagem no MontarInstrucoes2 da acbrBancoSantamder.pas. A mensagem final fica assim: "Cobrar juros de R$ 0,01 por dia de atrasCobrar Multa de R$ 0,03 a partir 23/09/2". Note que na terceira mensagem falta os 3 últimos dígitos do ano. Isso gera rejeição da homologação pelo Santander. O corte ocorre porque a function function MontarInstrucoes2: string; copia apenas 40 caracteres de cada mensagem e, como a mensagem tem mais de 40 caracteres...acaba cortando. Aumentei o tamanho do copy dessa function para 45. Unit com a correção em anexo. Não sei se é a melhor forma, mas para mim resolveu. Se possível, atualizem no svn. Obrigado. ACBrBancoSantander.pas

Bom dia, Consegui fazer um testes de remessa. Ao gerar o arquivo remessa e tentar enviar com tamanho setado em 10 no nosso número, ocorre erro (anexo) de nosso número inválido. O erro ocorre porque o DV acaba não sendo incluído e fica errado com 10 no tamanho máximo. Com tamanho 7 ele calcula tudo correto. Porém, aí no tratamento do arquivo de retorno, o valor de ACBrBoleto1.ListadeBoletos.Objects.NossoNumero acaba ficando errado porque ele lê apenas 7 dígitos, ou seja, das posições 38 a 45. Enfim, se colocar tamanho máximo 10, corrige o tratamento do retorno, mas gera erro na remessa. Se colocar 7, resolve a remessa, mas cria erro no tratamento do retorno. O que talvez pudesse ser uma solução seria mudar a linha 537 da acbrBancoBancoob.pas de "NossoNumero := Copy(Linha,38,7);" para "NossoNumero := copy(Linha,38,10);" e não deixar o tamanho máximo do nosso num em 7. Isso corrigiria o tratamento do retorno e não influenciaria diretamente na remessa pois essa linha é somente do retorno. Porém, isso geraria uma exceção na "procedure TACBrTitulo.SetNossoNumero ( const AValue: String );". Sinceramente travei. Não tenho mais ideias para acerta isso, hehe! Se alguém tiver uma sugestão... Obrigado. cb220801.rem

Só um detalhe que acho que precisaríamos analisar @José M. S. Junior. Veja o que você me diz. É o seguinte: no arquivo de retorno do banco, o título que mencionei (número 455), nosso número com 10 dígitos, ele retorna assim: "0000004551", ou seja, o "1" é o DV, correto? Com tamanho 7, esse de fato é o DV desse título. Porém, quando gero o boleto com a mudança proposta, ou seja, colocar o tamanho máximo do nosso número para 10, o ACBR gera o boleto assim: "0000004550", ou seja, com DV=0. Pela lógica isso vai dar erro na hora do banco processar o arquivo remessa, pois, se, mesmo já no novo layout (tamanho 10), o banco aceitou com DV=1, então, se enviar com DV=0, será rejeitado, entendeu? Ainda não tive como testar isso.

Não. Não tenho como testar com cnab400. Até porque o Sicoob está abolindo essa opção. Os convênios (pelo menos os novos) dessa cooperativa agora são aceitos apenas com cnab240. Obrigado.

Acredito que na ACBrBancoob.pas teriam que ser alterado as linhas: 88 - de "fpTamanhoMaximoNossoNum := 7;" para "fpTamanhoMaximoNossoNum := 10;" e 537 - de "NossoNumero := Copy(Linha,38,7);" para "NossoNumero := Copy(Linha,38,10);" Unit alterada em anexo. Obs.: não sei dizer se essa alteração, principalmente da linha 88 não vá gerar outros problemas, talvez na emissão. Estou apenas postando as alterações que fiz aqui e resolveram para a leitura do retorno. Mas acho que os moderadores devem analisar e, se for o caso, atualizar os fontes. Obrigado. ACBrBancoBancoob.pas

Bom dia, A linha 537 ACBrBancoob.pas (função procedure TACBrBancoob.LerRetorno240) está assim "NossoNumero := Copy(Linha,38,7);" Ou seja, está buscando o nosso número das posições 38 a 44. Porém, no arquivo de retorno (anexo), esse dado está vindo das posições 40 a 46. No arquivo anexo tem dois títulos baixados. Vejamos apenas o primeiro: o nosso número desse título é 0000453. A leitura retorna 0000004. Será que há algum erro no Acbr ou é o banco que mudou esse layout de retorno? Obrigado. 3180_00265012_20180820_C240_00.ret

Boa tarde, Acho que era problema de schemas desatualizados. Copiei os schemas do svn e resolveu. Obrigado.

Boa tarde, Na validação de MDFe está ocorrendo um erro (print anexo) ao validar o valor da IE, campo rodo.veicTracao.prop.IE. Ocorre que o proprietário do veículo é um CPF e, nesse caso, a IE deve ficar em branco, mas não aceita. Conferi no XML e a IE está mesmo em branco Veja as tag relacionados ao transporte <rodo><veicTracao><placa>JYA7662</placa><tara>3000</tara><capKG>7100</capKG><capM3>0</capM3><prop><CPF>93799918191</CPF><RNTRC>00922040</RNTRC><xNome>GILMAR DONIZETE VIEIRA</xNome><IE></IE><UF>MT</UF><tpProp>0</tpProp></prop><condutor><xNome>GILMAR DONIZETE VIEIRA</xNome><CPF>93799918191</CPF></condutor><tpRod>06</tpRod><tpCar>02</tpCar><UF>MT</UF></veicTracao></rodo> Alguma sugestão? Obrigado.

Bom dia, Eu segui a sugestão do @Daniel Simoes e fiz minha própria tela de listagem dos certificados para o usuário selecionar qual certificado deseja vincular. Aí partir daí não tivemos mais relatos desse erro do plugin de banco fechar meu sistema. Compartilho a função em anexo. Veja se lhe é útil. Abraços. functionCertDigital.txt

Boa tarde, Fiz isso e agora está dando rejeição: "erro não catalogado". Alguma dica? Obrigado.

Boa tarde, Eu estava com esse erro em GO. As configurações abaixo resolveram: SSL.SSLType := LT_TLSv1_2; Configuracoes.WebServices.TimeOut := 15000; Abraços

Boa tarde, Já tive vários problemas como esse. A causa é o plugin de algum banco instalado/ativo no computador. Muito provavelmente Warsaw. Normalmente reiniciar o micro resolve. Mas pode ser necessário desinstalar o plugin e o sistema do banco. Abraços

Boa tarde, Desculpe, mas não estou conseguindo o XML. Para poder fazer a nota passar, o usuário simplesmente resolveu mudar o CSOSN para 102, acredita? Dá erro num enquadramento e eles vão mudando o CSOSN até que um dê certo, rs... Tentei reproduzir o erro aqui em laboratório, em homologação, mas não ocorre. Vou aguardar e ver se ocorre novamente. Pode também ser que era instabilidade no WS. De toda forma, agradeço sua ajuda. Obrigado.

Não, uso TLS_All. Não tenho como dbugar aqui, mas usuário informou que o problema só ocorre quando usa CSOSN 500 e informa os dados nos novos campos do "ICMS Efetivo". Obrigado

Bom dia, Alguma ideia sobre a possível causa do erro anexo? Obs.: SEFAZ Maranhão. Obrigado.

Bom dia Italo, Beleza pura. Entendi. Obrigado.

Bom dia, Sim, é xsLibXml2. A configuração é esta: SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsLibXml2; tem que usar os esquemas com final OPENSSL. Não entendi muito bem. Vi que na pasta dos schemas tem o tiposGeralMDFe_v3.00-OPENSSL.xsd. Mas como direciono o componente para utilizar esse arquivo e não padrão? Obrigado

Boa noite, Alguma sugestão @Rafael Dias ? Obrigado.

Bom dia, Arquivo em anexo. Eu inclusive havia analisado a tag nro e parece estar correta. Obrigado. 21180705157537000264580010000002681577941147-mdfe.xml

Bom dia, Estou tendo o erro abaixo em um cliente ao emitir MDFe: falha na validação dos dados do manifesto 268 1824 - element '{http://www.portalfiscal/mdfe}nro': 'SN' is nota a valid value of the local atomic type Ao que tudo indica, o xsd não está aceitando o valor "SN", no campo do número da rua do endereço do emitente do MDFe. Mas esse valor está correto de acordo com as regras do próprio .xsd, ou seja, campo do tipo caractere de 1 a 60. O problema maior é que não consigo debugar, pois só acontece na máquina do cliente. Não parece ser erro de .xsd desatualizado, pois fiz os testes em minha máquina com os mesmos .xsd do usuário. Alguma dica? Obrigado.