Cleber Ferreira

Bom dia @xandebugmann, Pessoal providenciou porta usb 2.0. Depois disso não tive mais relatos.

Só para questão de aprendizado, hoje atendi um cliente com o mesmo problema. a ECF não conseguia retornar os dados da última redução z e ainda por cima a MFD dela se esgotou.

Boa tarde, agora no Evento OnDepoisConfirmarTransacoes, utilize o seguinte comando para ler os dados: if RespostasPendentes[i].Header = 'CRT' then dado := RespostasPendentes[i].LeInformacao(2021,000).AsString nos parênteses você coloca o campo que gostaria de ler. No exemplo a cima, estou lendo a linha: 2021-000 = 476331******6112 Com o LogDebug você consegue ver quais campos são retornados para escolher quais capturar.

Marca a opção LogDebug em: ACBrTEFD > CliSiTef. e Faça algumas transações novamente.

@DSilva no log, além dessas linhas que você postou, tem também o retorno campo a campo da transação. Posta o arquivo todo.

Os campos de ID CSC e CSC não estão invertidos?

Bom dia, @DSilva, o que o @Solivan disse pode auxiliar. Aí não precisaria nem de perguntar ao cliente. Os logs do ACBrTEFD retornam os dados da transação. Veja dentro dele se existe um retorno em particular para esse cartão. Campos: bandeira, tipo, adquirente, etc... Talvez aí você consiga fazer a distinção.

Bom dia, Talvez seria o caso de você criar uma regra de negócio que, quando o usuário selecionar a forma de pagamento cartão (recomendo criar uma forma de pagamento específica para esse cartão), o seu programa pode já enviar o valor para o TEF considerando os 10% de desconto. Caso a transação seja feita, você aplica o desconto no subtotal do cupom. No seu caso como o desconto é por item, antes de subtotalizar o cupom, você aplica o desconto ao item.

Boa tarde, Eu geralmente disparo a rotina de verificação de serviço da SEFAZ antes de executar o envio. Se não status positivos, aciono a contingência. Mas com certeza você consegue material na internet que possibilite tal verificação.

Bom dia, Me corrijam se eu estiver equivocado, mas tanto o SAT como o MFE não emitem o CF-e de forma autônoma sem depender da SEFAZ? Se for isso, essa requisição a SEFAZ não faz sentido. Outra coisa, ja verificou que essa numeração está pulando depois que se cancela um CF-e? Lembrando que o cancelamento também se utiliza de uma numeração. Outra coisa que você pode verificar é com relação a versão do software básico do SAT. Quem sabe, atualizando ele resolva a questão.

Enviei a copia dos xmls gerados ao homologador (guardo cópia de todos). Fizemos umas 2 transações informando os dados do POS. Pelo fato do simulador não estar funcionando, creio que o homologador, de posse dos xml's verificou a estrutura deles para saber se estava tudo certo. Com isso, fui aprovado no processo de homologação.

Eu homologuei semana passada e o roteiro seguido por quem me atendeu foi o que segue abaixo: 1. PREPARAR AMBIENTE: 1.1 – Se certificar de que tanto a aplicação comercial quanto o integrador estejam fechados. 1.2 – Abrir o integrador 1.3 – Abrir a aplicação comercial pelo integrador 2. VERIFICAÇÃO DADOS POS: 2.1 – Cadastro de POS Dados do POS: ID: Valor fornecido pelo usuário, pode ser um número sequencial. Serial do POS: No ambiente de produção, o valor inserido é o número de série do equipamento. Descrição: Valor fornecido pelo usuário, pode ser uma forma de identificar o POS. 2.2 – VERIFICAÇÃO CHAVE DE ACESSO AO VALIDADOR. Esse valor pode ser encontrado no manual do integrador fiscal, página 9. OBSERVAÇÃO: A chave de acesso ao validador é igual nos dois ambientes tanto na homologação quanto na produção. Chave de acesso Validador: 25CFE38D-3B92-46C0-91CA-CFF751A82D3D 2.3 – VERIFICAÇÃO CHAVE DE REQUISIÇÃO OBSERVAÇÃO: A chave de requisição é um código gerado a partir do CNPJ do contribuinte mais o CNPJ da adquirente. 3. TESTE DE VENDAS: 3.1 – Fazer uma venda a dinheiro 3.2 – Fazer uma nova venda (a venda deve ser finalizada com duas formas de pagamento, dinheiro e cartão). 3.3 – O AC deve solicitar COD DE AUT, NSU e BANDEIRA, antes de finalizar o cupom. 3.4 – Realizar uma venda com o integrador desligado – Nesse caso aplicação não deve emitir o cupom. 3.6 – Fazer uma nova venda a cartão, logo depois cancelá-la. 4. VERIFICAÇÃO DO BANCO DE DADOS 4.1 – Verificar no banco de dados as seguintes tabelas: ID_pagamentos e ID_respostafiscal 5. ENVIO DE DOCUMENTOS FISCAIS 5.1 – Enviar todos os XML's gerados no momento da homologação para o e-mail: [email protected] com o assunto “DADOS HOMOLOGAÇÃO + NOME SOFTWARE HOUSE”.

Bom dia, Hoje a sefaz está passando por instabilidade. Em alguns momentos ocorre a conexão, em outros não. O estagiário esse mês está arrebentando a boca do balão lá...rsrsr

Bom dia, aqui substitui e deu certo. Reinstalei os componentes pelo ACBrInstall e voltou tudo ao normal

Bom dia, agora é aguardar a correção em ambiente de homologação... difícil demais

Bom dia, Pelo que aprendi aqui no fórum a situação atual é: - Para emitir NFCe não precisa do integrador já há um bom tempo. - Caso o estabelecimento utilize TEF ou POS, você precisa do Integrador pois deve enviar a ele as informações de pagamento em cartão. Att.

Boa noite, o que você alterou nas units?

Ótimo @José M. S. Junior Era esse o ponto da dúvida para eu conseguir entender o fluxo completo. Muito obrigado...

Bom dia @Juliana Tamizou, Li sim, porém no passo-a-passo de uma transação com TEF, no passo 1 não é explicado o que preencher no campo IDFila. Uma vez que ele é retornado no EnviarPagamento (POS), como vou obter ele?

Boa tarde a todos, Lendo o manual do Integrador Fiscal, ficou claro para mim que as etapas são: 1 - Abrir venda e lançar itens; 2 - Registrar formas de pagamento; 3 - Caso tenha pagamento através de POS ou TEF, deve ser enviada uma intenção de pagamento; 4 - Ao final da emissão do Documento, enviar a confirmação de pagamento com os dados da transação. Minha dúvida está nessa intenção de pagamento e na confirmação. No exemplo do SAT > Aba MFE temos: - botão "MFE Enviar Pagamento". No meu entender essa seria a intenção de pagamento tanto para POS quanto para TEF. Porém no exemplo, tem uma observação orientando a utiliza-lo quando for transação POS; - botão "MFE Enviar StatusPagamento". No meu entender nessa rotina seriam enviados os dados das transações tanto para POS quanto para TEF. Porém no exemplo, tem uma observação orientando a utiliza-lo quando for transação TEF; levando em conta as observações, da a entender que ambas são as intenções de pagamento, e posteriormente no botão "RespostaFiscal", seria enviada a confirmação. Porém no botão "MFE Enviar StatusPagamento", um dos parâmetros pedidos é o IDFila. Se esse botão for a intenção de pagamento para TEF, como terei o IDFila? Fiquei confuso com relação a qual seria o fluxo correto. Se alguém pudesse me esclarecer esse ponto, eu poderia até adaptar o Exemplo ACBrSAT e disponibilizar.

Pois é, pelo exemplo do SAT, o formato é MM/AA. Porém o SiTef retorna invertido e sem barra separadora. No Pay&Go ainda não consegui testar pois o mesmo não retorna os dados necessários. Estou aguardando o suporte deles retornar acerca disso. Tentei buscar aqui um manual com regras de layout mas não encontrei. Você teria o link para baixar @EMBarbosa ?

Obrigado Daniel, Foi o que eu havia previsto mesmo. Novamente, muito obrigado.

Bom dia a todos, Eu estou implementando o ACBrTEFD na minha aplicação SAT/MFE/NFCe e estou com dúvida nos parâmetros passados para o método CRT. - no "Indice" que seria para a ecf, vocês passam em branco? - no "documento", no caso de SAT/MFE, qual numeração passar uma vez que a aplicação não tem controle sobre a numeração? Na NFCe estou passando o numero dela. Grato a todos desde já.

Bom dia a todos, Estou com uma dúvida simples. Ao invocar a classe RespostasPendentes.NFCeSAT.DataExpiracao, essa mesma data de expiração é retornada (SiTef) no formato "AAMM". Para passar ao Integrador CE, vocês passam da forma que retorna do TEF ou formatam para MM/AA?

Componente OnGuard. É ótimo e fácil de implementar.