[duvida] Solução para um Saas caso o cliente fique sem internet.

Meus 2 cents:

"Lasciate ogne speranza, voi ch'entrate"

Consulte sobre 'contingência offline nfce' no google

E voce provavelmente acabou de descobrir porque desenvolvedores individuais dificilmente se aventuram em sistemas ERP com escrituracao fiscal - ou porque acabam cobrando caro.

As regras da RECEITA e SEFAZ sao bem especificas (e podem variar de UF para UF).

De qualquer forma, em algumas impressoras SAT eh possivel armazenar o XML e enviar depois - mas existem regras para isso.

boa tarde, sr.

dadas as informações sobre o frontend ser em angular e o backend ser em .NET, simplesmente só posso sugerir utilizar tecnologias web, sem trazer complexidade a mais para o sistema.

alternativas: 1. off-line first via backend ou 2. off-line first via frontend.

1. rode uma versão de média fidelidade de teu backend em uma das máquinas conectadas a um mesmo roteador, abrindo uma porta reservada (p.e. 5000), de forma que teu backend escute nessa porta; teu servidor .NET pode expor o frontend em outra porta (p.e. 3000); dessa maneira, com apenas 1 computador host, vc consegue conectar todos os outros computadores de mesma rede a esse host que hospeda tanto backend quanto frontend. esse backend da loja local deve armazenar em sqlite os dados recentes primariamente em contigência, como provisório. durante uma oportuna e breve conexão à internet pública, o teu servidor principal de alta fidelidade, que é um backend completo, deverá receber todas essas informações, armazenando-as como versão final persistente, como se fosse um "dump".
   é evidente que agora tua monetização poderá agora corresponder a dois fatores na precificação: serviço offline sem emissão de nota fiscal, serviço online com emissão de nota fiscal. todo este fluxo no backend de média fidelidade deve funcionar graciosamente, com simples filas, ou utilizando-se da mesma tecnologia que já estava sendo utilizada no backend de alta fidelidade. dada a vantagem do padrão adapter, um ORM consegue adaptar as entidades tanto para um SGDB completo (postgres) quanto para um sqlite local. defina-se como de média fidelidade um backend o qual não possui conexão a uma API crucial para cumprimento de responsabilidades fiscais de médio e longo prazo; apesar disso, é suficiente para suprir com as responsabilidades administrativas e logísticas de curto prazo.

2. para uma solução viável somente ao frontend, como já foi dito várias vezes no tabnews em outros posts, reitero e ratifico que um PWA (progressive web app) com service workers e utilizando-se da API de websql ou indexeddb seriam suficientes para armazenar dados temporários no frontend acerca de alterações, edições e modificações off-line sem comprometer a consistência dos dados, uma vez que a maior parte das alterações para um sistema como esse podem ser executadas de forma transacional, como um livro de contabilidades, logo basta que se crie A. um livro contábil parecido com um log via indexedb ou B. um banco websql com resultado final das movimentações gerais. recomendo a opção "A", pois garante maior atomicidade, crítica para um sistema como esse. assim, quando a conexão voltar, realiza-se um dump geral.
   literalmente, como outros colegas comentaram, um sistema como esse é clássico.
   utilizar a alternativa 1 rende mais monetizações porém contrapõe-se pela necessidade de configurar infra caso inexistente. utilizar a alternativa 2 permite lançar um otimizado MVP mais reprodutível e ainda poder adicionar um PWA o qual pode ser vendido como aplicativo de celular ou programa dr desktop.
   no cenário clássico, com angular, muitos utilizam o capacitor para criar web apps com maior fidelidade (frontend).
   busque abstrair mais, e provavelmente uma parte da regra de negócio deverá ser redundante no frontend (secundária, pois backend deverá validá-la e transformá-la). garanta transações atômicas, com logs descritos e suficientes para quando for necessário realizar o dump. não obstante, pensando no problema dos sistemas distribuídos, talvez ainda seja interessante garantir eliminar redundância de informações duplicadas desnecessariamente, sincronização de relógios, etc.
   sempre que offline, garanta um early success visível, emita uma nota em contigência conforme as normas fiscais vigentes, e defina cláusulas no contrato bem conversado com o cliente teu (a loja).

um sistema web é MVP, e provavelmente o sr escolheu uma boa stack para os prováveis casos de uso que imagino.

oq o sr pensou para resolver isso?

aguardamos retorno.

Alguns colegas já mencionaram a solução para emissão da nota fiscal offline (emissão em contingência). Mas a questão que fica é: Se o cliente ficar sem internet, como ele vai acessar o seu SaaS?

o problema apresentado é uma saída para o caso de ter alguma falha na comunicação do seu sistema com a api geradora da nota.
mas se o seu cliente ficar sem internet, o seu saas ficará inacessível.

Agora, o que penso é que você realmente não precisa se preocupar com isso.
hoje em dia, é muito improvável que as pessoas fiquem sem internet.
que, dependendo do caso, se o cliente ficar sem internet ele até fica sem vender.

Pra emitir uma nota de maneira 100% offline, ou seja, quem está sem internet é o estabelecimento e não a sefaz, você tem duas opções:

• ter seu sistema rodando local na máquina do PDV
• ter seu sistema web rodando na rede do cliente.

o que eu mais vejo é a primeira opção. Mesmo empresas que tem o ERP web o PDV fica local no computador do caixa. Afinal ainda pode acontecer problemas na rede interna.

Eu participei de um projeto (como arquiteto e principal implementador) de um módulo (emissão de nfce / sat) do PDV de uma rede de fast-food. Eles usam a primeira opção: cada PDV tem uma cópia do programa de vendas + uma cópia do sistema emissor de notas.

Claro que isso implica em sincronização de dados, mas é o preço de trabalhar offline.

Nunca passei por isso, mas pensando aqui por alto. Você pode criar um modo offline, e criar um armazenamento local para emissão futura, quando a internet voltar. Ou um sistema de filas offline, deixando o gerenciamento apenas no back. Pode usar um banco mais leve, até mesmo um sqlite só para armazenar as notas pendentes e talz.

Tem esse conceito de local-first, ou offline-first. Talvez te ajude ao menos derivar outra ideia seguindo no mesmo caminho:

https://dev.to/lucasheriques/aplicacoes-local-first-o-futuro-da-web-4nf3

Não fazer um SaaS é a forma mais óbvia. Todo mundo só fala em SaaS porque é modinha, do ponto de vista de engenharia nem tudo faz sentido ser SaaS. Na verdade poucas coisas são claramente melhor para o usuário, mas é feito ou porque a pessoa é só "maria vai com as outras" ou porque ela entende que financeiramente dá mais lucro e pode ser mais fácil vender algo que a pessoa não vê quanto vai gastar no longo prazo, que quase sempre é mais do que se ele tivesse uma solução on-premisses.

Claro que eu poderia dizer que da mesma forma que se a pessoa depende do computador para fazer algo crítico precisa ser contingência de energia e de equipamento, se depender da internet precisa ter alguma contingência também, nem que seja pelo celular, satélite ou algo assim, depende do quanto teria de prejuízo se estiver tudo parado, as chances de parar e se compensa o cuto para ter essa contingência. Ou coloque em contrato que você não se responsabiliza se ele ou você ficar sem internet, procurando um advogado obviamente para fazer de forma séria, a nã oser que o objetivo seja só brincar mesmo.

Fora isso teria que fazer um SaaS falso, no fundo funciona local e o remoto vira quase um backup e talevz algumas tarefas não críticas que sejam exclusivas no seu servidor e não local. Mas derrota o objetivo, se for para fazer isso volte para o primeiro parágrafo.

Para ser mais sacana pode fazer algo local de um jeito que sirva para emitir a nota fazendo tudo manual, assim essencialmente não precisará de um banco de dados. De qualquer forma precisa ver a legislação atual e do local onde será usado para ver o quanto pode fazer isso, se dá para emitr sem enviar pela internet na hora e outras coisas legais.

Ainda tem alguns detalhes do que poderia fazer, mas aí vira consultoria.

Na verdade, fazer tudo web e SaaS costuma ser um abuso técnico, em geral piorando a experiência do usuário, e ficar sem ação é só um dos problemas. Quem sabe desenvolver software de verdade faz uma solução local e com cliente nativo com o mesmo nível de facilidade de web/SaaS. Mas sabemos que anda raro esse tipo de profissional hoje em dia.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Meus 2 cents expandidos:

Existem 2 questoes aqui: alimentar os dados dos sistemas internos (p.ex. estoque) e gerar a informacao fiscal - cada questao tem de ter tratamento diferente.

Se a internet esta fora, o que precisa fazer:

• Armazenar o conjunto de acoes que irao atualizar os sistemas (um exemplo bem simples e canhestro: um arquivo SQL contendo a sequencia de comandos BEGIN/INSERT/UPDATE/DELETE/COMMIT que devera ser executada no banco de dados principal. Nao eh uma abordagem para producao, mas fazendo isso voce vai perceber o caminho.)

• Informacao fiscal: Na emissao de contingencia voce gera dados especificos - grave estes XML equivalentes e depois envia para a SEFAZ. Tem um monte de detalhes aqui, mas a ideia basica eh esta. Se voce estiver usando uma impressora SAT, veja na documentacao dela como trata off-line, muitas ja fazem isso de forma automatizada.

Entao o teu SaaS vai ter uma versao local para receber os dados acima quando estiver offline - basicamente eh isso.

Outra questao: as vezes tem internet, mas a SEFAZ esta fora - neste caso o SaaS funciona normalemente (p.ex. atualizacao estoque), apenas gera os XML de contingencia para envio posterior.

você precisa que a aplicação continue acessível, mesmo que ele fique sem internet, esse é o ponto principal. se for um problema apenas com a sefaz, emite em contingência e envia depois.

solução total do problema: você precisa que pelo menos parte do seu saas rode no seu cliente. Algo instalável mesmo. e tem várias estratégias para isso. você pode instalar um "servidor" e os PDVs acessam os dados necessarias via LAN. Outra forma um pouco mais distribuída é ter "Agentes" em cada PDV, onde não seria necessário um sercidor centralizado.

isso não precisa ser tão complicado comi parece. provavelmente seu saas foi construído com tecnologia web. você pode fazer uso de ferramentas como o Electron por exemplo. E assim você pode fazer rotinas de fallback como por exemplo, está sem internet, vai salvando as coisas em um banco de dados local, que poder um SQLite. Quando estiver com internet novamente, sincroniza tudo com seus backend que vc na tem hoje. Esse seria com o modelo de agentes. Tendo uma aplicação servidora local on-premisse no cliente, muda só wue os PDVs vão se comunicar com o servidor local apenas. e esse local é quem vai sincronizar com a nuvem.

Sou CTO de uma empresa SaaS a mais de 10 anos no mercado, já tivemos uma versão funcional de nosso SaaS offline, isso fazia sentido 6 ou 7 anos atrás.

Atualmente se o estabelecimento ficar sem acesso a internet por mais que 10 minutos tem algo muito errado, especialmente quando se tem uma versão mobile da aplicação que ele pode abrir rapidamente em um 3G comum, ou compartilhar via wifi esse 3G com seu PC ou Notebook de "PDV".

Temos mais de 10 mil estabelecimentos usando nosso SaaS no BR, e mais de 1 milhão de transacoes processadas para clientes finais todos os meses.

Não temos absolutamente nenhum pedido de recursos offline a mais de 4 anos em nosso suporte.

Apenas pensem fora da caixa, tenham recursos criticos rodando em uma versão mobile e sucesso!

*Sim nós também emitimos notas fiscais em alguns planos. Elas podem ser entregues eletronicamente assim que forem emitidas.

Não tem como emitir nf offline, precisa consultar uma api do governo para validar a nota.