...
- Reshop (para integração com processos internos)
- UX (para experiência do usuário e sincronização)
- ERP (para sincronizaçãoo UX sincroniza os dados com o ERP, que posteriormente realiza a sincronização com o Reshop)
Para que isso ocorra, é necessário que a comunicação com ambos os sistemas esteja ativa.
...
Atualmente, o processo funciona da seguinte forma: sempre que há uma venda, é obrigatória a disponibilidade do Reshop. Caso o Reshop esteja offline, não é possível concluir a venda.
Em breve será disponibilizado um novo parâmetro que permitirá que o fluxo de venda ocorra mesmo em caso de falhas de comunicação com o Reshop. Com o parâmetro ativo, a venda será realizada normalmente e os registros serão integrados no OmniPOS, UX, Mobile e Self-Checkout. No entanto, essa venda não será registrada no Reshop no momento da transação; o envio ocorrerá posteriormente pelo UX ou ERP, dependendo da configuração do apontamento.
...
| Âncora | ||||
|---|---|---|---|---|
|
...
| Âncora | ||||
|---|---|---|---|---|
|
⏱️ Timeout
No OmniPOS, há um timeout fixo de 10 segundos. Caso ocorra qualquer falha após esse período, o sistema exibirá uma mensagem informando o problemao tempo de espera para o fluxo de integração com o Reshop é controlado pelo parâmetro REQUEST_TIMEOUT_RESHOP, que define o tempo máximo de retorno das requisições entre o OmniPOS e o Reshop.
O valor padrão é 120 segundos (máximo permitido), podendo ser configurado entre 5 e 120 segundos.
BLOQUEIA_OPERACOES_SEM_RESHOP, que define se a venda continua ou é bloqueada em caso de indisponibilidade, garantindo maior resiliência nas falhas de comunicação.
Existe a opção de controlar o comportamento da venda em cenários de indisponibilidade do Reshop por meio do parâmetro BLOQUEIA_OPERACOES_SEM_RESHOP, que define se a operação deve continuar ou ser bloqueada em caso de falha de comunicação.