ericserafim

Caros, Procurei no fórum uma solução para totalizar um cupom fiscal com acréscimo e desconto no mesmo cupom (simultaneamente) para a Bematech térmica, mas só encontrei a solução de realizar a soma de ambos e enviar utilizando o comando SubtotalizaCupom. Bom, este mesmo comando chamado na sequência (SubtotalizaCupom(Acrescimo) e SubtotalizaCupom(Desconto)) para impressoras Daruma térmicas funciona perfeitamente e com isso o objetivo é alcançado. Antes que alguém diga "Porque você não utiliza a solução de somar ambos?" Resposta: Meus clientes precisam do indicativo no cupom de total de acréscimo e desconto no seu fechamento. Contudo ao invés de utilizar o método SubtotalizaCupom para a impressora Bematech térmica, resolvi utilizar o método EnviaComando(#32 + 'T' + IntToStrZero( Round( VL_TotAcrescimo * 100),14) + IntToStrZero( Round( VL_TotDesconto * 100),14)) Este comando funciona mesmo se um dos parâmetros (acréscimo ou desconto) for zero, pois ele vai totalizar o que tiver valor. Em anexo comprovantes das três operações utilizando o método acima: Somente com desconto Somente com acréscimo Ambos simultaneamente Obtendo o resultado esperado, exatamente igual ao da Daruma. Então gostaria de ver com vocês se conseguimos implementar esta funcionalidade também para a Bematech?

Daniel, Como dito o problema acontece as vezes... quanto a modificar a propriedade fpDecimaisQtd depois de ativar, não procede, visto que configuro o componente e somente depois o método Ativar é invocado. Sim eu notei que o comando utiliza este field para enviar para a serial e justamente por este motivo que estou intrigado com esse erro esporádico. O que o cliente me relatou é que o problema acontece no meio da tarde, ou seja, depois de realizar diversas vendas no ECF. Pegando a configuração da máquina que opera com a ECF, notei que a mesma roda Windows XP com apenas 256MB de RAM, com processador celeron... Olhando com mais detalhe o comando de vendeItem, notei que o mesmo utiliza a função POWER que é assembler puro em todas os seus overloads, o que me ocorre é um possível problema de memória, seria possível isso estar gerando esta inconsistência na rotina POWER?

Olá Daniel, Estamos nos desviando do problema... Se o componente ignora esta propriedade porque lê da ecf e mesma está configurada para 3 casas na quantidade, porque o envio do comando vendeitem é enviado com 2 casas? Vide os detalhes na primeira iteração. Grato

Segue o log, a última venda do arquivo é a que está com erro. ECF_Log.txt

Caros, Preciso de ajuda na seguinte situação: Meu cliente possui várias lojas com ecf FS700 e FS600, em algumas lojas ocorre do cupom sair com a quantidade digitada no sistema diferente da impressa no cupom, ou seja a impressora recebeu uma quantidade inferior a digitada no sistema. Ativei o log dos comandos enviados e notei que o envio do comando para a rotina vende item, fica diferente no parâmetro quantidade quando o erro acontece, isso vendendo a mesma quantidade do mesmo produto ou produto diferente (aqui tanto faz, o problema está na quantidade e não no preço). Isso ocorre de forma aleatória na mesma ECF vendendo os mesmos produtos e mesma quantidade. Em um dos casos o cliente reiniciou o PC e tudo voltou a funcionar! A impressora está configurada para 3 casas decimais na quantidade e o parâmetro DecimaisQtd também está com 3. Segue o log dos comandos: Quando o erro não acontece, note que a quantidade é enviada com 3 casas decimais. 17:38:16:064 VendeItem( 013759 , RICCA PINCA DEPIL POTE UNID , FF , 1 , 0,98 , 0 , UN , $ , D , -1 ) TX -> [FS]F[207]1700010000000098000000000000018013759 UN ARICCA PINCA DEPIL POTE UNID[255]e 17:38:16:376 RX <- :0000000[207]003000000000098[CR][250] Quando o erro acontece, note que quantidade é enviada com 2 casas decimais. 17:55:21:001 VendeItem( 018282 , VEFIC SEC ESMALTE 200ML , FF , 1 , 12,98 , 0 , UN , $ , D , -1 ) TX -> [FS]F[207]1700001000001298000000000000018018282 UN AVEFIC SEC ESMALTE 200ML[255]s 17:55:21:298 RX <- :0000000[207]001000000000130[CR][251] Segue um exemplo de cupom impresso onde o problema ocorre. Gostaria de saber se alguém tem ideia porque este erro ocorre?

Caros, Ao tentar emitir uma nota na versão 3.10, notei que o componente desfaz o Set da versão verificando se o modelo confere e afins, só que isso acaba impedindo o uso do formato 3.10. Segue o patch com as alterações. Lembrando que realizei a atualização antes de gerar o patch ACBrNFeConfiguracoes.pas.patch.txt

Boa tarde Italo, Segui a tua sugestão de passar false no parâmetro síncrono e funcionou perfeitamente. Agradeço o teu retorno e empenho, Forte abraço, Eric Serafim Sidicom Software

Estamos juntos ! Daniel, Para não deixar os demais overloads dessa rotina "bugados" vou revisá-los e viabilizar a atualização deles também, mas só conseguirei fazer isso na semana do dia 30/06/2014. Quanto a versão do SVN, conferi e está tudo certo.

Bom dia Italo, Obrigado pelo retorno... Realizei mais alguns testes e não consegui chegar no resultado que você comentou. Testei diversas combinações das opções "salvar" disponíveis no componente e sempre recebo o XML sem a tag protNFe. Realizei as alterações sugeridas por você e não uso mais o método SavaToFile, isso fica sob responsabilidade do componente o salvamento dos arquivos. Gostaria de salientar que investiguei o fonte da rotina enviar (conforme citei acima) e não vi uma forma de acontecer o que você comentou, mas deixo bem claro que isso não é uma afirmação definitiva, visto que a comunidade já vem utilizando este componente a bastante tempo e pelo visto este problema não acontece. Te envio a imagem do componente contendo retângulos em vermelho e em azul, onde o vermelho simboliza as configurações para salvar os arquivos e o azul são propriedades definidas em tempo de execução. Atenciosamente, Eric Serafim

Olá Daniel, Acredito que sim, apenas inclui esta segurança com intuito de avisar o pessoal de que o resultado esperado não será atingido invocando este método com os parâmetros acima. Então acredito que podemos retirar sem problemas. Att Eric Serafim Sidicom Software

Caros, Testando a emissão de NF-e através do método AcbrNfe.Enviar(1, False, True), notei que ao salvar o XML utilizando Nfe.NotasFiscais.Items[0].SaveToFile(VL_NomeXML), o mesmo não continha a tag protNfe e seus respectivos dados de autorização. Então procurei no fórum sobre este assunto e só encontrei este problema para quem está usando o AcbrNFeMonitor (não é o meu caso), mesmo assim testei as sugestões que encontrei, tais como, definir TRUE nas propriedades Configuracoes.Arquivos.EmissaoPathNfe e Configuracoes.Arquivos.Salvar, mesmo assim não funcionou. Como consultando a nota utilizando o método AcbrNfe.Consultar estas informações são gerados com sucesso, resolvi investigar o caso. Ao verificar que a rotina consultar faz, notei que a rotina enviar não realiza os passos necessários para atingir tal objetivo, exceto para NFC-e ou se é a versão 3 do layout (IF), onde uma consulta é realizada e os dados pertinentes a tag protNfe são obtidos. Pesquisando um pouco mais sobre este assunto, principalmente sobre o uso indevido dos serviços (conforme documento Consumo_Indevido_Aplicacao_Cliente_v1.01.pdf), não encontrei nada que impeça a consulta da NF-e logo após obter o retorno de envio ok do lote. Portanto, venho por meio deste verificar a possibilidade de adotarmos a mesma solução da NFC-e (IF acima comentado) para a NF-e, resolvi comunicar vocês antes de realizar qualquer alteração nesta rotina, visto que a comunidade já vem utilizando este componente a bastante tempo. Se a solução que o pessoal vem utilizando é a chamada para o método consultar para obter estes dados, posso fazer o mesmo, mas acredito que seria mais produtivo, invocar o método enviar e já receber o XML pronto contendo todas as informações pertinentes a um XML autorizado. Desde já agradeço, Atenciosamente, Eric Serafim Sidicom Software

Caros, Realizei alguns ajustes nas rotina que geram o SPED e SINTEGRA dos fabricantes Bematech e Daruma, são eles: Bematech: Não estava gerando os arquivos esperados (SPED e SINTEGRA) quando especificado estes tipos de arquivos para rotina ArquivoMFD_DLL(DataInicial, DataFinal: TDateTime; NomeArquivo: AnsiString; Documentos: TACBrECFTipoDocumentoSet; Finalidade: TACBrECFFinalizaArqMFD). Daruma: ArquivoMFD_DLL mesmo overload da Bematech: Ajuste nos nomes dos arquivos gerados. Observação: Realizei as alterações somente neste overload com intuito de aguardar a aprovação da moderação, caso aprovem eu realizo nas demais chamadas para este método. Lembrando que atualizei os componentes antes de criar o patch em anexo. Att Eric Serafim Sidicom Software ACBrSerial.patch.txt