maycoll

Estou tendo um problema com um cliente onde o responsável pela emissão do boleto é o banco. Neste cliente eu usava uma versão anterior do acbr onde mesmo o banco sendo o responsável pela emissão do boleto, eu informava o nosso número e ele aceitava normalmente. Depois de atualizar o acbr, percebi que o campo nosso número está sendo zerado quando o responsável pela emissão do boleto é o banco. O problema maior é que parece haver uma incoerência no manual do bradesco onde ele fala que se: Perceberam a incoerência, uma hora ele diz que deve ser zerado, mas se você informar o nosso número o banco assume. O acbr esta seguindo a primeira regra. Porem o nosso cliente sempre usou com a configuração:" O banco emite o boleto e informando o nosso número ( inclusive em sistemas anteriores ao nosso )". Eu resolvi o problema aqui da seguinte maneira: Código original: if (ACBrBoleto.Cedente.ResponEmissao = tbBancoEmite) then begin ANossoNumero := StringOfChar('0', wTamNossoNum); DigitoNossoNumero := '0'; end else begin ANossoNumero := ACBrTitulo.NossoNumero; DigitoNossoNumero := CalcularDigitoVerificador(ACBrTitulo); end; Alterado para: if Trim(ACBrTitulo.NossoNumero) = EmptyStr then begin ANossoNumero := StringOfChar('0', wTamNossoNum); DigitoNossoNumero := '0'; end else begin ANossoNumero := ACBrTitulo.NossoNumero; DigitoNossoNumero := CalcularDigitoVerificador(ACBrTitulo); end; Alguém também já teve esse problema?

Obrigado, vou realizar os precedimentos.

Olá pessoal, Hoje temos o seguinte cenário : Enviamos uma NFCe pra a receita, porém é retornado erro: Erro Interno: 10060Erro HTTP: 0 Neste momento nosso sistema entra em modo de contingencia, criando outro xml com as respectivas tag's e com "uma nova chave". O danfe é impresso e a chave que será inserida no QRCode é a nova. Porém, algumas vezes a receita acaba acatando a nota anterior mesmo dando o erro 10060. Neste caso quando a conexão estabiliza e vamos enviar a nota em contingencia, temos duplicidade. Com isso, tratamos esse erro modificando as informações do sistema para a chave/xml que foi aceita anteriormente. Mas se o cliente for consultar o QRCode do danfe impresso em contingencia, as informações irão apontar para a chave que não foi aceita pela receita. Neste caso, existe a possibilidade de criar os xml's informando a chave que eu deseje? Por exemplo: Quando desse o primeiro erro, eu manteria a chave e criaria o novo xml informando a mesma chave, assim mesmo que a primeira nota tenha sido aceita se o cliente consultar o QRCode apontará para a mesma chave.

Tive um problema com o banco Banestes que não estava aceitando o boleto justamente pela conta/cedente. O problema que o Banestes não usa o digito verificador em agencia e conta do cliente. Porém como uso o AcbrMonitor tenho que passar assim os dados do cedente: BOLETO.ConfigurarDados("[Cedente] Nome=Nome do Cedente CNPJCPF=000000000000 Logradouro=Av. 1 Numero=2 Bairro=Centro Cidade=Guarapari CEP=29.200-00 UF=ES RespEmis=0 TipoPessoa=1 Modalidade=1 CodigoCedente=1234567 LayoutBol=3 [Conta] Conta=123456 DigitoConta=7 Agencia=01740 DigitoAgencia=0 [Banco] Numero=21 CNAB=240 IndiceACBr=11") Reparem que na tag [CONTA] o digito assume o ultimo digito do código do cedente ( se não passar digito, o acbr da erro ). Tive que alterar a função abaixo para que fosse gerado o boleto corretamente para o banco aceitar. function TACBrBancoBanestes.MontarCampoCodigoCedente ( const ACBrTitulo: TACBrTitulo ) : String; begin // Banestes não usa digitos verificadores em agência e conta //Result := ACBrTitulo.ACBrBoleto.Cedente.Agencia+ '/' + // ACBrTitulo.ACBrBoleto.Cedente.Conta; Result := ACBrTitulo.ACBrBoleto.Cedente.Agencia+ '/' + ACBrTitulo.ACBrBoleto.Cedente.Conta + ACBrTitulo.ACBrBoleto.Cedente.ContaDigito; end; Talvez ajude em alguma coisa

Ola Mauricio Bragaia .... tenho outro computadores com outros antivírus aqui na empresa, e já havia testado em outro sem problema nenhum , parece ser um falso positivo do Avast mesmo. O negocio é esperar eles analisarem mesmo.

Já havia realizado este procedimento Daniel ... o negocio é aguardar eles analisarem mesmo .. obrigado pela resposta

hleorj creio que a solução não seja trocar o antivirus .. pois os clientes de nossos clientes usam Avast ... e terão o mesmo problema ao abrir o arquivo. Desabilitei o avast e o pdf foi gerado .. enviei para um cliente que tem avast e quando ele foi abrir o problema tbm ocorreu. E que não da pre entender é que com uns xml's funciona e com outros não

Também estou com este problema. Quando mando o comando para o acbrMonitorPlus ( nfe.imprimirDanfePdf ) o Avast( meus teste aqui e nos clientes foram com este antivirus ) recebo a mensagem de js:Pdfka-gen [Expl]. O problema é que não são em todos os xml's que ocorre isso. Segue dois xml's para analise caso necessário. Obs: Ambos xml's foram gerados pelo acbrMonitorPlus comVirus.xml semVirus.xml

Obrigado Daniel ... tudo certo

Olá pessoal, Acabei de atualizar os fontes do AcbrMonitorPlus e estou tendo um erro ao criar uma NFe. O problema ocorre pois o campo "número" no endereço do destinatário não esta sendo informado, isso porque o endereço nao possui numero. "Sendo que estou testando com todos os dados do projeto, executando pelo Lazarus mesmo." ERRO: Falha na validação dos dados da nota: 1495 TAG:<dest><enderDest> ID:E07/nro(Número) - Nenhum valor informado. TAG:<dest><enderDest> ID:E07/nro(Número) - Nenhum valor informado. '' viola a restrição pattern de '[!-ÿ]{1}[ -ÿ]*[!-ÿ]{1}|[!-ÿ]{1}'. Falha da análise do elemento '{http://www.portalfiscal.inf.br/nfe}nro' com valor ''. Percebi tambem o que parece ser um erro de UTF-8 no retorno do log, mas acredito que isso não seja o problema. A questão é: Quando o endereço não possuir numero, a tag "numero" deve ser omitida ou informada com algum valor vazio; PS: Log em anexo. lognfe.txt

Obrigado Daniel ... Resolvido!!

Olá pessoal, Estou compilando o ACBrPlus Monitor e estou tendo problemas com os componentes TDateEdit. O erro que a aparece é esse: "Error reading deUSUDataCadastro.Text: Unknown property: "Text" " Tanto ao abrir ou compilar o projeto aparece essa mensagem de erro. Não consegui localizar nos fontes do projeto alguma linha que usasse a propriedade text do dateEdit, sendo que o erro também ocorre no componentes deRFDDataSwBasico. Alguém sabe como resolver isso? PS: Lazarus versão 1.2.6 - FPC: 2.6.4 "Fontes atualizado hoje 04/01/2016"

Ola Juliana, Simplesmente quando mando o arquivo de remessa para analise do suporte ele me retorna esse erro. (Suprimi algumas informações do cliente) ======================================== HEADER ======================================== Cedente centralizador: XX NOME DO CLIENTE XX Tipo de remessa: REMESSA-PRODUCAO Convenio: 0000.000.00000000-0 Inscricao: 00.000.000/0000-00 Banco: CAIXA ECONOMICA FEDERAL Geracao: 28/09/2015 as 14:29:08 seq 000001 ======================================== HEADER OK ===================================== ====================================== CAPA DE LOTE ==================================== Num remessa: 00000001 Gravacao: 28/09/2015 Cedente do lote: XX NOME DO CLIENTE XX Convenio: 0000.000.00000000-0 Inscricao: 00.000.000/0000-00 Geracao: 28/09/2015 ===================================== CAPA DE LOTE OK ================================== Linha 3 SEGMENTO P. Codigos de erro: 31.3P Total de registros do lote = 4

Bom dia pessoal, Estou homologando um boleto na Caixa Econômica com o layout SIGCOB pelo ACBrMonitor. Após corrigir a maioria dos erro, tem um que não estou conseguindo resolver, apesar de o arquivo não parecer estar errado segundo o manual. O erro é : "Linha 3 SEGMENTO P. Códigos de erro: 31.3P" Olhando o manual, o código 31.3P é relativo à data do desconto, porém no meu arquivo de remessa o código de desconto é zero(Sem desconto), logo a data e o valor do desconto também são zerados. Alguém sabe como resolver isso. Estou enviando o arquivo de remessa em anexo. 000001.rem

Pessoal, ainda estou com o problema com a remessa da caixa.... A mensagem do validador é esta: "Linha 3 SEGMENTO P. Codigos de erro: Este Título tem que estar marcado para protestar ou devolver. 31.3P" Sendo que, segundo o manual, 31.3P é referente à Data de Desconto. Alguém tem alguma sugestão?