Lewati ke isi

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.move for 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_ID processor, context t6b2_bridge_processor) may create W10 pending enrollments only through scola.w10.service.create_pending_from_bridge.
  • Distinct Billing Manager performs pending → billed via 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.