Query the manufacturer's live data with an RSQL filter. Datasets: order (Orders and quotes share the same entity. The state field distinguishes QUOTE, ORDER, and DRAFT. Payment status is independent: a placed PO/invoice order can remain UNPAID until settlement. 'price' is the order total in the order's own 'currency'; 'localPrice' is the same total converted to the operator's home currency ('localCurrency'). Sum localPrice (not price) to compare revenue across orders in different currencies. 'source' is the sales channel: INBOUND = placed by the customer through the storefront (self-service, online); OUTBOUND = created and sent out by the manufacturer's team (a staff-built quote). Filter or group by source to split self-service vs staff-created orders.); partRevision (Part revisions (a versioned 3D part). 'designName' is the manufacturer's INTERNAL name for the part design — not what the customer sees; when a user names a part they usually mean the customer-facing requisition.name, so prefer that for matching user references. Geometry detail is via inspectPartRevision.); partSpecification (Part specifications: how a part revision is to be made (process, material, finish).); productionStep (A stage in production: a build group of parts undergoing one operation (e.g. 3D Print, Post-Process, Quality Control). Parts move from step to step as they are manufactured. Needs a subscription to the FACTORY_FLOOR module.); customerOrganisation (Customer organisations (the manufacturer's customers).); cart (Storefront shopping carts (status OPEN, CONVERTED to an order, or DELETED). Use for conversion analysis.); requisition (Requisitions: a part specification ordered on an order (the order line item; carries quantity and pricing). 'name' is the CUSTOMER-FACING part name — this is what customers and users call the line, so match it when someone refers to a part by name (filter name=="...", or name-contains via RSQL). It is distinct from the manufacturer's internal partRevision.designName; the same physical part can have a different customer-facing name here. pricePaid is the actual per-line revenue in the parent order's currency; localPricePaid is the same in the operator's home currency (sum this for cross-order revenue). quotedPrice is the stored quote price; explainPrice recomputes on the versions and settings it was quoted on and reports pricing freshness.); workOrder (Work orders: production execution for a requisition (quantity to build, routing template). 'steps' is the ordered list of operations this work order will go through on the shop floor (its routing) — read it to know what will be done to build this order. Needs a subscription to the FACTORY_FLOOR module.); processPrices (Manufacturing processes and their pricing configuration. 'pricingAlgo' says how a process is priced: TS_EQUATION processes use a TypeScript pricing equation (activeTypescriptEquationId; read it with describePricingEquationApi(includeSource=true)); any other value is a legacy built-in algorithm with no equation to read. The row folds in the process's setup: boundingBox (max part size L x W x H), bulkQuantities (the quantity breaks shown for bulk pricing), materialVariables (the per-material variable names the equation reads), and counts of materials, post-processings, precision and infill options. isInternal processes are hidden from the storefront. A row with a customerOrganisationId is a customer-specific copy of a process.); materialPrices (A material's pricing configuration for one process (a process x material pairing). Carries the material (materialId/materialName), its density, and 'variables' — the material's TypeScript-equation variable values (operator-defined name=value pairs the pricing equation reads off the material). Use to see a material's rates without reverse-engineering them from quotes: filter by processPricesId and materialId (both from partSpecification). The 'variables' text isn't itself filterable — filter on materialId/processPricesId/density/isDefault instead. Rates are process-specific, so the same material can appear once per process.); postProcessing (Post-processing / finishing options the manufacturer offers (e.g. painting, polishing). 'type' says how it is priced: TS_EQUATION ones have their own TypeScript equation (activeTypescriptEquationId; read it with describePricingEquationApi(scope=POST_PROCESSING, ownerId, includeSource=true)); any other type is a legacy built-in formula with no equation to read. 'processes' lists the processes it is available on, 'operations' the shop-floor operations it adds, 'colors' its colour choices and 'incompatibleMaterials' the materials it cannot be applied to. Options sharing a mutuallyExclusiveGroup cannot be combined on one part.); typescriptEquation (TypeScript pricing equations (metadata only — describePricingEquationApi(includeSource=true) for the live source). 'scope' is PROCESS (processPricesId), POST_PROCESSING (postProcessingId) or ORDER (the operator's single order-level equation that adds whole-order line items; both ids null); 'isLive' tells whether it is the one currently used for quoting. Several draft equations can sit next to the live one; 'origin' is UI or MCP (written through save) and 'createdBy' the authoring user.); operationScheduling (How the production schedule runs each operation (one row per operation, the completed one excluded; 'id' is the operation id). 'needs' are the machines or people it holds at the same time (none = a wait such as cooling); 'batching' is how parts go through: NONE one work order at a time, VOLUME builds filled by part volume (usableVolumePercent of each machine's build volume), COUNT batches of partsPerBatch, KEEP_PREVIOUS the build from the operation before stays together. A build or batch starts when its machine is free unless it is below minFillPercent; then it waits for more parts, at most maxWaitHours. Time is durationHours per job or batch, or setupMinutes + minutesPerPart per part. runsUnattended: only the start must be in open hours. 'problems' are what the plan would warn about. Needs a subscription to the FACTORY_FLOOR and SCHEDULING modules.); operation (Manufacturing operations (shop-floor stations) in 'sequence' order, e.g. 3D Print, Post-Process, Quality Control. Parts move operation to operation; batches moved at an operation are grouped into production steps (build groups). Column meanings: productionStepType is the station kind — BASE (a normal station), DOWNLOAD_PARTS_AS_GROUP (parts are downloaded as one build file), UPLOAD_THREED_NESTED (a nested build / bill of parts is uploaded), QUALITY_CONTROL (inspection; scrap is recorded here). viewType is the backlog's default view at this station: PART lists individual parts, BUILD lists build groups. buildConstraint says which parts may share one build group: NONE, MATERIAL (same material), MATERIAL_AND_COLOR, MATERIAL_AND_SHEET_THICKNESS. stepNamePrefix + stepNamingStrategy control how a new build group is named when a batch arrives: ALWAYS_RENAME (new name every time), RENAME_IF_BUILD_CHANGED (new name only when the build composition changed), INHERIT_FROM_PREVIOUS (keep the previous station's group name). allowOverproduction lets staff move more parts than the ordered balance. durationHours is the planning estimate for time spent at the station. isCompletedStatus marks the station whose exit means the part is finished. automations run when staff progress parts here (NOTIFY_ON_ORDER_COMPLETED). Referenced by productionStep.operationId and scrap.operationId. Needs a subscription to the FACTORY_FLOOR module.); batchMovement (Forward batch moves through production: each row is a batch of parts ADVANCING from one operation to the next (throughput). Scrap events are NOT here — see the scrap dataset for those. 'batchSize' is the quantity that moved; 'operationName' is the operation the batch left; 'toOperationName' is the one it moved to. Filter by createdAt for a time window or requisitionId/workOrderId for one job. For a SCRAP RATE by operation, aggregate sum(batchSize) here grouped by [operationName] (the parts that passed) and aggregate scrap the same way (the parts scrapped); rate = scrap / (scrap + moved) at each operation. Needs a subscription to the FACTORY_FLOOR module.); scrap (Scrap events: parts scrapped as they move through production. This is the floor-wide scrap log — query or aggregate it DIRECTLY for any scrap question; do not gather scrap by iterating requisitions or getProductionHistory. 'reason' is the free-text scrap cause; 'batchSize' is the quantity scrapped; 'operationName' is the operation the scrap happened at; filter by createdAt for a time window or requisitionId/workOrderId for one job. To find what causes the most scrap, aggregate sum(batchSize) grouped by reason (or operationName). For a scrap RATE you also need the parts that passed — aggregate the batchMovement dataset by operationName and divide. Needs a subscription to the FACTORY_FLOOR module.); material (The material catalogue (platform materials plus the manufacturer's own). Rates are NOT here — a material only has prices once it is paired with a process; query materialPrices (materialId==) for those.); color (Colour options. Each colour belongs to one materialPrices row (a material on a process) or to one post-processing; 'kind' says which and the matching *Id column points at the parent.); jurisdiction (The platform's tax-jurisdiction catalogue: every code a taxJurisdiction can be created for, with its name and country. Platform reference data, identical for every manufacturer (not tenant data). Use it to find the isoCode for save(entity="taxJurisdiction"): filter by country (the Country enum name, e.g. GERMANY) and read the region names; DEFAULT and EXEMPT are the two special codes.); leadTime (Lead-time options offered at checkout. 'buffer' is the number of days added to the production estimate; the default one is pre-selected on the storefront and read by the pricing equation.); precisionPrices (Precision / tolerance options sold per process, each with a price adder. A row with a customerOrganisationId is a customer-specific override of the base option.); infill (Infill options per process (FDM-style density presets). 'infillValue' is the fill percentage; the default is pre-selected on the storefront. A row with a customerOrganisationId is a customer override.); taxJurisdiction (Tax setup per jurisdiction (country / region). 'components' lists the tax components applied (name and percentage) and 'totalPercentage' their sum. The DEFAULT jurisdiction is the fallback when a customer's address matches nothing; EXEMPT is used for tax-exempt customers.); taxComponent (Reusable tax components (e.g. VAT 19%) that jurisdictions combine. See taxJurisdiction.components for where each is applied.); paymentTerm (Payment terms offered to customers (e.g. Net 30). accountingSystemTermId links the term to the connected accounting system.); discount (Discounts: GENERIC (a code any customer can use), CUSTOMER (a code for one customer) or INSTANT (applied automatically). Active means endTime is in the future.); shippingBox (Shipping box sizes used to pack orders (dimensions in unitBasis).); shippingMethod (Shipping methods offered at checkout. shippingMode is FIXED_PRICE (flat price, optional weight tiers and a country list), CARRIER_ACCOUNT (live rates from the manufacturer's carrier account) or SELF_COLLECTION (pick-up). Tier and country detail is folded into the row.); productionResource (The machines, people and stations the production schedule seats work on. 'capacity' is how many jobs it holds at once; 'buildVolumeCm3' is set on machines that run many parts as one build (an MJF or SLS printer); 'tags' are its skills, which an operation can ask for; 'openHours' are its weekly hours in the shop's time zone ("always" = no limit). Which operations use it: describeConfiguration(section="scheduling"). Needs a subscription to the FACTORY_FLOOR and SCHEDULING modules.); routingTemplate (Routing templates: the ordered operations a work order goes through. 'steps' is the sequence of operation names. A template can be generic or bound to one partSpecification. When the storefront setting isApprovedRoutingTemplateRequired is on, only approved templates can be used. Needs a subscription to the FACTORY_FLOOR module.); kanbanColumn (Order-board (kanban) columns in display order. 'automations' lists what fires when an order enters the column (NOTIFY_CUSTOMER_OF_NEW_STATUS, SEND_INVOICE, SEND_ORDER_CONFIRMATION).); documentTemplate (Document templates (order confirmation, invoice, estimate, traveller sheets, labels) per language. Metadata only — use getDocumentTemplate(id) to read the HTML content.). Operators: == != =gt= =ge= =lt= =le= =in=(a,b) =out=(a,b); combine with ';' (AND) and ',' (OR). Each row is returned as 'field=value' pairs and always includes its id and foreign keys (the join keys); pass 'fields' to select specific columns (any field from describeQueryableFields). Call describeDataModel to see how datasets relate, and describeQueryableFields(entity) to learn a dataset's filterable fields.