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-rsbackend 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:
tenantIdprovider = RS- connection status
- credentials/token reference placeholder
- last sync / last error
- audit timestamps
External documents
Documents are stored with normalized internal states:
DRAFTREADY_FOR_SUBMISSIONSUBMISSION_PENDINGSUBMITTEDCONFIRMEDREJECTEDCANCELLEDSYNC_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:
createDraftDocumentsubmitDocumentfetchDocumentStatuslistDocumentscancelDocument
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.