JLuis

Isaque, obrigado pelo retorno e atenção. Foi de grande ajuda. Abraço.

Estou sendo questionado por um contador que importa o arquivo SPED em seu sistema contábil sobre a estrutura do arquivo especificamente em relação ao registro 0220 (fatores de conversão) pois segundo ele está tendo problemas para validar as quantidades compradas/vendidas que constam nos registros C170 em relação ao inventário (bloco H). Atualmente, o arquivo é gerado com todos os registros 0200 e na sequência todos os 0220, porém, como o 0220 é "filho" do 0200, estão me solicitando para que o 0220 seja gerado no TXT na sequência do 0200, ou seja, se o item no 0200 utiliza uma fator de conversão então, o 0220 deveria vir na sequência com o respectivo fator de conversão! Algo que me chamou a atenção e que é argumento do contador é que no PVA, caso o registro 0220 não esteja na sequência do 0200, após importar o arquivo ao consultar o 0200 o PVA não mostra nada na grade de visualização dos fatores de conversão do item selecionado (Guia Escrituração....Tabelas do Contribuinte... Item/Produtos....Fatores de Conversão de Unidades), somente ao posicionar no último item é que todos os fatores de conversão são exibidos na grade de baixo.. Minha indagação é se esta solicitação faz algum sentido, se há algo de errado com a geração e se é possível gerar da forma solicitada. Desde já agradeço.

Bom dia Juliana, Tenho mais uma pequena contribuição para subir para o SVN... Para o Banrisul, adicionei a possibilidade de envio da instrução 16 "Alteração do numero de dias para protesto" que não estava contemplada. As alterações são mínimas nas duas units em anexo. Mais uma vez agradeço. Att. ACBrBancoBanrisul.pas ACBrBoleto.pas

Olá Juliana, obrigado pela atenção, ... só acho que houve algum problema no seu "merge", no fonte que eu anexei eu havia organizado os códigos de retorno dentro do [...] segundo o índice da estrutura case mas como vc. ordenou-os alfabeticamente dentro do conjunto de valores testado pela função AnsiIndexStr, a partir do "B9" o índice de todas as mensagens a seguir não bate com a posição dos respectivos códigos dentro do conjunto [..]! O "B9" inclusive eu havia acrescentado porque não estava sendo testado pelo case. Para ser mais claro estou anexando uma imagem demonstrando um exemplo com o C4, C7 e C8 que estão nas posições 9, 10, 11 respectivamente dentro do conjunto e ficaram nas posições 48,49 e 50 do case.... Assim, o sistema sempre apresentará a mensagem errada não condizente com o código retornado pelo banco!! No fonte que eu anexei no primeiro post eu havia organizado isso inclusive acrescentei a mensagem do "B9" que não estava na lista. Com toRetornoInstrucaoRejeitada: //32 a partir da linha 1092 ocorreu o mesmo problema. Peço-lhe por gentileza verificar, se precisar de ajuda estou à disposição ok Obrigado. Juliana, Para ajudar, refiz os ajustes ref. aos problemas relatados no post anterior porém, sem reordenar os códigos dentro do conjunto [...], acho que mexer nisso só vai dar mais confusão, melhor manter na ordem que os códigos vinham sendo acrescentados. É importante destacar que sempre deve-se acrescentar ao final do conjunto para não bagunçar os testes do case em relação aos respectivos códigos de cada mensagem ok Permaneço à disposição. Att. ACBrBancoSicredi.pas

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