Werner_Marques
-
Total de ítens
780 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Werner_Marques
-
-
Obrigado pela resposta.
Vi os exemplos, mas como funcionaria a integração? O monitor deve ficar instalado no servidor da minha aplicação?
Usar delphi na web está descartado.
-
Boa Tarde,
Tenho uma aplicação escrita em delphi e estou migrando para php, já migrei boa parte dela, mas estou com problemas para migrar a parte de documentos fiscais. O ACBr Monitor pode ser integrado com php? O monitor deve ficar instalado no meu servidor web ou na maquina do cliente?
-
Bom dia,
Gostaria de saber sobre o projeto do ACBrCIOT, e está sempre sendo atualizado, e qual administradora está sendo utilizada no projeto ? Tem alguma integração com o MDFe ?
-
-
5 horas atrás, EMBarbosa disse:
Você poderia verificar com o aplicativo de exemplo? Porque não temos nenhum relato desse de que o PDF sai diferente da impressão. Isso seria a primeira vez.
Realmente, no programa de exemplo não apresenta esse problema, mesmo com as margens configuradas da mesma forma.
-
3 minutos atrás, EMBarbosa disse:
Você está utilizando a versão em Fortes ou Fast Report?
Fortes
-
Bom dia, Já vi esse tópico,percebi que tiveram essas alterações.
Quando eu altero as margens para que não corte na impressão, acaba cortando no arquivo PDF, não encontrei um valor que fique bem nas duas formas.
-
Bom dia, já vi alguns tópicos com esse mesmo assunto, mas não consegui resolver meu problema.
quando faço a impressão do DAMDFE com os valores padrão do componente, as margens ficam cortando cortando, conforme imagem.
Mesmo já fazendo as alterações sugeridas em outros tópicos, a margem a direita sempre sai cortada.
-
Vou verificar!
Obrigado!
- 1
-
27 minutos atrás, José M. S. Junior disse:
Boa tarde
O Digito verificador é calculável pelo componente por isso tem uma propriedade específica para ele. Ao ler o retorno deve ler apenas o NossoNumero mesmo, se tentar gerar um boleto com os dados de retorno vai ver que ele recalcula o dígito. Se precisar utilizar na sua aplicação pode chamar a função MontarCampoNossoNumero, ou chamar a função que retorna a linha digitável: MontarLinhaDigitavel.
Mais no caso não preciso gerar o boleto novamente, apenas identificar o que nosso número que foi gerado e enviado na remessa.
-
14 minutos atrás, Juliana Tamizou disse:
Tópico movido para a área do SAC, para que o SLA de respostas seja considerado
Boa tarde.
O DV é entendido como parte separada do nosso numero por isso não é lido. Mas porque vc quer gerar a linha digitável após processar o retorno?
Att.
Desculpa! Na verdade me referia somente a linha do arquivo, nesse caso do código do arquivo .pas que estava trazendo somente o nosso número sem o dígito.
-
Bom dia,
Estou homologando o boleto no banco Santander. E percebi que após importar o arquivo retorno a linha digitável ficou diferente da remessa.
Ao verificar o fonte ACBrBancoSantander.pas ( CNAB400 ) verifiquei que a divergência está no nosso número conforme detalhes:
A Remessa:
LInha 715: PadLeft(RightStr(NossoNumero,7),7,'0') + DigitoNossoNumero + // 63 a 70
O Retorno :
Linha 1062: NossoNumero := Copy(Linha,63,07);
A diferença, na remessa o nosso número tinha 8 dígitos sendo que os 7 primeiros é o nosso número e o 8º dígito é o Digito Verificador (que foi calculado anteriormente). No Retorno o fonte simplesmente lê os 7 dígitos como sendo o nosso número sem incorporar o dígito verificador, conforme na remessa. Se na remessa incorpora com o digito verificador, consequentemente ao ler o retorno deveria vim da mesma forma, ou teria algum campo que possa trazer o digito verificador na ACBrBoleto1.LerRetorno?
Segue layout atualizado.
H7800 Layout CNAB 400 com registro (padrão 353) Abril 2019 v 2.20.pdf
-
1 hora atrás, José M. S. Junior disse:
Bom dia
Existe uma variação na geração do nosso número, pode ver as regras na função "FormataNossoNumero" da classe do Banco do Brasil...
É baseado no Código de "Carteira", Numero do "Convenio" e o tamanho do Campo "NossoNumero" .
Precisaria ver exatamente em qual manual o gerador do banco está se baseando, e o tamanho do NossoNumero que está utilizando... Provavelmente o gerador do Banco não está utilizando os mesmos dados passados ou o tamanho do nosso número pode ser outro ao gerar pelo Banco...
Bom dia,
Vou conferir com meu cliente como estão configuradas essas informações no programa dele.
-
30 minutos atrás, BigWings disse:
Não consegui replicar.
Pelo demo do componente, informando o nosso número 40233, carteira 17 e convênio 3193857, a linha digitável gerada foi:
00190.00009 03193.857004 00040.233173 8 79660000000800
Verifique se está passando o nosso número corretamente para o componente.
Estou passando o nosso numero sem os zeros só o valores válidos.
-
Boa Tarde, alguma posição?
-
Agora, Juliana Tamizou disse:
Boa tarde.
Informe oque foi passado nas propriedades carteira e convenio..vale lembrar que existem informações que realmente são diferentes ao emitir o boleto pelo sistema próprio e ao emitir pelos aplicativos do banco.
Att.
Carteira = 17
convenio = 3193857
-
Agora, BigWings disse:
Geralmente o dígito é apenas informado na impressão do boleto.
Notou diferença na linha digitável ou no código de barras?
Sim, na linha digitável também está diferente.
linha do gerenciador: 00190 0009 03193 857707 00040 233173 6 79660000000800
linha gerada pelo componente:00190 00009 03193 857004 00402 335178 9 79660000000800
-
Agora, Juliana Tamizou disse:
Bom dia.
Passe somente os números validos, sem o "0".
Att.
Obrigado por Responder.
Mesmo informando apenas os números válidos o nosso número ainda permanece diferente. O próprio componente insere os zeros no numero.
-
Bom dia,
Estou gerando os boletos no formato CBR641 pelo componente, mas eles estão com o nosso número diferente dos boletos que são gerados pelo gerenciador financeiro e por isso não consigo realizar o pagamento dos mesmos.
nosso número gerado pelo gerenciador: 31938577000040233-9
nosso número gerado pelo componente: 31938570000040233
O valor que passo para o componente é 0000040233
Como posso resolver esse problema?
-
13 horas atrás, Scandolara disse:
se nao informar infANTT retorna como rejeicao 458-Rejeicao Tipo de Transportador nao deve ser informado para emitente de carga propria do veiculo.
Se alterar o tipo de emitente, conforme rejeicao, passa a ser carga propria e nao conforme o correto .
As empresa sao ETC , contratando terceiros para transportar, ou seja, tem q informar o infANTT devido a informação ,conforme manual do MDFe sobre o infANTT
infANTT = Registro obrigatório do emitente do MDFe junto à ANTT para exercer a atividade de transportador rodoviário de cargas por conta de terceiros e mediante
remuneração.Bom dia,
Estou com a mesma situação, sendo que o transportador é de carga própria. Alguma solução?
-
30 minutos atrás, erickmendes disse:
Pessoal, consegui resolver o meu caso aqui. Confiram se na tag <prop> tem os dados do motorista agregado. No meu estava saindo os dados do emitente e por isso rejeita. A partir de hoje a Sefaz está fazendo a validação destes dados.
Alguém encontrou mais alguma solução ?
-
O proprietário do veículo é pessoa física, e o transportador vinculado a ANTT é pessoa jurídica.
Estou informando o proprietário CPF, porém o veículo com ANTT está vinculado a um CNPJ. Mesmo assim apresenta a rejeição, como se tivesse que informar o proprietário com os dados do transportador vinculada a ANTT, sendo que dessa forma antes estava gerando normalmente.
-
O proprietário do veículo é pessoa física, e o transportador vinculado a ANTT é pessoa jurídica.
Estou informando o proprietário CPF, porém o veículo com ANTT está vinculado a um CNPJ. Mesmo assim apresenta a rejeição, como se tivesse que informar o proprietário com os dados do transportador vinculada a ANTT, sendo que dessa forma antes estava gerando normalmente.
- 1
-
Dúvida iniciante ACBrMonitor PLUS
em ACBrMonitorPLUS
Postado
Obrigado.
Estou assistindo as aulas e qualquer duvida, volto a postar.