guilhermesmc

char* __stdcall GetPortaSAT(char *numSerie, int numSessao, char *codAtivacao); char* __stdcall GetMapaPortasSAT(char *codAtivacao); int __stdcall AbreSerialSAT(int commPort, int nBaudRate, int nBits, int nParity, int nStopBits); os parametros nBaudRate, nBits, nParity e nStopBits podem ser informados todos como 0 pois são ignorados pela DLL.

Tive esse problema por utilizar caracteres especiais na descrições dos produtos.

Que nem eu disse anteriormente, eu fiz isso pois sei a infra que eu tenho. Realmente não aconselho essa opção para clientes que não tem uma infra adequada. (No break para os servidores/switchs, redundâncias e etc) Atualmente rodo 40 checkouts em 2 lojas utilizando somente servidores de sat e o único problema que tive até hoje foi com os equipamentos. Um outro potencial cenário favorável ao servidor de sat é quando o cliente opta por utilizar a NFCe e dai o servidor de sat encaixa na contingência.

Minha solução: Eu trabalho com numeros de cupom "virtuais" e utilizo o numero do cfe somente para fins fiscais. Cada documento emitido no pdv (venda, canc, fechamento op e etc), utiliza um numero sequencial do pdv, e é este que eu envio ao tef.

O único sat que é viável utilizar mais de 1 na mesma maquina é o da kryptus.

Segue exemplo funcionando da consulta.

Ele pede mas não valida, aqui se eu der um cancelar na tela de seleção de certificado ele acessa normalmente...

Faz umas 2 semanas que já estou utilizando normalmente.

Daniel, não discordo do seu ponto de vista e inclusive reconheço que não é qualquer cliente que pode fazer isso... Eu fiz pois sou o desenvolvedor e o cliente, então eu sei a infra que eu tenho e o que da ou não da para fazer, tanto que na filial em que utilizo os sats direto nos pdvs, é devido a loja estar em reforma e não ter a confiabilidade necessária para utilizar os servidores. A única coisa que eu fiz foi dar meus 2 cents sobre o assunto para quem quiser mexer com isso. Obs: Por isso mesmo que eu tenho 3 servidores totalizando 10 sats e não somente um servidor, afinal, quem tem 1 não tem nada rs.

A questão da redundância paralela é simplesmente isso: O servidor roda com 4 sats em paralelo no mesmo servidor, logo consegue processar 4 vendas por vez (balanceamento) e no caso de um dos sats parar os outros 3 continuam processando (redundância). Cada sat roda em um processo separado que o servidor gerencia, logo se um processo travar ou crashar os outros continuam funcionando. Cada processo tem um loop onde ele tenta pegar uma venda para processar. Processo que ele efetua: Existe uma tabela onde o servidor grava os xmls recebidos dos pdvs. Cada processo com o seu sat tenta dar um update na tabela colocando o numero de serie dele em um dos campos, por mais que os 4 tentem ao mesmo tempo o banco de dados só vai deixar um conseguir dar esse update. Se ele não conseguir, tenta com outro xml no banco. Se ele conseguir ele grava no banco o numero de sessão que ele irá utilizar para processar a venda (qualquer problema o numero de sessão está lá para ser utilizado no ConsultarUltimoNumeroSessao). Ele envia a venda, pega o retorno do sat e grava no banco. Durante todo esse processo o pdv estava conectado ao servidor consultando o "status" da venda enviada. Após o processamento o servidor retorna ao pdv o resultado (xml retornado ou erro retornado). O servidor só deixa conectar N sockets ao mesmo tempo, onde N = número de sats ativos e desbloqueados. No caso do client no pdv, ele tenta conectar no primeiro servidor, se não conseguir (servidor offline ou com todos os sockets em uso) vai pro segundo e assim vai. Uma vez que ele conseguir enviar o xml e pegar o identificador referente à aquele xml, ele continua com aquele servidor até o termino do processo. Espero ter ajudado... Abs

NFCE utilizada em modo offline: falta de conexão com a sefaz e também no caso de falta de conexão interna do estabelecimento (ex: todos os switchs/hubs queimaram)? No caso de SP o contribuinte que optar por utilizar a NFCE vai comprar um SAT para cada checkout também já que não existe contingência offline? Pra que utilizar NFCE em primeiro lugar? Ou compraria 1/2/3 SATs compartilhados para o estab inteiro só de backup no caso de queda da conexão/sefaz? Dependendo da quantidade de checkouts, do dia e da quantidade de máquinas POS que um varejo tem, fica praticamente impossível trabalhar nesse cenário. Qual a possibilidade real de 2/3 switchs darem problema no mesmo dia? Que eu equipe todos os pdvs com uma conexão de rede secundária (ex wifi), qual será meu gasto perto de ~1200/pdv por um aparelho que se vier a apresentar algum problema não tem conserto.

Com 60% pra mais de vendas em TEF depende muito se a pessoa tem dinheiro ou não na falta do mesmo. Quanto à NFCE, desculpe minha falta de familiaridade com o projeto... mas é o pdv que comunica diretamente com a sefaz e no caso de falta de conexão emite em contingência ou tem um servidor que faz o processamento online/contingênciado para os checkouts?

Se "o" switch morre, morre o TEF, a NFCE e assim vai... Investir em infra de rede não é algo necessário só para esse cenário, mas como vários outros também. Concordo que existe esse risco, por mais baixo que seja, por isso coloquei os caixas pares em um switch e os impares em outro. Em outra filial eu tenho caixas com SATs locais que funcionam 100% offline.

Bom vou deixar os meus 2 cents aqui. Estou trabalhando com SATs compartilhados desde junho de 2015, e no atual momento estou rodando uma loja de 23 checkouts com 4 aparelhos redundantes-paralelos resultando em um montante de mais de 260 mil cupons emitidos desde então. A diferença do sistema que eu desenvolvi tanto na parte do servidor quanto na parte do checkout é a questão da redundância paralela, os 4 sats do servidor funcionam em paralelo, tanto para balanceamento de carga quanto para backup. Na parte do checkout, eu tenho 3 servidores, um com 4 sats (o primário) e 2 servidores backup com 3 sats cada (secundário e terciário), que o pdv faz um "loop" até achar um servidor online que tenha sats "ociosos" (no meu cenário de 23 checkouts é muito raro que aconteça uma venda no servidor secundário por exemplo, a incidência de finalizações no mesmo instante é muito rara). Além de ter uma redução considerável nos custos, a administração dos aparelhos ficou muito fácil, já que periodicamente o servidor consulta status dos aparelhos, logs e etc. Na questão de infra as alterações que fiz foram: Comprei um switch a mais e metade dos pdvs ficaram no switch original e a outra metade no novo switch. Um dos servidores fica ligado em um dos switchs dos caixas. Obs: Só para constar, o paralelismo-redundante só é possível com equipamentos da Kryptus, nenhum outro fabricante consegue tratar mais que um sat por máquina de forma confiável.

Eu recomendaria o SAT da Kryptus, é o único que não utiliza emulação Serial para comunicar com o SAT, utilizar a usb diretamente é muito mais estável. Estou com vários sats deles ligados direto, comunicando no mínimo a cada 30 segundos com a "AC", 24h por dia e a grande maioria deles não teve um retorno sequer de timeout/falha de comunicação. Praticamente todos já efetuaram mais de 40 mil vendas cada.