@mj-biz-apps/orders-core-entities-server 0.0.1 → 5.2.0

package/dist/OrderEntityServer.d.ts

@@ -0,0 +1,542 @@
+/**
+ * OrderEntityServer — the server-only Order subclass that makes booking atomic (plan D12).
+ *
+ * On the FIRST transition into `Confirmed` (plan D8), one transaction covers:
+ *
+ *     order header  →  its lines  →  one JE per line  →  each line's JournalEntryID stamp
+ *
+ * Any failure rolls the whole thing back. A confirmed order without its journal entries is
+ * invalid state, so there is deliberately no partial-success path and no compensation logic.
+ *
+ * The JE set is written by accounting's `Accounting.CreateJournalEntries`, whose own transaction
+ * NESTS inside ours as savepoints — so the single outer commit here covers the order row and
+ * every entry. (This is why no TransactionGroup plumbing is needed; nesting composes.)
+ *
+ * PROVIDER DISCIPLINE (plan D12): everything uses `this.ProviderToUse` — the entity's own
+ * provider — throughout. A fresh global `Metadata` inside the transaction path would open a
+ * SECOND connection that cannot see our uncommitted work, silently breaking atomicity.
+ *
+ * IDEMPOTENCY: booking keys off `ConfirmedAt`. Once set, re-saving a confirmed order updates the
+ * row normally and never re-books. `OrderLine.JournalEntryID` is additionally NULL→value-once at
+ * the database level (trigger 51008), so a double-book is refused by the DB even if this class
+ * were bypassed.
+ *
+ * CONNECTS TO:
+ *   FACTORY:  OrderJournalEntryFactory (./OrderJournalEntryFactory.ts)
+ *   RESOLVER: GLAccountResolver (./GLAccountResolver.ts)
+ *   OP:       'Accounting.CreateJournalEntries' (@mj-biz-apps/accounting-core-entities-server)
+ */
+import { EntitySaveOptions, ValidationResult } from '@memberjunction/core';
+import { OrderHeaderEntity } from '@mj-biz-apps/orders-entities';
+import { type ManualDiscountRequest, type RequestedCharge } from '@mj-biz-apps/orders-entities';
+export declare class OrderEntityServer extends OrderHeaderEntity {
+    /** Price decompositions produced during this save, written once the lines have IDs (D69). */
+    private _priceComponents;
+    /** Why a line owes no tax, by line index — written as a zero-amount component (D73). */
+    private _taxReasons;
+    private _manualDiscounts;
+    private _charges;
+    /**
+     * The total the CALLER was shown, if they want the confirm to refuse when it no longer matches.
+     *
+     * Between a user reading a total and pressing Confirm, a promotion can expire or a rate can
+     * change, and without a guard the order books at the new number in silence. `Orders.ConfirmOrder`
+     * accepted `ExpectedGrossTotal` for exactly this and then read it nowhere — a guard that reads as
+     * enforced and is not, which is the failure mode this codebase keeps finding.
+     *
+     * It was implemented once by running an ENTIRE second booking through a rolled-back transaction
+     * purely to learn the total, and removed because that cost was not acceptable. Its correct home
+     * was always inside the booking transaction, where the real gross exists anyway — which is where
+     * it now lives. Left null, nothing changes.
+     */
+    ExpectedGrossTotal: number | null;
+    /**
+     * Promotion and charge decisions made by `prepareLines` and consumed by `savePendingLines`.
+     *
+     * They are decided while the lines are still in memory — a Confirmed line is frozen by trigger
+     * 51003 — but the ROWS they produce need line keys, so writing them waits until after the
+     * inserts. The two halves used to be one method; they were split when companion validation
+     * moved the deadline for a complete line ahead of the header save.
+     */
+    private _pendingPromotions;
+    private _pendingCharges;
+    /** Codes that resolved to nothing usable, so the caller can tell the customer WHY. */
+    private _unusableCodes;
+    /**
+     * Ad-hoc discounts with a stated reason, each gated by the applying user's SalesAuthority.
+     *
+     * Named `Requested…` for the same reason as {@link RequestedCharges}: `Adjustments` is the
+     * collection holding what the engine decided, and a request is not that.
+     */
+    get RequestedDiscounts(): ManualDiscountRequest[];
+    set RequestedDiscounts(value: ManualDiscountRequest[]);
+    /**
+     * Charges to apply to this order (D71) — shipping, handling, tax layers. Computed AFTER
+     * promotions, because a charge's basis is the discounted line.
+     *
+     * NOT named `Charges`: that is now the related-record COLLECTION on the generated class, which
+     * holds the rows the engine wrote. This is the request channel a server-side caller uses — the
+     * two meet in `drainStagedPricingRequests`, which reads staged rows into exactly this shape. A
+     * browser has only the collection, because it cannot name a charge type by code.
+     */
+    get RequestedCharges(): RequestedCharge[];
+    set RequestedCharges(value: RequestedCharge[]);
+    /**
+     * Codes that did not apply, and why — 'no such code', 'not currently running', 'this customer
+     * does not qualify'. Silence is the wrong answer here: a customer who typed a code needs to be
+     * told it did nothing, and told what to do about it.
+     */
+    get UnusablePromotionCodes(): Array<{
+        Code: string;
+        Reason: string;
+    }>;
+    /**
+     * WITHOUT THIS, NOTHING BELOW RUNS.
+     *
+     * `BaseEntity.DefaultSkipAsyncValidation` returns **true** — `Save()` calls `Validate()` always
+     * but reaches `ValidateAsync()` only when a subclass opts in. This class never did, so its
+     * entire async validation block was dead code from the day it was written: the "an order
+     * entering the booked state must have something to book" rule never fired, and neither did the
+     * loop that surfaces each line's `ValidateAsync` failures against the order.
+     *
+     * That is not a theory. Saving an order straight to Confirmed with ZERO lines succeeded and
+     * produced ORD-000030 — a confirmed order with nothing on it. `ProductPriceEntityServer` is the
+     * only class in this package that got this right, and its comment says exactly why.
+     *
+     * The failure mode is the dangerous kind: the rule reads as enforced, reviews as enforced, and
+     * is not. If you add a `ValidateAsync` to any entity here, add this override with it.
+     */
+    get DefaultSkipAsyncValidation(): boolean;
+    /**
+     * The one order rule that CANNOT be decided without the database.
+     *
+     * The payer rule, the status-transition guard and the has-lines rule for a loaded collection all
+     * moved to `OrderHeaderEntity.Validate()`, so the browser now refuses those before a round trip.
+     * What is left here is the case the browser genuinely cannot answer: an order that is already
+     * saved, being confirmed, whose `Lines` collection was never loaded. In memory that is
+     * indistinguishable from an empty order — and answering "empty" would refuse a perfectly good
+     * confirm of an order whose lines are sitting on disk.
+     *
+     * Per-line validation is no longer fanned out by hand. `Lines` is a companion, and
+     * `BaseEntity.Save()` validates every companion — including pending removals — before the first
+     * row is written, attributing failures by position (`Lines[3].Quantity`).
+     */
+    ValidateAsync(): Promise<ValidationResult>;
+    Save(options?: EntitySaveOptions): Promise<boolean>;
+    /**
+     * Turn a thrown booking error into the `BaseEntityResult` a caller can read off `LatestResult`.
+     * The message is the error's own text — GLAccountResolver and SubscriptionBehavior both write
+     * messages meant for a human, so passing them through beats a generic "save failed".
+     */
+    private buildFailureResult;
+    /**
+     * Resolve and store this order's due date, walking the terms rungs (D83).
+     *
+     * A STATED DUE DATE IS LEFT ALONE. `PaymentTermsBehavior` reports whether the answer came from
+     * the caller, and a stated date is never recomputed — that is how a contracts app supplies terms
+     * Orders has no way to derive, and how a negotiated date survives the next save.
+     *
+     * The resolved TERMS are recorded alongside the date when the order did not name them, so the
+     * invoice can print "Net 30" rather than inferring it back out of an interval.
+     *
+     * A failure here does not fail the confirm. Booking is the irreversible step and money has
+     * already moved in the ledger; refusing it because a lookup could not be read would be a far
+     * worse outcome than an order that falls back to due-on-receipt and says so in the log.
+     */
+    private resolveDueDate;
+    /** This buyer's negotiated terms, joined to their net days. */
+    private customerPaymentTerms;
+    /**
+     * The selling company's default terms — the last step of the due-date walk before "due on
+     * receipt" (D83).
+     *
+     * Reads `OrderCompanyPolicy`, NOT accounting's `AccountingCompanyProfile`.
+     *
+     * It used to read the latter, and accounting removed that column (their issue #22) on grounds
+     * this codebase agrees with: accounting records what was owed and when, but deciding WHEN AN
+     * ORDER IS DUE is a selling decision, so the default belongs to the app that makes it. Orders
+     * kept reading the removed column, so every order whose customer had no negotiated terms failed
+     * the walk with `Invalid column name 'DefaultPaymentTermsTypeID'` — six integration checks, and
+     * in production the entire company-default step.
+     *
+     * `OrderCompanyPolicy` is the right home and needed no new table: it is already the per-company
+     * orders policy row, IS-A `__mj.Company` so its ID *is* the company ID, and a company with no
+     * row simply takes the defaults — which here means falling through to due on receipt.
+     */
+    private companyDefaultTerms;
+    /**
+     * Refuse an illegal status move BEFORE this save does anything, and say why.
+     *
+     * ONLY the lifecycle verdict is asked here, deliberately. `super.Save()` runs the full
+     * `Validate()` later, and that is the right place for the rest of it: `Validate()` includes the
+     * generated NOT NULL field checks, and `OrderNumber`, `Company` and every line's `UnitPrice` are
+     * populated BY this save — minted from the sequence, or resolved by the pricing walk below. An
+     * attempt to run all of `Validate()` up front refused every confirm in the suite with
+     * "Order Number cannot be null", on fields the save was about to fill in.
+     *
+     * The transition check has no such dependency: it reads the persisted `Status` against the new
+     * one, and both are known before anything runs. Asking it here is what makes integration check
+     * OS4 hold — a refused move must change nothing on disk and book nothing, and by the time
+     * control reaches `super.Save()` this method has already priced lines, decided promotions and
+     * charges, minted an order number and posted journal entries.
+     *
+     * The booking rules that DO need the full record — a payer, something to book — live on
+     * `OrderHeaderEntity.Validate()` and fire inside `super.Save()`, where `bookingInFlight` keeps
+     * `willBookOnThisSave()` answering true even though `ConfirmedAt` has just been stamped.
+     *
+     * Reports through `LatestResult`, the same shape every other refusal on this path uses, so a
+     * caller gets the reason rather than a bare `false`.
+     */
+    private passesStatusTransition;
+    /**
+     * Settle every line's money IN MEMORY. Writes nothing.
+     *
+     * EVERY in-memory decision happens before any row goes down. That ordering is forced rather
+     * than tidy: a Confirmed line is frozen by trigger 51003, and because the CRUD procs run under
+     * INSERT-EXEC, a trigger rollback raises 'Cannot use the ROLLBACK statement within an
+     * INSERT-EXEC statement' — an error naming neither the line nor the rule it broke. So anything
+     * that changes a line's money must be settled BEFORE the insert, not corrected after it.
+     *
+     * Split out of `savePendingLines` and hoisted ahead of the header save when `Lines` became a
+     * related-record collection: MJ validates companions from the parent's save, so a line has to be
+     * complete — `CompanyID` stamped, `UnitPrice` resolved, both NOT NULL and neither ever authored
+     * by a caller — before that save runs, not after it.
+     */
+    private prepareLines;
+    /**
+     * Write the lines that `prepareLines` settled, plus the adjustment rows that need their keys.
+     */
+    /**
+     * Write the adjustment and allocation rows once the lines have real IDs.
+     *
+     * These only ADD rows — the frozen line is never touched again, which is what keeps this clear
+     * of the immutability trigger.
+     */
+    private writePromotionRecords;
+    /** Net for a line that has not been saved yet — mirrors OrderLineEntityServer's own formula. */
+    private pendingLineNet;
+    /**
+     * The exact extended amount a price rule computed for this line, if one did.
+     *
+     * `_priceComponents` is populated by the pricing pass in this same save, so this
+     * is the authority while the line is still in flight; the line itself carries the
+     * same figure for its own totals hook, which runs outside this class.
+     */
+    private resolvedExtendedFor;
+    /** Persist priced lines and the component/charge rows that need their IDs. */
+    private persistPreparedLines;
+    private savePendingLines;
+    /** Write the charge and allocation rows once the lines have real IDs. */
+    private writeChargeRecords;
+    /**
+     * Create the grants this order's lines confer (D27/D76).
+     *
+     * Delegates entirely to `EntitlementEngine`; what lives here is the mapping from the order's own
+     * entities to the structural shape the engine takes, plus the balance the timing rule needs.
+     *
+     * `Balance` is re-read from the header rather than trusted from memory: `createInitialPayment`
+     * has just run, and the rollup triggers (D41) moved `AmountPaid`/`Balance` on the ROW without
+     * telling this object. An `OnPaidInFull` grant reading a stale balance would sit Suspended on an
+     * order that is already paid.
+     */
+    private grantEntitlements;
+    /**
+     * Turn any bundle line into a parent plus its component children (D32/D41/D45).
+     *
+     * Delegates to `BundleEngine`; what lives here is making a fresh line entity the way this class
+     * does, and giving the parent an ID before either row is written so the children can point at it
+     * at INSERT time rather than through a later update the immutability trigger would refuse.
+     */
+    /**
+     * Turn charge and adjustment rows a CLIENT staged into the engine's request arrays.
+     *
+     * ## Why this exists
+     *
+     * `Charges` and `Adjustments` are related-record collections so a browser can ask for a shipping
+     * charge or an ad-hoc discount and have it cross the wire with the order. Before them these were
+     * transient arrays only the server could fill, so once `OrderDraft` was deleted a promotion code
+     * or a manual discount typed on screen showed up in the PRICE PREVIEW and then vanished at
+     * confirm — the screen and the ledger disagreeing, silently, which is the one failure this app
+     * spends most of its guard rails preventing.
+     *
+     * ## Why the staged rows are CONSUMED rather than saved as they arrive
+     *
+     * A staged row is a REQUEST, and it is not the same object as the record the engine writes. A
+     * client can fill in three of a charge's fifteen fields — the type, an amount or rate, and a
+     * reason for an override. `BasisAmount`, the per-line allocations, the tax jurisdiction and the
+     * sequence are all decided by the pricing walk, and the allocations cannot even be written until
+     * the lines have IDs. Letting the graph write the row as it arrived would put a half-formed
+     * charge in the transaction and then need a second write to correct it — with a window in
+     * between where the order carries a charge with no basis.
+     *
+     * So the rows are read as requests and removed, and `WriteCharges` / the promotion writer produce
+     * the authoritative rows exactly as they always have. The engine is untouched by this change,
+     * which matters: it is the part with 373 integration checks against it.
+     *
+     * On the way OUT the collections mean what they say — `Charges.Load()` on a saved order returns
+     * what the engine decided. Request on the way in, record on the way out.
+     */
+    private drainStagedPricingRequests;
+    /** `ChargeType.ID` → `Code`, for the staged rows only. One read, not one per row. */
+    private chargeTypeCodesByID;
+    private expandBundles;
+    /**
+     * Mint the stored-value instruments this order's gift-card lines sell (D44).
+     *
+     * Delegates to `GiftCardEngine`; what lives here is the mapping from the order's entities to the
+     * shape the engine takes. The engine is idempotent against the database, so a re-save of an
+     * already confirmed order issues nothing — which matters because a second set of cards would be
+     * free money that reconciles perfectly, with the accounts present and the ledger balanced.
+     *
+     * `IssuingCompanyID` is the ORDER's company rather than any line's. A gift card is a claim on
+     * the entity that sold it, and on a multi-company order the seller is the header's company even
+     * where a line's product belongs to a sibling.
+     */
+    private issueGiftCards;
+    /** The header's rollup columns as the DATABASE now holds them, after the payment triggers ran. */
+    private readBalanceFromRow;
+    /**
+     * Take access away from what was sent back.
+     *
+     * A full return revokes; a partial return reduces the quantity proportionally. Uncountable grants
+     * — a Feature, an AccessLevel — survive a partial return, because the customer still holds some of
+     * the thing that conferred them.
+     *
+     * Runs on the REVERSAL order's lines, unwinding the grants that hang off each ORIGIN line. The
+     * origin's quantity is what the proportion is taken against, so it is read from the origin rather
+     * than inferred from the reversal.
+     */
+    private revokeEntitlementsForReversals;
+    /**
+     * Settle a reversal line from the line it unwinds (D16). Returns true when this line WAS a
+     * reversal, so the caller knows to skip ordinary pricing.
+     *
+     * THREE THINGS ONLY THE ORIGIN KNOWS, and each of them produces a balanced journal entry when
+     * it goes wrong — which is why they are refusals here rather than checks somewhere downstream:
+     *
+     *   - **How much is left.** Returning 5 against a line that sold 2 refunds money never
+     *     collected. The entry balances; nothing later in the pipeline can tell.
+     *   - **What it cost.** Pricing a return against today's table refunds last year's purchase at
+     *     this year's rate. A stated `UnitPrice` still wins — see `applyResolvedPrice` — because a
+     *     stated price is a decision somebody made, and a negotiated return settlement is exactly
+     *     that.
+     *   - **Which product.** An ID copied from the wrong row credits another company's revenue.
+     *
+     * Runs on any line carrying `ReversesOrderLineID`, including a POSITIVE one: a line that points
+     * at an origin is making a claim about that origin, and the claim is checkable either way.
+     */
+    private applyReversalOrigin;
+    /**
+     * Record WHY a line owes no tax, as a zero-amount price component (D73).
+     *
+     * A zero tax line looks identical whether the product was untaxable, we had no nexus, or the
+     * buyer held a certificate — and those are different facts. An auditor asking "why was no tax
+     * charged on this line" needs the reason, not the total, and the component trail is where the
+     * rest of the line's reasoning already lives.
+     */
+    private saveTaxReasons;
+    /**
+     * Write the price decomposition for lines that were priced by the engine (D69).
+     *
+     * Runs AFTER the lines are saved, because a component points at a line that must already exist.
+     * Pricing disputes are inevitable and "the system computed it" is not an answer to a customer or
+     * an auditor, so the reasoning is stored rather than recomputed later against rules that may by
+     * then have changed.
+     */
+    private savePriceComponents;
+    /**
+     * Stamp an event line's service period from the EVENT's own dates (D-EVENT).
+     *
+     * WHY THIS IS NOT LEFT TO THE CALLER
+     * An event product is bought in advance and earned on the day it happens: the money is deferred
+     * revenue until then. That behaviour needs `ServicePeriodStart`/`End` — `AllBackEnd` recognizes
+     * 100% on the END date, and `RequireServicePeriod` refuses to run without one.
+     *
+     * Leaving those dates to whoever creates the line means the recognition date for a conference is
+     * hand-typed on every ticket sold, and a typo silently books revenue in the wrong period. The
+     * event already knows when it is. Reading it from `EventProduct` makes the correct answer the
+     * default and the ticket line carry no date at all.
+     *
+     * An explicitly-set period WINS and is never overwritten: a line covering only part of a
+     * multi-day event, or a deliberate override, is a legitimate thing to express. Subscription
+     * lines are untouched — their period comes from the term, which is decided later and is
+     * authoritative over anything typed (see `materializeSubscriptions`).
+     *
+     * A product with no `EventProduct` row is simply not an event; nothing happens.
+     */
+    private applyEventServicePeriod;
+    /**
+     * Build one draft per line, submit them as ONE set, then stamp each line with its entry.
+     * Every step is inside the caller's transaction.
+     */
+    private bookLines;
+    /**
+     * Invoke accounting's SET operation. Resolved through MJ's class factory by key so this
+     * package does not hard-depend on the accounting server package at build time.
+     */
+    private submitDrafts;
+    /**
+     * Stamp each line with its BOOKING entry (NULL→value-once; trigger 51008 enforces the same
+     * rule independently). Recognition entries are forward-dated releases — they belong to the
+     * schedule, not to the line's booking pointer, so they are skipped here.
+     */
+    private stampJournalEntryIDs;
+    /**
+     * Walk up the IS-A chain to the Order Line that owns `JournalEntryID`.
+     * Event Order Line / Subscription Order Line instances in `this.Lines` are
+     * children of that row; stamping on the parent and saving with
+     * `IsParentEntitySave` skips leaf delegation.
+     */
+    private resolveOrderLineForStamp;
+    /**
+     * For every subscription line, apply the type's rules and materialize the Subscription (find,
+     * extend, reactivate, or create) plus the SubscriptionTerm this purchase bought.
+     *
+     * Runs BEFORE booking so the recognition entries can anchor to the term and use its
+     * anchored/prorated window — a calendar-anchored membership bought in July does NOT recognize
+     * over July→July; it recognizes over July→Dec at a prorated amount.
+     *
+     * All rule evaluation is delegated to `SubscriptionBehavior`, which is pure. This method does
+     * the persistence, inside the caller's transaction.
+     */
+    private materializeSubscriptions;
+    /**
+     * Evaluate the subscription rules for every pending line, BEFORE any of them is inserted.
+     *
+     * Pure with respect to this app's tables — it reads the catalog and any existing subscription,
+     * then asks the behaviour what to do. Nothing is written, so a rules rejection aborts the
+     * confirm before a single line exists.
+     */
+    private decideSubscriptions;
+    /**
+     * WHO a line is for: the line's ship-to, falling back to the order header (D61).
+     *
+     * Ship-to on a line means "where this goes" for a physical product and "who this is for" when
+     * there is nothing to ship. A subscription line therefore reads its subscriber from the same
+     * fields a shipped line reads its destination from — one question, two kinds of answer.
+     *
+     * The fallback is per-side, not all-or-nothing: a line may name only a person (a seat bought
+     * under the order's customer organization) and still inherit that organization from the header.
+     */
+    private resolveSubscriber;
+    /**
+     * Fill in the organization from the person's affiliation, when it was left blank (D64).
+     *
+     * Only ever ADDS: an organization that was stated — on the line, the order's ship-to, or its
+     * customer — is never second-guessed. And it only runs when the setting says so, so a
+     * deployment that would rather not infer anything simply turns it off and blank stays blank.
+     */
+    private withInferredOrganization;
+    /**
+     * The organization a person belonged to AS OF the order date (D64).
+     *
+     * `Person` has no organization column — bizapps-common models affiliation as a dated
+     * `Relationship` (FromPersonID → ToOrganizationID, with StartDate/EndDate/Status). So this is a
+     * point-in-time question, and the answer legitimately changes when someone moves employer. That
+     * is exactly why the result is STAMPED onto the order rather than resolved on read: deriving it
+     * later would silently rewrite the history of an order that is otherwise immutable once booked.
+     *
+     * The rule, per Amith:
+     *   zero qualifying affiliations → leave blank. That IS a personal order — no flag needed,
+     *                                  because "person, no organization" already says it.
+     *   exactly one                  → use it.
+     *   more than one                → the most recent by StartDate. A person can hold several at
+     *                                  once (employee here, board member there), and Relationship
+     *                                  has no uniqueness constraint, so this case is normal rather
+     *                                  than exceptional and needs a stated rule instead of a guess.
+     *
+     * Which relationship types qualify is a SETTING, defaulting to `Employee` — being a `Vendor` to
+     * an organization must not make it your bill-to.
+     */
+    private organizationAsOf;
+    /** Lines whose product carries a subscription type, joined to their rules. */
+    private subscriptionLines;
+    /**
+     * The behaviour object: the base class when the type has no driver (the common case — the
+     * columns ARE the rules, D45), or a registered subclass when one is named.
+     */
+    private behaviorFor;
+    /**
+     * The subscription this purchase attaches to.
+     *
+     * A RENEWAL names its subscription outright (D55) — resolving by (customer, product) instead
+     * would be a guess, and would pick the wrong one whenever a customer holds two subscriptions to
+     * the same product under an `AllowMultiple` type.
+     */
+    private findExistingSubscription;
+    /** Load a subscription plus the end and number of its latest term, by whatever filter. */
+    private loadSubscriptionState;
+    private createSubscription;
+    /**
+     * Append to the subscription's immutable lifecycle log.
+     *
+     * The log is the answer to "what happened to this membership, and when" — the question support
+     * actually gets asked. Writing it at every transition is the only thing that makes the table
+     * worth having; a `SubscriptionEvent` table nobody writes to is just schema.
+     */
+    private logSubscriptionEvent;
+    /** Extension or reactivation — the term is what changes; the subscription just re-activates. */
+    private touchExistingSubscription;
+    /**
+     * Mint the next `SUB-{seq}` from the SubscriptionSequence singleton.
+     *
+     * A subscription number is member-facing — it is the "membership number" someone reads over the
+     * phone — so it gets its own counter rather than being derived from whichever order created it.
+     */
+    private assignSubscriptionNumber;
+    /**
+     * Mint the next `ORD-{seq}` from the OrderSequence singleton.
+     *
+     * The order IS the invoice (D2), so this is an A/R document number and auditors expect it to
+     * be gap-conscious. Taken with UPDLOCK+HOLDLOCK inside the caller's transaction so concurrent
+     * confirms serialize on the counter rather than colliding on the UNIQUE index.
+     *
+     * Currently a GLOBAL sequence per D30. Jeremy's global-vs-per-company call is still open; the
+     * change would be a WHERE clause here plus a CompanyID on the sequence table.
+     */
+    private assignOrderNumber;
+    /**
+     * Take the next value from one of the singleton counter tables.
+     *
+     * Taken with UPDLOCK+HOLDLOCK inside the CALLER'S transaction, so concurrent confirms serialize
+     * on the counter row rather than colliding on the UNIQUE index — and a confirm that rolls back
+     * releases its number rather than burning it.
+     *
+     * `OUTPUT ... INTO` (not a bare `OUTPUT`): CodeGen puts an `__mj_UpdatedAt` trigger on every
+     * table, and SQL Server forbids a bare OUTPUT clause on a table that has triggers.
+     */
+    private nextSequence;
+    /**
+     * Turn the order's captured payment INTENT into a real payment.
+     *
+     * `InitialPaymentTypeID`/`Amount`/`DetailID` are a convenience capture at order entry; on
+     * confirm they become a PaymentHeader plus a PaymentLine applied to this order. The rollup
+     * triggers then move AmountPaid/Balance/PaymentStatus on their own (D41) — nothing here
+     * touches those fields.
+     *
+     * The instrument is COPIED, never shared (D39): the order keeps its snapshot of what was
+     * intended, the payment gets its own record of what ran, and neither can rewrite the other.
+     */
+    /**
+     * Refuse the confirm when the initial tender needs a reference and none reached us.
+     *
+     * "None reached us" means no typed `InitialPaymentReference`, no `InitialPaymentDetailID`,
+     * or a detail whose `ReferenceNumber` is blank — an instrument row with an empty reference
+     * is the same failure wearing a foreign key.
+     */
+    private requireReferenceWhenTenderDemandsOne;
+    private createInitialPayment;
+    /** Mint a PaymentDetail from the typed check / wire / transfer number. */
+    private createPaymentDetailFromReference;
+    /** Duplicate a PaymentDetail so each host owns its own immutable snapshot (D39). */
+    private copyPaymentDetail;
+    private assignPaymentNumber;
+    /** Resolver + accounting engine come from the shared bridge — see AccountingBridge.ts. */
+    private buildResolver;
+    private entityIDFor;
+    private loadLinesForBooking;
+    private countPersistedLines;
+}
+/** Tree-shaking anchor — call from the server bootstrap so @RegisterClass is retained. */
+export declare function LoadOrderEntityServer(): void;
+//# sourceMappingURL=OrderEntityServer.d.ts.map

package/dist/OrderEntityServer.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"OrderEntityServer.d.ts","sourceRoot":"","sources":["../src/OrderEntityServer.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,OAAO,EAMH,iBAAiB,EASjB,gBAAgB,EACnB,MAAM,sBAAsB,CAAC;AAE9B,OAAO,EACH,iBAAiB,EASpB,MAAM,8BAA8B,CAAC;AActC,OAAO,EAAqR,KAAK,qBAAqB,EAAgD,KAAK,eAAe,EAAiH,MAAM,8BAA8B,CAAC;AAoHhhB,qBACa,iBAAkB,SAAQ,iBAAiB;IACpD,6FAA6F;IAC7F,OAAO,CAAC,gBAAgB,CAA4D;IACpF,wFAAwF;IACxF,OAAO,CAAC,WAAW,CAA6B;IAChD,OAAO,CAAC,gBAAgB,CAA+B;IACvD,OAAO,CAAC,QAAQ,CAAyB;IACzC;;;;;;;;;;;;OAYG;IACI,kBAAkB,EAAE,MAAM,GAAG,IAAI,CAAQ;IAEhD;;;;;;;OAOG;IACH,OAAO,CAAC,kBAAkB,CAAmC;IAC7D,OAAO,CAAC,eAAe,CAAqC;IAE5D,sFAAsF;IACtF,OAAO,CAAC,cAAc,CAA+C;IASrE;;;;;OAKG;IACH,IAAW,kBAAkB,IAAI,qBAAqB,EAAE,CAEvD;IACD,IAAW,kBAAkB,CAAC,KAAK,EAAE,qBAAqB,EAAE,EAE3D;IAED;;;;;;;;OAQG;IACH,IAAW,gBAAgB,IAAI,eAAe,EAAE,CAE/C;IACD,IAAW,gBAAgB,CAAC,KAAK,EAAE,eAAe,EAAE,EAEnD;IAED;;;;OAIG;IACH,IAAW,sBAAsB,IAAI,KAAK,CAAC;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,MAAM,EAAE,MAAM,CAAA;KAAE,CAAC,CAE3E;IAcD;;;;;;;;;;;;;;;OAeG;IACH,IAAoB,0BAA0B,IAAI,OAAO,CAExD;IAED;;;;;;;;;;;;;OAaG;IACmB,aAAa,IAAI,OAAO,CAAC,gBAAgB,CAAC;IA8B1C,IAAI,CAAC,OAAO,CAAC,EAAE,iBAAiB,GAAG,OAAO,CAAC,OAAO,CAAC;IA4NzE;;;;OAIG;IACH,OAAO,CAAC,kBAAkB;IAc1B;;;;;;;;;;;;;OAaG;YACW,cAAc;IA+C5B,+DAA+D;YACjD,oBAAoB;IA4ClC;;;;;;;;;;;;;;;;OAgBG;YACW,mBAAmB;IAmBjC;;;;;;;;;;;;;;;;;;;;;;OAsBG;IACH,OAAO,CAAC,sBAAsB;IAgB9B;;;;;;;;;;;;;OAaG;YACW,YAAY;IA2F1B;;OAEG;IACH;;;;;OAKG;YACW,qBAAqB;IAiBnC,gGAAgG;IAChG,OAAO,CAAC,cAAc;IAYtB;;;;;;OAMG;IACH,OAAO,CAAC,mBAAmB;IAI3B,8EAA8E;YAChE,oBAAoB;YAQpB,gBAAgB;IAqC9B,yEAAyE;YAC3D,kBAAkB;IAiBhC;;;;;;;;;;OAUG;YACW,iBAAiB;IAiC/B;;;;;;OAMG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA4BG;YACW,0BAA0B;IAiDxC,qFAAqF;YACvE,mBAAmB;YAkBnB,aAAa;IAoF3B;;;;;;;;;;;OAWG;YACW,cAAc;IA8B5B,kGAAkG;YACpF,kBAAkB;IAkBhC;;;;;;;;;;OAUG;YACW,8BAA8B;IA6B5C;;;;;;;;;;;;;;;;;OAiBG;YACW,mBAAmB;IA8EjC;;;;;;;OAOG;YACW,cAAc;IA6B5B;;;;;;;OAOG;YACW,mBAAmB;IAyCjC;;;;;;;;;;;;;;;;;;;OAmBG;YACW,uBAAuB;IAiCrC;;;OAGG;YACW,SAAS;IA8CvB;;;OAGG;YACW,YAAY;IAgC1B;;;;OAIG;YACW,oBAAoB;IAwDlC;;;;;OAKG;IACH,OAAO,CAAC,wBAAwB;IAchC;;;;;;;;;;OAUG;YACW,wBAAwB;IAkHtC;;;;;;OAMG;YACW,mBAAmB;IAqFjC;;;;;;;;;OASG;IACH,OAAO,CAAC,iBAAiB;IAQzB;;;;;;OAMG;YACW,wBAAwB;IAUtC;;;;;;;;;;;;;;;;;;;;OAoBG;YACW,gBAAgB;IAgC9B,8EAA8E;YAChE,iBAAiB;IA0C/B;;;OAGG;IACH,OAAO,CAAC,WAAW;IAenB;;;;;;OAMG;YACW,wBAAwB;IAqBtC,0FAA0F;YAC5E,qBAAqB;YA6CrB,kBAAkB;IA6DhC;;;;;;OAMG;YACW,oBAAoB;IA+BlC,gGAAgG;YAClF,yBAAyB;IAuCvC;;;;;OAKG;YACW,wBAAwB;IAMtC;;;;;;;;;OASG;YACW,iBAAiB;IAI/B;;;;;;;;;OASG;YACW,YAAY;IAuB1B;;;;;;;;;;OAUG;IACH;;;;;;OAMG;YACW,oCAAoC;YAwBpC,oBAAoB;IA+DlC,0EAA0E;YAC5D,gCAAgC;IAmB9C,oFAAoF;YACtE,iBAAiB;YA8BjB,mBAAmB;IAMjC,0FAA0F;YAC5E,aAAa;IAI3B,OAAO,CAAC,WAAW;YAIL,mBAAmB;YAcnB,mBAAmB;CAcpC;AAgED,0FAA0F;AAC1F,wBAAgB,qBAAqB,IAAI,IAAI,CAE5C"}