Painel de líderes

Boa tarde, Enviado para o SVN uma possível solução para o problema. Essa solução foi aplicada no Fortes, se faz necessário agora fazer algo semelhante para o Fast.

Em MG está ocorrendo essa rejeição em envio de nfe normal, mas não para todos os emitentes. Se enviar em contingência, a nfe é autorizada. Não é possível determinar a causa do erro. A migração de servidores está ocasionando várias rejeições.

Boa noite, Isso mesmo.

Olá amigos, aos que tem PDV no RS, seria isto no XML para venda Pix conforme Sefaz/RS indica? Ele validou o XML em homologação. Neste exemplo teve 3 Pix na mesma NFC-e: <detPag> <tPag>17</tPag> <vPag>6.00</vPag> </detPag> <detPag> <tPag>17</tPag> <vPag>7.00</vPag> </detPag> <detPag> <tPag>17</tPag> <vPag>10.00</vPag> </detPag> <infAdic> <infCpl>No.Interno:301888 / Vendedor:LOJA</infCpl> <obsCont xCampo="txidPIX"> <xTexto>d331dd6af4f6</xTexto> </obsCont> <obsCont xCampo="txidPIX"> <xTexto>d331dd6af4f6</xTexto> </obsCont> <obsCont xCampo="txidPIX"> <xTexto>d331dd6af4f6</xTexto> </obsCont> </infAdic>

Boa tarde! Por volta das 16:05 começamos a receber no canal #sefaz em nossa comunidade do Discord relatos de problemas ao tentar emitir Nota para Sefaz de São Paulo. O relato comum entre os membros é de estarem recebendo Time Out. Alguns também informaram estar recebendo "Erro 503 The Service is unavailable". Conferindo no DownDetector é possível observar que a quantidade de reclamações para a Sefaz de São Paulo subiram exponencialmente a partir das 16 horas: Não tem informação sobre contingência ativada no Portal da NFe até o momento da publicação deste tópico.

Boa tarde! Até onde meu conhecimento alcança, eventos apenas no WS da UF mesmo. Para MG, olha o que diz as instruções no portal SPED: "NF-e emitidas em contingência SVC: O evento de CC-e deve ser transmitido para a SEF/MG e não para a SVC. A partir do momento em que a NF-e autorizada pela SVC foi compartilhada com a SEF/MG o emitente poderá transmitir a CC-e para essa NF-e." Fonte: http://www.sped.fazenda.mg.gov.br/spedmg/nfe/Carta-de-Correcao/

Boa tarde, Normalmente o site downdetector é uma boa referencia quando a SEFAZ ainda não sinalizou que o serviço não está funcionando. Vejam esse tópico.

@cne Só uma observação... Sempre que vc envia não quer dizer que foi aceito e registrado os boletos. É Necessário pegar o retorno para que vc possa tratar os boletos rejeitados. Ignore se já faz tal procedimento.

Bom dia! Conferindo no painel da Situação-SVC é possível observar que há uma mensagem informando que a Sefaz BA está com contingência agenda para o dia 09/07/2023 com previsão de início as 00:00 e término às 08:00 do mesmo dia. Para usar o ACBr em contingência durante este período, por favor, siga as orientações deste tópico:

Estão atualizadas, como sabem estou mexendo nos componentes, então quando preciso efetuar um teste como esse por exemplo, eu coloco tudo oque está em produção do SVN para testar e confirmar se realmente não foi alguma modificação que eu fiz que acabou acarretando em algum mal funcionamento.

Obrigado Diego! Tenha um excelente dia!

Pessoal, vi que não respondi. Deu td certo, obrigado a todos!

grato por responder

Atualizei e o problema foi resolvido. Muito obrigado

irei tentar, obrigado

Eu mando o NSU registro 012-000 do PayGO para o cAut, até onde entendi era este pra mandar. Abra um tópico novo deste problema e não neste post que discute apenas a lei em si. E eu também estou com problemas com Vero quando tentamos usar BANRICARD, no POS passa normal, pelo PayGO diz produto inexistente. A PayGO disse que era com a Vero a Vero diz que é com a PayGO.

Olá @Daniel InfoCotidiano Segue print do e-mail que recebemos do banco. Fico no aguardo e obrigado.

com valor de 75 na LarguraCodProd Completed: At revision: 29984

é Fortes, mais vou esperar ele me enviar a tal legislação, obrigado.

acho que isso não ocorreria... em todo caso, se cai sempre no mesmo evento... é fácil de apenas ignorar o Enter, com Exit, caso você perceba que ele está em processamento... procedure TForm1.Button1Click(Sender: TObject); begin if not Button1.Enabled then // <---- AQUI ---- Exit; Button1.Enabled := False; // executa sua rotina no botão Button1.Enabled := True; end;

Boa tarde a todos! Conferindo no dia 03/07/2023 as 15:31 no Portal da Nota Fiscal Eletrônica, é possível observar que a contingência foi prolongada por mais um dia, agora com previsão de encerramento as 14:00 do dia 05/07/2023

Anexe o log do instalador mas se notar ele tá vendo a bpl do delphi 7 que tu tem no micro e tá confundindo com a sua do delphi 10.3 lembre-se de ter uma pasta só do ACBr. configurar as enviroments variables de ambos os delphis para ver cada um o seu. e rodar o instalador. além do fortes e não compilar manualmente os pacotes senão vira uma bagunça dentro seu windows. use somente o instalador

Boa tarde, A principio esse tipo de tratamento deve ser feito na sua própria aplicação. Um tipo de controle bastante comum é o "semáforo", onde quando uma operação é inciada você bloqueia e somente libera quando ela termina. procedure TForm1.Button1Click(Sender: TObject); begin Button1.Enabled := False; // executa sua rotina no botão Button1.Enabled := True; end; Acima um exemplo no click de um botão. Quando inicia a execução ele deixa o botão desabilitado para não ser clicado novamente e só vai habilitar o botão no final do processo. Esse mesmo tipo de tratamento pode ser feito com uma variável interna de controle ou com threads ou funções. Aí depende mais de como o seu código-fonte está estruturado.

Eu não uso os fontes do Acbr para montar o “txidPIX”. Então eu ainda estou um pouco perdido. Pelo que vi o TEF NSU que vem no TEF PayGo tem 40 digitos e o xTexto da NFC-e aceita até 60. Seria isto?

Bom dia! Essas propriedades são para que o componente realize a consulta automática do Lote ou NFe enviado previamente em modo assíncrono. Se você está recebendo a mensagem de Nota em duplicidade das duas uma, ou a NFe que estava tentando ser emitida estava realmente em duplicidade e esse era o retorno do processamento ou sua aplicação estava enviando novamente. Sugiro que reveja sua rotina. Vamos analisar por partes a sua configuração atual. Como você mesmo colocou, as configurações de tempo, são de fato em milissegundos. No seu caso, está configurado para que o componente espere 1000 milisegundos, ou seja, 1 segundo após fazer o envio da NFe para realizar a consulta do retorno do processamento pela primeira vez. Essa configuração faz com que o componente espere 2 segundos entre as tentativas de consulta. Esta configuração define que o componente deve tentar realizar a consulta no máximo 10 vezes até obter um resultado positivo. Esta configuração define que o componente vai aguardar até 30 segundos antes de considerar que houve time out na requisição. O TimeOut está com um valor bom, mas o Aguardar e o Intervalo, a meu ver estão muito curtos. Tente algo como:

Bom dia Léo, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa tarde, Devido ao timeout o componente não deve estar chegando ao ponto de salvar os retornos. Aumente o timeout para 30k ou mais que deverá resolver.

O TEF por API/DLL, PayGoWeb, é muito rápido e simples de instalar... Mas você deve tomar alguns cuidados para que ele funcione corretamente nos seus clientes Finais Se você está recebendo alguma das msgs de erro abaixo: SEQUENCIA INVALIDA DO NUMERO DE SOLICITACAO ERRO DE AUTENTICACAO DO PONTO DE CAPTURA A causa desse problema, pode ser o Fato de sua aplicação, que carrega a DLL da PayGoWeb, estar sendo executada em várias instâncias, ao mesmo tempo, na mesma máquina... Ou seja, o Operador executou a aplicação duas ou mais vezes, e está operando o TEF em várias janelas da sua mesma aplicação... Isso gera uma série de problemas, e deve ser evitado... O PinPad não poderá ser acessado em modo compartilhado, por várias instâncias da DLL da PayGoWeb, ao mesmo tempo, e você pode receber erros de acesso ao PinPad As tabelas internas da PayGoWeb, que ela cria em sua Pasta de Trabalho podem perder o sincronismo, pois agora temos várias instâncias da DLL da PayGoWeb gravando nas mesmas tabelas... Portanto, devemos evitar que a aplicação de Frente de Caixa, possa ser aberta várias vezes, na mesma máquina... Uma das técnica para fazer isso, é usar a API do Windows, com o método CreateMutex Veja um exemplo, abaixo, usando Delphi. program SeuPrograma; uses Interfaces, sysutils, IniFiles, Windows, Dialogs, Forms, .... ; {$R *.res} var Ini : TIniFile; UmaInstancia : Boolean; begin Ini := TIniFile.Create( ExtractFilePath(Application.ExeName)+ 'Config.ini' ) ; try UmaInstancia := Ini.ReadBool('Config', 'Uma_Instancia', false); finally Ini.Free; end; Application.Initialize; if UmaInstancia then begin CreateMutex(nil, True, 'NomeDoSeuPrograma'); // <--------------- AQUI ------------- if GetLastError = ERROR_ALREADY_EXISTS then begin MessageDlg('NomeDoSeuPrograma','O programa já está em execução', mtError, [mbOK], 0); Application.Terminate; exit ; end; end; Application.CreateForm(TFrmMain, FrmMain) ; Application.Run; end. Ou Seja, o Primeiro Mutex será criado com sucesso... Mas quando a segunda aplicação for executada, haverá um erro na criação do Mutex, e isso forçará a entrada no IF que aborta a execução do programa, fechando a segunda instância...