Valdir Dill

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!

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.

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

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

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

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.

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

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.

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

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...

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.

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.

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

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

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.

Sim.

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.

Ok. Muito obrigado pela ajuda.

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.

Certo, entendi. Então o XML que fica lá na SEFAZ não é o mesmo daquele gerado pelo sistema (via Acbr)? Porque a pergunta? porque antes do nosso sistema enviar o XML é feita a validação dele e valida, tudo certo. Porém, agora, ao tentar fazer a mesma validação, mas no arquivo baixado do portal, dá o erro. Portanto, se antes validade e agora não...me perdoe se estou falando besteira, rs...mas é o que eu entendi da situação.

Mesmo resultado.

LibXML2

Não entendi. Eu estou ciente que uma vírgula que seja alterada no XML vai invalidar o XML todo. Mas não foi esse o caso. Esse XML é um arquivo baixado pelo usuário direto do portal da SEFAZ. Outro ponto, como já mencionei, é que o XML é validado no validador da SEFAZ-RS. Obrigado.

Bom dia, Estou tentando validar o xml anexo com ACBrNFe1.NotasFiscais.Validar... ocorre o erro "...no matching global declarationo available...'' (print em anexo). No validador da SEFAZ-RS não dá nenhum erro. Para adiantar uma possível análise, informe que relatei a situação chat do SAC e tive a resposta: "Big Wings: Testei aqui pelo Notepad++, validando o XML todo contra o schema procNFe_v4.00.xsd ele valida, mas se extrair o grupo <NFe> e validar contra o nfe_v4.00.xsd, que é o que o ACBr faz, causa erro de validação. Acho melhor abrir um tópico no fórum". Alguma sugestão da causa/solução dessa situação? Obrigado. 50201004970863000142550010000110291706594010-NFe.xml

Show de bola! Obrigado a todos pelas dicas!