Tudo aqui vem directamente do estado real do projecto, não de uma promessa. Onde algo ainda não está validado, dizemos isso explicitamente.
O pipeline de build empacota todos os módulos (funcionais + o conector l10n_pt_arxi_signing_ws) com um MANIFEST.json com hash SHA-256 por módulo:
python3 fiscaldoo-infra/build/build_package.py \ --fiscaldoo-deploy /caminho/para/fiscaldoo-deploy/fiscaldoo \ --connector fiscaldoo-connector-odoo # produz dist/<versão>-<hash-curto>.tar.gz
Extrai no servidor e acrescenta ao addons_path — nunca substitui o que já lá está:
<odoo>/addons,<extraído>/addons,<extraído>/community
ANY_VALUE(), que o Postgres 15 não tem. Achado confirmado a testar o módulo contra um Odoo real, não assumido.Por omissão o conector corre em modo mock — nunca liga a lado nenhum, mesmo em bases de teste. Para ligar ao serviço de assinatura real:
| Parâmetro | Valor |
|---|---|
l10n_pt_arxi_signing_ws.transport | real |
l10n_pt_arxi_signing_ws.real_enabled | True |
requirements.txt, que é o que o Odoo.sh aceita por submódulo git.Passo planeado: fiscaldoo-connector-odoo como submódulo git do repositório do Odoo.sh, com as dependências Python num requirements.txt na raiz.
REST, JSON. Especificação completa em openapi/fiscaldoo.yaml — gerada a partir dos modelos reais do código, não escrita à parte.
| Método | Caminho | Para quê |
|---|---|---|
| POST | /v1/documents/sign | Assinar um documento certificado |
| GET | /v1/chain/summary | Contagem de documentos assinados por série |
| POST | /v1/instances/activate | Activar uma instância com código de uso único |
| POST | /v1/oauth/token | Trocar segredo por um token de 15 min |
| GET | /v1/licenses/current | Licença assinada em vigor (7 dias) |
| POST | /v1/instances/{id}/revoke | Revogar — pára emissão nova, nunca apaga dados |
| PUT/GET/DELETE | /v1/credentials/{client_id} | Credencial de subutilizador AT (nunca a principal) |
| GET | /v1/healthz | Estado de saúde — o mesmo que a página de estado pública usa |
Não exactamente. O software certificado (n.º 2790) é o produto da ARXI — Odoo + os módulos de localização portuguesa. O fiscaldoo é a marca comercial de como esse produto se vende e opera como serviço. O número 2790 nunca se "empresta" a terceiros.
Provavelmente sim. Um parceiro que instala, parametriza ou intervém tecnicamente enquadra-se como "instalador" nos termos do art. 11.º do DL 28/2019 — com obrigações próprias de integridade, distintas das da ARXI (produtor) e do cliente final. O contrato de parceiro define a repartição exacta.
Não é, por si só, ilegal — mas também não está confirmado por escrito pela AT (é a pergunta mais crítica do plano). A arquitectura foi desenhada para cumprir a letra da lei — chave sob controlo exclusivo do produtor, documento só "emitido" com assinatura válida guardada, numeração/cadeia respeitada — mas falta confirmação expressa antes de um lançamento comercial.
Sim, desde que sejam credenciais de subutilizador — nunca as credenciais principais do Portal das Finanças — com autorização contratual do cliente, cifradas, com possibilidade de revogação.
O processamento salarial centralizado é juridicamente possível, com a ARXI a actuar como subcontratante (RGPD art. 28.º) — mas exige um Acordo de Tratamento de Dados por cliente, isolamento, cifragem, minimização (dados de saúde/filiação sindical são categoria especial, art. 9.º), e uma avaliação de impacto própria.
Sim, preservando o histórico fiscal anterior sem o reescrever nem gerar novas assinaturas para documentos antigos — entram como "documentos integrados". Séries novas comunicam-se à AT normalmente.
Não — são proprietários, confirmado por auditoria directa ao código. Só um ficheiro tem uma excepção LGPL-3 documentada e isolada, por conter código do próprio Odoo.