diff --git a/src/Apps/W1/Quality Management/app/CLAUDE.md b/src/Apps/W1/Quality Management/app/CLAUDE.md new file mode 100644 index 0000000000..a8be82a09e --- /dev/null +++ b/src/Apps/W1/Quality Management/app/CLAUDE.md @@ -0,0 +1,56 @@ +# Quality Management + +A comprehensive quality inspection framework for Business Central. Enables organizations to define quality tests, group them into reusable templates, configure rules that auto-generate inspections from business transactions (purchase receipts, production output, assembly, warehouse, transfers), record measurement results, and take disposition actions on non-conforming items. Currently an early-access feature available to partners. + +## Quick reference + +- **ID range**: 20400--20600 +- **Namespace**: `Microsoft.Inventory.QualityManagement` (and sub-namespaces) +- **Dependencies**: None (extends base application directly) +- **Experience**: Essential for most features; Premium required for production output inspections + +## How it works + +The app follows a multi-level configuration hierarchy. At the base are **Quality Tests** -- individual measurements or checks with a value type (decimal, integer, boolean, text, option, table lookup, text expression). Tests are grouped into **Quality Inspection Templates**, which define sampling strategies (fixed quantity or percentage). **Inspection Generation Rules** connect templates to business events with item/vendor/location filters, so inspections are auto-created when specific transactions occur. + +When an inspection is created (automatically, manually, or on schedule), the system clones the template's tests into inspection lines. Each line records a measured value that is evaluated against **Result Conditions** -- configurable rules that map value ranges or expressions to result codes (PASS, FAIL, INPROGRESS, or custom). Results have an **Evaluation Sequence** that determines priority: the system picks the highest-priority matching result. Conditions can be overridden at three levels: test defaults, template overrides, and inspection-specific overrides. + +The inspection integrates deeply with BC's item tracking system. Results can block or allow specific transaction types per lot/serial/package -- a FAIL result can block sales, transfers, picks, and movements while still allowing put-away to quarantine. The system supports re-inspections (numbered chain) and workflow integration for approval, lot blocking, and automated disposition actions. + +After finishing an inspection, **Dispositions** handle non-conforming items: change item tracking codes, create negative adjustments (scrap), move inventory (quarantine), create purchase returns, warehouse put-aways, or transfer orders. These can be triggered manually or via workflow responses. + +## Structure + +- `src/Configuration/` -- Tests, templates, results, conditions, generation rules, lookup values (46 files, the config hierarchy) +- `src/Integration/` -- Event subscribers and page extensions that hook QM into BC domains: purchasing, production, assembly, warehouse, sales, transfers, item tracking (67 files) +- `src/Dispositions/` -- Post-inspection actions: item tracking changes, negative adjustments, inventory moves, purchase returns, warehouse put-aways, transfer orders (22 files) +- `src/Document/` -- Inspection header/line tables and card/list pages +- `src/Utilities/` -- Expression evaluation, value parsing, boolean parsing, source field traversal helpers +- `src/Workflow/` -- BC workflow integration (approval events, lot blocking responses) +- `src/Setup/` -- Global setup table, guided experience, application area registration +- `src/Reports/` -- Certificate of Analysis, non-conformance report, bulk creation/scheduling reports +- `src/RoleCenters/` -- Quality Manager role center and cue table + +## Documentation + +- [docs/data-model.md](docs/data-model.md) -- Inspection hierarchy, configuration tables, result evaluation, item tracking blocking +- [docs/business-logic.md](docs/business-logic.md) -- Inspection creation, result evaluation, finishing, re-inspection, dispositions +- [docs/extensibility.md](docs/extensibility.md) -- 28+ integration events for customizing inspections, results, and workflows +- [src/Configuration/docs/CLAUDE.md](src/Configuration/docs/CLAUDE.md) -- Test, template, and generation rule configuration +- [src/Integration/docs/CLAUDE.md](src/Integration/docs/CLAUDE.md) -- Per-domain BC integration hooks +- [src/Dispositions/docs/CLAUDE.md](src/Dispositions/docs/CLAUDE.md) -- Post-inspection disposition actions +- [src/Utilities/docs/CLAUDE.md](src/Utilities/docs/CLAUDE.md) -- Expression and value evaluation +- [src/Workflow/docs/CLAUDE.md](src/Workflow/docs/CLAUDE.md) -- Workflow integration + +## Things to know + +- **Three creation modes** -- automatic (event-driven from posting), manual (from document lines or standalone), and scheduled (job queue with generation rules). The "intent" on a generation rule determines which BC event triggers creation. +- **Three-level condition override** -- result conditions can be set at the test level (defaults), overridden at the template level, and overridden again at the inspection level. The most specific wins. +- **Evaluation sequence determines result** -- when multiple conditions match, the result with the lowest evaluation sequence number wins. This is how FAIL overrides PASS when both conditions are met. +- **RecordId-based source tracking** -- inspections store up to 5 RecordIds plus 10 custom fields for source tracking. This allows attaching inspections to any BC table without schema changes. +- **Item tracking blocking is per-transaction-type** -- a result can block sales but allow put-away (quarantine scenario). Nine independent boolean fields control this per result code. +- **Re-inspection is a numbered chain** -- each re-inspection increments `Re-inspection No.` on the same `No.`. Only the most recent re-inspection is flagged as active for transaction blocking. +- **Expression tests reference other lines** -- a test with `Test Value Type = Text Expression` can reference other line values via formulas, creating computed fields within an inspection. +- **Table Lookup tests** -- tests can reference any BC table/field for dropdown values, with configurable filters. This avoids hardcoding option lists. +- **Feature is early access** -- as of 2025/2026, available only in partner sandbox environments. Auto-installs on new environments; manual install from AppSource for existing ones. +- **`_Obsolete` note** -- there is no _Obsolete folder in this app; it's a clean, modern codebase. diff --git a/src/Apps/W1/Quality Management/app/docs/business-logic.md b/src/Apps/W1/Quality Management/app/docs/business-logic.md new file mode 100644 index 0000000000..b00153e4b3 --- /dev/null +++ b/src/Apps/W1/Quality Management/app/docs/business-logic.md @@ -0,0 +1,91 @@ +# Business logic + +## Overview + +The app's business logic covers four phases of the inspection lifecycle: creation (how inspections come into existence), execution (recording values and evaluating results), completion (finishing with validation), and disposition (acting on non-conforming items). The creation phase has three modes; the evaluation phase uses a condition-driven engine; dispositions generate downstream BC documents. + +## Inspection creation + +```mermaid +flowchart TD + A{Creation mode?} -->|Automatic| B[BC event fires] + A -->|Manual| C[User creates from document/standalone] + A -->|Scheduled| D[Job queue runs generation rules] + B --> E[Match generation rules] + D --> E + E --> F{Rule matches item/vendor/location?} + F -->|No| G[Skip] + F -->|Yes| H{Existing inspection?} + C --> H + H -->|Use existing| I[Return existing] + H -->|Create new| J[Create header from template] + H -->|Re-inspect| K[Increment re-inspection no.] + J --> L[Clone template lines as inspection lines] + K --> L + L --> M[Evaluate with default values] + M --> N[Trigger workflow if configured] +``` + +**Automatic creation** is triggered by event subscribers in the Integration module. Each domain (purchase, production, assembly, warehouse, transfer, sales return) has subscribers on posting codeunits that call `QltyInspectionCreate`. The generation rule's `Intent` + trigger enum determines which events fire. + +**Manual creation** can be initiated from item tracking lines, document lines, or the template list page. The `QltyInspectionCreate` codeunit handles all modes. + +**Scheduled creation** uses job queue entries linked to generation rules with a `Schedule Group`. The `QltyScheduleInspection` report iterates matching rules and creates inspections for applicable items. + +The `Inspection Creation Option` on setup controls behavior when an inspection already exists: always create new, always re-inspect, use existing open, use any existing, or create re-inspection if finished. + +## Result evaluation + +The `QltyResultEvaluation` codeunit is the evaluation engine. When a test value changes on an inspection line: + +1. **Parse the value** -- `QltyValueParsing` converts text input to the appropriate type (numeric, boolean, etc.) +2. **Match conditions** -- iterate `QltyIResultConditConf` records for this test/template/inspection, checking if the value satisfies each condition expression +3. **Apply evaluation sequence** -- the matching result with the lowest `Evaluation Sequence` wins +4. **Cascade to header** -- after all lines are evaluated, the header result is determined by the line with the lowest evaluation sequence among all line results + +For **Text Expression** tests, `QltyExpressionMgmt` evaluates formulas that can reference other inspection line values, creating computed/derived measurements within an inspection. + +Condition expressions support ranges (`10..20`), comparisons (`>=80`), lists (`RED|GREEN|BLUE`), and combinations. The `QltyBooleanParsing` codeunit handles complex boolean logic in condition strings. + +## Finishing an inspection + +Finishing validates several conditions: + +- **Item tracking** -- if setup requires, lot/serial/package must be filled and (optionally) posted to inventory +- **Result blocking** -- results with `Finish Allowed = Do Not Allow Finish` prevent completion (e.g., INPROGRESS) +- **All lines evaluated** -- lines without a result may block depending on configuration + +On finish: sets `Finished Date` and `Finished By User ID`, locks the record from further edits, triggers the `OnInspectionFinished` workflow event. Item tracking blocking rules from the result now take effect for downstream transactions. + +## Re-inspection + +When a re-inspection is needed, the system increments `Re-inspection No.` on a new header sharing the same `No.`. Source fields, template, and item tracking are copied from the prior inspection. Lines are re-cloned from the template with fresh default values. The `Most Recent Re-inspection` flag is set on the new header and cleared on the old one. + +## Dispositions + +Post-inspection actions for non-conforming items, handled by codeunits in the Dispositions module: + +- **Item tracking change** (`QltyDispChangeTracking`) -- reclassify lot/serial/package numbers +- **Negative adjustment** (`QltyDispNegAdjustInv`) -- create item journal lines for scrap/waste +- **Inventory move** (`QltyDispMoveItemReclass` / `QltyDispMoveWhseReclass`) -- transfer to quarantine bin or rework location via reclassification journal +- **Purchase return** (`QltyDispPurchaseReturn`) -- create purchase return order to send back to vendor +- **Warehouse put-away** (`QltyDispWarehousePutAway`) -- direct to rework/quarantine bin +- **Transfer order** (`QltyDispCreateTransferOrder`) -- move to another location (external lab, rework center) + +These can be triggered manually from the inspection card or automatically via workflow responses when an inspection finishes with a specific result. + +## Integration triggers + +Each BC domain has dedicated subscriber codeunits in the Integration module: + +| Domain | Trigger event | Codeunit | +|--------|--------------|----------| +| Purchasing | Post purchase receipt | `QltyReceivingIntegration` | +| Production | Post output journal | `QltyManufacturIntegration` | +| Assembly | Post assembly output | `QltyAssemblyIntegration` | +| Warehouse | Register warehouse receipt | `QltyReceivingIntegration` | +| Transfer | Post transfer receipt | `QltyTransferIntegration` | +| Sales return | Post sales return receipt | `QltySalesIntegration` | +| Warehouse movement | Register movement | `QltyWarehouseIntegration` | + +The Integration module also extends 27+ BC pages with inspection-related fields, actions, and factboxes -- making inspections visible wherever users work with the source documents. diff --git a/src/Apps/W1/Quality Management/app/docs/data-model.md b/src/Apps/W1/Quality Management/app/docs/data-model.md new file mode 100644 index 0000000000..21419581f1 --- /dev/null +++ b/src/Apps/W1/Quality Management/app/docs/data-model.md @@ -0,0 +1,63 @@ +# Data model + +## Overview + +The data model has three conceptual layers: configuration (tests, templates, results, generation rules), documents (inspection header/line), and setup (global settings). The configuration layer defines what to inspect and how to evaluate results. The document layer captures actual inspections. The key design insight is the flexible source tracking via RecordIds -- inspections can attach to any BC table without schema changes. + +## Inspection documents + +```mermaid +erDiagram + "Qlty Inspection Header" ||--|{ "Qlty Inspection Line" : "has lines" + "Qlty Inspection Header" }o--|| "Qlty Inspection Template Hdr" : "created from" + "Qlty Inspection Header" }o--o| "Qlty Inspection Result" : "header result" + "Qlty Inspection Line" }o--o| "Qlty Inspection Result" : "line result" + "Qlty Inspection Line" }o--|| "Qlty Test" : "tests" +``` + +The `QltyInspectionHeader` (20405) is the core document. Its primary key is `No.` + `Re-inspection No.`, which enables the re-inspection chain -- same inspection number, incrementing re-inspection counter. The header stores source tracking via `Source Table No.`, `Source Document No.`, `Source Item No.`, plus up to 5 `RecordId` fields and 10 custom text/decimal fields for flexible source linking. + +The `QltyInspectionLine` (20406) stores individual test measurements. Each line has a `Test Value` (Text[250]) plus a `Test Value Blob` for large values, and a `Derived Numeric Value` for auto-calculated numeric interpretation. The `Failure State` enum tracks whether the line failed from an Acceptable Quality Level check. Lines reference their template origin via `Template Code` + `Template Line No.`. + +### Quantity model + +The header tracks `Source Quantity (Base)`, `Pass Quantity`, `Fail Quantity`, and `Sample Size`. Sample size is derived from the template's sampling strategy (fixed or percentage). Pass and fail quantities can be manually entered or derived from line results. + +### Re-inspection + +Re-inspections share the same `No.` but increment `Re-inspection No.`. The `Most Recent Re-inspection` boolean flags the latest in the chain. Only the most recent re-inspection's result applies for item tracking blocking decisions. + +## Configuration hierarchy + +```mermaid +erDiagram + "Qlty Test" ||--o{ "Qlty Inspection Template Line" : "used in templates" + "Qlty Inspection Template Hdr" ||--|{ "Qlty Inspection Template Line" : "has lines" + "Qlty Inspection Gen Rule" }o--|| "Qlty Inspection Template Hdr" : "uses template" + "Qlty Test" ||--o{ "Qlty Test Lookup Value" : "custom lookup values" +``` + +**QltyTest** (20401) defines what to measure. Key properties: `Test Value Type` (one of 10 types including Decimal, Boolean, Text Expression, Table Lookup), `Allowable Values` (constraint expression), and for Table Lookup types: `Lookup Table No.`, `Lookup Field No.`, `Lookup Table Filter`. The Table Lookup mechanism allows tests to reference any BC table/field as a dropdown, with filter expressions. + +**QltyInspectionTemplateHdr/Line** (20402/20403) groups tests with a sampling strategy. `Sample Source` is either `Fixed Quantity` or `Percent of Quantity`. Template lines can override test-level properties (description, UOM, expression formula). + +**QltyInspectionGenRule** (20409) connects templates to business events. The `Intent` enum determines the domain (Purchase, Production, Transfer, etc.), and intent-specific trigger enums control when to fire (e.g., `Purchase Order Trigger: On Receipt`). Item and attribute filters narrow which items trigger the rule. + +## Result evaluation + +```mermaid +erDiagram + "Qlty Inspection Result" ||--o{ "Qlty Result Condition Config" : "has conditions" + "Qlty Inspection Result" ||--o{ "Qlty Inspection Header" : "assigned to headers" + "Qlty Inspection Result" ||--o{ "Qlty Inspection Line" : "assigned to lines" +``` + +**QltyInspectionResult** (20411) defines outcomes (PASS, FAIL, INPROGRESS, custom). Each result has an `Evaluation Sequence` (priority -- lower wins), `Result Category` (Acceptable/Not acceptable/Uncategorized), and `Finish Allowed` (whether the inspection can be completed with this result). + +The result also controls item tracking blocking via 9 independent fields: `Item Tracking Allow Sales`, `Allow Transfer`, `Allow Consumption`, `Allow Pick`, `Allow Put-Away`, `Allow Movement`, `Allow Output`, `Allow Assembly Consumption`, `Allow Assembly Output`. Each can be `Allowed`, `Blocked`, or `Blocked but can be overridden`. This enables granular quarantine scenarios. + +**QltyIResultConditConf** (20418) maps test values to result codes. Conditions are text expressions (e.g., `>=80`, `RED|GREEN`, `true`) with a priority. They exist at three levels: test defaults, template overrides, and inspection-specific overrides. + +## Setup + +**QltyManagementSetup** (20400) is the global singleton. Key settings: `Inspection Creation Option` (always new, re-inspection, use existing, etc.), `Inspection Search Criteria` (how to find existing inspections), trigger defaults per domain, item tracking enforcement rules, and journal batch names for disposition operations. diff --git a/src/Apps/W1/Quality Management/app/docs/extensibility.md b/src/Apps/W1/Quality Management/app/docs/extensibility.md new file mode 100644 index 0000000000..882ec3171b --- /dev/null +++ b/src/Apps/W1/Quality Management/app/docs/extensibility.md @@ -0,0 +1,48 @@ +# Extensibility + +## Overview + +Quality Management publishes 28+ integration events at major decision points in the inspection lifecycle. The extensibility surface covers inspection creation, result evaluation, template/test configuration, inspection finishing, and source document filtering. The app also integrates with BC's workflow engine for event-driven automation. + +## Customize inspection creation + +The `QltyInspectionCreate` codeunit publishes events around the creation flow: + +- **OnBeforeCreateInspection** -- intercept before any creation logic runs. Use to cancel creation for specific scenarios or modify input parameters. +- **OnAfterCreateInspectionBeforeDialog** -- modify the inspection header after creation but before the UI shows it to the user. +- **OnAfterCreateInspectionAfterDialog** -- post-UI actions after the user has seen/modified the new inspection. +- **OnBeforeFindExistingInspection** -- customize the logic that searches for existing inspections (relevant when `Inspection Creation Option` is "Use existing"). +- **OnBeforeCreateReinspection** / **OnAfterCreateReinspection** -- customize re-inspection creation. +- **OnCustomCreateInspectionBehavior** -- extend the `Inspection Creation Option` enum with custom creation strategies. Subscribe to this to handle your own enum values. + +## Customize result evaluation + +- **OnBeforeEvaluateNumericTestValue** (in `QltyInspectionLine` and `QltyResultEvaluation`) -- intercept numeric value parsing to support custom numeric formats or validation. +- **OnValidateExpressionFormula** (in `QltyTest` and `QltyInspectionTemplateLine`) -- validate custom expression syntax beyond the built-in parser. + +## Customize test and template configuration + +- **OnBeforeAssistEditDefaultValue** (in `QltyTest`) -- extend the default value entry UI with custom assist-edit behavior. +- **OnBeforeAssistAllowableValues** (in `QltyTest`) -- extend the allowable values entry UI. +- **OnBeforeIsNumericFieldType** (in `QltyTest`) -- extend numeric field type detection for custom value types. + +## Customize inspection lifecycle + +Events on `QltyInspectionHeader`: + +- **OnBeforeFinishInspection** / **OnBeforeReopenInspection** -- validate or cancel finish/reopen actions. +- **OnInspectionFinished** / **OnInspectionReopen** -- react to lifecycle changes (e.g., trigger external notifications, update related records). +- **OnAfterFindLineUpdateResultFromLines** / **OnBeforeFindLineUpdateResultFromLines** -- customize how line results aggregate to the header result. + +## Customize source document filtering + +- **OnBeforeSetRecordFiltersToFindInspectionFor** / **OnAfterSetRecordFiltersToFindInspectionFor** -- customize how the system searches for inspections related to a specific source record. Use this when the standard source field matching doesn't cover your scenario. + +## Workflow integration + +The Workflow module subscribes to BC's workflow engine with these events: + +- **When a Quality Inspection is Created** -- trigger workflows on new inspections +- **When a Quality Inspection is Finished** -- trigger workflows on completion + +Workflow responses can: block/unblock lots, move inventory, create negative adjustments, create transfer orders, create purchase returns, create re-inspections, and send notifications. This enables fully automated quality disposition pipelines. diff --git a/src/Apps/W1/Quality Management/app/src/Configuration/docs/CLAUDE.md b/src/Apps/W1/Quality Management/app/src/Configuration/docs/CLAUDE.md new file mode 100644 index 0000000000..dda40d5776 --- /dev/null +++ b/src/Apps/W1/Quality Management/app/src/Configuration/docs/CLAUDE.md @@ -0,0 +1,18 @@ +# Configuration + +Defines the entire quality inspection configuration hierarchy: what to measure (tests), how to group measurements (templates), when to auto-create inspections (generation rules), and how to evaluate outcomes (results and conditions). This is where all the "blueprints" live -- actual inspections are created from these definitions. + +## How it works + +The hierarchy flows upward: **Quality Tests** define individual measurements with value types (decimal, boolean, text, table lookup, expression, etc.) and default allowable values. Tests are grouped into **Quality Inspection Templates** with sampling strategies (fixed quantity or percentage of source quantity). **Inspection Generation Rules** connect templates to business events via intent + trigger enums and item/attribute filters, enabling automatic inspection creation. + +**Result evaluation** is configured through **Quality Inspection Results** (codes like PASS, FAIL, INPROGRESS) and **Result Conditions** that map value ranges/expressions to result codes. Conditions exist at three levels -- test defaults, template overrides, and inspection-specific overrides. The most specific level wins. Each result has an `Evaluation Sequence` that determines priority when multiple conditions match. + +## Things to know + +- **Test Value Types are rich** -- beyond simple decimal/text, there are Table Lookup (picks from any BC table/field with filters), Text Expression (formulas referencing other inspection lines), Option (from lookup values), and Value Type Label (display-only). +- **QltyTestLookupValue** stores custom picklist values for tests -- alternative to Table Lookup when you don't want to reference a real BC table. +- **Sampling is template-level** -- `Sample Source` (Fixed Quantity or Percent of Quantity) determines how many units to inspect. This is inherited by the inspection header's `Sample Size`. +- **Generation rules match by Intent** -- the `Intent` enum (Purchase, Production, Transfer, Assembly, Warehouse, Sales Return, Warehouse Receipt) determines which BC events trigger the rule. Each intent has its own trigger enum (e.g., `Purchase Order Trigger: On Receipt | On Invoice`). +- **Result conditions support complex expressions** -- ranges (`10..20`), comparisons (`>=80`), lists (`RED|GREEN|BLUE`), boolean combinations. The `QltyBooleanParsing` codeunit in Utilities handles parsing. +- **Generation rules have a Schedule Group** for job-queue-based scheduled inspection creation, separate from event-driven automatic creation. diff --git a/src/Apps/W1/Quality Management/app/src/Configuration/docs/data-model.md b/src/Apps/W1/Quality Management/app/src/Configuration/docs/data-model.md new file mode 100644 index 0000000000..f7243014e4 --- /dev/null +++ b/src/Apps/W1/Quality Management/app/src/Configuration/docs/data-model.md @@ -0,0 +1,48 @@ +# Data model -- Configuration + +## Overview + +The configuration module contains 9 tables that define the inspection blueprint hierarchy. Tests define individual measurements, templates group tests with sampling, generation rules connect templates to business events, and results/conditions define pass/fail evaluation. + +## Tests and lookup values + +```mermaid +erDiagram + "Qlty Test" ||--o{ "Qlty Test Lookup Value" : "custom values" + "Qlty Test" ||--o{ "Qlty Inspection Template Line" : "used in" + "Qlty Test" ||--o{ "Qlty Result Condition Config" : "default conditions" +``` + +`QltyTest` (20401) is the atomic measurement definition. The `Test Value Type` enum controls the entire input/validation UX: Decimal and Integer get numeric input, Boolean gets a checkbox, Option and Table Lookup get dropdowns, Text Expression gets a formula editor. For Table Lookup types, three fields (`Lookup Table No.`, `Lookup Field No.`, `Lookup Table Filter`) configure which BC table/field to use as the dropdown source. + +`QltyTestLookupValue` (20408) provides an alternative to Table Lookup -- a custom picklist with `Lookup Group Code`, `Value`, `Description`, and 4 extensible custom text fields. Useful when the desired values don't exist in any BC table. + +## Templates and lines + +```mermaid +erDiagram + "Qlty Inspection Template Hdr" ||--|{ "Qlty Inspection Template Line" : "has lines" + "Qlty Inspection Template Line" }o--|| "Qlty Test" : "references test" + "Qlty Inspection Template Line" ||--o{ "Qlty Result Condition Config" : "template-level overrides" +``` + +`QltyInspectionTemplateHdr` (20402) groups tests with a sampling strategy. `Sample Source` determines whether to inspect a fixed number of units or a percentage. `Copied From Template Code` provides audit trail when templates are cloned. + +`QltyInspectionTemplateLine` (20403) links tests to templates and can override test-level properties: description, UOM, expression formula. Template lines can also override result conditions -- a test might default PASS for `>=80` but a stricter template could override to `>=90`. + +## Results and conditions + +```mermaid +erDiagram + "Qlty Inspection Result" ||--o{ "Qlty Result Condition Config" : "conditions" + "Qlty Inspection Result" ||--o{ "Qlty Inspection Header" : "assigned to" + "Qlty Inspection Result" ||--o{ "Qlty Inspection Line" : "assigned to" +``` + +`QltyInspectionResult` (20411) defines outcome codes. Beyond the obvious code/description, the interesting fields are: `Evaluation Sequence` (priority -- lower wins), `Result Category` (Acceptable/Not acceptable), `Finish Allowed` (whether the inspection can complete with this result), and 9 item tracking blocking fields that control per-transaction-type access. + +`QltyIResultConditConf` (20418) is the condition rules table. Each row maps a condition expression to a result code at a specific level (`Condition Type`: Test, Template, or Inspection). The condition is a text expression evaluated against the test value. Multiple conditions can exist per test -- evaluation sequence determines which wins. + +## Generation rules + +`QltyInspectionGenRule` (20409) connects templates to business events. `Intent` determines the domain (Purchase, Production, etc.), and intent-specific trigger enums control the activation point. `Item Filter` and `Item Attribute Filter` narrow which items trigger the rule. `Schedule Group` enables job-queue-based creation separate from event-driven triggers. diff --git a/src/Apps/W1/Quality Management/app/src/Dispositions/docs/CLAUDE.md b/src/Apps/W1/Quality Management/app/src/Dispositions/docs/CLAUDE.md new file mode 100644 index 0000000000..48c60ff55c --- /dev/null +++ b/src/Apps/W1/Quality Management/app/src/Dispositions/docs/CLAUDE.md @@ -0,0 +1,24 @@ +# Dispositions + +Handles post-inspection actions for non-conforming items. Each disposition type creates or modifies BC documents/entries to physically handle items that failed quality checks. The module uses an interface pattern (`QltyDispositionInterface`) for extensibility. + +## How it works + +After an inspection finishes with a failing result, the user (or a workflow response) triggers a disposition action. Seven disposition types are available, each implemented as a separate codeunit: + +- **Change item tracking** -- reclassify lot/serial/package numbers via item reclassification journal +- **Negative adjustment** -- scrap or destroy items via item journal negative adjustment lines +- **Move inventory (item reclass)** -- transfer to quarantine bin via item reclassification journal +- **Move inventory (warehouse reclass)** -- same but via warehouse reclassification journal (for directed put-away locations) +- **Purchase return** -- create a purchase return order to send back to the vendor +- **Warehouse put-away** -- create internal put-away to move items to a rework/quarantine bin +- **Transfer order** -- create a transfer order to move items to another location (external lab, rework center) + +Each disposition codeunit generates the appropriate BC document/journal lines, populating them from the inspection's source fields (item, lot, quantity, location). + +## Things to know + +- **Interface-based** -- `QltyDispositionInterface` (the single interface in this app) defines the contract. Each disposition codeunit implements it. +- **Reports as entry points** -- disposition actions are triggered via processing-only reports (`QltyChangeItemTracking`, `QltyCreateNegativeAdjmt`, `QltyMoveInventory`, `QltyCreatePurchaseReturn`, `QltyCreateInternalPutaway`, `QltyCreateTransferOrder`). These reports handle the request page (quantity, destination, etc.) and call the codeunit. +- **Workflow-triggerable** -- workflow responses can automatically trigger dispositions when an inspection finishes, enabling fully automated quality pipelines. +- **Quantity-aware** -- dispositions respect the inspection's fail quantity, not the full source quantity. Only the non-conforming portion is disposed. diff --git a/src/Apps/W1/Quality Management/app/src/Integration/docs/CLAUDE.md b/src/Apps/W1/Quality Management/app/src/Integration/docs/CLAUDE.md new file mode 100644 index 0000000000..c521dd1d59 --- /dev/null +++ b/src/Apps/W1/Quality Management/app/src/Integration/docs/CLAUDE.md @@ -0,0 +1,20 @@ +# Integration + +Hooks Quality Management into BC's core business processes via event subscribers and page extensions. This is the largest module (67 files) because it touches every domain where inspections can originate -- purchasing, production, assembly, warehouse, sales, transfers, and item tracking. + +## How it works + +Each BC domain has a dedicated integration codeunit that subscribes to posting events. When a purchase receipt is posted, `QltyReceivingIntegration` fires. When production output is posted, `QltyManufacturIntegration` fires. These subscribers call `QltyInspectionCreate` to generate inspections based on matching generation rules. + +The module also extends 27+ BC pages with page extensions that add inspection-related columns, actions (create inspection, view inspections), and factboxes. This makes quality data visible directly in the BC pages users already work with -- purchase orders, production orders, item cards, warehouse receipts, etc. + +Item tracking integration (15 files in `Inventory/Tracking/`) is the most complex sub-area. It enforces result-based blocking on transactions -- checking whether the lot/serial/package has a quality result that allows the specific transaction type (sales, transfer, consumption, pick, put-away, movement, output). + +## Things to know + +- **Event subscribers are domain-specific** -- each domain has its own codeunit rather than a single dispatcher. This keeps the subscription logic local to the domain it understands. +- **Page extensions outnumber everything else** -- 27 page extensions vs 13 codeunits. Most of the integration work is UI: showing inspection status and actions on existing BC pages. +- **Item tracking blocking is checked at transaction time** -- not just at inspection finish. The `QltyItemTrackingIntegration` codeunit subscribes to posting events across all domains to enforce blocking. +- **Transfer integration is split** -- `Inventory/Transfer/` covers transfer order integration, while `Inventory/Transfer/Document/` and `Inventory/Transfer/History/` handle document-level and posted transfer integration separately. +- **Navigate integration** -- `Foundation/Navigate/` hooks into BC's Navigate feature so users can find inspections from posted documents. +- **Attachment integration** -- `Foundation/Attachment/` connects inspection pictures/documents to BC's standard Document Attachment system. diff --git a/src/Apps/W1/Quality Management/app/src/Utilities/docs/CLAUDE.md b/src/Apps/W1/Quality Management/app/src/Utilities/docs/CLAUDE.md new file mode 100644 index 0000000000..e66a7e1ded --- /dev/null +++ b/src/Apps/W1/Quality Management/app/src/Utilities/docs/CLAUDE.md @@ -0,0 +1,19 @@ +# Utilities + +Helper codeunits for expression evaluation, value parsing, and source field extraction. These are the computational workhorses used by the result evaluation engine and inspection creation logic. + +## How it works + +The utilities break down into three areas: + +**Expression evaluation** (`QltyExpressionMgmt`) -- evaluates Text Expression test formulas that can reference other inspection line values. For example, a formula might calculate "Pass Rate = Pass Count / Total Count * 100" using values from other lines in the same inspection. + +**Value parsing** (`QltyValueParsing`, `QltyBooleanParsing`) -- converts text test values into typed values for condition evaluation. `QltyValueParsing` handles numeric, date, and option conversions. `QltyBooleanParsing` handles complex boolean condition expressions with ranges, comparisons, lists, and logical operators. + +**Source traversal** (`QltyTraversal`) -- extracts source fields (item no., lot no., location, quantity, etc.) from various BC record types. Given a RecordId, it determines the table type and reads the relevant fields. This enables inspection creation from any BC table without hardcoding. + +## Things to know + +- **QltyBooleanParsing is the condition engine** -- it parses expressions like `>=80`, `10..20`, `RED|GREEN`, and `true` against test values. Understanding this codeunit is essential for understanding how result conditions work. +- **QltyTraversal uses RecordRef** -- it dynamically reads fields from source records using RecordRef/FieldRef, supporting any BC table without compile-time dependencies. +- **Expression formulas reference by line number** -- Text Expression tests use line numbers to reference other inspection lines, not field names. This means reordering template lines can break expressions. diff --git a/src/Apps/W1/Quality Management/app/src/Workflow/docs/CLAUDE.md b/src/Apps/W1/Quality Management/app/src/Workflow/docs/CLAUDE.md new file mode 100644 index 0000000000..16c306d7b1 --- /dev/null +++ b/src/Apps/W1/Quality Management/app/src/Workflow/docs/CLAUDE.md @@ -0,0 +1,18 @@ +# Workflow + +Integrates Quality Management with BC's standard Workflow engine, enabling event-driven automation of quality processes. Workflows can trigger on inspection creation or completion and execute disposition actions automatically. + +## How it works + +The `QltyStartWorkflow` codeunit publishes workflow events: "When a Quality Inspection is Created" and "When a Quality Inspection is Finished". The `QltyWorkflowApprovals` codeunit registers these events with BC's workflow engine and defines available responses. + +Workflow conditions can filter on any inspection header field -- typically `Result Code` to trigger different actions for PASS vs FAIL. Available workflow responses include: block lot, unblock lot, create negative adjustment, move inventory, create transfer order, create purchase return, create re-inspection, and send notification. + +A common workflow: inspection finishes with FAIL result -> automatically block the lot -> create a purchase return order -> send notification to quality manager. + +## Things to know + +- **Workflow is optional** -- all disposition actions can be done manually without workflows. Workflows add automation. +- **The `Workflow Integration Enabled` toggle** on QltyManagementSetup controls whether workflow events fire at all. If disabled, no workflow processing occurs. +- **Lot blocking via workflow** -- the workflow response creates/modifies `Lot No. Information Card` entries, which is BC's built-in mechanism for blocking lots from transactions. This is a stronger block than the result-based per-transaction-type blocking. +- **Re-inspection via workflow** -- a workflow response can automatically create a re-inspection when an inspection fails, continuing the quality chain without manual intervention.