T6B.2 Approved Bridge Contract¶
Decision date: 2026-08-17
Approver: requesting user (this conversation)
Status: IMMUTABLE T6B.2 IMPLEMENTATION CONTRACT
Scope: SC-ADM ↔ SC-FEES post-enrollment handoff only
Does not: certify T6B, authorize demo/production, invent pre-enrollment applicant billing, scholarship policy, gateway, or accounting.
This record is derived from the T6B.2 execute prompt plus the approved W03 and W10 contracts. It does not rewrite T6A-W03-approved-product-contract.md or T6B-FEES-approved-product-contract.md.
Canonical flow¶
W03 accepted
→ authorized Enrollment Officer completes accepted → enrolled
→ active same-company op.student exists
→ bridge creates one durable Admission→Fees handoff
→ bridge creates zero or more W10 fee enrollments in pending
→ a distinct authorized Billing Manager reviews and approves
→ W10 creates the canonical bill
→ payer uses canonical W10 payment lifecycle
The bridge must not create a paid or approved bill during W03 enrollment.
Post-enrollment boundary¶
W10 requires an active same-company student. T6B.2 V1 does not certify:
- formulir / registration fee before student creation;
- applicant-owned bill without
op.student; - direct
account.movefor an applicant; - payment as a prerequisite for W03 verification/acceptance/enrollment;
- applicant payment through legacy SPMB invoice controllers.
If those behaviors are required, engineering must stop with T6B.2 ENTRY BLOCKED — PRE-ENROLLMENT APPLICANT BILLING PRODUCT DECISION REQUIRED. They are fail-closed, not implemented.
Installation vs entitlement¶
| Admission module | Fees module | Admission entitlement | Fees entitlement | Bridge behavior |
|---|---|---|---|---|
| absent | any | n/a | n/a | module absent |
| any | absent | n/a | n/a | module absent |
| installed | installed | OFF | OFF | denied; no side effect |
| installed | installed | ON | OFF | feature_disabled; W03 standalone works |
| installed | installed | OFF | ON | feature_disabled; W10 standalone works |
| installed | installed | ON | ON | handoff may execute |
Auto-install occurs only when both parent modules coexist. Installation never substitutes for entitlement. Sensitive operations re-evaluate both flags per attempt. Existing sessions do not retain bridge authority after either flag is disabled.
Authority¶
- Enrollment Officer may originate a trusted handoff. They do not receive
finance.billing.manage, billing approval, verification, refund, or accounting. - System/worker identity (
SUPERUSER_IDprocessor, contextt6b2_bridge_processor) may create W10pendingenrollments only throughscola.w10.service.create_pending_from_bridge. - Distinct Billing Manager performs
pending → billedvia canonical W10. - Audit records W03 actor/role, processor uid, and later W10 approver.
Financial owner¶
SC-FEES is authoritative for template/rule version, frozen amount, enrollment, bill, payment, receipt, correction/refund/reversal, and balance.
SC-ADM may hold only: source admission reference, selected fee-template references, handoff state/reference, and a non-authoritative status projection. Admission must not copy a second mutable W10 ledger.
Fee selection¶
Only explicitly configured W10 templates on the admission register, valid for active company, active/effective rule, student course/batch when constrained, and current rule version.
No implicit global batch/course fallback. Missing configuration: enrollment succeeds; no fee enrollment/bill; handoff configuration_required; audit records reason; retry after configuration is idempotent.
W10 state¶
For each selected template the bridge creates at most one canonical W10 enrollment in pending. It must not create approved/billed enrollments, scola.w10.bill, receipts, payments, account.move, or journal effects.
Bill freeze fields: rule/template ID, rule version, amount, company, student, admission source reference, idempotency/business key.
Discounts¶
Affirmation/scholarship fields are informational. They must not change the W10 amount unless represented by an approved effective SC-FEES rule. Admission fee previews cannot override canonical W10 amount. Complex scholarship mapping is a named downstream decision.
Durable handoff¶
Model scola.admission.fees.handoff + .line.
States: pending, processed, configuration_required, recovery_required, cancelled.
Required fields: unique source key, attempt counter, bounded retry (MAX_ATTEMPTS=5), last error without secrets, source admission/student/company, source actor/role, resulting W10 enrollment IDs, correlation/idempotency keys, timestamps.
W03 enrollment transaction atomically commits the enrolled student and the durable handoff. Transient W10 failure must not roll back W03. Unknown failures fail closed into recovery.
Idempotency¶
- Handoff key:
adm-fees-handoff:<company_id>:<admission_id>:<student_id> - Enrollment key:
adm-fees:<company_id>:<admission_id>:<student_id>:<fee_template_id>:<rule_version>
Backed by SQL uniqueness and SELECT … FOR UPDATE. Same key + changed payload → conflict. Partial multi-template failure is independently reconcilable.
Tenant isolation¶
Same-company for admission, register, student, course, batch, template/rule, W10 enrollment, handoff, and bill. GT-T1 → GT-T2 is denied with zero mutation and no foreign leak.
Reversal¶
W03 enrolled is terminal (approved W03 contract). There is no W03 post-enrollment reversal route. Residual: do not invent one.
If an unbilled pending handoff is cancelled by an operator recovery helper: pending W10 enrollment may be cancelled; billed-without-payment requires canonical W10 cancellation; verified payment → recovery_required, no auto delete/refund.
No alternate lifecycle¶
Fail-close: Admission account.move, account.payment.register, /api/SPMB/payment/*, /api/SPMB/my/admission/*invoice*, legacy proof/payment, /web/dataset mutation, native Odoo/OpenEduCat fee mutation, gateway callbacks, website /my/child/.../upload.
Permitted: feature_disabled / accounting_excluded / gateway_excluded / HTTP 410; safe UI link to canonical W10; read-only projection of handoff status.
UI¶
Internal Platform: no launcher, no commercial package, no menu when either entitlement is off, no finance authority from Admissions visibility.
Minimal UI: entitlement-aware template picker; read-only handoff status; student/parent uses W10 billing pages; Billing Manager uses Fees UI.
English technical names; Bahasa Indonesia user copy.