Sim. Um segundo atelier, uma segunda loja, vários locais de obra: o local é um DADO que você descreve no momento da geração, não uma versão do software a comprar. Cada registo está associado ao seu respetivo local, as listas são filtradas, os indicadores são calculados apenas sobre o âmbito que definiu, e nenhuma linha da tabela de preços depende do número de locais. Há dois limites importantes a conhecer antes de começar: não existe um seletor GLOBAL de local que mude toda a aplicação de uma só vez, e as contas não têm restrições por local, uma conta com permissão de leitura acede a tudo. Esta página explica o que funciona, qual a forma a escolher conforme os seus locais e o que exigiria desenvolvimento adicional.
A armadilha não é o preço, é a duplicação
O que os comparativos do setor descrevem é muito consistente: quando uma pequena empresa abre um segundo ponto de venda sem uma ferramenta pensada para isso, instala uma CÓPIA do sistema existente. O resultado? Dois ficheiros independentes, duas faturações separadas e nenhuma visão global sem uma compilação manual no final do mês. A isto junta-se uma frustração mais insidiosa: muitas ferramentas anunciam «multi-loja» sem oferecer verdadeiro controlo centralizado, somou pontos de venda, mas não criou uma rede.
A questão, portanto, não é «este software oferece uma opção multi-lojas?», mas sim «como é que o local está representado nos meus dados?». Trata-se de um problema de MODELIZAÇÃO, e é exatamente neste terreno que uma aplicação descrita e depois gerada se comporta de forma diferente de um produto pronto a usar: não há nenhuma versão superior a desbloquear, há apenas uma descrição a fazer corretamente, uma única vez.
O local é um dado, não uma versão do software
Na prática, descreve-o como qualquer outro elemento: «Tenho dois ateliers, Norte e Sul; cada intervenção, cada peça em stock e cada cliente está associado a um deles, e quero ver os meus indicadores por atelier.» O gerador produz então a estrutura correspondente, a entidade ou lista de valores, a associação de cada registo, os ecrãs com filtros. Nada é adivinhado: o que não escrever não existe, e o que escrever é produzido de forma determinística.
Um ponto merece ser destacado com clareza, pois é invulgar: nenhuma linha da grelha de preços depende do número de locais. Os planos distinguem-se pelo número de aplicações ativas e pelo volume de geração, não pelo número de estabelecimentos, ateliers ou locais de obra que a sua aplicação gere. Um terceiro local não é um novo patamar a alcançar, é simplesmente mais um valor numa lista.
A forma a escolher conforme os seus locais
Existem duas formas, e elas não produzem o mesmo resultado, por isso, vale a pena escolher com conhecimento de causa. Se os seus locais forem poucos e estáveis, dois ateliers, três lojas, declare-os como uma LISTA DE VALORES. É esta a forma que oferece mais funcionalidades: o painel de filtros inclui então um seletor de local ao lado da barra de pesquisa, o filtro escolhido permanece na URL da página, logo, um link como «intervenções em atraso no atelier Sul» pode ser enviado tal qual a um colega, e as vistas que agrupam por estado também conseguem agrupar por local.
Se os seus locais forem fichas completas, com morada, responsável, horários e contacto, então são ENREGISTOS à parte, ligados aos restantes dados. Ganha a ficha completa do local, mas perde o seletor imediato: o painel de filtros só adiciona um critério dedicado para listas de valores; os restantes campos ficam integrados na pesquisa de texto integral, que já os abrange. E, em ambos os casos, um indicador do painel de controlo pode ser delimitado a um local específico, com um clique que leva diretamente à lista correspondente, já filtrada.
Os dois limites a conhecer antes de começar
O primeiro: não existe um seletor GLOBAL de local. O filtro vive em cada lista individualmente; não há um interruptor no topo do ecrã que coloque toda a aplicação «em modo atelier Sul» durante a sessão. Para uma estrutura pequena que pretende precisamente uma visão global, isto não é um obstáculo, é até o contrário do problema descrito acima. Já para quem passa o dia inteiro num único local e nunca quer ver os restantes, trata-se de um verdadeiro incómodo, e é melhor saber disso desde já.
O segundo limite é mais grave: as contas não têm restrições por local. Uma aplicação com autenticação inclui uma gestão real de utilizadores, cada um com as suas credenciais e permissões, leitura apenas ou edição, mas essas permissões aplicam-se à aplicação como um todo, não a um perímetro específico. Uma conta com direito de leitura lê tudo. Se a confidencialidade entre locais for um requisito, há dois caminhos: adicionar esse isolamento ao código, que é seu e exportável, ou gerar uma aplicação distinta para cada local, aceitando assim voltar exatamente ao problema inicial: a ausência de visão global. É melhor dizer isto desde o início do que descobrir depois.