Valdir Dill

1 Julho, 2021

18 minutos atrás, Italo Giurizzato Junior disse:

Bom dia Valdir,

Você configurou as propriedades de Margens?

No programa exemplo mostra como fazer essa configuração.

Bom dia Italo.

Sim, está configurado as 4 margens.

Tanto é que aqui em laboratório e em outros usuários não ocorre problemas. Apenas nesse cliente.

Acredito que possa ter relação com alguma configuração que o Fortes pega da impressora no Windows.

Obrigado!

1 Julho, 2021

Bom dia,

Alguma ideia do que pode estar causando esse corte da impressão na margem direita? DANFE em anexo.

Testado em nossa máquina e o problema não ocorre. No cliente acontece tanto na impressão de fato, quanto no preview em tela.

Será que pode ser configuração da impressora padrão? O que poderia ser?

Obrigado!

29 Junho, 2021

Boa tarde,

Só para registrar um feedback. Não consegui um solução completa, mas deixo registrado como contornei a situação.

Fiz a reinstalação do Acbr, marcando a opção (opção deixar somente a LibXX) que o @Juliomar Marchettisugeriu, mas não surtiu efeito. Marquei inclusive a opção "apagar arquivos antigos".

Na compilação direta no F9 não funciona de jeito nenhum. Deixei processando por 14 minutos e não saiu do lugar. Como mencionei na abertura do tópico, ele vai progredindo e compilando várias units, mas quando chega na AcbrTEFPayGoWebComum.pas não vai para frente. Não trava, apenas fica "processaaaaaando.....".

A solução que achei foi: primeiro faz um build (shift+F9). Ele demooooora também na AcbrTEFPayGoWebComum.pas, mas em 8 minutos termina. Após isso compilo (F9) e vai rapidão.

Lembrando que se não vincular a ACBrTEFDClass na uses da minha aplicação, aí o F9 (até sem build) compila em menos de 30 segundos.

Obs.: também não é problema de máquina (i5 + 8GB).

Obrigado!

29 Junho, 2021

Bom dia,

Estamos tendo problemas ao tentar complicar uma aplicação para Android.
Delphi 10.4.

Temos vários units do Acbr vinculadas à aplicação e compila sem problemas.
Mas, quando incluímos a ACBrTEFDClass na uses, acontece a situação abaixo detalhada.

O problema:
Ao tentar compilar, inicia-se o processo normal, mas, quando chega na AcbrTEFPayGoWebComum.pas, o processo não prossegue.
Fica "processando" e não conclui. Deixamos por vários minutos e fica sempre nessa tela.
Testamos tanto na nossa aplicação, quanto no demo Acbr (print anexo).

Alguma sugestão de solução?

Obrigado!

14 Junho, 2021

10 minutos atrás, Victor H. Gonzales - Panda disse:

Bom dia,

Por favor anexe o manual deste banco e o arquivo de retorno em questão

Obrigado

Bom dia,

Arquivos em anexo.

2021_Junho_CNAB400_UNICRED_TODAS_0000814156_0590_08062021_01 (3).RET GR - COB136 - Layout CNAB 400 - Retorno.pdf MANUAL UNICRED CNAB 240 E 400.pdf

12 Junho, 2021

Bom dia,

Na leitura de retorno, o Acbr está lendo o nosso número com 17 caracteres,
procedure TACBrBancoUnicredES.LerRetorno400(ARetorno: TStringList), linha 251 -> fpTamanhoMaximoNossoNum := 17
e, depois na linha 283 -> NossoNumero := Copy(Linha,46, fpTamanhoMaximoNossoNum);

Já na constructor TACBrBancoUnicredES.create(AOwner: TACBrBanco), linha 84, o componente define o tamanho do nosso número como 10 -> fpTamanhoMaximoNossoNum := 10;

Fiquei um pouco confuso, pois pelo que li no manual do banco, o nossonumero tem 10 dígitos.
Porém o componente está hora usando 10 e hora 17.

Podem, por gentileza, me esclarecer sobre isso?

Obrigado!

12 Junho, 2021

Bom dia,

Na leitura de retorno, o Acbr está lendo o nosso número com 17 caracteres,
procedure TACBrBancoUnicredES.LerRetorno400(ARetorno: TStringList), linha 251 -> fpTamanhoMaximoNossoNum := 17
e, depois na linha 283 -> NossoNumero := Copy(Linha,46, fpTamanhoMaximoNossoNum);

Já na constructor TACBrBancoUnicredES.create(AOwner: TACBrBanco), linha 84, o componente define o tamanho do nosso número como 10 -> fpTamanhoMaximoNossoNum := 10;

Fiquei um pouco confuso, pois pelo que li no manual do banco, o nossonumero tem 10 dígitos.
Porém o componente está hora usando 10 e hora 17.

Podem, por gentileza, me esclarecer sobre isso?

Obrigado!

4 Junho, 2021

Boa noite,

Estamos tendo esse erro abaixo no envio de email pelo AcbrMail.

SMTP Error: unable to send Mail data.
554 5.7.1 rejected for policy reason
503 5.5.1 Error: need RCPT command

O problema ocorre apenas quando tem anexo. Parece se alguma "desconfiança" do servidor em relação ao anexo. Mas são simples XML. Nada de "perigoso", rs.

Alguma sugestão do que pode ser a causa disso?

Obrigado.

4 Junho, 2021

Em 31/05/2021 at 12:38, Daniel Simoes disse:

@BigWings, o que acha ?

Uma solução, seria editar o próprio arquivo do IBPT... isso invalidaria ele, de alguma forma ?

Boa noite,

Não, não invalida. Na tabela anterior havíamos feito isso, ou seja, mexemos nos 27 arquivos antes de liberar para o usuário baixar. E funcionou legal.

Mas concluímos que dá bem menos trabalho incluir esse stringReplace que citei na postagem anterior.

Abraços

31 Maio, 2021

Bom dia,

Só para contribuir...

O erro ocorreu aqui também. Acontece porque na linha 6093 de todos os arquivos .csv, na tabela 21.1.H e agora também na 21.1.I , traz um texto com duas aspas duplas repetidas.

39233090;01;0;""Ex" 01 -

Isso faz com que o quebralinha gere um erro.

A solução que adotamos foi -> VLinha := StringReplace(VLinha,'""Ex"','"Ex',[rfReplaceAll]), direto na nossa aplicação, sem mexer nos fontes Acbr.

Obrigado

19 Maio, 2021

Bom dia,

Dando feedback. Finalmente conseguimos homologar Unicred, com código do banco próprio (136).

Em arquivo anexo arquivo Unicred_Homologacao.png, com resultado da homologação.

Demais arquivos são os manuais do banco 136, os quais envio como sugestão para disponibilização no svn.

Obrigado.

GR - COB136 - Composicao da Ficha de Compensacao.pdf GR - COB136 - Layout CNAB 400 - Remessa.pdf GR - COB136 - Layout CNAB 400 - Retorno.pdf Retorno -UNI0148905- PERFORMANCE CAR MECANICA LTDA v3.pdf

10 Maio, 2021

1 hora atrás, José M. S. Junior disse:

Bom dia,

Além disso está confuso mesmo... O próprio relatório se contradiz... informando que Código Beneficiário é 10 digitos mas no exemplo impresso está 10 posições + Dígito. Creio que não seja isso o motivo da rejeição até por que outras pessoas já homologaram com esse layout.

Sim, como eu disse é um pouco confusa essa análise deles.

Mas em relação ao formato do código do beneficiário, isso, na minha opinião, não está confuso. Esse boleto que eles trazem impresso no relatório, é justamente o boleto enviado para homologação. No boleto está com 11 (10+1) dígitos, quando o correto (pelo manual do banco) seriam 10 (9+1).

Obrigado.

10 Maio, 2021

6 minutos atrás, Victor H. Gonzales - Panda disse:

Bom dia,

O "erro" está somente na impressão da ficha de compensação?

se sim, é FortesReport ou FastReport ?

se FastReport qual o FR3 utilizado?

Abraços

Bom dia,

O relatório (anexo) do banco relativo a análise da homologação é um pouco confuso, mas, ao que parece, o problema é apenas na impressão.

Usamos Fortes Report.

Obrigado

Retorno de homologacao - ACPARTS BRASIL SC LTDA.pdf

8 Maio, 2021

Em 05/05/2021 at 11:18, Daniel Simoes disse:

@valdirdill, por favor releia a minha msg...

Acho que isso é bem diferente da sua interpretação... e não é ser grosseiro... estou recomendado que você use os nosso canais que você se sinta mais a vontade...

Todos eles são regidos pelo mesmo prazo de SLA nas respostas

Bem, é um pouco chato insistir nesse assunto, mas não posso deixar de me explicar, rs...

Está tudo certo @Daniel Simoes , não disse que foi grosseiro, pelo menos não minha foi intenção. Sei que não é nem de longe seu estilo ofender alguém, muito pelo contrário, sempre dando atenção e ajuda a todos.

Mas, se você analisar bem no contexto, vai ver que o seu texto ficou meio que parecendo que não podemos reclamar, rs? Sei que não foi isso que você quis dizer, mas no texto frio da mensagem é isso que ficou parecendo, entende?

Veja bem, lá no chat a gente posta uma dúvida/dificuldade. Aí alguém responde falando tal coisa. Em seguida eu respondo: "...mas eu já fiz isso...". Aí não tem mais continuidade do atendimento. A pessoa não responde mais. Isso já aconteceu comigo mais de uma vez.
E, nesse caso em específico, sequer a primeira resposta eu tive lá no Discord.
Aí, o que é que eu fiz, postei aqui no fórum para ficar registrado, inclusive com mais detalhamento e explicações mais analíticas da situação, inclusive ilustrando com arquivos.

O que recebo de resposta aqui:
"...acho que sua dúvida está relacionado a atualização do seu SVN e já foi respondido em outro tópico e no Discord..."
A pessoa viu minha postagem no chat e pensou que tinha respondido.
Não é justo, não concordas? Por isso registrei a reclamação e não tem a ver com o chat ser melhor ou pior que o fórum. A questão é que o atendimento peca ao "imaginar" que algo foi respondido, quando não foi ou então não dar uma continuidade no atendimento, nem que seja para dizer algo do tipo "...não tenho mais sugestões para o seu problema...". Pelo menos saberemos que a pessoa analisou.

Aí, no final das contas, fica parecendo que eu sou daquele tipo de usuário xarope, rs... que dispara chamado do mesmo assunto para tudo quanto é canal, quando não é nada disso.

Por fim, minha crítica foi para relatar meu ponto de vista, mas, principalmente, para ajudar.

Obrigado e abraços a todos.

8 Maio, 2021

Boa noite,

Estamos tentando homologar boleto Unicred.
Estamos usando layout cobUnicredES.

Segundo o manual do banco (em anexo, pagina 6), o campo
AGÊNCIA / CÓDIGO DO BENEFICIÁRIO: deverá ser preenchido com o código da agência,
contendo 4 (quatro) caracteres / Conta Corrente com 10 (dez) caracteres. Ex.
9999/999999999-9. Obs.: Preencher com zeros à direita quando necessário.

Estamos alimentando o componente assim:
- Conta: 81416
- ContaDigito: 4
- Agência: 1205
- AgenciaDigito: 0

Na ficha de compensação, no campo acima mencionado (AGÊNCIA / CÓDIGO DO BENEFICIÁRIO), está saindo assim:
1205-0/0000081416-4

Segundo o banco, esse campo deveria ficar assim:
1205/000081416-4
Ou seja, a agência deve imprimir apenas o número da agência (sem o DV) e o código do beneficiário com 10 dígitos, aí incluído o DV.

Estou fazendo algo errado ou é o componente que precisaria ser atualizado para se adequar ao que exige o banco?

Obrigado.

GR - COB136 - Composicao da Ficha de Compensacao.pdf

5 Maio, 2021

Em 03/05/2021 at 23:14, Daniel Simoes disse:

Se não gosta... Nesse caso use apenas o Fórum...

Sobre o seu caso... Você precisa nos passar informações mais precisas, de como podemos reproduzir o problema, usando os Demos do ACBr...

As rotinas que calculam o fuso horário do ACBr, são as mesmas para TODOS os DFe's..

Bom dia

Poxa, "...se não gosta, não usa.."? nem parece o Daniel que conheço, rs.. tenho mais de 11 anos de Acbr. Essa foi a primeira, e acho que será a última vez que reclamei de algo...

Mas tudo certo. Vamos em frente...

Obrigado! Abraços...

3 Maio, 2021

9 horas atrás, Juliomar Marchetti disse:

acho que sua dúvida está relacionado a atualização do seu SVN e já foi respondido em outro tópico e no Discord

Boa noite @Juliomar Marchetti,

Não. Com certeza não está relacionado a atualização, pois atualizo os fontes quase que diariamente.

Lá no Discord postei, mas não tive respostas. Acho que você está fazendo confusão porque eu postei outra questão lá no chat tive uma resposta, mas foi de outra questão. Desta questão aqui não tive resposta lá. Por isso é que abrir o post aqui para tentar deixar mais claro e já anexar os arquivos.

Não sei, mas me parece que essa coisa de chat via Discord e fórum está deixando a deixando a desejar @daniel almeidaEu particularmente não estou gostando. Inicia-se um atendimento por lá e muitas vezes só tem a primeira resposta...depois não há continuidade. Aí tentamos abrir um post no fórum e obtém-se a resposta que atendimento já foi dado pelo Discord, quando não foi, pelo menos não a contento. Sei que o SAC não é para resolver os nossos problemas. É apenas uma ajuda auxiliar, mas, sei lá, vocês estão implementando tanta coisa, inclusive bate-papos e etc., o que acho legal, mas não sei, me parece que pecam um pouco naquilo que já estava funcionando bem antes. Desculpe se aqui não é o lugar para isso, mas...

Em relação a esse post. Se possível, me passem alguma sugestão do item 2 da postagem inicial, ou seja, sobre como poderia resolver a situação para poder enviar as notas agora, se é que há uma solução. Se não houver sugestão, sem problemas, é só dizer "não faço ideia de como resolver...", mas preciso me certificar de que os especialistas, rs..do ACbr analisaram a situação e de fato não há uma solução clara para o problema, ok?

Obrigado.

3 Maio, 2021

8 minutos atrás, Italo Giurizzato Junior disse:

Bom dia Valdir,

Na unit pcnAuxiliar chegou a analisar as funções: IsHorarioDeVerao, GetInicioDoHorarioDeVerao e GetFimDoHorarioDeVerao ?

Mas antes certifique-se que todos os fontes de todas as pastas estão atualizados.

Bom dia,

De fato @Italo Giurizzato Junior, eu não tinha analisado. Agora analisei e entendi. Só em datas antes de 2020 é que ele considerará o horário de verão.

Mas e quanto a primeira questão => configurando ACBrNFe1.Configuracoes.WebServices.TimeZoneConf.ModoDeteccao = tzPCN, o componente Acbr vai alimentar o UTC para compor os DFes conforme for a UTC de cada UF, utilizando para isso, o valor de ACBrNFe1.Configuracoes.WebServicesUF. É isso mesmo né?

Obrigado.

1 Maio, 2021

Boa noite,

Estamos iniciando a implementação de boletos Unicred.
Segundo informações do pessoal da agência (cooperativa) onde o cliente tem conta, essa agência está vinculada ao layout SC.

No manual Unicredi, o qual estamos anexando aqui, que o usuários nos enviou e que ele recebeu do seu banco, está definido que os boletos dele deve ser gerado o layout com o código próprio Unicred, ou seja, banco = 136.

Porém, ao setarmos no ACBrBoleto1.Banco.TipoCobranca := cobUnicredSC, o boleto é gerado com base no layout Bradesco, pois a ACBrBancoUnicredSC.pas tem definido o fpNumero = 237.
A cobUnicredES gera layout com código próprio do UNicred, ou seja, banco = 136. Mas não creio que seria correto ACBrBoleto1.Banco.TipoCobranca := cobUnicredES se, segundo o próprio banco, a cobrança dessa agência segue o layout SC.

A minha questão/dúvida: será que a orientação do pessoal do banco para se gerar o layout com codigo do banco próprio (136) está errada? Ou é o Acbr que falta implementar a mudança de correspondente Bradesco para codigo 136, no caso do unicredSC?
Pelo que vi essa mudança para codigo próprio do banco foi ainda em jan/2019. Por isso estou achando estranho que o Acbr ainda teria implementado esse novo layout. Mas, ao mesmo tempo, o banco diz que o layout SC não usa mais o correspondente Bradesco.

Poderiam, por gentileza, me ajudar a entender/resolver essa questão?

Obrigado.

GR - COB136 - Composicao da Ficha de Compensacao.pdf GR - COB136 - Layout CNAB 400 - Remessa.pdf GR - COB136 - Cobranca WEB - Layout CNAB 400 - Remessa.docx

1 Maio, 2021

Boa noite,

Estamos com um usuário tendo rejeição ao enviar uma NFe cujo evento EPEC foi enviado.
Rejeição 467 - Dados da NFe divergentes do EPEC tag: dhemi.
Deduzimos que a causa está relacionada ao fuso horário (UTC).

XML enviado em EPEC, em anexo.
Consulta do EPEC no portal, em anexo.

A configuração ACBrNFe1.Configuracoes.WebServices.TimeZoneConf.ModoDeteccao = tzSistema

Como dá para verificar no XML, ficou gravado no XML UTC = -03:00, quando deveria estar -04:00, pois a UF é MT.

As questões que gostaríamos de uma ajuda, se possível, são duas:

1) O usuário jura que não alterou o fuso horário no Windows.
Há inclusive várias outras notas, autorizadas no mesmo dia, mas sem ser por EPEC e cujo XML está salvo com UTC correto -04:00.
Verificamos o Windows dele e realmente está lá UTC de Cuiabá, ou seja, -04:00. Claro que ele poderia ter alterado no Windows para -03:00 enviado o EPEC e depois voltado para -04:00, mas acho bem improvável isso.
Então, como pode se explicar esse ocorrido do XML dessa nota estar gerado com UTC -03:00?

2) Como resolver isso e poder transmitir a NFe?
Dentre outras sugestões, já encontramos (e seguimos) orientação para alterar o XML substituindo de -03:00 para -04:00, mas ao tentar enviar o XML, ocorre o mesmo erro, ou seja, a rejeição 467 acima detalhada.

Obrigado.

51210411550797000117550010000010864444421042-NFe.xml

1 Maio, 2021

Boa noite,

Pelo que entendi, se eu configurar:
- ACBrNFe1.Configuracoes.WebServices.TimeZoneConf.ModoDeteccao = tzPCN, o componente Acbr vai alimentar o UTC para compor os DFes conforme for a UTC de cada estado, utilizando para isso, o valor de ACBrNFe1.Configuracoes.WebServicesUF;

- ACBrNFe1.Configuracoes.WebServices.TimeZoneConf.ModoDeteccao = tzSistema, vai usar o UTC do sistema operacional;

- ACBrNFe1.Configuracoes.WebServices.TimeZoneConf.ModoDeteccao = tzManual, vai usar aquilo que for informado em ACBrNFe1.Configuracoes.WebServices.TimeZoneConf.TimeZoneStr

essas conclusões acima estão certas?

Caso a resposta acima seja sim, uma outra questão surge: no caso, a função que obtém o valor do UTC é a GetUTC( da pcnAuxiliar.pas, correto?
Porém, essa função está considerando horário de verão para algumas UFs (UTC4).
Até onde eu seu, não existe mais horário de verão para nenhuma UF.
Então tem algo errado nessa função ou tem algo que eu não estou deixando passar?

Obrigado.

30 Novembro, 2020

2 minutos atrás, Juliomar Marchetti disse:

Está usando FireDAC?

Sim.

30 Novembro, 2020

Bom dia,

Estou com um problema que ocorreu já umas duas vezes em 1 cliente.
O problema é off-tópic, mas como tem relação com gravação de dados em DFes, talvez alguém do grupo já tenha vivido situação semelhante e agradeço se puder me ajudar.

É o seguinte: para gravar os XMLs de DFes no banco de dados, utilizamos a função zip da acbrUtil.

O erro acontece quando vamos descompactar (unzip) o dado gravado. Dá o "error reading zip file".
Analisando o dado gravado no banco nesse campo aparece o seguinte texto:
xï¿½ï¿½:[ï¿½ï¿½È’ï¿½ï¿½+ï¿½ï¿½<ï¿½ï¿½ï¿½"ï¿½ziï¿½&WQnrQï¿½ï¿½|ï¿½(ï¿½
O texto é bem maior, mas tudo assim, com caracteres estranhos. É como se o sistema ao gravar ou então o banco de dados tivesse disparado uma conversão em outro encoding.

Investigando mais, verificamos que não é o zip() que causou o problema. Imagino eu que possa ser alguma coisa na máquina do usuário.
Em outros campos de outras tabelas onde o conteúdo do texto tenha acentos, ocorreu o mesmo problema, ou seja, ficou gravados caracteres estranhos no banco.
Por exemplo:
Um texto que deveria estar assim: Iniciou a NFe 95 série 1, vinculada à venda n° 97
Está assim: Iniciou a NFe 95 sÃ©rie 1, vinculada Ã venda nÂº 97

O mais estranho ainda é que isso ocorreu apenas em um dia específico. Nos dias anteriores e nos dias seguintes, o mesmo sistema, no mesmo banco de dados, tudo foi gravado corretamente.
É como se alguma coisa na máquina, nesse dia e apenas nesse, tivesse mudado e depois retornado ao normal.

O charset do banco é CHARACTER SET WIN1252 COLLATE WIN_PTBR.

Se alguém já tiver passado por uma situação dessas e puder me dar alguma dica...

Obrigado.

23 Outubro, 2020

4 minutos atrás, Italo Jurisato Junior disse:
Valdir,

Na unit ACBrNFeNotasFiscais procure pela função ObterNFeXML.

Ela tem que ficar da seguinte forma:
function NotaFiscal.ObterNFeXML(const AXML: String): String;
var
  DeclaracaoXML: String;
begin
  DeclaracaoXML := ObtemDeclaracaoXML(AXML);

  Result := RetornarConteudoEntre(AXML, '<NFe xmlns', '</NFe>');
  if not EstaVazio(Result) then
    Result := '<NFe xmlns' + Result + '</NFe>'
  else
  begin
    Result := LerTagXML(AXML, 'NFe');
    if not EstaVazio(Result) then
      Result := '<NFe xmlns="' + ACBRNFE_NAMESPACE +'">' + Result + '</NFe>'
  end;

  if not EstaVazio(Result) then
    Result := DeclaracaoXML + Result;
end;
A linha que devemos alterar é a linha:

Result := '<NFe>' + Result + '</NFe>'

o correto é:

Result := '<NFe xmlns="' + ACBRNFE_NAMESPACE +'">' + Result + '</NFe>'

Ok. Muito obrigado pela ajuda.

23 Outubro, 2020

1 hora atrás, Italo Jurisato Junior disse:

Boa tarde Valdir,

Eu não sei como a SEFAZ trabalha.

Se ela disponibiliza o mesmo XML enviado para você realizar o Download ou se ela gera um novo com base nos dados contidos no XML enviado.

Pelo jeito a SEFAZ-MS deve gerar um novo XML, outra coisa que não sei se você notou esse XML que você baixou possui 2 assinaturas.

Uma é do emitente e a outra é da SEFAZ que se encontra dentro do grupo protNFe.

Não sei se são todas, mas existem SEFAZ que ao baixar o XML da nota caso tenha eventos vinculados a mesma como por exemplo carta de correção, o XML referente aos eventos fazem parte do XML da nota, ou seja, um XML só contendo os dados da nota mais os dados dos eventos.

Ok. Entendido.

Só mais uma questão: você poderia me dar uma ajudazinha, rs, em relação ao código para incluir esse namespace no XML antes de validá-lo?

Pelo que você fala, parece ser coisa simples, mas não estou sabendo começar, rs...

Obrigado.

Entrar

Sobre nós...

Blocks

Notes ACBrLibNFe

Fóruns

Downloads

Calendário

Posts postados por Valdir Dill

Sobre nós...

Informação Importante