fabiofranzini

José, eu testei com a ultima versão da dimep (2.0.0.6) e é retornado o erro ('CFe não carregado'), porém o cupom é enviado normalmente! Estou utilizando a dll 1.0.8.3, até o momento não ocorreu nenhum problema! Já enviei mensagem para a dimep com os logs, se tiver alguma resposta volto postar o resultado; Segue anexo. 1.0.8.3.rar

Riquena, o problema se encontra na dll, creio que será necessário esperar uma nova versão da mesma;

Olá, Como descrito no post citado, o problema é um possível problema na DLL. Att.

José, a dll que tenho é da dimep e a mesma está informando a versão 1.0.8.3;

Olá Hoje me deparei com o mesmo problema, o problema acontece com a função xSAT_EnviarDadosVenda da DLL que não retorna o parâmetro já citado neste post . Voltei a versão da dll (no caso da dimep) e o sat voltou a retornar o xml corretamente.

Daniel, boa tarde, estamos utilizando alguns aparelhos deste a algumas semanas já, e não alteramos nada com relação a aplicação e nem ao ACBR, tem se mostrado um bom equipamento.

Olá! Estou com um problema, estou cuidando de um sistema que implementa a emissão de cfe sat via ecfVirtual, porém existem usuários deste sistema que trabalham das 19:00 as 2:00. Como estou utilizando a ecfVirtual, quando vira o dia, o mesmo pede a emissão da redução Z e esta não é válida para o SAT. A pergunta é: Existe alguma forma de desabilitar a checagem da Redução Z ?

Olá, bom dia a todos, não encontrei nada a respeito em nenhum outro tópico. Se alguém puder ajudar o que ocorre esta descrito abaixo. Estou tendo problema ao inutilizar a NFe, utilizo o comando como no acbrnfe de exemplo. ACBrNFe1.WebServices.Inutiliza(frm_configuracao.edtEmitCNPJ.Text, frm_inutiliza.ED_JUSTIFICATIVA.Text, StrToInt(frm_inutiliza.ed_ano.Text), StrToInt(frm_inutiliza.ed_modelo.Text), StrToInt(frm_inutiliza.ed_serie.Text), StrToInt(frm_inutiliza.ed_inicio.Text), StrToInt(frm_inutiliza.ed_fim.Text )); Fiz a validação do xml de pedido de inutilização e obtive a resposta abaixo: Parser XML: Nenhum erro encontrado Tipo de Mensagem: Inutilização de Numeração Schema XML: Nenhum erro encontrado Inutilização 35161726143700018155000000000015000000020 Certificado Digital do Titular: CN=PAULO SERGIO NAVARRO E CIA LTDA:17261437000181 Assinatura Digital: Inválida Os outros serviços, como envio, cancelamento e outros, funcionam normalmente, por isto descartei por enquanto a configuração do componente, e também o problema ser o certificado digital. Em anexo segue pedido de inutilização e resposta obtida. 35161726143700018155000000000010000000015-inu.xml 35161726143700018155000000000010000000015-inu-soap.xml 35161726143700018155000000000010000000015-ped-inu.xml 35161726143700018155000000000010000000015-ped-inu-soap.xml

Olá ! Venho me deparando com dois problemas que não sei exatamente o que fazer para soluciona-los. O primeiro é que, o componente ACBrSAT(creio eu), em algumas ocasiões não retorna os dados do CFe emitido(chave, datas etc). O segundo problema, e talvez relacionado, é que em alguns casos o componente não salva o XML, porém pelo SGR é possível encontra o CFe. Alguém saberia me dizer se os problemas citados já ocorrerem, ou se é um problema comum ou até se é algo normal? Desde já agradeço, Daniel Cunha. P.S: Estou utilizando o Sat da Bematech;

Em meu caso já tentei informar um desconto no item e na mesma venda colocar o desconto no final. Observei que o desconto no final é rateado automaticamente nos itens(no xml), ou seja, se o primeiro tinha 1,30 de desconto agora ele passa a ter 1,45. Há alguma forma de não ratear?

Sérgio, você sabe se é possível informar desconto item a item e no final dar mais desconto pelo componente, sendo que o segundo só incidiria nos itens que não tiveram desconto? Att.

Olá! Pesquisando na página do SAT, verifiquei que a versão do software do SAT vigente é a mesma que meus aparelhos estão. Verifiquei também que a validade destes é a mesma 31/07/2016. Ao meu entender, a mudança para o layout 0.07 para os meus aparelhos(DIMEP e Bematech) só passará valer do dia 01/08/2016 a diante ou perto disso...

Olá! Em meu caso tanto o Sat Dimep quanto o Bematech continuam no layout 0.06. Já tentei atualizar DLLs, atualizar o SAT e em meu código já estou informando o layout ( ACBrSAT1.Config.infCFe_versaoDadosEnt := 0.07 ) ... Alguém saberia dizer se este comportamento é normal? Att, Daniel Cunha PS.: Os dois SATs acima citados são de desenvolvimento.

Por um acaso você desativa e ativa novamente o componente? Se sim, assim como o próprio Sérgio já me respondeu uma vez, da uma olhada na fonte do SATTeste.... Pelo que verifiquei, no caso do cancelamento você terá que carregar o arquivo .xml para então cancelá-lo

Olá Queria tirar uma dúvida. Hoje me deparei com um problema onde o cliente não conseguia cancelar o último cupom do sat. Após testes e acompanhamento com o cliente percebi que ele tentava cancelar a venda após desativar o sat e ativar novamente, com isso testei e debuguei todos os passos para o cancelamento e verifiquei que o ACBrSAT precisa estar com o xml carregado para conseguir cancelar o sat e neste caso(como a comunicação fui interrompida) o mesmo já não estava em memória. Em testes verifiquei que a procedure TACBrECFVirtualSATClass.CancelaCupomVirtual; verifica se o mesmo está na memória mas não encontra o arquivo, a chave vem certinha. Resumindo: Era para o ACBrSAT carregar o xml automáticamente para o cancelamento? PS.: É possível carregar um xml de venda apenas pela chave do SAT? Obrigado, Daniel Cunha

Segue fonte . Obrigado ACBrDownloadClass.pas

Olá , Venho desenvolvendo uma aplicação que utiliza o ACBrDownload para baixar um arquivo por HTTP. Em testes verifiquei que vezes baixa normalmente e vezes retorna o erro: Logo comecei a pesquisar sobre aqui no fórum e verifiquei que existiam pessoas com o mesmo problema mas nenhuma solução. Então fui para a linha onde o erro acontece no arquivo ACBrDownloadClass e verifiquei que ele tenta renomear o arquivo .part. Esse é o trecho ORIGINAL do código onde o problema acontece(linhas 336 a 345): O sFileName representa o arquivo em seu formato original então se ele já existe ele tenta deletar o arquivo , e se o arquivo não existe ele renomeia o .part para o formato original. Nessa lógica pensei na seguinte problemática: "E se o .part estiver completo mas não foi liberado para uso?" então fiz uma A.T.E(Gambiarra): Bom e para minha surpresa funcionou! 10/10 vezes de execução do mesmo código. Logo após verifiquei um problema: o componente passa 2x pelo mesmo trecho te código, então ele não valida o primeiro if: porém na segunda passagem pelo trecho ele DELETA o arquivo baixado e por fim retorna erro por não achar o .part Então refatorei o código: Concluindo o problema era que o código deletava o arquivo baixado e tentava renomear o download(.part) que já tinha sido renomeado anteriormente. Essa foi a solução que encontrei... Até mais ! Daniel Cunha

Bematech RB1000 FI

Olá! Ontem me deparei com um problema, um cliente me questionou que alguns cupons não geraram xml. Até ai ok, pois poderia ser algum problema por falta de dados ou até de resposta do sat(pois o cliente utiliza um hub USB e as vezes da mal contato na fonte), porém, ao consultar no sistema do sat no sefaz havia um gap entre numeração de cupons. Exemplo: O lote 1 contém cupons de 1 a 10, e o lote 2 cupons de 18 a 22. Na pasta enviados não contem nenhum XML na data e com o mesmo valor das vendas que "faltam", também não existem cancelamentos; Concluindo: Quem gera o número do Cupom? O sat inutiliza automaticamente cupons que não continham dados corretos? Desde já agradeço! Daniel Cunha

Olá, Hoje me deparei com um problema, ao atualizar as fontes do ACBr (Limpei a instalação e reinstalei) a seguinte linha retornou erro: Houve alguma mudança ou eu que estou fazendo algo errado? -Daniel Cunha

Olá! Estou fuçando na implementação em delphi para o micro terminal TCP IDTech MOD-7390-00-ID. Até o momento não obtive sucesso... Alguém sabe algo sobre?

Ola, boa tarde Marcos, você tem uma tabela com valores referentes ao FPC de cada estado ?

Bom dia Douglas, optando pelo forts, foi menos traumático que pensei, e não levou muito para fazer a troca, e temos mais um bom motivo para migrar para ele, como mostrado no tópico http://www.projetoacbr.com.br/forum/announcement/12-novo-fortes-report-ce-e-projeto-acbr/ podemos ver que o pessoal esta mesmo disposto a tornar a melhor opção.

Douglas, eu consegui migrar para o Fortes, que acho que é o primeiro a receber atualizações sempre pela comunidade, talvez por ser o mais usado, por funcionar delphi/lazarus, então abandonei o RAVE de vez, mas estava mesmo desta forma saindo sem espaços, mas somente no preview ao se enviar para impressora saia correto. Mas não tenho mais nenhuma informação além daquelas pra te ajudar, já que abandonamos ele tb.

Carlos qual servidor SMTP vc esta utilizando ? Aqui tivemos problemas com yahoo, resolvemos utilizando a porta 465