douglas_k

Membros
  • Total de ítens

    83
  • Registro em

  • Última visita

  • Days Won

    1

douglas_k last won the day on December 7 2016

douglas_k had the most liked content!

Reputação

11 Good

Sobre douglas_k

  • Rank
    Membro
  • Data de Nascimento

Contact Methods

  • Website URL
    http://www.g3sistemas.com

Profile Information

  • Sexo
    Masculino
  • Localização
    palmitos sc

Últimos Visitantes

602 visualizações
  1. 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.
  2. 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.
  3. 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.
  4. atualizei e testei, agora esta correto
  5. 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
  6. 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?
  7. 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.
  8. Bom dia EMBarbosa, Realmente, fiz testes passando o caminho relativo e funcionou corretamente. Deixei com as 40 posições mesmo na procedure. Muito obrigado.
  9. 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.
  10. 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?
  11. 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
  12. 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.
  13. 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.
  14. 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.