douglas_k

Fiz a atualização pelo SVN e agora esta ok. Obrigado.

Bom dia Daniel, O modelo que estou utilizando para testes é uma Bematech 4200 TH FI II. Em produção peguei o problema em uma EPSON TM-T900F, as duas utilizam o modelo EscEcf para comunicar. Coloquei em anexo o log do acbr das tentativas com duas compilações diferentes do ECFTeste uma com uma versão mais antiga que é retornado as aliquotas e outra dessa ultima versão que tenho problema. Nas duas percebi que o CarregaAliquotas retorna certinho os valores o problema ta mesmo nesse teste que é um pouco abaixo do CarregaAliquotas { Deve desconsiderar alíquotas zeradas e índice FF, II, NN (ECFVirtual) } if (fpAliquotas.Aliquota <= 0) or (not StrIsNumber(fpAliquotas.Indice)) then Continue; Sobre ter alíquotas de ICMS com % 0 não possuo. O fpAliquotas.Indice vem carregado com T01, T02, T03... acbrlog-correto.txt acbrlog-erro.txt

Bom dia Pessoal, Atualizei o ACBr recentemente e no comando DadosReducaoZ parou de retornar os dados da alíquotas do ICMS. O que reparei debugando é que um teste foi alterado na function TACBrECFClass.GetDadosReducaoZ: String; da unit ACBrECFClass. Atualmente: { Deve desconsiderar alíquotas zeradas e índice FF, II, NN (ECFVirtual) } if (fpAliquotas.Aliquota <= 0) or (not StrIsNumber(fpAliquotas.Indice)) then Continue; Versão que possuía anteriormente: { Deve desconsiderar alíquotas zeradas e índice FF, II, NN (ECFVirtual) } if (fpAliquotas.Aliquota <= 0) and (StrIsAlpha(fpAliquotas.Indice)) then Continue; Alguém já teve esse problema? Fiz testes com o ECFTeste com as duas versões. Com a anterior as alíquotas são retornadas e com a versão atual não. Outro problema que estou tendo é para atualizar o ACBr, quando vou fazer um SVN Update retorna erro, conforme a imagem em anexo.

Exato, acredito também que isso deve ser alguma falha nas validações deles. Alguém já teve esse erro retornado? Sobre o outro erro 'Quando situação tributária for não tributado ou isento, alíquota precisa estar em branco', você teve Anderson?

Boa tarde Pessoal, Estou fazendo testes no envio do arquivo de estoques no blocox e me deparei com a seguinte situação: - Gero o xml e faço o envio sem erros, quando vou consultar a situação do recibo é retornado o seguinte erro: 'Certificado digital sem CNPJ ou com diferente do estabelecimento'. Ocorre o seguinte, hoje temos um cliente que tem 1 certificado digital e vários estabelecimentos com CNPJ diferentes, por exemplo, 11.111.111/0000-11, 11.111.111/0000-22, 11.111.111/0000-33, para emissão de NF-e, com o mesmo certificado emitimos notas para todos estabelecimentos, agora para o envio do bloco X esta me retornando esse erro. Se eu alterar as informações do CNPJ do arquivo de estoque na mão, colocando o da matriz ai não ocorre o erro. Será que cada estabelecimento terá que ter seu certificado próprio? O nosso certificado é o A1. Outro retorno de erro que tenho, quando consulto o recibo de envio do arquivo de estoque do bloco x é: 'Quando situação tributária for não tributado ou isento, alíquota precisa estar em branco'. Verificando o xml vi que mesmo quando é isento ele esta indo com alíquota '0,00', na especificação do arquivo comenta que nessa situação deve ir vazio. Obrigado a todos.

Bom dia, Só para conhecimento, não encontrei configuração para alterar essa situação, então utilizei a função RecodeMilliSecond(hora, 0); da unit DateUtils que dessa forma passo como zero o valor dos millisegundos e ajusta meu problema.

Boa tarde Juliomar, Fiz um programa de testes para verificar o caso da gravação dos campos time no postgres utilizando os componentes do Firedac (FDConnection, FDQuery, FDTransaction) e continuou gravando com milissegundos. Fiz o teste passando os dados da seguinte forma FDQuery1.FieldByName('hora').AsDateTime := time; e ele grava no formato '10:17:22.708'. Se eu passar como string FDQuery1.FieldByName('hora').AsString e fazer um FormatDateTime('hh:nn:ss', now); ai ele grava certo. Pelo que vc já comentou não teve esse problema, talvez saiba como contornar isso, talvez tenha alguma configuração que eu ainda não tenha encontrado nos componentes Firedac. Desde já agradeço.

atualizei e testei, agora esta correto

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.