William F. L.

Aqui tenho integração com SmartPOS e minha api envia apenas o json com todos os dados da Nfc-e após autorizada, no aplicativo aí gero o extrato na unha com as informações do json. Deu um certo trabalho no começo, mas agora roda liso.

Mas como o contador vai saber os "percentuais de ibs e cbs", quando estiver regulamentado a tabela por estado e munícipio, essa porcentagem será com base no destinatário !

Só um complemento, colocamos em produção essa alteração em 2 clientes com o modelo Print ID Touch. Via cabo de rede sem problemas, mas na USB tive q ajustar o arquivo "ACBrUSBID.ini" para:

Eu homologuei com 2 soluções usando m-sitef integrado ao totem SK210: - autopagamento (somente recebe comandas abertas) - autoatendimento (faz pedidos e também recebe) As 2 situações inicialmente existe uma pré-homologação do roteiro e depois homologação remota com a TEF House.

Consegui disparar o beep no modelo "Print iD". Foi ajustado o comando de beep para compatibilizar com os 2 modelos de impressora da Control ID. Será necessário ajustar o arquivo "ACBrUSBID.ini", pois foi alterado o trecho abaixo para identificar o "Protocolo ACBr" com o tipo específico "14-ppControlID": ACBrUSBID.ini ACBrEscControlID.pas

Segue em anexo contribuição para avaliação. Achei alguns tópicos para enviar um "beep" para impressora Control ID de forma manual, implementei seguindo os padrões do componente. Herdei da classe "TACBrEscPosEpson" que já usamos na Control ID e criei uma nova classe "TACBrEscControlID" apenas reescrevendo o método "Create". Modelos: Print ID Touch - OK Print ID - Não Funcionou ACBrEscControlID.pas ACBrPosPrinter.pas

Aqui temos essa cobrando de 2 modos: 1 - como acréscimo no cupom fiscal e com isso o estabelecimento paga imposto sobre esse valor 2 - como item no cupom fiscal, mas usando NCM e CFOP diferenciado * nesse caso nos passaram que existem algumas regras que o estabelecimento precisa seguir segundo a Lei 13.419 de 2017 (lei das gorjetas)

São 2 questões complicadas mesmo, atualizações e limite de requisições. Essa alteração que mandei até tenho usado aqui no dia a dia. Tenho uma outra consulta aqui para dados de empresa, mas essa API é paga e tem limite, porém faço um cache das informações em um banco online com "tempo de vida" dos registros, assim reduzo bem as consultas diretas.

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

O aparelho SAT que vai guardando esses cupons na memória interna do aparelho. Só complementando, o ACBrSAT em si não tem relação direta com esse "represamento" de cupons dentro do aparelho. Seguindo essa linha, quem preenche "Número do Cupom" e a "Data do Cupom" é o aparelho SAT, sendo assim se o cupom foi emitido em Dezembro, a data do cupom será de Dezembro. -> pasta fisica 12/2023 -> data do cupom 12/2023 -> envio para SEFAZ 01/2024 (o aparelho só tinha internet nesse periodo) Aqui isso já deu discussão com os contadores, pq alguns gostam de comparar o relatório do sistema com o excel que a própria SEFAZ disponibiliza no portal. Porém quando eles abrem o portal (no inicio do ano), os cupons "represados" no aparelho ainda não foram enviados para a SEFAZ, ai começa a dor de cabeça.

Olha, tentamos isso no cliente e no pc de testes, várias vezes, mas vai bem um tempo depois começa a para denovo.