Revenue Service Multi-Tenant Preparation

What exists today

• A normalized tenant/company authority connection model
• A normalized commercial/tax document lifecycle
• A mock Revenue Service provider adapter behind a provider interface
• A dedicated svc-rs backend slice with persistence and audit events
• A minimal profile UI for mock connection and draft/submission state

What is mock today

• Authority connection setup
• Document draft creation
• Submission state progression
• Status sync outcomes
• External document identifiers and provider payloads

Nothing in this slice calls a live Revenue Service API yet.

Core architecture

Authority connection

Each tenant/company gets its own connection record:

• tenantId
• provider = RS
• connection status
• credentials/token reference placeholder
• last sync / last error
• audit timestamps

External documents

Documents are stored with normalized internal states:

• DRAFT
• READY_FOR_SUBMISSION
• SUBMISSION_PENDING
• SUBMITTED
• CONFIRMED
• REJECTED
• CANCELLED
• SYNC_ERROR

Each record keeps:

• seller / buyer
• items
• amounts
• provider placeholder ids/status
• actor metadata
• audit timestamps

Provider seam

The live RS adapter will plug into the same interface:

• createDraftDocument
• submitDocument
• fetchDocumentStatus
• listDocuments
• cancelDocument

What plugs in later

• Real tenant authority auth/credential storage
• Live SOAP/REST provider adapter
• Real polling or callback sync
• Final tenant authorization model
• Production submission validation and RS-specific payload schemas

Current UI contract

The profile surface only consumes normalized internal state. It does not know about:

• SOAP vs REST
• final RS auth shape
• raw provider payload details
• final credential semantics

That separation is intentional to minimize future refactor.