fernandes_bfg

Pessoal, boa tarde. Estava com o mesmo problema após atualizar os fontes do ACBr e fazer e reinstalar tudo. Ao imprimir danfe do Fortes Report-CE, apresentava erro de Acces Violation. Depois de tentar várias coisas postadas aqui no fórum e quase para excluir tudo e instalar tudo "do zero", tive a idéia de apagar a pasta Lib que fica dentro da pasta dos fontes do ACBr. Após isso, apenas reinstalei o ACBr e funcionou. Fica a dica aí pro pessoal. Abraços.

Boa tarde pessoal. Pesquisei mais a fundo o problema da acentuação do XML da carta de correção. Na unit ACBrDFeWebService, na procedure procedure TDFeWebService.EnviarDados;, para retornar o XML para a aplicação, o resultado é tratado e "devolvida" as acentuações, o que faz com que o XML fique ilegível. Gostaria de saber se o procedimento de alterar o XML para receber acentuação é correto ou não. ACBrDFeWebService.pas { Resposta sempre é UTF8, ParseTXT chamará DecodetoString, que converterá de UTF8 para o formato nativo de String usada pela IDE } FPRetornoWS := ParseText(FPRetornoWS, True, True);

Bom dia pessoal, me desculpem por antecipação caso haja algum tópico semelhante ao que vou postar. Gostaria de saber se existe no Trunk2 algum tratamento da Carta de Correção referente a acentuação do XML. Na pasta que configurei \Eventos\CCe, os XMLs estão sendo considerados incorretos pois existe dentro deles o texto "Carta de Correção registrada". Testei com a versão antiga (Trunk1) e está sendo salvo certinho. Deixei passar alguma coisa? Alguém sabe como resolver? Desde já agradeço a atenção e colaboração. Fico no aguardo.

Qual a versão do Delphi vc está utilizando? Se for Delphi7, vá em Component > Install Package > Clique sobre Fortes Report e Remove. Após isso, desvincule a library do mesmo (Tools > Environment Options > Library > Library Path) O diretório para instalação do novo Fortes Report vai da sua escolha, não há um diretório específico.

Boa tarde senhores. Para tentar reforçar ou chamar atenção a esse problema de perda da chave privada do certificado digital, vou colocar mais parâmetros para análise. Nos últimos dias devido a mau tempo e a N fatores, em alguns dos meus clientes o Sat acabou queimando e a NFC-e entrou em ação como contingência e para meu cliente não ficar "parado". Alguns desses clientes possuíam o certificado A3 e o mesmo foi instalado e configurado no caixa e a NFC-e começou a ser emitida. Até aí sem maiores problemas. O que acontece é que algum tempo depois da instalação e configuração (horas em alguns casos), o sistema começa a apresentar algumas instabilidades, o que reparamos é que sem mais nem menos, aparece a caixa de inserção do PIN do certificado digital. Como o operador tem essa informação, digita e após isso, percebemos que quase sempre o certificado perde sua chave privada. Eu não sei se por haver muita movimentação (muito mais que a emissão da NF-e), o certificado acaba refugando e/ou o acesso constante acaba ocasionando algum tipo de sobrecarga (note-se que é apenas um palpite sem o menor embasamento científico). Gostaria de chamar a atenção mais uma vez para esse assunto, pois como sempre, acaba caindo a culpa no sistema e, consequentemente, nos ombros do desenvolvedor e a tecnologia que usamos é posta a prova (Componente ABCr). Alguém sabe de mais alguma coisa que possamos fazer para prevenir esses casos ou tem alguma novidade sobre esse assunto? Desde já agradeço.

Bom dia, fiquei de dar a resposta e acabei me esquecendo. No meu caso, com a versão atualizada da DLL não aconteceu mais, ou seja, realmente resolveram o problema. Deixo aqui meus agradecimentos a equipe da sweda. (O que prova que de fato o problema não era do componente).

Já aconteceu no meu software com o problema do Sat em Processamento justo na hora de capturar os dados da venda. Como eu exibia uma mensagem para o cliente de tentar novamente, a venda era enviada de novo. Com isso, no meu sistema ficava faltando a numeração do primeiro cupom enviado. O melhor meio de saber é baixando os lotes dos cupons recebidos na Sefaz utilizando o certificado digital do cliente no endereço https://satsp.fazenda.sp.gov.br/COMSAT/ Se lá estiver 2 cupons seguidos e idênticos, há uma boa chance de ser um erro no seu software.

Bom dia, encontrei a informação oficial. http://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false#355 16/10/2015 - Atenção: Publicada atualização da NT2015/002 e respectivo Pacote de Liberação, contendo as seguintes alterações Atenção: Publicada atualização da NT2015/002 e respectivo Pacote de Liberação, contendo as seguintes alterações: Alteração do prazo de implantação da versão em produção para o dia 01/12/2015, por solicitação das empresas; Alteração do campo de valor do Encerrante para 3 casas decimais; Eliminação da regra de validação prevista originalmente para o piloto da NFC-e (RV: A02-10); Para os casos de exportação indireta (CFOP=3.503, 7.501) passa a ser obrigatória a informação de Nota Fiscal referenciada (RV: I08-190); Para a NFC-e, não deve ser informado o grupo de exportação (tag:detExport, RV: I50-10); Melhor definidas as regras de validações relacionadas com a venda de Combustível pela NFCe, documentando a obrigatoriedade da informação do grupo de combustível conforme critério da UF (eliminada RV LA01-10 e LA01-30, alterada RV LA01-20); Na validação do QR-Code da NFC-e, serão aceitos os caracteres hexadecimal em letras maiúsculas ou minúsculas, conforme Manual do DANFE da NFC-e (RV: ZX02-64, ZX02-92, ZX02-116); Flexibilizada a implantação em produção de algumas regras de validação, permitindo que elas sejam implementadas pelas empresas em uma data variável, a partir da implantação da NT em produção pela SEFAZ Autorizadora até a data informada na própria regra de validação (data limite = 01/01/2016). Ou seja, a empresa pode implantar as mudanças necessárias em seus aplicativos, dentro deste período informado, em qualquer data a seu critério. As regras de validação com esta flexibilização são: RV I05-20, LA01-20, LA11-10, N12-30, N12a-20, N12a-30, YA04-10, YA04a-10, YA05-10, ZX02-10, entre outras alterações detalhadas na Nota Técnica. Assinado por: Coordenação Técnica do ENCAT

Bom dia pessoal, estou pegando "carona" nesse tópico pra não ficar lotando o fórum com assuntos semelhantes. Fui acionado pelo meu setor comercial para saber mais sobre o funcionamento do sat GERTEC (GerSat). Gostaria de saber mais sobre os problemas encontrados (pesquisei aqui no fórum e aparentemente não foram muitos, quase nenhum, apenas um problema com o código EAN). O Sat Sweda, que é o que mais comercializamos aqui por exemplo, tivemos alguns problemas com data/hora, "Sat em processamento" e "XML corrompidos", todos já se encaminhando para a solução ou solucionados. Entretanto, estão querendo migrar para essa nova marca (provavelmente por fatores financeiros), mas para isso precisam saber sobre a parte técnica, se está estável ou se apresenta inconsistências ou erros em seu uso. Conto com a ajuda de vocês. Desde já agradecido.

Bom dia, obrigado pelo retorno. Tenho vários clientes que acontecem esse problema com muita frequencia. Vou instalar a DLL e muito em breve teremos um retorno. Posto aqui assim que possível o resultado. Agradecido.

Logo no início do projeto da NF-e criei uma função própria pra capturar os campos da nota de acordo com o código fonte da página. Acho que o pessoal da sefaz deve ter "sacado" e transformou a consulta em uma imagem e isso jogou no lixo minha função. Ultimamente reparei que voltaram a ser campo texto, mas nem sei até onde compensa criar uma função para ler isso novamente pois pode ocorrer o mesmo. O ideal seria utilizar o certificado, baixar o xml e dar entrada no sistema.

Prezado Daniel Simões, na verdade em momento algum duvidei da qualidade do componente ACBrSat. O problema em questão é propriamente do equipamento, pois tenho clientes utilizando as marcas Dimep e Tanca e não tenho problema algum com elas. Pela análise dos logs a sensação que tenho é que há a falha do EQUIPAMENTO e não do componente. Já estou tentando solucionar junto ao suporte, só queria compartilhar a experiência para que os outros desenvolvedores possam estar por dentro do que se passa. Abraços.

Boa tarde a todos. Tenho mais de CEM clientes instalados e rodando o Sat da Marca Sweda. Em uma estimativa feita pelo setor de suporte ao gerar os arquivos fiscais (apurando os XMLs do Sat), constatamos que para quase todos os clientes há uma falha de 5 a 10 xml no período fiscal. Peguei um como exemplo e constatei que há um problema grave acontecendo no envio dos dados da venda do Sat Fiscal. Exemplo em questão: Enviar os dados da Venda -> - 10:34:08:214 - -- 10:34:08:214 - numeroSessao: 442505 - Comando: EnviarDadosVenda( <CFe> <infCFe versaoDadosEnt="0.06"> <ide> <CNPJ>00000000000000</CNPJ> <signAC>XXXXXXXXXXXXXXXXXXXXXXXXXXX</signAC> <numeroCaixa>002</numeroCaixa> </ide> <emit> <CNPJ>99999999999999</CNPJ> <IE>999999999999</IE> <indRatISSQN>N</indRatISSQN> </emit> <dest> <xNome>CONSUMIDOR</xNome> </dest> <det nItem="1"> <prod> <cProd>3</cProd> <xProd>B04-GASOLINA ADTIVADA</xProd> <NCM>27101259</NCM> <CFOP>5656</CFOP> <uCom>L</uCom> <qCom>9.1220</qCom> <vUnCom>3.289</vUnCom> <indRegra>T</indRegra> <obsFiscoDet xCampoDet="Cod. Produto ANP"> <xTextoDet>320102002</xTextoDet> </obsFiscoDet> </prod> <imposto> <vItem12741>11.54</vItem12741> <ICMS> <ICMS40> <Orig>0</Orig> <CST>60</CST> </ICMS40> </ICMS> <PIS> <PISNT> <CST>04</CST> </PISNT> </PIS> <COFINS> <COFINSNT> <CST>04</CST> </COFINSNT> </COFINS> </imposto> </det> <total> <vCFeLei12741>11.54</vCFeLei12741> </total> <pgto> <MP> <cMP>03</cMP> <vMP>30.00</vMP> </MP> </pgto> <infAdic> <infCpl>Informação complementar....</infCpl> </infAdic> </infCFe> </CFe> ) Analisando o Log do ACBr, o retorno da tentativa da venda é o seguinte: Pode se perceber que o retorno está corrompido e o sat fica em processamento logo em seguida. No meu sistema, eu trato esse erro e pergunto pro usuário se ele quer tentar enviar a venda novamente. Se ele responde SIM, a venda é enviada novamente, só que a primeira venda deu certo e acaba que é faturado 2x ! A versão da DLL já é a última e já efetuamos a troca dos cabos do equipamento. Esse é apenas um exemplo e reparei que sempre que a captura dos dados da venda apresenta erro, não tenho acesso ao XML da venda e nem tenho condições de efetuar o cancelamento. Já entramos em contato com o suporte da sweda várias vezes e até agora não foi apresentado nenhum tipo de solução efetiva. Gostaria de saber se mais alguém está tendo problemas com essa marca e se há alguma solução por parte do componente ACBrSat ou da própria DLL para que possamos contornar esse tipo de problema.

Bom dia a todos. Já é terça-feira e os Sats prosseguem parados. Engraçado é que temos vários clientes e o sat deu bloqueio autônomo somente em uns 10. Fica difícil explicar pra esses clientes o motivo do Sat dele ter parado. Em um canal no suporte da sweda, me disseram que cada sat possui uma parametrização e que tem um tempo máximo de comunicação com a sefaz (Ela própria faz a carga desse parâmetro), quando ele é atingido e não é possível se comunicar com a receita, o sat entra em bloqueio autônomo. Tentamos procurar saber qual seria esse tempo para já nos precavermos em cada cliente, mas somente a Sefaz tem acesso a essa informação. Nos casos em que o cliente fica sem opção de emitir cupom fiscal pela ECF, estamos habilitando e instalando a NFC-e como contingência. Esse projeto do Sat está cada dia mais complicado e apresentando mais problemas. Apenas queria compartilhar a vivência que estamos tendo aqui com essa tecnologia. Nem sempre o cliente consegue discernir o problema do equipamento e do software. O desgaste é grande...

Prezados, bom dia. Gostaria de saber se alguém já descobriu algo sobre o problema descrito acima. Agradeço.

Prezado Daniel, Para mim foi essencial a alteração para adequar eficaz e rapidamente a impressão do extrato do Sat para esse modelo de impressora. Meu prazo era curto rsrs, e ainda não tive tempo de estudar o componente TACBrPosPrinter. Obrigado pela resposta e espero que as informações ajudem! Qualquer dúvida, estou a disposição. Abraços

Senhores, boa tarde! Pesquisei no fórum e no Google em geral e não encontrei muita informação sobre a impressora não fiscal Sweda modelo SI-300S. Adquirimos uma recentemente para ser utilizada no "kit sat", ou seja, para imprimir extratos do Sat Fiscal. Eis algumas considerações sobre a mesma: Impressão em tamanho normal apenas aceita 42 colunas (padrão das outras marcas, EPSON por exemplo é 48) Tive que alterar o fonte de forma a imprimir tudo condensado. Problemas com o código de páginas quando é feita a impressão por ESC/POS. Não estava imprimindo acentuação. Tive que alterar a codificação da página para WPC-1252. É necessário alterar uma chave na parte inferior do equipamento para que se possa comunicar via ESC/POS. A maior parte dos comandos da impressora EPSON funciona nela, inclusive o QRCode. Como vi que estava sem muito material e informação, tomei a liberdade de alterar a unit do ACBr para adicionar e adequar esse modelo de impressora. Me perdoem se fugi em algum padrão ou algo não esteja coerente. Estou anexando por talvez ajudar alguém na mesma situação. O código está comentado justificando as alterações. Em anexo uma foto do extrato depois das alterações e o fonte para analise. Desde já agradeço. acbrsatextratoescposSwedaSI300s.rar

Ah sim, vou dar um update por via das dúvidas e retorno aqui no fórum para falar se resolveu ou não. Muito obrigado.

Sem problemas. Agradecido.

Certo, entendido. O que estranhei foi não ter limpo o componente do Cupom Eletronico e só de chamar a função Chave:= UpperCase(ACBrSAT1.CFe.AsXMLString); Ele já perdeu essa configuração. Sendo assim, achei mais sensato utilizar a configuração do Arredondamento/Truncamento para setar o número de casas decimais, pois essa não é perdida.

Bom dia EvandroMira. Meus fontes estão atualizados sim. Eu primeiro direciono que é combustível e depois passo os valores. Ao capturar a informação do XML novamente, a propriedade EhCombustivel fica perdida, não entendi muito bem o porque. De toda forma essa adaptação funcionou, pois a informação referente ao Arredondamento/Truncamento não se perde ao chamar a função novamente.

Bom dia senhores. Meu software é direcionado a postos de combustíveis e já tenho o Sat implantado em alguns clientes e estou adequando os fontes e presenciando algumas situações específicas. Um dos meus clientes reparou que na impressão, o preço do combustível não estava correto com as 3 casas decimais como de costume. Fui analisar a situação e eu estava direcionando o item com a tag "EhCombustivel" para que o ACBr fizesse os devidos tratamentos quanto as casas decimais. Debugando, percebi que ao passar pela segunda vez na função procedure TCFeW.GerarDetProd(const i: integer); essa indicação "EhCombustivel" se perde (volta a ser false), e daí em diante, todas as informações dos itens, são tratadas como se trabalhasse com apenas 2 casas decimais (XML e Impressão). Por hora, alterei o fonte \ACBr\Trunk\Fontes\ACBrSat\pcnCFeW.pas com o seguinte código: procedure TCFeW.GerarDetProd(const i: integer); var DecQtd: TpcnTipoCampo; begin If CFe.Det[i].Prod.indRegra = irArredondamento then begin DecQtd := tcDe2; end Else begin DecQtd := tcDe3; end; Poderiam me dizer se estou fazendo algo errado ou se essa solução é valida? Desde já agradeço a atenção dos senhores e qualquer dúvida, estou a disposição.

Prezados, bom dia. Estou no aguardo da publicação no SVN. Por hora deixei comentado, conforme mandei acima. Obrigado a todos pela atenção.

Boa tarde Daniel Simoes, no XML, a observação vem errada (com o xCampo1 e xTexto1). Eu localizei nos fontes do ACBr onde são alimentados esses dois campos: pcnCFeR.pas: CFe.InfAdic.obsFisco.Add; (*Z04*)CFe.InfAdic.obsFisco[i].xCampo := Leitor.rAtributo('xCampo'); (*Z05*)CFe.InfAdic.obsFisco[i].xTexto := Leitor.rCampo(tcStr, 'xTexto'); Por algum motivo, como padrão esses campos vem preenchidos como xCampo1 e xTexto1, respectivamente. Se eu deixar assim (*Z04*)CFe.InfAdic.obsFisco[i].xCampo := '';//Leitor.rAtributo('xCampo'); (*Z05*)CFe.InfAdic.obsFisco[i].xTexto := '';//Leitor.rCampo(tcStr, 'xTexto'); , o XML final fica sem essa informação. Por essa razão fiquei com a sensação de que o componente ACBr está enviando essa informação indevidamente. A questão é que se eu manipulo pelo componente, limpando essas informações, ele não "obedece". Será que interpretei errado?

Senhores, bom dia. Já estou com meu sistema em produção quanto ao Sat Fiscal utilizando Sweda e Dimep. Estou com um problema referente ao campo de Observação do Fisco. Já tentei limpar ou sequer alimentar a informação ao gerar o documento sat e mesmo assim, ao gerar o XML/ Imprimir o NFC-e Sat, os campos xCampo e xTexto estão apresentando um conteúdo padrão não convencional: <obsFisco xCampo="xCampo1"> <xTexto>xTexto1</xTexto> Ao gerar o documento, é impresso no comprovante "xCampo1-xTexto1" eis o que já testei e não resolveu: InfAdic.obsFisco.Clear; With InfAdic.obsFisco.Add do begin xCampo:= ''; xTexto:= ''; end; Já atualizei os fontes do ACBr, sem sucesso. Maiores dúvidas, estou a disposição. Desde já agradecido a todos.