gobbo

EMBarbosa, bom dia. Concluí equivocadamente que o "assunto" se refletia ao nome do tópico "Alterações Enviadas Por Usuários" e não ao seu "conteúdo" (posts), assim como acontece em vários outros fóruns que participo (eles odeiam que sejam criados novos tópicos com assuntos/títulos semelhantes). Pode ficar tranquilo, não se repetirá mais... Obrigado.

Aos administradores, bom dia. Tenho mais uma alteração a propor: - DANFe em RaveReports => utilizo o Delphi 2005 (delphi 9) com o Rave 7.0 (e não o Rave 6.0). Porém há diretivas de compilação como esta abaixo: ... {$IFDEF VER170} Rave60VCL, {$ENDIF} // D2005 ... e preciso sempre alterar para isso: ... {$IFDEF VER170} Rave70VCL, {$ENDIF} // D2005 ... Como o Delphi 2005 não vem com um RaveReports pré-instalado (temos que comprar os componentes separadamente), vincular a versão do Delphi à versão do Rave me parece sem sentido, pois podemos comprar e instalar qualquer versão do Rave existente no mercado. Alguma sugestão de como implementar isso da forma correta e que atenda a todas versões do Rave para o Delphi 2005? Ou não há outra forma, cada um deve modificar isso de acordo com as suas próprias versões? Seguem os códigos-fontes modificados. Obrigado. ACBrNFe2.zip

OK. Obrigado. Pacotes.zip

Prezados administradores do ACBr, boa tarde. Seguindo a mesma linha deste tópico já aberto, envio em anexo alguns códigos-fonte modificados visando compatibilizar os nomes dos pacotes instalados no Delphi (Descrições dos Pacotes). Estas modificações não alteram em nada o funcionamento do sistema, somente é uma questão "cosmética" para que os usuários do Delphi visualizem os nomes dos pacotes adequadamente e com isso evitar confusões com pacotes já instalados de outros fornecedores. No aguardo dos comentários dos administradores. Obrigado. Pacotes.zip

Correto.

Prezados administradores do ACBr, boa tarde. Segue em anexo alguns códigos-fonte modificados visando atender aos usuários do DELPHI 2005 (ou Delphi 9), que é o meu caso específico. Estas modificações aparentemente não alteram em nada o funcionamento do sistema, somente os deixa compatíveis com esta versão do Delphi 2005, evitando assim que tenhamos que alterá-los para que sejam compilados adequadamente. No aguardo dos comentários dos administradores. Obrigado. ACBrNFe2.zip

Régys, boa tarde. Não não.. me expressei mal... Eu homologuei em 2012 (nesta versão ER 01.11), e como minha homologação continua válida (por 2 anos), continuo precisando usar o layout da ER 01.11. Mas como tive que modificar outras coisas no meu PDV, estamos solicitando somente uma alteração de MD5 na Secretaria de Estado da Fazenda. Mas o nosso aplicativo continua usando ER 01.11 de acordo com o laudo de 2012 (e por isso continuo validando meus arquivos no seu programa selecionando a ER 01.11). Quanto a alteração da geração do registro R05, creio ser indiferente a versão da ER. O problema estava na "formatação" do NUM_CONT, causando a geração de um número errado. Por exemplo: Código-fonte atual: CCF=1 (um) => geração 000100 (cem) Código-fonte corrigido: CCF=1 (um) => geração 000001 (um) Para avaliar ambos os casos, baixe os anexos acima (Testes - Movimento por ECF.zip) e valide-os no seu programa. Você verá os 2 problemas mencionados: - ER 01.11 sendo exigido o valor 0112 (em todos os arquivos); - Registro R05 com o CCF 000100 (cem) ao invés de 000001 (um) comparando com o registro R04 (arquivo "030904000000EMULADOR23072013 - ERRADO - Revision 4886 em diante.txt")

Os arquivos de testes foram verificados com o aplicativo "Visualizador de Arquivos Paf" e gostaria de parabenizar seus idealizadores pela excelente iniciativa. P.S. Ainda estou usando a ER 01.11, homologuei nesta versão e ainda está válida para nossos clientes. O único detalhe nesta aplicação é que ao validar um arquivo 01.11, ele informa uma inconsistência: valor informado 0111, valor esperado 0112 Isso mesmo selecionando o layout 01.11 no "combo box" do aplicativo. Agora sem este aplicativo, nem perceberia este probleminha na geração do "Movimento por ECF".

Régys e Isaque, boa tarde. PROBLEMA NÃO RESOLVIDO... consegui simular novamente o erro que encontrei no final de semana. E já detectei o problema no código-fonte: Atual: LFill( IfThen(NUM_CONT=-1, RegR04.NUM_CONT, NUM_CONT), 6) Proposta para correção: IfThen(NUM_CONT=-1, LFill(RegR04.NUM_CONT, 6), LFill(NUM_CONT, 6)) + Com isso, não interessa como o registro R05 foi abastecido (ou deixado nulo), ele sempre gerará o valor com a formatação correta. Exemplos dos meus testes: CORRETO => Revision 4885 CCF=1 <=> 000001 R05EMULADOR OMP-2100 TH FI 01000005000001001599371... ERRADO => Revision 4886 em diante CCF=1 <=> 000100 R05EMULADOR OMP-2100 TH FI 01000005000100001599371 Seguem em anexo os arquivo de testes gerados e também o código-fonte modificado para análise de uma nova revision. Obrigado. ACBrPAF_R_Class.pas Testes - Movimento por ECF.zip

Régys e Isaque, boa tarde. Testei novamente agora e o problema não aconteceu mais... (deve ter sido falha no meu banco de dados do final de semana). Então, por favor, considerem com assunto encerrado, problema resolvido. Desculpem o transtorno.

Após a revision 4886 (28/02/2013), os registros R05 estão sendo gerados com o número do CCF/CVC/CBP (NUM_CONT) errados. Fonte antigo (revision 4885): funcionando LFill(RegR04.NUM_CONT, 6) Fonte novo (revision 4886 em diante): gerando errado LFill( IfThen(NUM_CONT=-1, RegR04.NUM_CONT, NUM_CONT), 6) Por exemplo, você passa um CCF = 5 e ele gera 000500. Segue a correção com esta linha de código modificada. ACBrPAF_R_Class.pas

Bom dia Isaque. Vi que meus códigos foram analisados e já subiram pro SVN. Obrigado.

Preciso gerar um arquivo com Registros D500 (e filhos) que contém NFs canceladas. Porém, para esse caso (NFs canceladas) o validador EFD Fiscal exigia que alguns campos fossem gerados vazios. Modifiquei então essa geração seguindo a lógica do Registro D100 já existente. Para o meu caso resolveu, acho que serve para os demais casos, certo? ACBrSPEDFiscal.zip

Faltou o anexo... pnfsConversao.pas

Após o update de hoje, o pacote ACBrNFSe não está mais compilando. Segue o código-fonte corrigido.

Obrigado Isaque. Mas ainda não consegui baixar pelo SVN.

Preciso gerar um arquivo no período de 01/01/2011 a 30/04/2013. Porém, para esse período não era gerado o campo MOT_INV e o validador EFD o exigia. => DT_INI >= EncodeDate(2012,07,01) Modifiquei então para que seja considerada a data final: => DT_FIN >= EncodeDate(2012,07,01) Para o meu caso especial resolveu, acho que serve para os demais casos, certo? ACBrEFDBloco_H_Class.pas

Florianópolis tem seu sistema próprio, não compatível com o ACBr. Veja os manuais em: http://www.pmf.sc.gov.br/sites/notaeletronica/index.php?cms=nfps+e+++downloads&menu=5 Já Blumenau tem no ACBr utilizando o provedor GINFES, veja no demo do ACBr. Manual do web service de Blumenau em: http://www.blumenau.sc.gov.br/gxpsites/agxppdwn.aspx?1,1,556,O,P,0,6124%3bP%3b1%3b20, P.S. Blumenau foi incluída na revision 5006 de 21/03/13, assim como várias outras cidades para o provedor GINFES. Somente não está sendo listado no Demo por falta de atualização no mesmo. Confira a função "CodCidadeToProvedor" da unit pnfsConversao.pas

Resolvido: com o update 5218 tudo compilando.

Após o update de hoje, o pacote não está mais compilando, com erro em: ACBrNFSeWebServices.pas function TNFSeEnviarSincrono.Executar: Boolean; ... if FConfiguracoes.WebServices.Salvar then FConfiguracoes.Geral.Save(IntToStr(NumeroRps)+'-env-loteS-c.xml', Texto, FConfiguracoes.Arquivos.GetPathGer); ... [Error] ACBrNFSeWebServices.pas(3425): E2003 Undeclared identifier: 'NumeroRps'

Esse novo arquivo "Dados Técnicos para Geração do Arquivo Eletrônico do Troco Cartão" somente será necessário se: Requisito XIV - Item 4 a1) quando utilizado exclusivamente por estabelecimento enquadrado como minimercado, mercado, supermercado, situado no Estado de Santa Catarina e cuja atividade seja o comércio varejista de mercadorias em geral, com predominância de produtos alimentícios, admite-se, mediante parametrização, inacessível ao usuário, que o valor a ser informado à empresa administradora de cartão de crédito ou débito seja superior em até R$ 10,00 (dez reais), condição em que o PAF-ECF deverá disponibilizar função que permita realizar a gravação de arquivo eletrônico do tipo texto (TXT), em conformidade com o leiaute e com as especificações estabelecidas no Anexo XV, nos seguintes modos: 1) por meio do comando definido no item 25 do requisito VII; 2) automática e imediatamente após a emissão do documento Redução Z. O arquivo deverá conter as informações referentes ao totalizador de troco, sempre que o meio de pagamento for exclusivamente cartão de crédito ou débito e a administradora esteja relacionada no Anexo XV, identificada por seu CNPJ;

PRIORI CONSULTORIA E SISTEMAS LTDA http://www.priori-sc.com.br Fone: (48) 3348-3646 Contato: Vilmar Software: PRIORICFG 1.1 Laudo: UNO0762012 Homologação: 18/05/2012 Publicação DOU: 25/05/2012 http://www.fazenda.gov.br/confaz/Confaz ... 084_12.htm Roteiro de testes: 1.7 Especificações Requisitos: 01.11 Componentes usados do ACBr: ACBrECF, ACBrTEFD, ACBrAAC, ACBrEAD, ACBrPAF, ACBrSintegra, ACBrSpedFiscal, ACBrNFe, ACBrDANFERaveCB.

Os homologadores da Unochapecó estão se baseando no que está escrito na ER, e de fato está escrito assim: requisito IV item 4: "...emitir DAV, impresso no ECF, como Relatório Gerencial, conforme definido no inciso III do art. 1º, observando o requisito VI, exceto quanto: a) ao tamanho mínimo previsto no item 2 do requisito VI; ao modelo estabelecido no Anexo II; c) às expressões previstas na alínea "a" do item 2 do requisito VI." requisito VI item 2: ".... c) a denominação e o CNPJ do estabelecimento emitente, devidamente consistido; ..." Como os dados do emitente está na alínea "c" (a exceção é só para a alínea "a"), então estes dados do emitente devem ser impressos também quando do DAV por ECF. Foi assim que eles "me convenceram".

Realmente eu não sei, filiais talvez??? Mas eu já desisti de discutir com homologadores, eles mandam, nós obedecemos.

Regys, também fiz exatamente este questionamento para a homologadora. Veja as respostas: a) Quanto a obrigatoriedade dos dados do emitente Minha consideração: Caso a impressão do DAV seja feita por ECF, imprimir a denominação e o CNPJ do estabelecimento emitente é redundante, pois quando o DAV é impresso por ECF, esses dados já vem no "cabeçalho fixo" do relatório gerencial, mediante informações gravadas na MF do ECF, sem possibilidade de alteração pelo usuário e/ou programador. Reimprimir no corpo do relatório gerencial novamente os dados do emitente, além de ser redundante, é também "perigoso", pois podemos imprimir qualquer dado, podendo inclusive ser diferente daquele gravado na MF do ECF e abrir possibilidade de "enganar/ludibriar" o consumidor. Resposta da homologadora: Deve compor este campo porque o CNPJ que está no cabeçalho nem sempre será o mesmo CNPJ do estabelecimento. Estamos apenas cobrando das empresas desenvolvedoras o que a ER estabelece. Quanto a concomitância da impressão do DAV: Pelo ECF.Demo, tinha interpretado que a concomitância no DAV deveria ser idêntica a que ocorre para um cupom fiscal: digitação do item => visualização na tela => IMPRESSÃO NO ECF => gravação no bd Mas então a interpretação correta quanto a concomitância no DAV deve ser assim: digitação do item => visualização na tela => gravação no bd Somente depois de todos os itens deste DAV terem sido registrados é que se acionam os métodos de impressão deste DAV por completo no ECF. ...terminei a digitação do DAV, se tudo OK, então: ECF.Dav_Abrir; para cada item faça ECF.DAV_RegistrarItem; ECF.DAV_Fechar; É isso mesmo?