William F. L.

Segue em anexo contribuição para avaliação. Achei interessante porque esse WebService "CEP AwesomeAPI" retorna o código IBGE. ACBrCEP.pas

Aqui temos o seguinte fluxo de envio, não é 100% pois sempre somos surpreendidos com alguma novidade, mas no geral atende muito bem. AUTORIZAÇÃO DA NFC-e -> Ocorrem erros que mapeamos como Timeout: - essa NFC-e é gravada como "PENDENTE" no banco de dados junto com o XML e fica travada - operador recebe um aviso em tela que houve um erro ao enviar a NFC-e - é habilitado envio OFFLINE das NFC-e - o sistema duplica a NFC-e, sobe a numeração e envia como "OFFLINE" - imprime 2 vias do extrato - existe uma flag no sistema "Emitir Online Automaticamente", se houver internet na próxima venda o sistema tenta autorizar direto a NFC-e, senão joga como OFFLINE Á partir disso temos um monitor de NFC-e que fica monitorando NFC-e "OFFLINE" e "PENDENTE" OFFLINE -> o monitor só envia e protocola a autorização no XML PENDENTE -> aqui a coisa complica um pouco: 1 - monitor primeiro consulta se essa chave já existe na SEFAZ se existir ele cancela "por substituição" passando o número da NFC-e que foi gerada em contingência 2 - se a chave ainda não existir na SEFAZ ele automaticamente solicita a inutilização dessa numeração pendente

Você está tendo esse erro em produção ou no seu aparelho de desenvolvimento ? Porque se for em desenvolvimento experimente retirar o cabo USB de debug.

Colega não sei se enquadra no mesmo cenário que o seu, mas aqui homologamos com m-Sitef no SK 210 da Gertec e tinhamos o mesmo erro que o seu mas usando PinPad físico no totem. No nosso caso dava esse erro sempre que tinhamos o cabo USB de deploy plugado no totem, quando retiravamos o cabo a transação ocorria normalmente.

Na verdade eu só enviei a string <beep>, sem texto ou formatações. Mas vou procurar o método.

Bom dia Daniel, testei enviando 4x comandos "</beep>" intervalado com Sleep(100). Funcionou usando "ppEscGPrinter ", porém a impressora solta pequenos fragmentos de impressão para cada comando "</beep>". Existe alguma forma dela só emitir o beep, sem imprimir nada ?

Estou testando com nossa Elgin i8 mesmo, foram feitos 2 testes: 1 - Usando ppEscPosEpson (não emitiu beep) 1 - Usando ppEscGPrinter (emitiu apenas 1x o beep) Segue print do Demo e Log. log.txt

Olá, estamos implementando nossa fila de impressão com ACBrPosPrinter e está indo muito bem, porém surgiu uma situação de usar vários "Beeps" na mesma impressão. Testamos 1x o comando "</beep>" na Elgin i8 e foi tranquilo, porém tem um cliente que usa "10x" o beep no final da impressão. Era configurado isso direto no driver da impressora, mas estamos mudando para ESCPOS e assim não depender mais do driver. Mesmo enviando várias vezes o comando na mesma linha "</beep></beep></beep>" ou enviando um por linha, o beep só é emitido 1x. Testei no Demo do ACBrPosPrinter e só vai 1x mesmo, alguém sabe se tem algum segredo esse beeps ?

try // Rotina de Envio except on e:Exception do begin LRetorno.AddPair('message', e.message); LRetorno.AddPair('status', TJSONNumber.Create(500)); Res.Send<TJSONAncestor>(LRetorno).Status(500); end; end; Sugiro capturar "e.message" aqui vc terá sua mensagem.

Rapaz em vários grupos e até aqui no fórum tem vários relatos do mesmo problema em SP. É problema lá na SEFAZ, aqui também tenho cliente que emite 1 NF-e por mês e ontem deu consumo indevido no envio.

Aqui tivemos alguns chamados de consumo indevido, mas o cliente aguarda alguns minutos e consulta novamente, vem o protocolo de autorização.

Segundo a NT 2013.003 ele pode aparecer no quadro:

São Paulo anda ocorrendo mesmo, observe que pelo fluxo: - envia a nfe e a sefaz devolve o recibo - o acbr conforme configuração faz consultas até receber o protocolo Se ultrapassar o limite de tentativas aí recebemos lote em processamento. Essas consultas que costumam dar problema, aí colocamos a nfe em um status intermediário para posterior consulta.

"ahhhh como fico sabendo se origem desse consumo foi pelo IP ?" Consumo Indevido é sempre bloqueado pelo IP, porém acredito não ser o IP interno da sua rede e sim o IP público da sua internet. Tivemos ano passado um caso no Paraná, onde um cliente tomou dezenas de "consumo indevido" durante algumas horas e foi penalizado com o bloqueio do CNPJ junto à SEFAZ. O contador dele teve que entrar em contato e solicitar o desbloqueio. No nosso caso foi um monitor de NFC-e que ficou forçando o envio da mesma NFC-e que continha um item com "NCM inexistente".

Recebeu consumo indevido só resta aguardar o tempo necessário, aqui orientamos aguardar 60 minutos. Porém é interessante investigar a origem desse consumo indevido que é pelo IP. - várias tentativas com mesmo erro - consultas consecutivas