JLuis

Juliana Tamizou, peço por gentileza subir para o SVN o fonte em anexo no qual fiz alguns ajustes cfe. descrito abaixo 1) Correção TipoOcorrencia toRetornoRegistroRecusado: //03, linha 820 da function TACBrBancoSicredi.CodMotivoRejeicaoToDescricao() O CodMotivo 'C5' que no conjunto do AnsiIndexStr está na posição 9, estava no result da posição 46 do case. 1.1) Códigos de motivo adicionados: 'C4', 'C7', 'C8' e 'C9' 2) Correção TipoOcorrencia toRetornoBaixaRejeitada: //27 Os códigos de motivo 'C5', 'C7' também estavam com o Result invertido. No "else", a linha: case StrToInt(CodMotivo) of foi substituida por: case StrToIntDef(CodMotivo,-1) of pois já ocorreu um caso em que retornou código que não consta no manual do Sicredi, com esta alteração caso retorne um código diferente entra como "Outros Motivos". 3) TipoOcorrencia toRetornoInstrucaoRejeitada: //32 3.1) Código 'C4' não previsto no Result 3.2) Código 'C5' o Result estava no índice errado. 3.3) Códigos de motivo adicionados: 'I9', 'K9', 'A3', 'C8', 'C9', 'J3' e 'D1' * Os ajustes e códigos adicionados foram apurados em casos de erros ocorridos na leitura do retorno. Desde já agradeço. ACBrBancoSicredi.pas

Bom dia Juliana, Atualizei os fontes agora pela manhã e tive que resolver alguns conflitos em razão de que precisei adicionar tratamento para alguns códigos de retorno (rejeição no C400) que constam no manual do Sicredi porém não eram tratados. Venho mantendo esta versão em paralelo já há algum tempo pois já tentei enviar os fontes para alguém subir pro SVN porém não fui atendido. Mas, no caso de hoje verifiquei que foi adicionado tratamento para o código "C5" (eu já tinha ele na minha versão) só que pelo que verifiquei não está correta a posição do código na estrutura case com a sua posição no set [] de elementos. Pois bem, resolvi os meus conflitos e também corrigi a posição do elemento adicionado por vocês e estou anexando a Unit ajustada também com o tratamento para outros códigos de retorno que precisei adicionar já há algum tempo. Se puderes verificar e subir pro SVN fico grato pois não precisaria mais manter uma versão paralela desta unit. Outra questão importante, seria a de adicionar os novos códigos tratados sempre no final do conjunto, isso facilitaria a manutenção para quem precisa manter uma versão paralela. Desde já agradeço. ACBrBancoSicredi.pas

Bom dia, Resolvi da seguinte forma: if (dt >= StrToDate('03/11/2015')) or (dmACBr.NFe.Configuracoes.WebServices.Ambiente = taHomologacao) then dmACBr.NFe.Configuracoes.Geral.IncluirQRCodeXMLNFCe := True else dmACBr.NFe.Configuracoes.Geral.IncluirQRCodeXMLNFCe := False;

Bom dia, Digamos que mesmo não tendo problemas técnicos para o envio da NFC-e, por algum motivo a nota é rejeitada e o objetivo seria corrigir o problema, gerar o XML novamente e enviar.... pergunto: No caso de passar mais de 5 minutos esta NF deverá sempre ser emitida com tpEmis=9 ou seja, em contingência, ou ao gerar novamente o XML posso gerar com a data e hora atuais?? Desde já agradeço.

Boa tarde, Estamos aparentemente com o mesmo problema em produção, pelo menos a msg. de erro é a mesma cStat = 225, Rejeicao: Falha no Schema XML do lote de NFe. Quanto a tag tPag estamos enviando apenas <pag> <tPag>01</tPag> <vPag>48.55</vPag> </pag> Já removi totalmente esta tag mas o problema continua. No ambiente de homologação está ok. Alguém te alguma tem alguma ideia do que pode estar ocorrendo no ambiente de produção? Obrigado

Olá... Atualizei o ACBr a poucos minutos e estão ocorrendo erros em relação as variáveis "i" e "sDoc" na unit pcnEnvEventoNFe. Pelo que vi fazendo um diff com a versão anterior, foi feito o desmembramento de uma porção de código da função TEventoNFe.GerarXML para criação da procedure GerarDestNFe , porém, não foi dado tratamento a estas variáveis que eram locais na função citada. Desde já agradeço. Resolvido... atualizei novamente, compilando sem erros. Obrigado.

Bom dia Daniel, Resolvido, foi só setar a propriedade "Configuracoes.Arquivos.EmissaoPathNFe" com "True". Com isso a função "NotaFiscal.CalcularPathArquivo" passou a tomar como base a data de emissão para calcular o caminho e não a data atual, gravando o XML na pasta correta. Obrigado.

Olá Daniel, Vou tentar ser mais claro então.... O fato: Notas geradas em 31/08 e portanto com data de emissão = 31/08 foram enviadas/autorizadas somente hoje e, os arquivos XML foram criados na pasta mensal 201509/NFe e não na pasta mensal 201508/NFe e portanto, na separação "por mês de emissão" tenho notas de agosto na pasta de setembro ok Então, a dúvida é se isso pode ser algum problema em relação ao trunk2 que será corrigido ou se este comportamento do componente é o correto e daí então eu irei tratar no meu sistema esta situação. Obrigado.

Boa tarde, Atualizei para o trunk2 e me deparei com a seguinte situação...: Um de meus clientes realizou a geração de algumas notas no dia 31/08, porém, só enviou para a sefaz no dia de hoje (02/09) sendo que as mesmas foram autorizadas normalmente, porém, os arquivos XMLs foram criados na pasta mensal 201509 e não na pasta 201508, ou seja, está direcionando para a pasta com base na data de autorização e não de emissão. A chave da NF-e está sendo montada corretamente com base na emissão da nota (ex.: 431508....) porém o arquivo é criado na pasta 201509. Isso está me causando problema no caso da reimpressão do DANFE uma vez que minha rotina toma como base a data de emissão para localizar o XML. Gostaria de saber se este é o comportamento padrão do ACBr pois neste caso terei que contornar o problema de outra forma. Obrigado.

Instalação OK Obrigado Isaque.

Estou com o mesmo problema... parece que é decorrente dos fontes do SPEDECF comitados hoje. Tentei remover a pasta ..\Fontes\ACBrTXT\ACBrSPED\ACBrSPEDECF porém há outras dependências e não compila.

Boa tarde, Atualizei os fontes novamente e instalou... tudo certo. Obrigado.

Bom dia, Estou com o mesmo problema no Delphi XE Abaixo trecho do log de instalação: Embarcadero Delphi for Win32 compiler version 22.0 Copyright (c) 1983,2010 Embarcadero Technologies, Inc. C:\Componentes\ACBr\Fontes\ACBrDFe\ACBrCTe\PCNCTe\pcteRetDistDFeInt.pas(532) Error: E2003 Undeclared identifier: 'ENCODING_UTF8' C:\Componentes\ACBr\Fontes\ACBrDFe\ACBrCTe\PCNCTe\pcteRetDistDFeInt.pas(532) Error: E2250 There is no overloaded version of 'Pos' that can be called with these arguments C:\Componentes\ACBr\Fontes\ACBrDFe\ACBrCTe\PCNCTe\pcteRetDistDFeInt.pas(568) Error: E2250 There is no overloaded version of 'Pos' that can be called with these arguments C:\Componentes\ACBr\Fontes\ACBrDFe\ACBrCTe\ACBrCTeWebServices.pas(1950) Fatal: F2063 Could not compile used unit 'pcteRetDistDFeInt.pas' Compilation failure

Precisei fazer algumas alterações e estou anexando os fontes para análise e posterior commit no SVN, cfe. segue: Banrisul CNAB 400: * Possibilitar gerar instrução 16 para postergar o prazo de protesto * Possibilitar informar o número de dias para cobrança de multa (estava fixo '00') Fontes alterados: ACBrBoleto.pas e ACBrBancoBanrisul.pas Sicredi: * Tratamento para códigos de rejeição não tratados até então e que geravam erro de conversão para inteiro quando da carga do arquivo de retorno. Rotina: CodMotivoRejeicaoToDescricao() Fonte alterado: ACBrBancoSicredi.pas Peço por gentileza alguém revisar e subir as alterações para o SVN. Obrigado ACBrBoleto.pas ACBrBancoBanrisul.pas ACBrBancoSicredi.pas ACBrBoleto.pas ACBrBancoBanrisul.pas ACBrBancoSicredi.pas

Novamente tive problemas com o retorno do Sicredi em relação ao código de rejeição "C5", já havia feito alguns ajustes e postado anteriormente e precisei alterar novamente. O problema é o mesmo citado no post anterior porém em outra parte do código onde também são tratados os motivos de rejeição. Em anexo a unit atualizada a qual peço a gentileza de alguém atualizar no SVN. Obrigado. ACBrBancoSicredi.pas

Valeu! Obrigado.

Ao carregar o retorno do sicredi está ocorrendo um erro de conversão para inteiro em função de não estar sendo previsto o motivo de rejeição de baixa "C5", conforme corrigido no código abaixo: Linhas 941 a 959: toRetornoBaixaRejeitada: //27 case AnsiIndexStr(CodMotivo,['A1', 'C5', 'C6', 'C7']) of 0: Result:= 'A1-Praça do sacado não cadastrada'; 1: Result:= 'C5-Título rejeitado pela centralizadora'; 2: Result:= 'C6-Título já liquidado'; 3: Result:= 'C7-Título já baixado'; else case StrToInt(CodMotivo) of // << Linha onde ocorria o erro 00: Result:= '00-Ocorrência aceita, baixa rejeitada'; 07: Result:= '07-Agência\Conta\dígito inválidos'; 08: Result:= '08-Nosso número inválido'; 10: Result:= '10-Carteira inválida'; 15: Result:= '15-Agência\Carteira\Conta\nosso número inválidos'; 40: Result:= '40-Título com ordem de protesto emitida'; 60: Result:= '60-Movimento para título não cadastrado'; else Result:= padR(CodMotivo,2,'0') +' - Outros Motivos'; end; end; A correção foi simples mas o que me preocupa é que pelo manual CNAB400 do Sicredi há outros motivos cujo código possui letras que não estão sendo tratados e que no momento em que ocorrerem resultará no mesmo problema! Estou anexando o fonte para atualização no SVN Obrigado. ACBrBancoSicredi.pas

Bom dia, Tive o mesmo problema e consegui resolver utilizando os fontes anexados pelo Rafael no post anterior o qual fez pequenos ajustes na largura de algumas colunas (poucos milímetros) liberando espaço suficiente para impressão da "unidade" com até 6 caracteres resolvendo o caso. Seria interessante que alguém atualizasse os fontes no SVN. Desde já agradeço.

Seguem os arquivos. Tal como caso anterior as alterações são apenas no .dfm Att. ACBrBoletoFCQuickFr.zip

Bom dia Juliomar, Ao atender a solicitação de um cliente para a impressão com comprovante de entrega verifiquei que o LayOutPadraoEntrega e também BoletoCarne estão com os mesmos problemas do outro layout que vc. corrigiu (label do Local de pagamento com AutoSize=False e imagem da logo com Stretch=False), é só setar estas propriedades para true em ambos os layouts. Se possível, avalie também a possibilidade de também deixar como padrão a propriedade "PreviewInitialState = wsMaximized" para evitar que o usuário tenha que maximizar a tela de preview toda vez ok. Mais uma vez obrigado.

Fontes alterados em anexo. Lembrando que a alteração foi só no .dfm conforme proporiedades e objetos citados acima. Outra propriedade que poderia contribuir para uma maior praticidade seria a "PreviewInitialState = wsMaximized" para que o preview de impressão já seja exibido em tela cheia, mas aí já é uma questão de preferência. Se vc. puder alterar... Obrigado. ACBrBoletoFCQuick.zip

Precisei fazer alguns ajustes na impressão via QuickReport (LayoutBoleto) como segue: >> Em relação ao local de pagamento, no recibo do sacado está cortando parte do texto. O motivo é que o objeto lblLocalPagto está com AutoSize=False e precisei setar para True. Na Ficha de Compensação está ok. >> No logo da ficha de compensação não está redimensionando a imagem caso a imagem não tenha o tamanho exato do objeto imgBanco3 que está com Stretch=False e também tive que setar para True. No recibo do sacado está ok. Em anexo imagem demonstrando o problema. Alguém por gentileza poderia ajustar e subir pro SVN ? Desde já agradeço.

Resolvido, o problema estava no software Safesign que estava desatualizado... baixei versão atualizada do site da Serasa e resolveu.... fica a dica. De qualquer forma obrigado pelo retorno.

Boa tarde, Estou com este mesmo problema e gostaria de saber se alguém conseguiu solução !!! Toda a instalação parece estar correta porém ao informar a senha é como se não tivesse informado nada, fica pedindo a senha e não dá erro algum independente da senha que informar... a senha está correta, fiz a instalação pelo assistente da Serasa e no assistente do certificado o mesmo aparece como "operacional" e "não bloqueado", PIN Ok e PUK Ok. O cliente está usando W7 64bits e leitora de cartão Perto (CCID). Poderia ser algum problema no cartão? Alguém já chegou a alguma conclusão sobre este problema? Obrigado.

Estou com problema no envio de notas em lotes em que clientes estão reclamando que a identificação do destinatário no canhoto difere do destinatário da NF-e. Verifiquei que ocorre de sair o mesmo destinatário no canhoto de várias notas de um mesmo lote. Ao reimprimir o DANFE um a um sai certo. Uso o DanfeRaveCB e já revisei meu código várias vezes em busca de algum problema na minha rotina e a princípio está tudo certo, principalmente pelo fato de que é uma rotina em uso a bastante tempo e de uns 60 dias para cá passou a ocorrer este problema. Antes de imprimir verifico cada nota do lote e testo se foi confirmada e então monto o texto do canhoto da seguinte forma: NFePrinc.DANFE.ExibirResumoCanhoto := True; for i:= 0 to NFePrinc.NotasFiscais.Count-1 do begin if NFePrinc.NotasFiscais.Items.Confirmada then begin NFePrinc.NotasFiscais.Items.SaveToFile(); NFePrinc.DANFE.ExibirResumoCanhoto_Texto := 'Emissão: '+DFeUtil.FormatDate(DateToStr(NFePrinc.NotasFiscais.Items.NFe.Ide.dEmi))+ ' Dest/Reme: '+Trim(NFePrinc.NotasFiscais.Items.NFe.Dest.XNome)+ ' Valor Total: '+DFeUtil.FormatFloat(NFePrinc.NotasFiscais.Items.NFe.Total.ICMSTot.VNF) Application.ProcessMessages; // << Acrescentei na última tentativa de resolver o problema mas não surtiu efeito ... NFePrinc.NotasFiscais.Items.Imprimir(); end; end; Alguém já teve problema parecido? Teria alguma sugestão?