mgaSystem

Bom dia Daniel, tem sim dentro do arquivo de configuração do Sat tem se gera log e a pasta e nome do arquivo. Isto está certo. O fato é que o Log do acbrsat.log cria e é costantemente atualizado pela Acbr. Já o log da dll ele não está gerando como deveria. Como eu converso com técnicos e não com desenvolvedores não tenho muito suporte para poder tirar minhas dúvidas. Dentro do demo do acbrsat vi que apenas configuramos o caminho e nome do log do acbr e nunca o log do Dimep. Questinonei a eles se é a Dll deles que cria este log, porém pediram para ver com vocês. Estranhamente quando eu compilo o demo da Acbr satteste.exe e coloco na máquina do cliente está gerando este arquivo de log, Em anexo o satdimep.ini que mostra o caminho e se gera log e uma imagem da pasta onde mostra o arquivo criado do acbr e sempre atualizado e o de log da Dimep que continua com data de ontem e nunca atualiza. E segundo os mesmos toda vez que se faz uma consulta deveria gerar e atualizar o arquivo de log deles. Obrigado Márcio satdimep.ini

Boa tarde Em uma tentativa de resolver problema de lentidão do Sat Dimep, que sempre funcionou satisfatoriamente o pessoal da Dimep, muito solicitos, me perguntou porque o sistema não está gerando um arquivo chamado logsat_dimep.log que é um nome genérico que eles colocam na pasta c:\sat no arquivo de configuração da dll. O arquivo acbrlog.log está send gerado normalmente. Questionei ao técnico se o responsável por gerar o arquivo de log da dll seria a Dimep ou se seria a Acbr. Se alguém tiver esta resposta me ajudaria muito, pois quando faço o mesmo processo pelo executável de teste da acbr o log é gerado como solicitado pela dimep. Obrigado.

Boa tarde. No xml em anexo houve uma rejeição onde o sat não retorna dados muitos claros da rejeição, porém analisando o xml vi que a tag <nro/> está de um jeito estranho. Olhei outros xmls do emitente e não apresenta esta falha. Detalhe é que o emitente fez esta nota para um cliente fora de sp e alterou a UF para Sp. Caso este erro seja causado por este motivo terei que barrar a emissão de cupom para fora do estado e sugerir a Nfe. No item 2 tenho uma dúvida sobre o imposto. Eu informei na tagimpostos.icms igual 060 e o sistema transformou o que deveria ser uma tag icms060 em icms040 com conteúdo 060. Este caso é por curiosidade mesmo pois não gera erros. Esta conversão foi feita automaticamente pelo acbr? Obrigado AD20230719111310-019360-env.xml

Boa tarde. Obrigado. Subindo o arquivo de log para análise. log_Delphi_10.2_Tokyo_Win32.txt

Boa noite, há um tempo vi um post sobre este assunto e a resposta da acbr que a última versão delphi CE realmente não tem instalador por linha de comando. Estou tendo erro na versão 10.2.3 tokyo architect. Esta versão deveria aceitar a instalação? Obrigado A última versão do Delphi CE não suporta compilador por Linha de comando.. não há como usar o instalador do ACBr, com ele..

Boa tarde. Procurei em vários sites em também no ACBR sobre meios de pagamento da NFC-e. No mês 3 de 2021 BigWIngs falou que para meios de pagamento pix deveria ser usado o tipo fpPagamentoInstantaneo. Homologuei minha aplicação com a skytef com TefDll e também Pix, porém quando faço a geração do xml e coloco os valores 17 18 dá erro na validação dos dados, conforme imagem anexa. Se tentar colocar 99 com xpag 'Carteira digital' também a própria validação da Acbr rejeita. Fazendo como 99 e sem a tag xpag dá certo. Pode derrepente estar faltando preenchimento de alguma coisa, O sistema já funciona há um bom tempo com tef e outras formas de pagamento. o Código que passei Está fixo só para agilizar teste. Na minha aplicação não está fixo e sim dinâmico, mas o resultado no xml é o mesmo. Obrigado 31220721671706000155650010000018119000018114-nfe.xml 31220721671706000155650010000018119000018114-nfe.xml

Obrigado pela ajuda. Vou verificar se por acaso, o que eu fiz aqui na minha máquina caiu como contingência também. A sequência está preservada . Já fiz a conferência e não possui furos na sequência , não sendo necessário fazer inutilização. Obrigado mais uma vez. Abraço

Claro, em anexo Xml e print da tela de consulta NFc-e no site da Sefaz-MG Obrigado 31220221671706000155650010000024569000024560-nfe.xml

Boa tarde. O Cliente está trabalhando em modo de produção e com situação normal. Como eu apenas posso emitir testes, na minha simulei como ambiente homologação/normal. A questão que o relógio do windows 10 do cliente por algum motivo desconfigurou ficando com horário 23:59 do dia 09/02. Então o tempo de atraso de data é muito maior que 5 minutos. O que acho mais estranho é que mesmo na minha máquina consigo que a nota seja aprovada com data do dia anterior e em momento algum a sefaz rejeita a nota. Caso vocês consigam simular poderão ver que está sendo aceito. Pelo menos em Belo Horizonte - MG. Tenho o xml e o print da pasta do cliente que mostram a data de geração e o conteúdo do xml. E na sefaz MG está com data de inclusão 09/02 23:59 e data de aprovação como 10/02. Obrigado

Boa tarde. No dia de hoje um cliente me ligou relatando que deu um erro no sistema dele. Ao dar ok na mensagem a nota foi enviada e o cupom foi emitido. Ao consultar a nota no meu sistema, verifiquei que a data de emissão ficou com a data de ontem 09/02/2022 as 23:59. Mostrei ao cliente a data e hora que estava no sistema operaciona dele. Consultei a nota na Sefaz - Mg e mesma foi aceita. Resolvi testar na minha máquina e alterei a data para a mesma 09/02/2022 as 23:59. A nota foi aprovada e emitiu cupom fiscal. (Ambiente Homologação). Teria alguma orientação sobre esta questâo? Certo seria data mensagem com data e hora atrasada? Obrigado.

Boa tarde. Já tenho vários projetos usando acbr e preciso colocar no meu sistema NFCE/SAT o tef. Fiz homologação junto a paygo(homologado) usando troca de arquivos e também com a fiz a homologação com a skytef usando troca de arquivos e estou aguardando o resultado. Usei uma classe que desenvolvi. Vi que o componente acbr está pronto e funcionando e usei o demo e gostaria de colocar em minha aplicação de forma definitiva. Preciso tirar dúvidas caso alguem possa me ajudar. 1 - Gostaria de ver a possibilidade de suprimir perguntas, pois várias delas já foram feitas pela minha aplicação e gostaria de passar por parâmetro: Ex: se a venda é cartão de débito ele pergunta se é à vista, se é magnético ou digitável. Se é crédito ele pergunta se é á vista, parcelado, depois pergunta taxas. Tem como pular fases e pedir a senha direto. Tem estabelecimentos que trabalham de forma muito simples 2- Na impressão sai um primeiro comprovante que é um resumo do que foi venda de crédito e venda de débito antes da via dos cartôes. Tem como não imprimir? 3- No componente tem uma propriedade geral ACBrTEFD1.ConfirmarAntesDosComprovantes ela funciona para todos os tipos de gerenciador tef? 4- Em operações com cartão simples ou multiplos cartões, a confirmação é automática? 5- Em caso onde a operação onde a nota deu rejeição e o pagamento já foi confirmado, posso fazer o cnc direto ou tenho que chamar função administrativa? 6 - Reimpressão de cupons só em modo administrativo? Obrigado Márcio.

Boa tarde, preciso tirar uma dúvida a respeito de um problema que estou tendo. Se por ventura uma NFCe é rejeitada por dados inválidos, o xml da nota está gravado na pasta. Enquanto o operador vê o problema de cadastro ele resolve fazer outra NFC-e na frente. Neste momento ele gera um segundo xml com o mesmo número de nota com dígito diferente. Quando o contador importou os xmls emitidos apresentou duplicidade de nota com valores diferentes e uma deles não aprovada. Gostaria de saber se existe algum recurso automático que sobreponha o xml ou eu teria que fazer a exclusão do xml caso o operador desista da operação. Para notas normais apenas faço o seguinte try ACBrNFe.Enviar(vNumLote,false,true,false); //lote / imprimir / sincrono / zipado erro_ws := 'N'; except erro_ws := 'S'; GravaRetornoNota; end; Para contingências faço ACBrNFe.NotasFiscais.Assinar; ACBrNFe.NotasFiscais.Validar; ACBrNFe.NotasFiscais.GravarXML(); gravaRetornoNota; Caso algum procedimento esteja errado, ou incompleto, agradeço a colaboração. Obrigado

Boa tarde. Estou passando pelos mesmos problemas a vários dias. Enviei um e-mail para a Sefaz - MG que respondeu, falando na sexta-feira que existe um erro em uma das instâncias da NFC-e. O problema persiste e tenho clientes com mais de 200 NFC-e em contingência. Se você tenta enviar ele demora e em seguida você tenta enviar , ele demora e dá duplicidade , então está horrível o serviço deles.

André só mais uma coisa o xml quando eu dou loadfromfile e mando enviar ele passa a ficar com a data do dia. Então o componente não poderia estar gerando algum tipo de alteração no mesmo?

Boa tarde. Quando gero o xml, no momento da contingência ele fica gravado e só utilizo no momento de enviar de forma definitiva, então não interfiro no processo recriando o xml. Mas vou verificar e agradeço a resposta. Abraço