douglas_k

certo..

Bom dia, Existem mais registros com o mesmo problema. O C2, por exemplo: C2034706260015552017010605471214 3 7 DIESEL 20170106054712000000419.78208000000419.83370EMITIDOCFNBE091110100011238481201701060501450005325420563390000051620 o P o A tambem... A220170106Dinheiro 1000001.70614

certo, mais tem a possibilidade de trabalhar apenas substituindo SQLConnection e SQLDataSet pelos FDConnection e FDQuery, assim mantendo a estrutura que já vinha sendo usado com dbExpress. Quais componentes você utiliza do FireDac?

Boa tarde Pessoal. Até então utilizamos o DBExpress para conexão com banco de dados e utilizamos os componentes SQLConnection + SQLDataSet + DataSetProvider + ClientDataSet. Agora resolvemos trocar o DBExpress para o Firedac que já tem conexão nativa com o postgres não precisando mais usar o ODBC. Conseguimos trabalhar apenas trocando os componentes SQLConnection por FDConnection1 e o SQLDataSet pelo FDQuery, mantendo todo o resto, sem fazer praticamente nenhuma alteração. Agora encontramos um problema que talvez alguém já tenha passado ou tenha alguma dica. Toda vez que vou salvar alguma informações na base de dados que se refira a um campo hora, por exemplo, ClientDataSet.FieldByName('hor_abastecida_poabas').AsDateTime := now; ele sempre esta gravando com os milissegundos juntos, '16:37:40.413' e não gostaria que ele fizesse assim e apenas até os segundos '16:37:40'. Tem alguma forma de configurar isso no Firedac? No DBExpress salvava da forma correta.

Bom dia EMBarbosa, Realmente, fiz testes passando o caminho relativo e funcionou corretamente. Deixei com as 40 posições mesmo na procedure. Muito obrigado.

Bom dia Pessoal, No momento que vou incluir os arquivos que fazem parte do nosso PAF-ECF no arquivo auxiliar criptografado ACBrAAC.IdentPAF.OutrosArquivos quando eu faço um add(caminho); verifiquei que em alguns casos ele estava cortando parte do nome e assim não calculava o MD5 desse arquivo. Olhando os fontes vi que na procedure TACBrECFArquivo.SetNome(const AValue : String) ; da unit ACBrPAFClass ele limita o nome do arquivo para 40 posições. Não sei o porque desse limite, talvez tenha algum motivo. Tem possibilidade de aumentar esse tamanho? Até mais.

uhum, verdade. Bom como realmente na ER não trata isso, ajustei apenas no meu PDV para tratar isso da forma que o homologador fez no teste, mesmo que isso não seja cobrado pela ER, o ACBr realmente faz da forma como a ER determina, validando na abertura do cupom fiscal e atualizando a cada vende item. Ultima pergunta só para tirar uma duvida, quando os valores do GT ou numero de série não estão iguais entre o arquivo auxiliar criptografado e a ECF, no caso do operador enviar o comando para emissão de uma leitura x, em seu software vc permite a emissão, ou bloqueia dando erro que os dados não conferem?

Realmente na ER não fala sobre a questão de registro de item, no item 4 ele se atém apenas Ao ser inicializado, ao viabilizar o acesso à tela de registro de venda e ao enviar ao ECF comando para abertura de documento fiscal. Em anexo mandei o roteiro onde existe um teste com registro de item, o teste 78. De qualquer forma a ER não trata esse ponto no registro de item, só comenta no item 6 que caso não haja coincidência na comparação descrita no item 4 deste requisito e não havendo perda de dados gravados no arquivo auxiliar criptografado, impedir o seu próprio funcionamento, exceto para as funções descritas no item 1 do Requisito XIX. Ai sim teria que bloquear qualquer operação de impressão na ECF se essa comparação entre série e GT da ECF com o arquivo auxiliar criptografado não esteja ok. Roteiro de Análise Funcional PAF-ECF ER 02.04 - LTS Versão 1.0.pdf

Foi alterado direto no arquivo auxiliar criptografado. No requisito XXIV que ele trata isso. Foi alterado para um GT diferente do da ECF e então foi tentado fazer a venda de um item.

Bom dia, EMBarbosa, Eu tenho o AAC ligado com o ACBrECF, ele compõe corretamente o valor da GT e tudo. A necessidade surgiu pelo fato de na homologação haver um teste onde foi aberto um cupom fiscal e vendido um item, depois disso foi pegado e alterado o valor do GT no arquivo AAC e o homologador pediu para vender outro item. O que ocorreu foi que ele primeiro mandou o comando de venda de item para a ECF e só depois ele retornou um exception informando que o GT não estava batendo com o arquivo, ai acabou fazendo errado. Como tivemos que bloquear todas as operações que fazem alguma impressão na ECF como, por exemplo, leitura x, sangria, suprimento...nos casos que é verificado diferença do numero de série e do GT com o arquivo AAC, eu coloquei para antes de fazer esses comandos ele verificar o ACC forçando dessa forma.. ACBrECF.DoVerificaValorGT. Vou verificar se no ECFTeste consigo reproduzir o erro.

Boa tarde, Pessoal. Gostaria de tirar uma dúvida com vcs se talvez trataram diferente ou se isso realmente é um erro. Quando altero o numero de série ou o GT do AAC e tendo fazer uma ACBrECF.AbreCupom(); beleza, o bloqueio é feito correto, sendo o erro exibido e o cupom não é aberto. No caso haver perda no vende item ou no cancelamento de um cupom por exemplo, ele esta fazendo a validação do AAC depois de enviar o comando para a ECF. No caso do ACBrECF.VendeItem, por exemplo, abaixo o trexo de código da procedure begin AliquotaECF := ''; IniciaVendeItem(Codigo, Descricao, AliquotaICMS, AliquotaECF, Qtd, ValorUnitario, ValorDescontoAcrescimo, Unidade, TipoDescontoAcrescimo, DescontoAcrescimo, CodDepartamento); try Tratado := False; fsECF.VendeItem( Codigo, CodificarPaginaDeCodigoECF( Descricao ), AliquotaECF, Qtd, ValorUnitario, ValorDescontoAcrescimo, Unidade, TipoDescontoAcrescimo, DescontoAcrescimo, CodDepartamento ); except if Assigned( FOnErrorVendeItem ) then FOnErrorVendeItem(Tratado); if not Tratado then raise; end; FinalizaVendeItem(Codigo, Descricao, AliquotaICMS, AliquotaECF, Qtd, ValorUnitario, ValorDescontoAcrescimo, Unidade, TipoDescontoAcrescimo, DescontoAcrescimo); end; A verificação do AAC é feito dentro do finalizaVendeItem, nesse caso o comando já foi enviado para a ECF algumas linhas acima no comando fsECF.VendeItem. Acredito que teria que ter um DoVerificaValorGT ; antes de enviar o comando de venda de item para a ECF. Talvez esse tratamento deve ser efetuado de outra maneira e não estou fazendo, por isso levanto essa duvida. Até mais.

Bom dia Pessoal, Usamos os componentes ACBr a muito tempo já. Havíamos homologado o PAF-ECF desenvolvido em COBOL utilizando o ACBrMonitor por duas vezes. Depois disso redesenvolvemos todo o PDV utilizando Delphi e ontem pela segunda vez conseguimos efetuar a homologação do PDV desenvolvido nessa IDE. Hoje pensei em colocar aqui esse pequeno depoimento sobre a imensa ajuda que esses componentes nos proporcionam, facilitando e muito a vida de nós programadores e dando uma flexibilidade enorme para usar diversas ECFs, balanças, TEF e por ai vai. Só temos que agradecer e contribuir para que a comunidade se fortaleça cada vez mais e que possamos ter melhores produtos para atender nossos clientes. Homologamos na Unochapeco em Chapecó-SC e o nome do nosso Software é G3 PDV. Atendemos a ER 02.04, tendo DAV, Pré-Venda e aplicação especial para posto de combustível. Componentes ACBr utilizados..: ACBrECF, ACBrAAC, ACBrEAD, ACBrPAF, ACBrValidador, ACBrExtenso, ACBrNFe, ACBrECFVirtualNFCe, ACBrECFVirtualNaoFiscal, ACBrNfeDanfeEscPos, ACBrNFeDANFeESCPOS, ACBrNFeDANFCeFortes, ACBrNFeDANFCeFortesA4, ACBrNFeDANFEFR, ACBrMail, ACBrBAL, ACBrPosPrinter, ACBrBlocoX, ACBrNFeDANFeRL, ACBrTEFD

uhum, obrigado.

Bom dia, Pessoal. No requisito XII item 1. O PAF-ECF deve comandar automaticamente a emissão pelo ECF da Leitura da Memória Fiscal, contendo os dados relativos ao mês imediatamente anterior, quando da emissão da primeira Redução Z de cada mês, exceto no caso de ECF cujo software básico execute esta função. Minha duvida seria o seguinte, tem como identificar pela a ECF se o software básico executa essa função automaticamente, para assim saber quando preciso fazer pelo próprio PDV? Desde já agradeço.

Realmente estranho, eu já consegui efetuar o envio do bloco x estoque normalmente, mais de um momento para cá parou de funcionar, provavelmente algo no próprio web services, não me preocupei mais com isso pelo fato da homologadora não cobrar o envio.

Bom dia... O pessoal da nossa homologação na Unochapecó em Santa Catarina não irá cobrar o envio do bloco x, pelo fato desses webservices não serem de produção. Apenas será cobrado a geração dos arquivos e as mensagens de pendência de envio. No meu caso eu fiz testes de envio e realmente o arquivo da redução z vai sem problema ja o de estoques retorna o mesmo erro que pra você.

Show de bola, fiz os testes e esta ok. Obrigado.

Boa tarde Pessoal. Hoje na procedure TPAF_C.WriteRegistroC2 ele faz os seguintes testes para inserir no arquivo dos registros do PAF-ECF os dados dos abastecimentos C2. IfThen(STATUS_ABASTECIMENTO = 'EMITIDO CF', RFill(NRO_SERIE_ECF, 20), RFill('',20)) + IfThen(STATUS_ABASTECIMENTO = 'EMITIDO CF', LFill(DATA, 'yyyymmdd'), RFill('',8)) + IfThen(STATUS_ABASTECIMENTO = 'EMITIDO CF', LFill(HORA, 'hhmmss'), RFill('',6)) + A questão é que na nova ER 02.04 essas descrições de status_abastecimento mudaram para EMITIDO CFN, EMITIDO CFM , EMITIDO CFA, EMITIDO CFC , conforme requisito XXXVII, e dessa forma com os testes acima essas informações nunca irão, pelo fato de não existir mais esse status 'emitido CF'. Olhando no layout do arquivo o campo status do abastecimento possui apenas 10 casas mais como da para ver as descrições 'EMITIDO CFN' possui 11, dessa forma o homologador nos sugeriu tirar o espaço em branco, tratando assim como 'EMITIDOCFN', 'EMITIDOCFM' , 'EMITIDOCFA', 'EMITIDOCFC'. Fiz a correção das linhas acima fazendo com que as informações de data, hora e série sempre irão quando os status de abastecimentos são IfThen(((STATUS_ABASTECIMENTO = 'EMITIDOCFN') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFM') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFA') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFC')), RFill(NRO_SERIE_ECF, 20), RFill('',20)) + IfThen(((STATUS_ABASTECIMENTO = 'EMITIDOCFN') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFM') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFA') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFC')), LFill(DATA, 'yyyymmdd'), LFill(0,8)) + IfThen(((STATUS_ABASTECIMENTO = 'EMITIDOCFN') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFM') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFA') OR (STATUS_ABASTECIMENTO = 'EMITIDOCFC')), LFill(HORA, 'hhmmss'), LFill(0,6)) + Outra questão é que quando não tiver valor para data e hora ao invés de ficar vazio deve ser preencher com zeros o conteudo. Não sei se ficou claro, também não sei como faríamos para manter a compatibilidade com as versões compiladas para outras ERs, mais ajustei o fonte e estou anexando como sugestão. ACBrPAF_C_Class.pas

Esta sim Juliomar, nesse link https://www.confaz.fazenda.gov.br/legislacao/despacho/2016/dp154_16 é possível verificar que o campo quantidade esta com duas casas decimais tanto no arquivo de redução z como no de estoque. Eu tentei fazer o envio e validação com 3 casas e retornava rejeição, depois que ajustei para 2 foi tranquilo.

Bom dia, Tive que fazer a mesma alteração no elemento quantidade do arquivo de estoques também, onde passei o formatfloat de 3 para 2 casas decimais. Em anexo o .pas. Quanto ao tratamento do retorno do envio dos arquivos para capturar o Recibo, não sei se esta seria a melhor forma mais vou compartilhar a solução que encontrei. Primeiro o envio.. ACBrBlocoX.WebServices.EnviarBlocoX.XML := ACBrBlocoX.Estoque.XMLAssinado; ACBrBlocoX.WebServices.ValidarBlocoX.ValidarEcf := True; ACBrBlocoX.WebServices.ValidarBlocoX.ValidarPafEcf := True; ACBrBlocoX.WebServices.EnviarBlocoX.Executar; Depois para pegar o retorno.. vXMLDoc := TXMLDocument.Create(self); vXMLDoc.LoadFromXML(StringReplace( StringReplace(ACBrBlocoX.WebServices.EnviarBlocoX.RetWS, '<EnviarResult>', '', [rfReplaceAll, rfIgnoreCase]), '</EnviarResult>', '', [rfReplaceAll, rfIgnoreCase])); With vXMLDoc.DocumentElement do begin codigoRetorno := ChildNodes['Codigo'].text; reciboRetorno := ChildNodes['Recibo'].text; mensagemRetorno := ChildNodes['Mensagem'].text; end; ai é só trabalhar com as variáveis codigoRetorno, reciboRetorno e mensagemRetorno. É necessário declarar vXMLDoc: TXMLDocument; e NodeRec: IXMLNode; Até mais. ACBrBlocoX_Estoque.pas

Em anexo arquivo modificado. ACBrBlocoX_ReducaoZ.pas

Boa tarde Pessoal. Estive fazendo testes para o envio do 'Arquivo com Informações da Redução Z do PAF-ECF' presente no BlocoX. Nos testes que efetuei o arquivo estava retornando erro na validação 'Erro na validação do schema: O elemento 'Quantidade' é inválido'. Verifiquei que no layout do arquivo consta 2 decimais para o campo quantidade e o componente estava gerando com 3. No arquivo ACBrBlocoX_ReducaoZ na procedure TACBrBlocoX_ReducaoZ.GerarXML(const Assinar: Boolean); alterei a linha FGerador.wCampo(tcStr, '', 'Quantidade', 0, 0, 1, FormatFloat('0.000',Produtos[X].Quantidade)); para FGerador.wCampo(tcStr, '', 'Quantidade', 0, 0, 1, FormatFloat('0.00',Produtos[X].Quantidade)); Com essa modificação o problema foi resolvido. Outra questão é a seguinte, estou conseguindo efetuar a validação e o envio do arquivo com o código abaixo: ACBrBlocoX.WebServices.EnviarBlocoX.XML := ACBrBlocoX.ReducoesZ.XMLAssinado; ACBrBlocoX.WebServices.ValidarBlocoX.ValidarEcf := False; ACBrBlocoX.WebServices.ValidarBlocoX.ValidarPafEcf := False; ACBrBlocoX.WebServices.EnviarBlocoX.Executar; showmessage(ACBrBlocoX.WebServices.EnviarBlocoX.RetWS); A duvida seria, tem algo pronto para extrair o Recibo desse retorno? Desde já agradeço.

Bom dia joaoelson, Obrigado mais uma vez pela ajuda, fico feliz por sempre ter alguém disposto a ajudar, agregando conhecimento ao fórum. Esse erro ocorre pelo fato de na sua maquina não ter configurado uma conexão ODBC com o nome 'Supervisor' que é passado por parâmetro na conexão. Até ai tudo bem, não seria esse o problema, eu fiz esse programa de exemplo pra realmente dar erro ao tentar efetuar a conexão pelo ODBC. Eu estou conseguindo trabalhar tranquilamente com o DBExpress conectando ODBC no Postgres, a questão é quando por alguma situação meu aplicativo não consegue conexão com o BD. Digamos que por algum fator caiu a rede, ou foi configurado incorretamente o ODBC, ou como no exemplo que vc executou na sua maquina nem exista a conexão criada. Nesse momento quando é efetuado o fechamento do aplicativo é retornado o seguinte erro -> Esse seria o problema, sempre que por algum motivo dar erro de conexão entre meu aplicativo utilizando DBExpress conectando no ODBC, ao fechar ele o erro acima é retornado. As vezes é Runtime error 217 também. Se durante a execução do programa não ocorrer erro de conexão, ao fechar ele também não ocorre o runtime error. Faz esse teste joaoelson, executa o programa e depois fecha ele, 1 ..2 vezes, veja se não vai retornar o runtime error. Realmente já estamos estudando a troca entre o DBExpress e o FireDac, o problema agora é o tempo pra rever tudo que já esta funcionando.

Bom dia joaoelson, Na verdade ainda to peleando nesse problema. Tentei ver essa questão das dlls registrando e colocando no projeto as existentes da versão do Delphi que estou utilizando mais a principio ainda não resolveu. Provável que estou esquecendo algo, deixando passar algo despercebido. Também segui as dicas de outro post no site http://www.activedelphi.com.br/forum/viewtopic.php?t=92390&sid=07dd1b1dc70c28984cc32b440d368603 que até se encaixava na minha situação já que eu tinha o Delphi XE3 e o XE10 Seattle na mesma maquina mais também não resolveu. Mais vamos lá, procurando a solução. Assim que conseguir posto ela aqui. Obrigado pela colaboração. Anexei junto com o post um projeto que no FormActivate tenta conectar na BD pelo ODBC. Se vcs utilizam o Delphi XE 10, por exemplo, só compilam e executem o projeto e vejam se ao fechar o form ele vai retornar erro. Projeto.zip

ainda não consegui encontrar o problema, qualquer ajuda é bem vinda..