The master / slave document pattern

Almost every business document in xly — a quotation, a sales order, a work order, a payment voucher — is stored as one header row plus N detail rows. xly's term for this is master / slave. The master holds the document's identity and totals; each slave row is a line item, a stage, a material, a product, a charge.

The pattern is everywhere:

Document	Master	Slave family
Quotation	quoQuotationMaster	quoQuotationSlave, quoQuotationMaterials, quoQuotationProcess, quoQuotationFreight, quoQuotationParam, quoQuotationControl, quoQuotationControlCombine, quoQuotationCalc, quoQuotationPacking
Work order	mftWorkOrderMaster	mftWorkOrderSlave, mftWorkOrderMaterials, mftWorkOrderProcess, mftWorkOrderPacking, mftWorkOrderControl, mftWorkOrderControlCombine, mftWorkOrderSlaveMoney, mftWorkOrderCalc
Sales order	salSalesOrderMaster	salSalesOrderSlave, …
Cost analysis	accOrderCostAnalysisMaster	accOrderCostAnalysisOperation, accOrderCostAnalysisSlave, …
The framework's own forms	gdsconfigformmaster	gdsconfigformslave, gdsconfigformcustomslave, gdsconfigformuserslave

The convention is universal enough that the wiki uses "master" and "slave" as terms of art. They mean header and detail respectively; the naming is legacy from the codebase and worth preserving because it appears verbatim in 14k+ table and column names.

Conventions inside the pattern

• The slave row's join column is typically named sMasterId or sParentId (it's a semantic FK, not enforced). Sometimes it follows a more specific pattern like sQuoId for quotation slaves, sWoId for work-order slaves; check the slave table's columns to be sure.
• Master and all its slaves share the same multi-tenant scope columns (sBrandsId, sSubsidiaryId).
• "Control" slave variants (e.g., mftWorkOrderControl, quoQuotationControl) hold compound or aggregate state — totals, status flags, computed columns. They are still slaves of the master.
• Sub-detail tables are named with extra suffixes like …SlaveChildren or …ControlCombine, joining a slave row.

Why master / slave matters for the wiki

• Almost every form in Slice 1-style navigation is the master of its document family. The slaves are loaded as nested grids or as second forms when a master row is selected.
• The framework's own form metadata (gdsconfigformmaster / gdsconfigformslave) is itself an instance of the pattern — the framework documents itself using the same convention it asks PMs to follow.
• The customization overlays (gdsconfigformcustomslave, gdsconfigformuserslave) are sibling slave tables, not deeper pattern levels. See Slice 4.

"Slave" — naming caveat

The term carries connotations in English that are absent from the Chinese 主表 / 从表. The wiki preserves "slave" because:

1. Renaming would break every cross-reference into the codebase, the schema, and the auto-catalog (14k+ identifiers).
2. Mapping every occurrence to "detail" or "child" would distort searchability and produce wiki text that diverges from what developers actually grep.

Future xly versions may rebrand to "detail" / "header"; until then, the wiki uses the in-codebase term verbatim and notes it once here.