SGF/docs/SERVICE_INVOICE_ISSUANCE_SCOPE.md

Factura de serviço — âmbito mínimo de emissão

26/10/2026, Africa/Johannesburg. Versão 0.3, âmbito com implementação técnica isolada autorizada posteriormente, conforme secção 10. Base preservada: checkpoint 9f48004, cálculo condicionado aceite. Configuração/concessões reais e habilitação de emissão não são autorizadas pelo desenvolvimento técnico.

1. Base reutilizada e recorte proposto

Reutilizar a ficha local REAL_SERVICE_FISCAL_ASSESSMENT.md, aceitação do cálculo condicionado, matriz de informação documental, especificação e matriz fiscal reutilizada, preparação documental, pré-visualização e B1. A ficha nominativa permanece local; esta especificação não exporta o cliente ou os registos da base.

O perfil aprovado/activo e a decisão temporal aprovada mantêm os seus âmbitos. A segunda permite hoje cálculo condicionado, não determina exigibilidade ou apuramento. Não repetir a sua aprovação para voltar a demonstrar o que já foi aceite; uma autorização para emitir é um acto distinto.

Primeiro recorte: uma factura de serviço, uma linha, uma moeda explícita, preço sem imposto, sem descontos, retenções, adiantamentos, câmbio ou recorrência automática. Uma prestação e um rascunho existentes originam no máximo uma factura neste recorte; facturação parcial/dividida fica excluída. Factura não é recibo ou factura-recibo; emissão não declara pagamento nem reconhecimento contabilístico.

Entrega mínima proposta: revisão de prontidão → confirmação explícita de emissão → identidade documental e fotografia imutável → consulta e reprodução fiel do documento. O desenho pode ser implementado e provado em testes isolados antes da habilitação real; enquanto faltarem condições legais, o ambiente normal recusa emitir e a prova continua claramente sintética. Não apresentar uma simulação como factura válida.

2. Fontes reutilizadas e limites jurídicos

Não foi repetido o cotejo do InvesteMoz, consultado o portal ou efectuada nova pesquisa normativa nesta etapa. Reutilizam-se as referências/versões e os hashes já registados na matriz e na ficha:

Matéria	Origem já identificada	Uso e limite neste incremento
Base, taxa, exactidão e representação	IM-F v1.2, IM-P, IM-A; CIVA arts. 15/17; Lei 22/2022 republicada	Cálculo aceite é reutilizado. Política operacional de truncagem não é prova de conformidade universal de factura
Acontecimento e exigibilidade	IM-E, recibos L1 de 25/10/2026; CIVA arts. 7/8/17(2)	Distinguir regra pré-validada, facto efectivo, parcela e mês. Não converter próxima facturação em emissão/exigibilidade
Informação da factura	Matriz documental; CIVA art. 27, incluindo n.º 5 c/d já cotejado	Inventário de campos e componentes; confirmar cobertura integral dos requisitos aplicáveis antes de habilitar emissão. Não declarar que apenas os campos já implementados bastam legalmente
Alterações de 2026	Lei 10/2025, PDF 12–15 do exemplar BR 248/suplemento 1; art. 27(10), PDF 14, e art. 32	A submissão à AT é matéria distinta da apresentação visual e da identidade interna. O art. 32 rege os ramos declarativos já documentados, não numeração ou homologação do SGF
Regulamentação de emissão e software	RIVA art. 21 nos exemplares históricos já sinalizados; Decreto 8/2017/rectificações; comunicação regulamentar de Setembro de 2026	Referências históricas/anúncio não demonstram, por si, o procedimento vigente aplicável em 2026. Concluir apenas a lacuna específica necessária à emissão, sem refazer taxa/base/aritmética

Autorização/certificação do software ainda não demonstrada: não foi apresentada prova de que o SGF esteja autorizado/certificado/homologado para emitir, nem prova documentada de dispensa/inaplicabilidade. Também não está demonstrado qual procedimento vigente distingue autorização de sistemas/numeração, tipografias, facturação electrónica e comunicação de documentos à AT. São questões distintas; não inventar um número de certificação, assinatura, QR, fornecedor ou integração, nem afirmar que todos são obrigatórios ou dispensados.

Antes de emissão real: obter disposição oficial aplicável, artigo, vigência, âmbito deste modo de emissão e evidência do cumprimento ou da dispensa. Se existir acto/autorização, conservar referência verificável, entidade competente, titular/versão/instalação abrangidos e limites. Se houver comunicação prévia, formato obrigatório ou aceitação externa necessária à validade, definir o protocolo e estados com fundamento. A ausência destas provas bloqueia habilitação real; testes de aritmética, Git ou aprovação empresarial não as substituem.

3. Prontidão: o que bloqueia e o que nasce ao emitir

Elemento	Antes de emitir	No acto de emissão / efeito posterior
Emitente/cliente	Dados exigidos para o caso, origem e validação documental identificados. Nome suficiente para rascunho não significa prontidão de emissão	Fixar exactamente os dados usados; alterações posteriores do cadastro não mudam a factura
Serviço/prestação	Natureza, contraprestação, unidade de medida e cobertura relevantes demonstradas; não certificar execução a partir de rascunho	Preservar referências e versão da prestação. A factura não cria automaticamente prova de entrega
Perfil e resultado	Perfil aprovado, activo, vigente e compatível; resultado exacto actual. Representação documental aplicável validada, sem truncagem da base ou ajustes silenciosos	Revalidar contra a data/acontecimento efectivamente aplicável; se mudar a regra ou o montante, recusar e voltar à revisão
Decisão temporal	A actual aprovação de pending não basta. É necessária regra de determinação aprovada, com condições verificáveis para o ramo aplicável e prazo de emissão fundamentado	Quando a emissão for o acontecimento pertinente e tempestivo, capturar o instante real e determinar a consequência com essa regra. Não exigir uma factura já emitida para autorizar a primeira emissão
Datas anteriores relevantes	Se o facto gerador, prazo vencido ou outro acontecimento anterior for relevante, precisa de evidência antes da emissão	A emissão posterior não apaga ou desloca exigibilidade já ocorrida. Casos fora do primeiro recorte são recusados, não normalizados à data actual
Emissão efectiva	Não inventar uma data real antecipada para conseguir aprovação. Revisão pode mostrar «será fixada ao emitir» e a data esperada da operação	Instante do servidor com timezone explícita; guardar UTC, zona e data civil usada. Sem retrodatação/editabilidade neste primeiro recorte; mudança de dia desde a revisão obriga a rever
Período de apuramento	Não exige um mês inventado enquanto falta o acontecimento; exige regra aprovada que permita determiná-lo sem ambiguidade	Derivar do ramo de exigibilidade efectivamente fundamentado, na mesma confirmação; não deriva do ano da série ou do vencimento do cliente
Vencimento	Condições comerciais identificadas quando necessárias; «30 dias de serviço» não é prazo de crédito	Calcular apenas sob convenção acordada; não usar a próxima facturação como vencimento
Série e número	Série válida, âmbito/numeração inicial/fonte e processo de autorização identificados; ausência ou conflito bloqueia	Atribuir número definitivo uma única vez, dentro da operação controlada; nunca ao abrir a pré-visualização
Software e comunicação	Prova de conformidade/autorização/dispensa e processo de comunicação aplicável resolvidos	Se aceitação externa for condição, não marcar emitido antes dela; se comunicação for posterior, estado/prazo próprios e retries sem nova factura
Pagamento ao Estado	Não é necessário ter o apuramento líquido pago para criar uma factura; conhecer a regra declarativa não implica saldo calculado	Esta emissão não liquida o saldo ao Estado nem cria recebimento do cliente

O sistema deve apresentar bloqueios concretos e a fonte/condição correspondente. Não promover todos os campos de gestão opcionais a bloqueios legais: logótipo, contactos e instruções bancárias não passam a obrigatórios por constarem dos exemplos. Não reabrir a classificação contabilística para satisfazer emissão; se a operação exigir classificação, reutilizar a resolução existente sob o seu âmbito.

Estado do caso conhecido: a última conferência da pré-visualização mostrava dados documentais do emitente/cliente por completar e cobertura final não indicada; essa observação não é uma nova leitura da base. O cálculo e perfil estão aceites, mas não há prova de prontidão documental/fiscal integral. A decisão temporal permanece pending. Só confirmar como bloqueante cada falta que seja necessária ao caso/regra de emissão; não preencher a partir das imagens ou da data prevista de facturação.

4. Série, identidade e numeração — proposta técnica

• Identidade estável da factura separada do ID do rascunho, referência INT-B1, série/contador e ficheiro de apresentação. Unicidade proposta empresa emitente + tipo + série + número; série não é necessariamente ano e não pertence ao tenant como autorização geral.
• Uma série inicialmente para o tipo factura no âmbito aprovado; relação à unidade, ano/período e continuação de numeração exige decisão própria. Não criar automaticamente «FT/2026», começar em 1 ou importar o número das imagens.
• Cadastro de série versionado, estado aberto/encerrado, vigência, fonte/autorizações e contador protegido. Série encerrada não recebe novos números. Abrir/encerrar série não apaga documentos ou reutiliza números.
• Alocação sob bloqueio transaccional do contador; proibir duplicação/reutilização por API e na base, incluindo operações em massa. Concorrência em rascunhos diferentes da mesma série dá números distintos.
• Proposta local: atribuição de número e factura na mesma transacção, sem reserva exterior prévia. Falha anterior ao commit não produz uma factura; número não comunicado fora da transacção. Se regras legais/serviço externo exigirem reserva ou numeração não transaccional, rever este ponto e registar reservas/falhas explicitamente; não prometer ausência universal de lacunas ou apagar evidência de falhas.
• Reimpressão/reprodução conserva identidade, número, data e fotografia; rótulos original/cópia/duplicado e formato dependem das regras documentais aplicáveis, não de nova numeração.

5. Comando de emissão, fotografia e duplicados

1. Rever emissão: no contexto validado, consultar o rascunho actual e compor revisão coerente de cliente/emitente, prestação, preparação, cálculo, perfil, decisão/regra temporal, série, modelo e eventuais autorizações. Mostrar consequências e bloqueios; nenhuma atribuição de número.
2. Confirmar: pedido autenticado, CSRF, permissão própria, token de contexto, versões exactas, chave de idempotência e resumo criptográfico da revisão. O navegador não autoriza âmbito nem escolhe livremente taxa, número, data efectiva ou estado.
3. Revalidar e fixar: sob bloqueios consistentes, verificar direitos, prontidão, série, versões e regra temporal. Capturar o instante de emissão, resolver a consequência fiscal quando suportada, reconciliar montantes e atribuir número. Alteração material/viragem de data exige nova revisão, não substituição silenciosa.
4. Commit atómico: factura, fotografia, identidade/série/número, vínculo exclusivo ao rascunho/prestação deste recorte, auditoria e evento durável/outbox. Falha de qualquer componente desfaz o conjunto local. Nenhum consumidor contabilístico ou financeiro é executado neste incremento.
5. Recuperar: chave repetida com mesmo autor/conteúdo devolve a factura existente; mesma chave com conteúdo distinto é conflito. Duplo clique, timeout após commit, repetição de tarefa ou nova chave sobre rascunho já emitido não criam segunda factura. Disponibilizar consulta do resultado após resposta perdida.

Fotografia imutável: emitente/cliente e dados documentais usados; serviço/descrição/unidade/quantidade/preço; moeda; período/condições/vencimento; base, imposto exacto/documental, diferença e total; tratamento/taxa/fontes/política e versões; decisão/regra temporal e acontecimentos determinados; série/número/data efectiva; contexto/autor; versão de modelo e activos usados; instruções de pagamento se apresentadas; referência da conformidade/autorização aplicável. Preservar só o necessário, sem segredos.

A consulta emitida usa exclusivamente essa fotografia. Não reconstruir dados com cadastros actuais; guardar versão do renderizador/modelo e hash do artefacto final se existir. Hash é controlo de integridade técnico, não assinatura fiscal ou certificação. Falha posterior de geração de ficheiro não provoca nova emissão/novo número: reproduzir o mesmo documento fixado, conforme os requisitos do canal.

B1 continua exclusivamente confirmação interna histórica; não é convertido em factura emitida nem reescrito para ganhar dados ausentes. No mínimo, rascunho já bloqueado por B1 não é emitido directamente. Eventual passagem a novo rascunho ligado à origem precisa de desenho explícito, sem duplicação oculta da prestação.

6. Permissões e correcções

Direitos propostos, ainda sem concessão: service_invoices.view e .issue na unidade; invoice_series.view e .configure no âmbito da empresa, com restrições de uso por unidade. Confirmar nomenclatura final e matriz de contas antes de aplicar qualquer direito. Calcular, aprovar perfil/decisão temporal, gerir aparência ou confirmar B1 não concede emitir ou configurar séries. Revogação tem efeito no próximo pedido. Não atribuir automaticamente emissão a Osmane ou Samira.

Emitida significa imutável: recusar edição, eliminação, transferência de empresa/unidade e reabertura do original, também por SQL em massa. Antes da emissão pode corrigir-se o rascunho com novas versões/revisões; depois dela, a correcção deve ser documento/acontecimento próprio, autorizado, com motivo, autor, datas e ligação exacta ao original/linhas e impacto fiscal explicado.

No primeiro incremento, propor pedido de correcção pendente, sem efeito monetário, e consulta do original. Não implementar nota de crédito/débito ou anulação fiscal sem fundamento e âmbito aprovados. Não usar «cancelar» como apagamento, reutilizar número ou emitir substituição independente como atalho. Antes de habilitar emissão real, definir o procedimento legal e operacional para corrigir erros inevitáveis; se não estiver disponível no SGF, identificar procedimento externo autorizado e preservação das evidências, sem presumir que existe. Ausência de uma via válida de correcção é bloqueio de prontidão real.

7. Ecrãs e critérios de aceitação

Ecrãs mínimos: revisão de emissão no rascunho, com bloqueios e consequências; detalhe da factura emitida/reprodução fiel; configuração controlada da série; histórico e eventual pedido de correcção. Sem portal de clientes, envio por email, fornecedores, cobranças, stock ou contabilidade neste recorte. Canal/artefacto final precisa de decisão antes de implementar emissão real; uma página HTML não é presumida suficiente para todas as obrigações de entrega/conservação.

Provas isoladas com identidades sintéticas e sgf_tempo_test, sem operações fictícias na empresa real:

1. Prontidão incompleta, conformidade do software não demonstrada, série ausente/encerrada, moeda/perfil/regra incompatíveis e permissões insuficientes recusam emissão e não consomem uma identidade definitiva.
2. Cenário completo sintético produz exactamente uma factura, número único, data efectiva controlada, fotografia imutável e evento durável. Mudar cadastros/apresentação posteriormente não muda o emitido.
3. Pendência temporal aceite para cálculo não passa como autorização de emissão. Ramo dependente da emissão fixa o facto na confirmação, sob regra previamente aprovada; ramo anterior não é deslocado por data de emissão. Data futura prevista não se torna facto; viragem de dia obriga a rever.
4. Duplo clique, mesma/diferente chave, timeout antes/depois do commit e dois processos concorrentes não duplicam factura ou número. Falhas injectadas em contador/fotografia/auditoria/outbox provam atomicidade e recuperação.
5. Isolamento entre empresas do mesmo tenant e unidades, identificadores adulterados, revogação, versões antigas e alterações em massa recusados. Aprovações contabilísticas e B1 preservados, sem reruns desnecessários das entregas aceites.
6. Reprodução posterior usa a fotografia, não recalcula com regras actuais e não renumera. Pedir correcção não altera montantes/estado fiscal do original; ausência de correcção fiscal implementada fica explícita.
7. Nenhuma emissão marca recebimento, liquidação ao Estado ou lançamento como realizado. Provas sintéticas não retiram bloqueios de conformidade real nem seleccionam fornecedores.

8. Decisões realmente novas para delimitar implementação

Decisão	Natureza / saída necessária
Série inicial	Empresa, tipo, código, âmbito por unidade/período, numeração inicial/continuação e evidência de autorização aplicável. Não repetir decisões de regime, moeda ou taxa já aprovadas
Responsáveis e direitos	Quem pode emitir, configurar/encerrar série e pedir/tratar correcção; contas/âmbitos exactos sujeitos a confirmação específica
Canal documental	Representação a entregar/conservar e formato requerido: navegador, PDF ou outro com fundamento. Não escolher integração/fornecedor por omissão
Regra temporal para emissão	Quem propõe/valida a regra prospectiva e quais evidências fecham tempestividade/cobertura; preservar o facto efectivo para o momento de emissão. A aprovação anterior de pendência não é revogada nem convertida em determinação
Conformidade e correcção	Evidência oficial específica para software/séries/comunicação, representação monetária aplicável e procedimento válido de correcção. É validação normativa/operacional, não preferência visual ou novo ensaio aritmético

Recomendação de execução futura: primeiro resolver os bloqueios de prontidão que dependem de evidência/decisão, mantendo o sistema normal sem emitir; depois autorizar um único incremento de emissão/reprodução com as regras fechadas e provas sintéticas. Não criar um documento com aparência de factura fiscal apenas para contornar uma pendência legal. Se só for autorizada preparação técnica antes dessas provas, o modo real permanece bloqueado explicitamente.

Nesta revisão alterou-se apenas documentação. Nenhuma emissão, concessão, série, migração, recebimento, lançamento, teste destrutivo, publicação ou novo checkpoint foi executado. Não reabre 9f48004.

9. Decisões de desenho confirmadas pelo utilizador

Em 26/10/2026, o utilizador respondeu SIM à proposta de responsabilidades e navegador + PDF. Prevalece sobre as opções ainda abertas nas secções anteriores:

• Osmane prepara e emite. Emitir será uma permissão nova, a apresentar com conta, empresa/unidade e acção exactas para confirmação específica antes da concessão. Não é derivada de calcular, preparar ou gerir acessos; nenhuma concessão foi executada nesta revisão.
• Samira mantém a validação fiscal. Não recebe emissão ou administração por consequência desta escolha.
• Osmane propõe a regra temporal de emissão; Samira valida ou recusa a versão exacta. Reutilizar a separação de funções existente. Não converter a decisão temporal pendente aceite no incremento anterior em determinação de exigibilidade/apuramento ou autorização para emitir.
• Consulta no navegador e PDF reproduzível da mesma fotografia imutável, sem envio automático. Ambos apresentam o mesmo documento/identidade, conteúdo, datas e valores. Preservar a versão dos recursos/renderizador e, quando gerado, os bytes/hash do PDF; reconsultar ou descarregar não gera nova factura ou número. Não escolher agora biblioteca/dependência ou alterar versões.
• Série real ainda por decidir: continuação de série existente ou série própria do SGF, com suporte e controlo de transição para impedir sobreposição com outro emissor. Não atribuir código, número inicial ou data por omissão. Quem propõe/configura/encerra séries e quem trata correcções continua por indicar; não atribuir essas funções automaticamente a quem emite ou valida.
• Bloqueio real mantido: qualquer implementação futura antes de fechar a conformidade só pode ser demonstrada em ambiente isolado, com emissão real bloqueada. Esta confirmação de desenho não inicia implementação.

Verificação dirigida das lacunas de conformidade

Consulta em 26/10/2026 limitada a software, numeração/comunicação e correcção; não repetiu o cotejo de taxa/base/exigibilidade já reutilizado. Não se alterou o InvesteMoz ou acederam às suas configurações/bases.

Lacuna específica	Evidência localizada / alcance	Prova ainda necessária
Software: submissão versus aprovação	O índice oficial da AT — comunicados apresenta uma entrada datada de 01/02/2026 intitulada lista provisória de softwares de facturação. A abertura do endereço não disponibilizou articulado/anexo legível nesta consulta. A existência de lista provisória não demonstra certificação do SGF nem dispensa	Procedimento oficial aplicável, requisitos e evidência específica de autorização/certificação/dispensa para este software/instalação. Não declarar fechado com base em publicidade comercial ou lista de submissões
Regulamento e numeração/comunicação	A comunicação oficial do Governo anuncia alterações ao RIVA, incluindo o art. 21. É evidência de alteração anunciada, não substitui o articulado publicado e a sua eficácia. O art. 27(10) da Lei 10/2025 e o inventário anterior continuam reutilizados	Diploma publicado e disposições executórias que fechem autorização de emissão por computador, série/faixa/numeração e eventual comunicação à AT. Confirmar se a comunicação condiciona emissão ou constitui obrigação posterior. Não inventar API, prazo ou homologação
Correcção	O princípio aprovado de preservar o original e ligar a correcção permanece. A matriz documental e o percurso de serviços não comprovam forma/prazos fiscais da correcção real	Disposição oficial aplicável a anulação/rectificação e regularização de IVA, conteúdo do documento, evidência de conhecimento pelo destinatário quando exigível e procedimento autorizado. Não confundir recibo, estorno contabilístico ou pedido interno com nota fiscal válida

Resultado: as lacunas não estão encerradas por esta pesquisa dirigida. Não se conclui que o procedimento ou conhecimento não exista; falta evidência primária suficiente nos materiais efectivamente acessíveis. Não repetir perguntas de desenho já resolvidas nem pesquisas gerais sobre 16% ou cálculo exacto.

Lista reduzida de decisões pendentes: escolha/suporte da série real; responsáveis por configurar/encerrar séries e tratar correcções; confirmação específica dos futuros direitos de emissão; provas oficiais de conformidade acima. Responsáveis de preparação/emissão/validação temporal e canal navegador + PDF ficam fechados. Os factos efectivos de emissão continuam a nascer no próprio acto, sob regra previamente validada.

10. Decisões posteriores e execução técnica autorizada

O utilizador confirmou série nova, Osmane prepara séries e pede correcções, Samira valida a configuração e o tratamento fiscal. Essas decisões estão encerradas, juntamente com Osmane preparar/emitir, propor regra temporal, Samira validar essa regra e navegador + PDF sem envio automático. Código/número inicial reais e novas concessões serão apresentados separadamente antes de aplicação.

Posteriormente autorizou a implementação técnica e os testes isolados, com emissão real bloqueada até resolver conformidade e com confirmações específicas antes de migração em desenvolvimento/concessões. Resultado, provas, delta e propostas concretas em entrega técnica de teste. Não reabre o cálculo aceite nem habilita emissão real.