-
Total de ítens
954 -
Registro em
-
Última visita
-
Days Won
5
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Tudo que Valdir Dill postou
-
Remessa Sicoob - Erro na Versão Layout Header e Header do Lote
um tópico no fórum postou Valdir Dill Boleto
Bom dia, Estamos tendo rejeição do arquivo remessa Sicoob, por conta dos campos: - Versão do layout do Header, linha 1, colunas 164 a 166 do arquivos remessa - Versão do layout do Header do lote, linha 2, colunas 14 a 16 do arquivos remessa No primeiro item, o componente seta a versão como 81 e no manual está 87. Já no segundo, o componente seta a versão como 40, sendo que no manual está 45. Nos prints anexos traz essa questão de forma ilustrada para melhor compreensão. Isso poder ser algum erro no componente ou tem alguma configuração que devemos fazer no componente para que isso vá correto? Obrigado cb010501.rem -
Depois de uma semana o banco teimando que era nosso que estava formando o remessa errado, descobriu-se que era o funcionário do banco que passou o código da agência errado para o cliente. Como é cooperativa (ou pelo menos nessa cooperativa), parece que o código da agência tem que ser da matriz e não o código onde o cliente tem conta. Estranho isso, mas... Mas enfim, resolvido. Obrigado!
-
Bom dia, Estamos tendo rejeição pelo banco ao enviar no arquivo remessa, banco 133-Cresol. O erro é: "Convênio Cresol inválido (Agência=1620, Conta=33925, Código da Empresa33925) (linha=2)"... (print anexo). Arquivo remessa também em anexo. No componente estamos alimentando os dados assim: ACBrBoleto1.Cedente.Convenio := 39325 ACBrBoleto1.Cedente.Agencia := 1620 ACBrBoleto1.Cedente.Conta := 39325; ACBrBoleto1.Cedente.ContaDigito := 3; Alguma sugestão de onde podemos estar errando? Obrigado cb140401.rem
-
Bom dia, Gostaria de uma ajuda. Na verdade é mais uma opinião/sugestão dos colegas de como que vocês fazem no seu sistema em relação à questão abaixo detalhada. Seria mais uma dica/sugestão em relação à regra de negócio. É o seguinte: 1) Fatos: a) No sistema, usamos o TEF Paygo, onde entre outros recebimentos, há a opção de recebimento por PIX; b) O TEF não retorna o CNPJ da intermediadora do recebimento PIX; c) A partir de janeiro/2023, é necessário que todo recebimento de PIX seja informado no registro 1601 do SPED Fiscal. Entre outros dados, precisa informar o CNPJ da instituição que intermediou o recebimento desse PIX. 2) De forma simples, a dúvida é: como saber (e registrar no sistema) quem (CNPJ) da instituição intermediadora do recebimento (PIX), no momento que um PIX via TEF recebido para depois informar isso no SPED? Obrigado!
-
Problema de driver desatualizado não é, pois estou usando esse mesmo desse link, i8, versão 7.17.
-
Boa tarde, Sim, as 3 propriedades estão com esses valores que você menciona. Veja o print anexo e note aquilo que mencionei antes, ou seja, em design, o código de barras está ultrapassando o quadro da direita. Já na impressão, esse código de barras diminui. É como se a propriedade autosize mudasse para true na hora de imprimir. Mas olhei no código fonte e lá também está lTertxtCodBarras.AutoSize := false. Estranho isso. Será que pode ser o driver da impressora que interfere em algo?
-
Bom dia, Atualizei os fontes e reinstalei novamente hoje (10/03). Não mudou absolutamente nada aqui. Veja o print que estou enviando em anexo. Quando eu imprimo, o código de barras tem um tamanho. Já no print postado aqui outro dia pelo @Daniel InfoCotidianoo código é bem maior e aí sim as linhas ficam mais espaçadas e acredito que isso possa ter algum efeito quando da leitura do código de barras pelo app. Eu até fiz um teste mudando o código fonte (ACBrBoletoFCFortesFr.pas) e alterando a linha -lTertxtCodBarras.Width := 641 para -lTertxtCodBarras.Width := 841. Em seguida reinstalei o componente, executei a aplicação debugando para ver se estava passando ali nessa linha e passa, tudo certo. Mas mesmo com lTertxtCodBarras.Width = 841, nada muda na impressão, isso tanto no preview como no papel. Não sei, mas me parece que precisa alterar algo mais no código para que essa mudança do tamanho do código de barras surta o efeito desejado na hora da impressão. Obrigado!
-
Boa tarde, Delphi 10.4. Sim, 100%.
-
É, está atualizado. Esses parâmetros são os que estão lá nos fontes. Notei que, nessa tentativas, você está definindo, tanto no componente, como dinamicamente, que lTertxtCodBarras.Width será 641. Em design, esse width faz com que o código de barras ultrapasse uns 1,5 cm aquele quadro (lá onde tem o label "Autent.Mecânica - Ficha de Compensação") do boleto à direita. No print que você postou impresso aí, isso também acontece. Porém, quando eu executo a impressão, esse código de barras "encurta" e, seu final, fica a uns 1,5 cm desse quadro, ou seja, o código de barras quando a impressão ocorre, fica uns 3 cm menor do que em design. Então, essa mudança de alterar o tamanho para 641, me parece, que não está surtindo efeito. Obs.: essa diminuição do código de barras na impressão, ocorre tanto no preview, como na impressão de fato. Obrigado!
-
Boa tarde, Mesmo resultado. Não mudou nada na impressão. Pode me passar detalhes da alteração que foi feita? Só para eu conferir aqui nos fontes e ver se estão realmente atualizados. Obrigado
-
Bom dia, Boleto em anexo. Boleto.pdf
-
Boa tarde, As barras até que estão espaçadas, mas a altura das barras é pequena. Não é igual a esse modelo que você enviou. O procedimento fiz exatamente conforme orientado, ou seja, descompactei esses 2 arquivos na pasta e depois reinstalei o Acbr. Só depois fiz o teste novamente. Obrigadgo.
-
Bom dia, Fiz o processo todo de atualização, mas não surtiu efeito. Continua sem ler. Obrigado!
-
Bom dia Tanto faz se imprimo direto para impressora ou a partir do preview, a impressão será a mesma e o celular não lê. Já se gerar o preview e apontar o celular para a tela do computador, aí lê normal. Em resumo, o código de barras está sendo gerado corretamente. O problema está na leitura do código impresso em papel. O leitor não reconhece. Imagino que isso seja um problema das impressoras térmicas ou não? Em pesquisas na net vi vários relatos que térmicas têm dificuldade de imprimir código de barras legíveis. Obrigado!
-
Em anexo. Esse boleto é da nossa aplicação, mas testamos também pelo demo Acbr e acontece a mesma coisa. Obrigado! BoletoBobina.pdf
-
Boa tarde, Estou com dificuldades em ler código de barras impresso em impressora térmica. Usei o demo Acbr no layout lTermica80mm, impressora Elgin i8. A impressão ocorre tudo certo. Porém, não consigo fazer a leitura através de app de bancos. Gerando a mesma impressão em vídeo, aí consigo ler código de barras. Acredito que possa ter relação com a qualidade na impressão, pois notei que ela sai um pouco borrada. Alguma sugestão para resolver isso ou realmente térmicas não são indicadas para essa função? Obrigado!
-
Não Recebimento Notificações Por Email
Valdir Dill replied to Valdir Dill's tópico in Dúvidas gerais
Boa tarde, Sim, recebi! -
Boa tarde, Estou sem receber notificações por email já faz algumas semanas. Não sei exatamente quando, mas faz mais de 15 dias. Verifiquei minhas configurações de notificação (print anexo) e, aparentemente está tudo certo, ou seja, para que avisos sejam enviados no email. Mas como dá para verificar no print anexo, estão indo para a notificação no fórum (no sininho). Obrigado!
-
Boa noite, Sei que esse assunto já está para lá de batido por aqui, mas fiz várias pesquisas nas postagens anteriores e não consegui uma luz sobre erro de consumo indevido que está ocorrendo em um cliente. Antes de mais nada, gostaria de informar que, com absoluta certeza, não há outra pessoa ou sistema fazendo buscas no CNPJ do cliente. Fiz os seguintes procedimentos hoje e obtivemos os seguintes resultados: Método: AcbrNFe1.DistribuicaoDFePorUltNSU(UFCod, CNPJ, VUltimoNSU); Tentativa 1 - Consulta por último VUltimoNSU = 711 - Data: 08/10/2022 - Hora: 11:24 - Resultado: rejeição 656 - Deve ser aguardado 1 hora para efetuar nova solicitacao caso nao existam mais documentos a serem pesquisados. Tente apos 1 hora Tags retornadas: <ultNSU>000000000000711</ultNSU> <maxNSU>000000000000000</maxNSU> Obs.: a consulta anterior havia sido feita há mais de 2 horas Tentativa 2 - Consulta por último VUltimoNSU = 0 - Data: 08/10/2022 - Hora: 14:31 - Resultado: rejeição 656 - Deve ser utilizado o ultNSU nas solicitacoes subsequentes Tags retornadas: <ultNSU>000000000000711</ultNSU> <maxNSU>000000000000000</maxNSU> Tentativa 3 - Consulta por último VUltimoNSU = 712, ou seja, número superior ao ultNSU - Data: 08/10/2022 - Hora: 16:03 - Resultado: rejeição 589 - Numero do NSU informado superior ao maior NSU da base de dados do Ambiente Nacional <ultNSU>000000000000000</ultNSU> <maxNSU>000000000000000</maxNSU> A única explicação que consigo imaginar que poderia ser possível para ocorrer essa situação é que não exista NSU superior ao 711, mas com certeza tem. Mas ainda assim, a primeira consulta após 1 hora com o ultNSU = 711 teria que retornar cstat 137 e não rejeição de consumo indevido, não é? Alguma sugestão? Sei que é a SEFAZ que retorna essa rejeição, mas o usuário sempre quer uma explicação, coisa que nesse caso não estamos conseguindo ,rs.. Estou anexando os arquivos de consulta/retorno das, caso seja necessário. Obrigado 20221008112442-con-dist-dfe-soap.xml 20221008112444-dist-dfe-soap.xml 20221008143130-con-dist-dfe-soap.xml 20221008143131-dist-dfe-soap.xml
-
Bom dia, Fontes atualizados, testados e aprovados, rs.. Obrigado!
-
Bom dia. Desculpe insistência @Juliomar Marchetti, mas nossos clientes estão nos cobrando. Se puder fazer o upload que você mencionou, agradeço... Até não entendo como ninguém mais se manifestou sobre isso, pois, com certeza, há muitas empresas que utilizam essa conciliação do Banco do Brasil. Obrigado!
-
Boa tarde, Alguma novidade sobre essa questão ou ainda está em análise? Obrigado!
-
Bom dia, Arquivo solicitado, em anexo. Só alterei o número da conta, por questão de segurança/sigilo. Obrigado Extrato123456 -BB.ofx
-
Boa noite, Pelo que consegui entender na análise do método ACBrOFX1.Import, o componente trata os lançamentos cujo valor de TRNTYPE seja igual a XFER, todos como débito (print anexo). Porém, em um arquivo .txt de que um usuário nosso enviou (print anexo), é uma transferência recebida, ou seja, um crédito. Obs.: o arquivo é do Banco do Brasil. Seria isso um erro a ser corrigido ou como proceder? Obrigado!
-
Dúvida em Manifestação de Destinatário
um tópico no fórum postou Valdir Dill DFe - Documentos Fiscais Eletrônicos
Boa tarde, Fiz uma consulta pelo último NSU, e este era o NSU 10 -> ACBrNFe1.DistribuicaoDFePorUltNSU(VUF, VCNPJ, 10). Agora, se eu fosse fazer uma nova consulta, deveria usar: ACBrNFe1.DistribuicaoDFePorUltNSU(VUF, VCNJ, 11), correto? Muito bem: suponhamos que, ao invés dessa consulta a partir do NSU 11 acima, eu faça uma consulta pela chave -> ACBrNFe1.DistribuicaoDFePorChaveNFe(VUF, VCNPJ, VChave). Esta consulta pela chave vai retornar um NSU também, correto? Digamos que esse NSU dessa chave consultada é o 20. Pelo que eu entendi, e constatei isso em testes práticos, sempre que se for fazer uma consulta com ACBrNFe1.DistribuicaoDFePorUltNSU, deve ser usado o último NSU consultado para aquele CNPJ, independentemente de como foi feita essa consulta, ou então recebemos a rejeição de "consumo indevido". Se tudo isso está correto, então, na situação acima relatada, eu não poderei mais consultar os NSUs de 11 a 19, já que a última consulta, apesar dela ter sido feita pela chave, (ACBrNFe1.DistribuicaoDFePorChaveNFe(), foi do NSU 20. É assim mesmo que funciona? Obrigado!