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.