douglas_k

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..

Boa tarde Pessoal, De alguns dias pra cá me deparei com um problema que até então não encontrei solução. Algumas vezes quando fecho minha aplicação é retornado Runtime error 216 ou 217. Efetuei vários testes para afunilar e identificar qual seria o problema e consegui chegar no seguinte. O erro só ocorre quando minha aplicação não consegue conexão com o banco de dados Postgres que é acessado pelo ODBC utilizando DBExpress. Outro fator importante que compilando com o Delphi XE3 o erro não ocorre, agora com o XE7 e XE10 Seattle o erro se manifesta. Então em comum temos dois pontos, a versão da IDE e o problema ao conectar na base de dados, que juntos ocasionam o erro. Se eu tiver sucesso na conexão do banco o erro também não ocorre. Fiz um projeto de testes aonde que no FormActivate eu faço Connected := True; da base de dados, onde é possível simular o erro, o projeto esta em anexo. Alguém já teve algum problema semelhante? Desde já agradeço a ajuda da comunidade. Projeto.zip

Certo, apenas se tornam obrigatórias algumas regras de validação que hoje são opcionais. Se todas estão atendidas melhor. Obrigado.

Bom dia pessoal, Vi que consta uma nova nota técnica no portal http://www.nfe.fazenda.gov.br/portal em que tem algumas validações sobre a geração do QR-code se tornam obrigatórias a partir de 01/11/2016, entre algumas outras alterações. Gostaria de verificar se já foi verificado essa nova NT, talvez haja necessidade de alguma alteração no componente. Link da NT http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=hDS5co/qWOc= Desde já agradeço.

uhum, exato.. quando ocorre um exception na captura dessas informações eu pego depois de tirar a Z nesses casos, dessa forma contorna o problema.

Ainda não. Na verdade isso só ocorre quando é a primeira redução z da ECF, algo bem estranho. Já peguei 3 casos onde quando é a primeira redução Z da ECF e ela esta bloqueada ocorre o erro acima ao capturar a data e hora do software básico. Após essa primeira Z emitida, para as restantes não ocorre mais o erro. Vou tentar em contato com o fabricante e qualquer retorno posto aqui. Obrigado.

Boa tarde Pessoal. Começamos adquirir impressoras do modelo Epson TM-T900F. Quando a ECF esta com Redução Z bloqueada e for tentar capturar a data e hora do software básico para armazenar na base de dados ocorre o seguinte erro: Erro retornado pela Impressora: EPSON Categoria: 16-Erro específico do Fabricante Motivo: 8-Intervalo de jornada fiscal inválido. Alguém já teve esse problema? acbrlog.txt

Boa tarde marciodc, Estou com um problema semelhante ao seu. Quando vou fazer a recuperação da venda a variável fsEhVenda não esta setada. Pelo que vi essa variável é setada quando é efetuada a abertura da venda, mais nesse caso a abertura já foi efetuada e quero só continuar o processo. Se tivesse uma maneira de setar ela como true mataria a charada mais não estou conseguindo. Vc continua usando a mesma solução descrita a cima? Desde já agradeço

Bom dia _asseinfo, Tive um problema semelhante a esse e era no fechamento do cupom quando era passada a observação, em alguns casos estava indo um caractere que as impressoras epscon não aceitavam e dava a mesma exceção que para vc. Nesse tópico esta descrito o problema que já foi resolvido pelo Daniel. Se o problema for isso atualize seu ACBr e faça um novo teste. Para habilitar o log seta a propriedade ACBrECF1.ArqLOG com o caminho que vc quer que o log seja armazenado.

Depois de atualizar a ultima versão do ACBr no estabelecimento que estava com problema não aconteceu mais. Até simulei os casos que vinham acontecendo antes e passou corretamente.

show de bola Daniel, vou atualizar o ACBr e jogar no cliente para ver se resolve. Obrigado.

Ok, Daniel. Fico no aguardo. Obrigado desde já.

Bom dia Daniel, Conseguiu simular o erro com o ECFTeste?

Boa tarde Daniel, Até agora o modelo que identifiquei esse problema é na Epson TM-T900F. Consegui simular o erro na ECFTeste. Abra um cupom e faça uma venda normal até o fechamento do cupom. Na observação coloque o seguinte texto 'Trib aprox R$: 0,10 Fed, 0,11 Est e 0,00 Mun; Fonte:IBPT ca7gi3|Cliente:6434-7 RODRIGO JOSE OOOOOOO|CPF:000.000.000-00 IE:000.000.000|Endereco:LINHA TECHIO, SN|Limite: 767,61 - 0,00 = 767,61|Operador: 0' e o mesmo erro que descrevi acima vai ocorrer.

Encontrei o seguinte tópico de um colega com o mesmo erro: Foi com esse post que foi criado a alteração no ACBrECF modificado para ajustar as Linhas do Cupom, limitando-as em 8 linhas, se necessário. Isso evita erros em alguns ECFs. Fiz novos testes agora comentando primeiro as linhas if NumMaxLinhasRodape > 0 then Observacao := AjustaLinhas(Observacao, Colunas, NumMaxLinhasRodape); e deixando AjustaComandosControleImpressao(Observacao); normal, e também fazendo inverso descomentado o primeiro e comentado o segundo e nas duas situações o fechamento do cupom passou, o unico problema esta quando é deixado as duas rotinas juntas.

Bom dia Pessoal, Ao enviar o fechamento do cupom em uma ECF Epson TM-T900F, comunicando pelo modelo EscEcf, em algumas situações esta retornando o seguinte erro: ----------------- ERRO ----------------- Erro retornado pela Impressora: EPSON Categoria: 2-Erro em parâmetro do comando Motivo: 1-Conteúdo de parâmetro inválido no comando. ---------------------------------------- Procurando o que poderia estar acontecendo vi que é algo relacionado com a observação que é passada como parâmetro e que houveram modificações para tratar esse campo nas ultimas atualizações do ACBr. Na unit ACBrECF na procedure TACBrECF.FechaCupom(Observacao: AnsiString; IndiceBMP : Integer); foi incluído um novo teste { Todos ECFs suportam no máximo 8 Linhas no Rodapé. Ajusta se necessário, para evitar erro na Impressão, no caso de mais linhas serem enviadas } if NumMaxLinhasRodape > 0 then Observacao := AjustaLinhas(Observacao, Colunas, NumMaxLinhasRodape); Na unit ACBrECFEscECF na procedure TACBrECFEscECF.FechaCupom(Observacao: AnsiString; IndiceBMP: Integer); também foi incluído a linha AjustaComandosControleImpressao(Observacao); se eu comentar as duas novas implementações o erro não ocorre. Gostaria de ver se mais alguém teve problema semelhante ou se alguém sabe como reverter sem ter que modificar o fonte do ACBr, talvez tenha algum bug ou tenho que tratar diferente a observação passada no parâmetro? em anexo log do trecho onde é enviado o fecha cupom de um caso onde deu o erro e outro com as linhas comentadas e não retornando erro. LogACBr.txt

intendo, na verdade quando digo mesmo modelo ACBrNFeDANFCeFortes e ACBrNFeDANFCeEscPos me refiro ao layout de geração, que é semelhante. De qualquer forma a duvida sobre essa quebra de pagina que havia levantado, realmente analisando não é um problema.

Bom dia Daniel, Na verdade para impressão estou utilizando o componente EscPos e imprimindo em uma impressora não fiscal e esta funcionando perfeitamente. No caso descrito no post acima seria para efetuar a geração da Danfe em PDF para posterior manipulação. Estou utilizando os componentes ACBrNFeDANFCeFortes, ACBrNFeDANFCeFortesA4 e ACBrNFeDANFEFR e deixando configurável qual tipo de geração quero efetuar. Dessa forma quando utilizo a geração pelo ACBrNFeDANFCeFortes que seria o mesmo modelo impresso pelo EscPos o PDF gera em algumas situações com mais de uma pagina, quando possui logo praticamente em todas situações. Agora efetuando mais testes acredito que isso seja normal e não um problema. Gerei alguns exemplos e até sem logo gerou mais de uma pagina, em NFC-e com mais itens. Tentei mandar o PDF para impressora não fiscal e imprimiu sem problemas também. Utilizei o ACBrNFeDANFCeFortesA4 com 30 itens e também gerou com 2 paginas então acredito que não tenha nenhum problema mesmo. Só por questão de experiências, qual tipo de Danfe é mais adequado gerar para envio para um cliente por exemplo, sendo que a impressão é no modelo do componente EscPos. Gerar a Danfe com o mesmo modelo utilizando ACBrNFeDANFCeFortes ou gerar em A4, que para uma posterior impressão do cliente seja melhor?