APS Instructions
Resource and Capabilities
Audience: ERP users who are familiar with Action Target's system but are new to PlanetTogether. Scope: Phase 1 — resource master data, capabilities, and capability assignments. Related stories: US-003 (Resource Maintenance Matrix), US-004 (Resource, Capability, and Attribute Maintenance Tools).
1. How PlanetTogether Organizes the Factory
Before you can understand resources and capabilities, it helps to understand how PlanetTogether structures the physical world. PT uses a three-level hierarchy:
Plant
└── Department(s)
└── Resource(s)
Plant
A Plant represents an entire facility or production location — in PlanetTogether terms, a single physical factory. For Action Target's Phase 1 integration, there is exactly one plant: Action Target Inc. (mapped from base.ent.id = 1).
The Plant is also the scope of a PT optimization run. When PT schedules jobs, it optimizes within the boundaries of a plant.
Department
A Department is PlanetTogether's way of grouping resources that belong together. In most ERP systems, departments map closely to work centers. In Action Target's case, the four PT departments correspond to four vendor-organization rows in the ERP:
| PT Department | ERP vend_org.org_id |
ERP org_name |
|---|---|---|
| Fabrication | 1196 | AcTarg Fabrication |
| Assembly | 1445 | AcTarg Assembly |
| Electronics | 1544 | AcTarg Electronics |
| Wood Shop | 1628 | AcTarg Wood Shop |
What departments do in PT scheduling: Departments have one scheduling effect — each department can have its own frozen zone (a window of time near the current clock where PT will not automatically move scheduled work). Otherwise, departments are organizational groupings, not scheduling constraints.
Important limitation: Once a resource is assigned to a department in PT, it cannot be reassigned. Similarly, a department cannot be reassigned to a different plant. If a reassignment is ever needed, the resource or department must be deleted and recreated under the correct parent. Keep this in mind when setting up the initial data.
Department setup and maintenance is managed by IT and is read-only context for the Planning Resources tools. You will see departments when setting up resources, but you will not edit them there.
Resource
A Resource is the central scheduling object in PlanetTogether. A resource represents anything on the factory floor that performs work: a machine, a workstation, a labor pool, a tool, or any other entity that jobs must be scheduled on.
Key things to understand about resources:
- Every resource belongs to one department (and therefore one plant).
- A resource must have at least one capability assigned to it before jobs can be scheduled on it (see Section 2).
- Each resource has a Capacity Type that controls how many operations it can run at once:
- SingleTasking — Only one operation at a time. The operation must finish before the next one starts.
- MultiTasking — A finite number of operations can run simultaneously, controlled by the number of people available on each shift interval.
- Infinite — Any number of operations may be scheduled simultaneously with no constraint. Used when a resource type truly has no practical limit (e.g., a holding area).
- Resources can also have efficiency multipliers for setup time and cycle time, allowing PT to model resources that run faster or slower than standard time.
Action Target's Phase 1 resource pattern:
Resources are created at three granularities:
| Resource type | One record per... | PT Resource Type |
|---|---|---|
| Machine | Individual machine on the floor | Machine |
| Work Center | Work center (grouping of related machines or stations) | WorkCenter |
| Labor pool | Pool of workers with a shared skill set | Labor |
The current list of resources is maintained in aps.resource_source and managed through the Planning Resources screen. Do not rely on any static list in this document — the screen is always current.
2. Capabilities: Matching Resources to Work
What a Capability Is
A Capability defines a type of work — a skill or process that a resource is qualified to perform. Think of it as a tag or classification. Examples might be "Welding," "Painting," "Assembly," or "CNC Machining."
Capabilities are the bridge between a job operation and the resources that can perform it. Here's how they connect:
- A capability is created (e.g., "Welding").
- That capability is assigned to one or more resources (e.g., the Weld resource and the PT Weld resource both receive the "Welding" capability).
- A job operation declares that it requires the "Welding" capability.
- PT's scheduler then knows which resources are eligible to schedule that operation on.
In ERP terms: Capabilities typically correspond to work centers in traditional ERP systems. But they are more flexible — a capability can also represent a special material type, a process constraint, or any other qualifying characteristic that limits which resources can do the work.
Action Target's Phase 1 Capability Structure
Phase 1 uses three distinct capability types, each following a consistent naming convention that signals both intent and scheduling behavior at a glance:
| Type | Naming pattern | What it means | Notes field value |
|---|---|---|---|
| Labor | Labor - [Skill] |
Ties a labor resource to the type of work it performs. One labor capability per skill, assigned to exactly one labor resource. | (empty) |
| Pool | Pool - [Process] |
Groups interchangeable resources. Any resource in the pool can satisfy the requirement. | Jobs can run on any resource in the pool. |
| Machine | Machine - [Machine Name] |
Pins a requirement to a specific machine (or a very small set of equivalent machines). | Jobs can only run on specific resources. |
The Notes field on a capability conveys intent to planners and reviewers. Pool capabilities say "Jobs can run on any resource in the pool," and Machine capabilities say "Jobs can only run on specific resources." Labor capabilities leave notes empty — the prefix makes the constraint self-evident.
Why individual machines carry two capability types:
A machine like the Brake 400T is typically assigned both a Pool capability and a Machine-specific capability:
- The Pool capability (e.g.,
Pool - Bend) groups it with other interchangeable brakes so that generic bending operations can land on any eligible brake. - The Machine capability (e.g.,
Machine - Bend 400T) allows operations that require this specific press — due to tonnage or tooling — to be pinned exclusively to it.
An operation routes to whichever capability matches its requirement: generic work links to the Pool, tonnage-specific work links to the Machine capability.
Capability Assignments
A Capability Assignment is the record that links a specific capability to a specific resource. It requires:
- The capability being assigned
- The resource receiving it
- The plant and department context (derived automatically from the resource)
A resource can have many capabilities. A capability can be assigned to many resources. When a job operation requires multiple capabilities, a resource must have all of the required capabilities to be eligible — not just one of them.
Example: Suppose an operation requires both "Welding" and "Certified Inspection." Only a resource that has both capabilities assigned will be considered eligible to run that operation.
Capability-Operation Links
The third piece of the capability picture is the Capability-Operation Link: a record that declares which capability a given ERP routing operation requires.
Think of it this way:
- Resource-Capability Assignments say: "This resource can do this type of work."
- Capability-Operation Links say: "This operation requires this type of work."
PT's scheduler matches them: an operation can only land on a resource when the resource has all the capabilities the operation's links require.
Each link also has a Requirement Sequence (Seq). The sequence number identifies which resource slot a capability requirement belongs to — PT must find a separate, simultaneously available resource to satisfy each distinct sequence number.
The sequence values recorded here are the authoritative source for which resource slots an operation uses. When jobs are exported to PT, one resource requirement row is created per distinct seq found in this table for the operation — not a fixed number. An operation that has only Seq 1 and Seq 3 links gets exactly two resource requirements. Among all of an operation's slots, the one with the lowest seq is marked as the primary requirement — the anchor slot PT treats as its scheduling driver. Action Target's Phase 1 design uses up to three slots per operation: the specific machine (Seq = 1), the pool the machine belongs to (Seq = 2), and a labor resource (Seq = 3).
How Capabilities Affect Scheduling
PT will not schedule an operation on a resource unless that resource has all the capabilities the operation's links require. This means:
- Resources with no capabilities assigned cannot be scheduled on any operations.
- Operations with no capability link cannot be scheduled at all.
- Getting both sides right — what resources can do, and what operations require — is a prerequisite before job data can be exported to PT and scheduling can work correctly.
3. Our ERP Data Model: The aps.*_source Tables
All resource and capability data that flows to PlanetTogether is owned and maintained in the aps schema of the ERP database. PT is a consumer of this data — the ERP is the authoritative source of record.
The data lives in source tables (aps.*_source). PT-facing export views (aps.*_v) read from those source tables and present the data in the exact shape PT expects.
Source Tables
| Table | What it holds | PT object it feeds |
|---|---|---|
aps.plant_source |
The single Action Target plant record. | Plants |
aps.department_source |
The four production departments, linked to public.vend_org. |
Departments |
aps.resource_source |
Resource master records; each belongs to a department/plant. Work area resources carry workcenter (display name) and workcenter_id (the associated ati_pool id from work_order.ati_pools, stored as varchar; no FK enforced). |
Resources |
aps.capability_source |
Capability definitions (name, description, notes). | Capabilities |
aps.capability_assignment_source |
Which capabilities are assigned to which resources. | CapabilityAssignments |
aps.capability_operation_link |
Links ERP routing operations to capabilities, each with a requirement_seq. This is the authoritative source for which resource slots an operation requires. Only operations with active rows here will have resource requirements generated on export. |
JobResourceCapabilities |
aps.workcell_department_link |
Legacy lookup: maps workcell names to departments. Used for context; not a PT export. | (Internal reference) |
Export Views
The export views are the data layer PT reads from. You do not need to interact with them directly, but understanding what they filter is useful:
| View | Filters / shape |
|---|---|
aps.plants_v |
Active plants only. Columns: external_id, name, description. |
aps.departments_v |
Active departments joined to the active plant. |
aps.resources_v |
Active resources only. Includes default batch_type = 'None', capacity_type, resource_type. Exposes workcenter and workcenter_external_id (sourced from workcenter_id on aps.resource_source) for work area resources; null for machines and labor. |
aps.capabilities_v |
Active capabilities only. |
aps.capability_assignments_v |
Active assignments where both the capability and resource are also active. |
4. How Data Flows to PlanetTogether
Once your source tables are populated, the data flows to PT through export views:
aps.*_source tables → aps.*_v export views → PlanetTogether import
PT reads from the export views — it never reads directly from the source tables. The views:
- Filter out inactive records automatically (
where active = true). - Present columns in the exact names and shapes PT expects.
- Join related tables to resolve foreign keys into the values PT needs (e.g.,
capability_assignment_sourceis joined to both the capability and resource tables so only fully active assignments export).
5. Using the Planning Resources Screen
The Planning Resources tab is located inside the Product Information app. It is the central place to maintain all resource and capability data before it is exported to PlanetTogether.
Access to create, edit, and retire records requires the Manufacturing Engineering, Product Data Manager, or IT Admin role. Planning and scheduling leads have view-only access.
The screen contains five data grids. Three of them interact with each other dynamically based on what row you select, which is explained at the end of this section.
Main Toolbar
At the top of the screen, three toggle buttons control which grids are visible:
| Button | What it does |
|---|---|
| Hide / Show Resources | Collapses or expands the Resources grid. Hiding the grid also clears any active resource selection, which resets the Resource Capabilities filter back to showing all assignments. |
| Hide / Show Capabilities | Collapses or expands the Capabilities grid. Hiding it clears any active capability selection, resetting both the Resource Capabilities filter and the Operation Links filter. |
| Hide / Show Operation Links | Collapses or expands the Capability-Operation Links grid. The other grids are unaffected. |
Readiness Issues
This grid runs a live validation check every time you open the screen or save a change. It shows problems that would prevent a successful export to PlanetTogether.
Columns displayed:
| Column | What it shows |
|---|---|
| Severity | How serious the issue is (e.g., Error, Warning). |
| Code | A short code identifying the type of issue. |
| Message | A plain-language description of the problem. |
| Resource | The Resource ID involved, if applicable. |
| Capability | The Capability ID involved, if applicable. |
This grid is read-only. You resolve issues by correcting the underlying data in the Resources, Capabilities, Resource Capabilities, or Operation Links grids below, then the Readiness Issues grid will refresh automatically.
Resources Grid
This grid shows all APS resources from aps.resource_source. It is the starting point for managing everything the factory floor can do.
Columns displayed by default: Resource ID, Resource Name, Plant, Department, Resource Type, Capacity Type, Active. (A Notes column is also available but hidden by default.)
Toolbar actions:
| Action | Behavior |
|---|---|
| Add | Opens the resource form in create mode. All required fields must be filled before saving. |
| Edit | Opens the resource form loaded with the selected row's data. Select exactly one row first. |
| Retire | Prompts for confirmation, then marks the resource inactive (is_active = false). The resource is never physically deleted. It will be excluded from PT exports and cannot be scheduled on new jobs, but any historical references remain intact. |
| Show Inactive / Hide Inactive | Toggles whether inactive (retired) resources appear in the list. Defaults to hiding inactive records. Toggling this clears the current resource selection. |
| Show Only Unmapped / Show All Resources | Filters the list to resources that have no capability assignments at all. These resources cannot be scheduled by PT. Use this to quickly identify gaps before exporting. Toggling this also clears the current selection. |
Resource form fields:
| Field | Required | Notes |
|---|---|---|
| Resource Name | ✅ | The display name in PT. Use properly-cased names ("Powder Coat," not "powder coat"). |
| Plant | ✅ | Defaults to the existing plant. Phase 1 always uses plant 1. |
| Department | ✅ | Must match one of the four active departments. Pick from the dropdown. |
| Resource Type | ✅ | Loaded live from the database schema. Choose Machine for individual machines, WorkCenter for work centers, or Labor for labor pools. |
| Capacity Type | ✅ | Loaded live from the database schema. Defaults to Infinite for Phase 1. See Section 1 for what each value means in PT. |
| Notes | Optional free-text for internal use. Not sent to PT. |
Resource Type and Capacity Type dropdown values are loaded directly from the database schema's CHECK constraint via the API. This means the options always reflect what the schema allows — no UI change is needed if the constraint is ever updated.
Selecting a resource row: Clicking a row in this grid selects that resource and filters the Resource Capabilities grid to show only that resource's capability assignments. Any capability selection is cleared at the same time.
Capabilities Grid
This grid shows all APS capability definitions from aps.capability_source.
Columns displayed by default: Capability ID, Name, Description, Active. (A Notes column is also available but hidden by default.)
Toolbar actions:
| Action | Behavior |
|---|---|
| Add | Opens the capability form in create mode. |
| Edit | Opens the capability form for the selected row. |
| Retire | Prompts for confirmation, then marks the capability inactive. Never physically deleted. |
| Show Inactive / Hide Inactive | Toggles visibility of inactive capabilities. Defaults to hiding them. Clearing this also clears the current capability selection. |
| Show Only Unmapped / Show All Capabilities | Filters to capabilities that are not assigned to any resource. A capability with no resource assignments cannot be used to schedule anything. Use this to find capabilities that need to be assigned before exporting. |
Capability form fields:
| Field | Required | Notes |
|---|---|---|
| Capability ID | Read-only | Shown on the edit form for reference. On a new capability, the ID is generated automatically by the system — you do not supply it. |
| Name | ✅ | The display name in PT. This is what planners see when reviewing job requirements in PlanetTogether. |
| Description | Optional. Describe the type of work this capability covers, which resources it applies to, or any constraints. | |
| Notes | Optional internal notes. |
Capability IDs are system-generated when you add a new capability. You do not choose the ID. The generated ID flows to PT as the
Capabilities.ExternalIdand will be referenced by resource-capability assignments and operation links — so once created, a capability ID is permanent. Retire and recreate if a significant change is needed.
Selecting a capability row: Clicking a row selects that capability and simultaneously filters two grids:
- Resource Capabilities — shows only assignments that include this capability (i.e., which resources can do this type of work).
- Capability-Operation Links — shows only operation links for this capability (i.e., which operations require this type of work).
Any resource selection is cleared at the same time.
Resource Capabilities Grid
This grid shows resource-to-capability assignments from aps.capability_assignment_source. It is the link that tells PT which resources are eligible to perform which types of work.
Columns displayed by default: Resource, Capability, Plant, Department, Active. (Notes is available but hidden.)
Toolbar actions:
| Action | Behavior |
|---|---|
| Add | Opens the assignment form. Choose the resource and capability; Plant and Department are filled in automatically from the selected resource. |
| Edit | Opens the assignment form for the selected row. The Resource and Capability fields are locked because they form the composite primary key and cannot be changed after creation. Only Notes can be edited. |
| Retire | Prompts for confirmation, then removes or inactivates the assignment. |
Assignment form fields:
| Field | Add | Edit | Notes |
|---|---|---|---|
| Resource | ✅ editable | 🔒 locked | Dropdown shows only active resources. When a resource is selected, Plant and Department are filled in automatically. |
| Capability | ✅ editable | 🔒 locked | Dropdown shows only active capabilities. |
| Notes | editable | editable | Optional internal notes. |
How the filter works:
- If a resource is selected in the Resources grid: shows only that resource's assignments (i.e., what capabilities does this resource have?).
- If a capability is selected in the Capabilities grid: shows only assignments for that capability (i.e., which resources can do this work?).
- If nothing is selected: shows all assignments.
This makes the Resource Capabilities grid a two-direction lookup depending on what you click first.
Capability-Operation Links Grid
This grid links ERP routing operations to the capabilities they require. It lives in a separate source table and is the mechanism that tells PT what kind of work each operation step needs, so PT can find eligible resources.
Every routing operation that will be scheduled in PT must have at least one link here. Without it, PT cannot find a resource for the operation and it will not schedule.
Columns displayed by default: Operation, Capability, Capability Name, Seq (Requirement Sequence), Active. (Operation ID and Notes are also available.)
Toolbar actions:
| Action | Behavior |
|---|---|
| Add | Opens the operation link form. Choose the operation and capability. If a capability is currently selected in the Capabilities grid, the form pre-fills that capability. |
| Edit | Opens the form for the selected row. The Operation and Capability fields are locked (they identify the link). Only Requirement Sequence and Notes are editable. |
| Retire | Prompts for confirmation, then retires the link. |
Operation link form fields:
| Field | Add | Edit | Notes |
|---|---|---|---|
| Operation | ✅ editable | 🔒 locked | Dropdown populated from active ERP routing operations. |
| Capability | ✅ editable | 🔒 locked | Dropdown shows active capabilities. Pre-filled if a capability is selected. |
| Requirement Sequence | ✅ editable | editable | A positive integer (minimum 1). Determines the resource requirement slot in PT — see explanation below. |
| Notes | editable | editable | Optional internal notes. |
Understanding Requirement Sequence:
The Requirement Sequence (Seq) identifies which resource slot a capability requirement belongs to. PT must find a separate, simultaneously available resource to fill each slot. Action Target's Phase 1 design uses up to three slots per operation:
| Seq | Capability type | What PT finds |
|---|---|---|
| 1 | Machine (Machine - …) |
The specific machine (or machine class) the operation runs on. Drives the operation's run time and scheduling window. |
| 2 | Pool (Pool - …) |
A resource from the pool the machine belongs to. Constrains eligibility to machines within the defined group. |
| 3 | Labor (Labor - …) |
The labor resource required to run the operation. Must be available at the same time as the machine. |
Not every operation has all three slots — for example, operations without a machine-specific requirement omit Seq = 1, and blast has only Seq = 1 (no pool or labor link in Phase 1).
How the filter works:
- If a capability is selected in the Capabilities grid: shows only operation links for that capability (i.e., which operations require this capability).
- If nothing is selected (or a resource is selected): shows all operation links.
How the Tables Work Together
The three middle grids — Resources, Capabilities, and Resource Capabilities — plus the Operation Links grid are all connected through row selections. Here is a summary of what happens when you click in each grid:
| You click... | Resource Capabilities shows... | Operation Links shows... |
|---|---|---|
| A row in Resources | Only that resource's capability assignments | All links (unchanged) |
| A row in Capabilities | Only assignments for that capability | Only links for that capability |
| Empty space / deselect | All assignments | All links |
Clicking in Resources clears any capability selection, and clicking in Capabilities clears any resource selection. The two grids are mutually exclusive — you are always viewing the assignments from one direction at a time.
This design lets you quickly answer two common questions:
- "What capabilities does the Weld resource have?" → Click Weld in the Resources grid.
- "Which resources can perform Welding, and which operations require it?" → Click Welding in the Capabilities grid.
6. Phase 1 Scope: What's Used and What's Not
Some PlanetTogether resource features are available in the software but are not being configured for Phase 1. This is intentional — start simple and add complexity as needed.
| PT Feature | Phase 1 Status | Notes |
|---|---|---|
| Plants | ✅ Used | Single plant (Action Target). |
| Departments | ✅ Used | Four departments from ERP vend_org. Read-only in Phase 1 tools. |
| Resources | ✅ Used | Maintained in aps.resource_source. One per machine, one per work center, one per labor pool. |
| Capabilities | ✅ Used | Maintained in aps.capability_source. |
| Capability Assignments | ✅ Used | Maintained in aps.capability_assignment_source. |
| Capability-Operation Links | ✅ Used | Maintained in the operation capability link table. Required for job export. |
| Capacity Intervals / Calendars | ❌ Not used | PT will use default shift definitions; no ERP-driven calendar import in Phase 1. |
| Helper Resources (Seq > 1) | ✅ Used | Each operation links to up to three capability slots: Seq 1 = Machine, Seq 2 = Pool, Seq 3 = Labor. All three resources must be simultaneously available for PT to schedule the operation. |
| Cells | ❌ Not used | Cell scheduling not needed initially. |
| Product Rules | ❌ Not used | Confirmed not used for Phase 1. |
| Compatibility Code Tables | ❌ Not used | Not needed for Phase 1. |
| Cleanout Trigger Tables | ❌ Not used | Not needed for Phase 1. |
7. Summary: The Minimum You Need Before Jobs Can Schedule
Before PlanetTogether can schedule a job, the following must be in place:
- ✅ Plant record exists (
aps.plant_source). - ✅ Department records exist (
aps.department_source) for all departments referenced by resources. - ✅ Resource records exist and are active (
aps.resource_source). - ✅ Capability records exist and are active (
aps.capability_source). - ✅ Every resource that will carry job operations has at least one capability assigned (
aps.capability_assignment_source). - ✅ Every routing operation that will be scheduled in PT has at least one Capability-Operation Link pointing to a capability that is assigned to at least one active resource.
Missing any of these means PT either cannot find an eligible resource for an operation, or the operation will fail to schedule.
Attributes
Audience: ERP users who are familiar with Action Target's system but are new to PlanetTogether. Scope: Phase 1 — attribute definitions, attribute codes, and operation attribute links. Related stories: US-004 (Resource, Capability, and Attribute Maintenance Tools).
1. What Attributes Do in PlanetTogether
Attributes are custom data properties that can be attached to job operations. They give the scheduler a way to describe what kind of work an operation is — beyond which machine and labor pool it needs — so PlanetTogether can group, sequence, and schedule setup or cleanout time intelligently.
Phase 1 uses attributes for two purposes:
Sequence optimization (batching): When PT builds a schedule, it can minimize the number of setup changeovers by grouping consecutive operations that share the same attribute value on the same resource. An attribute with UseInSequencing = true becomes available to the PT Sequence Planning board's optimize factors. Schedulers can weight each attribute and configure how many optimization points to award for grouping similar work together.
Setup and cleanout time: When an attribute value changes between two consecutive operations on the same resource, PT can automatically schedule a setup or cleanout block between them. The AttributeTrigger property controls when the timer fires (e.g., always, when the code changes, when a numeric value rises), and AttributeType controls whether the time is counted as Setup or Clean time.
An attribute can serve both purposes at the same time, or just one, or purely as informational metadata visualized in the Gantt and scheduling grids.
2. The Three Layers: Attributes, Codes, and Operation Links
Working with attributes in the ERP involves three layers that build on each other:
Layer 1 — Attribute Definition
An Attribute is the property type itself — a named, configurable object that describes a characteristic of work. Examples: "Steel Grade," "Coating Type," "Product Family." The attribute definition sets all the defaults: how PT should visualize it, whether it drives sequencing or setup calculations, and what duration or cost to use when it fires.
Layer 2 — Attribute Codes
An Attribute Code is one allowed value for an attribute. Each attribute has a list of codes representing the discrete values it can take. For example, the "Steel Grade" attribute might have codes A36, A500-B, AR200, and HRPO.
Codes are the strings that get attached to individual operations. When two consecutive operations on the same resource carry different codes for the same attribute, PT can recognize the code change and trigger a setup or sequencing decision.
Layer 3 — Operation Attribute Links
An Operation Attribute Link is the record that ties a specific code to a specific routing operation. It says: "When this operation runs, it should carry this attribute value."
Links live on the router — both the workbench (draft) and production sides. When a workbench router is published, its attribute links are copied forward to the production router. When a template is generated from the production router, the attribute links become rows in aps.job_operation_attribute_source, which PT reads for scheduling.
3. The aps.*_source Tables
| Table | What it holds | PT object it feeds |
|---|---|---|
aps.attribute_source |
Attribute definitions (one row per attribute). | Attributes |
aps.attribute_code_source |
Allowed code values per attribute. | Referenced by Operation Attributes |
aps.bom_operations_attributes |
Operation attribute/code links for workbench and production routers. | (join source for template generation) |
aps.job_operation_attribute_source |
Generated per-operation attribute rows for template MOs. | OperationAttributes |
aps.attribute_code_table_source exists in the schema but is not used in Phase 1.
4. How Data Flows to PlanetTogether
aps.attribute_source → PT Attributes import
aps.attribute_code_source → (read at template generation time)
aps.bom_operations_attributes → (read at template generation time)
↓ GenerateRouterTemplate
aps.job_operation_attribute_source → PT Operation Attributes import
Attribute definitions are imported into PT as Attribute objects. The code values assigned to specific operations are carried in the template's Operation Attributes rows, generated each time a template is created or regenerated for a router. PT reads both when building a scenario.
5. Using the Planning Attributes Screen
The Planning Attributes tab is located inside the Product Information app. It is where you define attributes and manage their allowed code values before linking them to router operations.
Access to create, edit, and retire records requires the Manufacturing Engineering, Product Data Manager, or IT Admin role. Planning and scheduling leads have view-only access.
The screen contains two side-by-side grids. The Codes grid is filtered by whatever attribute is selected in the Attributes grid.
Main Toolbar
| Button | What it does |
|---|---|
| Hide / Show Attributes | Collapses or expands the Attributes grid. |
| Hide / Show Codes | Collapses or expands the Codes grid. |
| Show Inactive / Hide Inactive | Toggles visibility of inactive attributes. Defaults to hiding them. |
Attributes Grid
This grid shows all APS attribute definitions from aps.attribute_source.
Columns displayed by default: Attribute ID, Name, Description, Use in Sequencing, Active.
Toolbar actions:
| Action | Behavior |
|---|---|
| Add | Opens the attribute form in create mode. |
| Edit | Opens the attribute form loaded with the selected row's data. Select exactly one row first. |
| Retire | Prompts for confirmation, then marks the attribute inactive. Never physically deleted. |
Attribute form fields:
Identity
| Field | Required | Notes |
|---|---|---|
| Attribute ID | ✅ | Must match the ID used in PT imports. Convention: ATTR-[ShortName] (e.g., ATTR-SteelGrade). Locked after creation — retire and recreate if a change is needed. |
| Name | ✅ | Display name in PT and in ERP grids. |
| Description | Describe what characteristic this attribute classifies. |
PT Setup Behavior
| Field | Notes |
|---|---|
| Trigger | Controls when a setup or cleanout fires. See the trigger table below. Leave blank when using the attribute for sequencing only. |
| Type | Setup or Clean. Defines whether the incurred time counts as setup or cleanout. Leave blank for informational or sequencing-only attributes. |
| Cleanout Grade | Integer priority for simultaneous cleanout scheduling. When multiple cleanouts fire at the same time, the highest grade wins. A cleanout also resets all triggers at or below its own grade. Only relevant when Type = Clean. |
| Color Code | Hex color (#RRGGBB) for Gantt attribute segments. |
AttributeTrigger accepted values:
| Trigger value | When the setup or clean fires |
|---|---|
Always |
Every time this operation is scheduled, regardless of what comes before it. |
CodeChanges |
When this attribute's code changes from one scheduled operation to the next on the same resource. |
NumberChanges |
When this attribute's number value changes from the previous operation to the next on the same resource. |
NumberHigher |
When this attribute's number value increases from the previous operation to the next. |
NumberLower |
When this attribute's number value decreases from the previous operation to the next. |
LookupByCode |
Duration is determined by an Attribute Code Table (Phase 2 only). |
LookupByRange |
Duration is determined by an Attribute Range Table (Setup only; Phase 2 only). |
Never |
This attribute is not used for setup or clean calculations. |
Defaults
| Field | Notes |
|---|---|
| Default Cost | Cost incurred per setup or cleanout event triggered by this attribute. Not used with lookup table triggers. |
| Default Duration (hrs) | Hours incurred per event. Not used with lookup table triggers. |
Flags
| Flag | Default | What it controls in PT |
|---|---|---|
| Consecutive Setup | false | When true, multiple setup steps for the operation must run sequentially rather than concurrently. Total setup time = max non-consecutive time + sum of all consecutive times. |
| Incur Resource Setup | false | When true, the sequenced setup fires even if the resource's UseSequencedSetup flag is false. |
| Show in Gantt | false | When true, this attribute's name and code appear in the Gantt activity block when the Attribute Segment is enabled on the label. |
| Hide in Grids | false | When true, this attribute's columns are hidden from the Activities board scheduling grids. |
| Use in Sequencing | false | When true, this attribute is available to the Sequence Planning board's optimize factors for schedule batching and grouping. |
Selecting an attribute row: Clicking a row selects that attribute and filters the Codes grid to show only that attribute's allowed code values.
Codes Grid
This grid shows the allowed code values for the currently selected attribute, from aps.attribute_code_source. When no attribute is selected, this grid is empty — select an attribute row first.
Columns displayed by default: Code, Display Name, Description, Active.
Toolbar actions:
| Action | Behavior |
|---|---|
| Add | Opens the code form. The Attribute field is pre-filled and read-only. Disabled when no attribute is selected. |
| Edit | Opens the code form for the selected row. |
| Retire | Prompts for confirmation, then retires the code. Existing operation attribute links referencing a retired code remain historically valid — they are not automatically removed. |
| Show Inactive / Hide Inactive | Toggles visibility of inactive codes. |
Code form fields:
| Field | Required | Notes |
|---|---|---|
| Attribute | Read-only | Pre-filled from the currently selected attribute. |
| Code | ✅ | The short code string (e.g., A36, COAT-POWDER). Must be unique within the attribute. This is the value PT carries on job operations. |
| Display Name | A longer, readable label shown in ERP dropdowns and grids. | |
| Description | Optional explanation of what this code represents. | |
| Notes | Optional internal notes. |
Code uniqueness: Codes are unique within an attribute. The same code string can appear under two different attributes without conflict.
6. Linking Attributes to Operations (Routers Tab)
Attribute definitions and codes are only useful once they are attached to specific routing operations. This is done in the Routers tab, not the Attributes tab.
Where to Find the Operation Attribute Links
In the Routers tab, select a workbench or production router and then select a BOM operation row. The Operation Attributes sub-grid below the operations grid shows the attribute/code links for that operation.
Workbench vs. Production
Attribute links follow the same workbench/production pattern as the router itself:
| Side | What it holds | When it updates |
|---|---|---|
| Workbench | Draft attribute links configured before publishing. | Add/edit/retire any time the router is being edited. |
| Production | Published links that feed template generation. | Replaced automatically when the workbench router is published. |
Do not edit production operation attribute links directly for normal maintenance. Make changes on the workbench side, then publish.
Operation Attribute Links Grid
Columns displayed by default: Attribute, Code, Active.
Toolbar actions:
| Action | Behavior |
|---|---|
| Add | Opens the link form. Disabled when no BOM operation is selected or the router is not in an editable state. |
| Edit | Opens the link form for the selected row. |
| Retire | Prompts for confirmation, then retires the link. The operation will no longer carry this attribute when the next template is generated. |
Link form fields:
| Field | Required | Notes |
|---|---|---|
| Attribute | ✅ | Dropdown showing active attributes. |
| Code | ✅ | Dropdown showing active codes for the selected attribute. |
Multiple codes per operation: An operation can have more than one attribute link, and can have multiple links for the same attribute with different codes. All active links are exported as separate rows in
aps.job_operation_attribute_source.
How Publishing Propagates Attribute Links
When a workbench router is published:
- All existing production operation attribute links for that router are cleared.
- The workbench links are copied to the production side, translated through the workbench-to-production BOM operation ID map.
- The production links are now the authoritative source for the next template generation.
After publishing, regenerate the template so PT receives the updated attribute rows.
7. Phase 1 Scope: What's Used and What's Not
| PT Feature | Phase 1 Status | Notes |
|---|---|---|
| Attribute definitions | ✅ Used | Maintained in aps.attribute_source. |
| Attribute codes (ERP-owned allowed values) | ✅ Used | Maintained in aps.attribute_code_source. |
| Operation attribute links | ✅ Used | Configured per BOM operation in the Routers tab; propagated on publish; generated into templates. |
| UseInSequencing | ✅ Used | Attributes with this flag true are eligible for sequence optimization in PT. |
| AttributeType / AttributeTrigger (Setup or Clean) | ✅ Supported | Can be configured; actual scheduling of setup/clean time also requires the resource to have SetupIncluded = UseOperationAttributes (for Setup) or UseAttributeCleanouts = true (for Clean). |
| ShowInGantt / HideInGrids / ColorCode | ✅ Supported | PT will respect these flags once attribute data is imported. |
Attribute Code Tables (LookupByCode trigger) |
❌ Not used | Code Table data is not exported in Phase 1. |
Attribute Range Tables (LookupByRange trigger) |
❌ Not used | Range Table data is not exported in Phase 1. |
| Number-based attribute values on operations | ❌ Not used | Phase 1 operation links carry a code (string) value only. Triggers that depend on a numeric value (NumberChanges, NumberHigher, NumberLower) have no effect. |
8. Summary: The Minimum You Need Before Attribute Data Can Influence Scheduling
For PT to use an attribute during scheduling:
- ✅ An attribute definition exists and is active (
aps.attribute_source). - ✅ At least one code is defined and active for that attribute (
aps.attribute_code_source). - ✅ At least one BOM operation on the production router has an active link to that attribute and code (
aps.bom_operations_attributes,is_workbench = false). - ✅ The template has been generated (or regenerated) after the production links were set — attribute rows must exist in
aps.job_operation_attribute_source. - ✅ For sequence optimization:
UseInSequencing = trueon the attribute, and the attribute must be selected in the applicable optimize factor on the PT Sequence Planning board. - ✅ For setup time:
AttributeType = Setup, a trigger configured, a default duration set, and the resource must haveSetupIncluded = UseOperationAttributes. - ✅ For cleanout time:
AttributeType = Clean, a trigger configured, a default duration set, and the resource must haveUseAttributeCleanouts = true.
Missing any of these means the attribute is defined but has no scheduling effect in PT.
Routing Templates
Audience: ERP users who are familiar with Action Target's system but are new to PlanetTogether. Scope: Phase 1 — router-to-template linking and template generation. Related stories: US-014 (Routing Maintenance Tools), US-015 (Router Template Generation).
1. What Is a Template?
PlanetTogether schedules jobs by matching job operations to eligible resources. To do that efficiently, PT uses templates — pre-built representations of how a part is manufactured — that it holds in memory and applies each time a new job for that part arrives.
In Action Target's integration, a template is derived directly from an ERP router. The router already defines the sequence of operations, setup and run times, and the materials consumed at each step. Template generation reads that router and produces a standardized PT job structure from it — without touching native work order tables.
Key things to understand:
- Every part that will be scheduled in PT needs a template based on its current router.
- A template is tied to one specific router revision. When a router is superseded by a new revision, that new revision needs its own template.
- Generating a template is safe to repeat — re-running it refreshes the PT data from the current router state without creating duplicates.
- Templates do not affect live work orders. They are scheduling reference structures used by PT, not production documents.
2. Routers and the Concept of "Current"
An ERP router defines the manufacturing process for a part: the sequence of operations, the time each step takes, and the materials consumed. Routers are version-controlled — when a process changes, a new router revision is published for that part.
At any point in time, exactly one router revision is current for each part. A router is current when today's date falls within its effective date range (Effective From through Effective To). Older revisions are archived but remain visible in the system.
Why this matters for templates:
- Only a current router can have a template generated from it. The system blocks generation on archived routers.
- When a router is superseded by a new revision, the old template is not automatically updated. The new revision must be selected in the Templates screen and a new template generated from it.
- Future automation of this step is planned but not in scope for Phase 1.
3. What Gets Generated
When you generate a template from a router, the system produces a complete PT job structure covering:
| Generated object | What it represents |
|---|---|
| Template Job | The top-level PT job anchor for this router/part. |
| Manufacturing Order | One synthetic MO for the template — no sub-assembly expansion. |
| Operations | One PT operation per router BOM operation, in sequence order. |
| Resource Requirements | The machine, pool, and labor slots each operation needs (from Resource Management capability mappings). |
| Resource Capabilities | The specific capabilities required at each resource slot. |
| Activities | One internal activity per operation, used by PT for scheduling granularity. |
| Materials | Material consumption rows derived from the router's BOM. |
| Products | Output items for each operation, including phantom WIP items between steps. |
| Operation Attributes | Attribute/code pairs assigned to each operation, used by the PT Optimizer to group or sequence compatible operations (e.g., same burn material class or paint color). |
| Path / Path Nodes | The linear operation sequence that PT follows when scheduling. |
Resource requirement rows are only generated for operations that have active capability mappings in Resource Management. An operation with no capability mapping will still appear in the template (with its activity, time, and BOM rows), but PT will not be able to assign a resource to it until a mapping is configured.
Operation attribute rows are only generated for operations that have active attribute links configured on the router. Operations without attribute links will not have attribute rows — PT will not use them for grouping or sequencing until links are added and the template is regenerated.
4. The ERP Data Model
All template data lives in the aps schema alongside job and resource data, using source_type = 'TEMPLATE' to distinguish template rows from live work order rows.
The Router Link
| Table | What it holds |
|---|---|
aps.template_router_link |
The anchor record tying one router revision to its generated template. Holds the canonical link_id that drives all generated IDs. |
The link_id is the key that all generated IDs are built from:
| Generated ID | Pattern | Example |
|---|---|---|
| Template Job ID | template-{link_id} |
template-42 |
| Template MO ID | template-{link_id}-mo |
template-42-mo |
| Template Operation ID | template-{link_id}-op-{bom_op_id} |
template-42-op-68664 |
Template Source Tables
| Table | Template content |
|---|---|
aps.job_source |
One template job per router link. |
aps.manufacturing_order_source |
One template MO per router link. |
aps.job_operation_source |
One row per BOM operation. |
aps.job_resource_source |
Resource requirement slots (machine, pool, labor). |
aps.job_resource_capability_source |
Capability requirements per resource slot. |
aps.job_activity_source |
One activity per operation. |
aps.job_material_source |
Material consumption rows. |
aps.job_product_source |
Output items, including phantom WIP. |
aps.job_path_source |
The single default path for the template MO. |
aps.job_path_node_source |
Predecessor/successor pairs defining operation sequence. |
aps.job_operation_attribute_source |
Attribute/code pairs per operation, generated from active attribute links on the router. |
5. Using the Templates Screen
The Templates tab is located inside the Product Information app. It is the central place to view router status, generate templates, and inspect what was generated.
Access to generate templates requires the Manufacturing Engineering, Product Data Manager, or IT Admin role.
Main Toolbar
| Button | Behavior |
|---|---|
| Generate Template | Generates or regenerates the APS template for the selected router. Disabled unless exactly one current router is selected. Prompts for confirmation before running. |
| Router Details | Opens the Router Details panel for the selected router. Shows the operation list plus any blocking errors or warnings, without committing any data. |
| Show / Hide Template Details | Expands or collapses the Template Details panel below the Routers grid (see Section 5.4). |
Routers Grid
This grid lists all routers and their current template status.
Columns displayed by default: Router Name, Part, Rev, Description, Effective From, Effective To, Current, Template Status, Template Job ID, Last Generated.
Row colors:
| Color | Meaning |
|---|---|
| Yellow | Router is not current (archived). Template generation is blocked. |
| Red | Router is current but has no template — it has never been generated. |
| No color | Router is current and has a generated template. |
Routers grid toolbar:
| Button | Behavior |
|---|---|
| Show / Hide Archived | Toggles visibility of non-current (archived) routers. Defaults to hidden — only current routers are shown on load. |
| Show Only Unmapped / Show All | Filters to routers with no template at all (Template Status = none). Use this to find gaps before a PT go-live. |
Template Status values:
| Status | Meaning |
|---|---|
none |
No template has ever been generated for this router. |
generated |
A template exists and was generated from this router. Check Last Generated to see when. |
Router Details Panel
Clicking Router Details opens a modal for the selected router without modifying any data. It shows:
- Blocking Errors (red) — Problems that will prevent generation from succeeding. Fix these before attempting to generate. The most common is that the router is not current.
- Warnings (yellow) — Non-blocking issues that generation will proceed despite. The most common is that one or more operations have no active capability mapping in Resource Management, meaning those operations will not receive resource requirement rows.
- Router Operations table — Lists every BOM operation in sequence with setup and run times, its generated Template Operation ID (if a template already exists), and two readiness flags:
- Resource Mapped — Whether an active capability mapping exists for this operation in Resource Management. Operations without a mapping will not have resource slots generated.
- Attribute Mapped — Whether the operation has at least one active attribute link configured in the Routers tab. Operations without attribute links will not have attribute rows generated and will not be used by the PT Optimizer for grouping or sequencing.
Use the Router Details panel to check readiness before generating, especially for routers whose operations have recently changed or whose capability mappings are new.
Generation Result Panel
After clicking Generate Template and confirming, a result panel appears showing:
| Field | What it means |
|---|---|
| Template Job ID | The PT job ID that was created or reused for this template. |
| Template MO ID | The PT manufacturing order ID for this template. |
| Created | Number of new rows inserted across all template tables. |
| Updated | Number of existing rows refreshed. |
| Skipped | Rows that were already up to date and required no change. |
| Errors | Count of rows that failed. Any errors trigger a rollback — nothing is partially committed. |
| Warnings | Non-blocking notices, such as operations skipped due to missing capability mappings. |
A green success banner also appears at the top of the screen summarizing the result. The Routers grid refreshes automatically after generation to reflect the updated Last Generated date and Template Status.
Template Details Panel
Clicking Show Template Details expands a set of read-only inspection tables below the Routers grid. These tables show the raw APS source rows that were generated for a template — useful for verifying what PT will receive.
Selecting a router row (when the panel is visible) automatically loads that router's template data across all tables:
- Template Job, Manufacturing Order, Operations, Paths, Path Nodes
- Activities, Resources, Resource Capabilities
- Materials, Products, Operation Attributes
A Load All Templates button on the Template Job table loads every template job in the system for comparison.
This panel is primarily a diagnostic tool for verifying generation output and troubleshooting scheduling issues. Normal template maintenance does not require using it.
6. When to Generate or Regenerate
| Situation | Action |
|---|---|
| A new current router has no template (red row). | Select it and click Generate Template. |
| A router revision was superseded by a new revision. | Select the new current router row and generate. The old revision's template remains but will no longer be used for new jobs. |
| Capability mappings were added or changed for an operation. | Regenerate the template for any affected router so the new resource requirement rows are picked up. |
| Generation produced warnings about unmapped operations. | Configure the missing capability mappings in Resource Management, then regenerate. |
| Attribute links were added or changed for an operation. | Regenerate the template for any affected router so the updated attribute rows are picked up by PT. |
| Generation produced warnings about operations with no attribute mapping. | Add attribute links for those operations in the Routers tab, then regenerate. |
| Troubleshooting a scheduling issue in PT for a specific part. | Use Router Details to check readiness flags, then use Show Template Details to inspect the generated rows. |
7. Phase 1 Scope: What's Used and What's Not
| Feature | Phase 1 Status | Notes |
|---|---|---|
| Template generation from current routers | ✅ Used | One template per current router. Non-current routers are blocked. |
| Resource requirement generation | ✅ Used | Driven by capability mappings in Resource Management. Operations without mappings are skipped. |
| Material and product generation | ✅ Used | Derived from the router's BOM. Phantom WIP items are generated automatically. |
| Path and path node generation | ✅ Used | Single linear path per template MO. |
| Operation attribute generation | ✅ Used | Generated from active attribute links on the router's BOM operations. Operations without attribute links produce no attribute rows and will not be used by the PT Optimizer for grouping or sequencing. |
| Sub-assembly MO expansion | ❌ Not used | One MO per template; no recursive sub-assembly expansion. |
| Automatic regeneration on router publish | ❌ Not used | Manual regeneration only in Phase 1. Automation is a future enhancement. |
| Template deletion / deactivation | ❌ Not used | Old templates from archived routers are not automatically retired. |
Storage Areas
Audience: ERP users who are familiar with Action Target's system but are new to PlanetTogether. Scope: Phase 1 — storage area management, cell groups, and the item storage coverage requirement. Related stories: US-005 (Inventory and Warehouse Maintenance Matrix), US-006 (Inventory and Warehouse Maintenance Tools).
1. How PlanetTogether Uses Storage Areas
PlanetTogether requires three objects before it will accept an item during import:
- An Items row — the item master record.
- An Inventories row — the item's inventory definition for a warehouse.
- At least one ItemStorage row — a mapping from that item/warehouse pair to a specific storage area.
If any of the three is missing for an exported item, PT will reject the item and any sales orders, work orders, shop jobs, or job materials that reference it. Storage areas are therefore not optional configuration — they are a gating requirement for every item that will be scheduled in PT.
The ERP manages storage area data in the aps schema. PT reads the data through export views; it does not write back to storage area records in Phase 1.
2. The Three Storage Area Types
Every storage area has an ERP Type that describes how it is linked to the ERP:
| Type | What it represents | Storage Area ID generated as |
|---|---|---|
| Location | Linked to a specific ERP material location (mat_loc_cell). Use when one location's inventory maps cleanly to one PT storage area. |
LOC-{location_id} |
| Cell Group | Linked to a named set of bank/column/row ranges (aps.cell_groups). Use when physical cells defined by a cell group represent a single logical storage area. |
CELLS-{cell_group_slug} |
| Placeholder | No ERP link. Used for default/unmapped areas such as UNMAPPED or AMS_PLACEHOLDER. |
The storage area name itself |
Storage area IDs are generated automatically by a database trigger. You supply a name when creating the area; the system assigns the ID based on the type and linked object. Once created, the ID is frozen — it cannot change even if the name is edited later.
A storage area cannot link to both a location and a cell group at the same time. The system enforces an either/or (XOR) rule. Selecting a different ERP Type in the create form automatically clears the other field.
The Default / Unmapped Placeholder
Every active warehouse should have at least one placeholder storage area that acts as the unmapped default. When an item/warehouse pair does not yet have a business-owned storage area assignment, the export system can assign it to this default row so PT can still import the item. Without a default, those items fail the ItemStorage requirement and block the export.
Use the Validate / Readiness check (see Section 5) to confirm each warehouse has a default before exporting.
3. Cell Groups and Mappings
A Cell Group is a named, reusable set of physical cell ranges. It exists independently of any single storage area and can be referenced by exactly one active storage area at a time.
Each cell group has:
- A Name — a human-readable label (e.g., "Weld Cells").
- A Slug — a short uppercase identifier used in the auto-generated storage area ID. Must be uppercase letters, digits, and hyphens only — no spaces. Examples:
WELD-CELLS,ASSEMBLY-A.
Cell Group Mappings define which physical cells the group covers. Each mapping row specifies:
- Bank — the racking bank identifier (e.g.,
101A). - Col From / Col To — the column range within that bank.
- Row From / Row To — the optional row range within those columns.
One cell group can have many mapping rows — one per bank or contiguous range. The union of all mapping rows describes the full set of cells the group covers.
4. The ERP Data Model
All storage area data that flows to PlanetTogether is owned in the aps schema. PT reads from export views (aps.*_v) that filter and shape the source tables.
Source Tables
| Table | What it holds |
|---|---|
aps.storage_area_source |
Storage area master records. Holds erp_type, erp_inv, mrp_nettable, constrained, erp_location_id, and erp_cell_group_id. The storage_area_id column is trigger-assigned on insert and cannot be changed afterward. |
aps.cell_groups |
Cell group master records. The slug column drives the CELLS-{slug} storage area ID. |
aps.cell_group_mappings |
Bank/column/row range rows for each cell group. |
Export Views (what PT reads)
| View | Feeds PT object | Notes |
|---|---|---|
aps.storage_areas_v |
Inventories / ItemStorage reference |
Active storage areas only. |
aps.item_storage_v |
ItemStorage |
Active item/storage area pairs only. |
aps.item_storage_lots_v |
ItemStorageLots |
Active lot-level assignments. |
The ERP is the authoritative source. Changes made inside PT to storage area data are not written back in Phase 1.
5. Using the Inventory Manager Setup Screen
The Setup tab in the Inventory Manager app is the central place to maintain storage areas and cell groups.
Access to create, edit, and retire records requires the Quality Manager role.
The screen operates in two modes controlled by toolbar toggles. The default mode when you open the tab is Storage Areas.
Main Toolbar
| Button | What it does |
|---|---|
| Show / Hide Storage Areas | Toggles the Storage Areas list. Visible by default. |
| Show / Hide Setup Tools | Toggles the Setup Tools section (cell groups and mappings). Hidden by default. |
| Validate / Readiness | Runs a live readiness check and opens the results modal. |
| Preview Ensure Item Storage | Shows which item/warehouse pairs would receive a default storage area assignment if the ensure function were run. |
| Refresh | Reloads the storage areas list from the database. |
Storage Areas List
This grid shows all storage areas from aps.storage_area_source.
Columns displayed: Storage Area ID, Name, Warehouse, ERP Type, ERP Inv, Location / Cell Group link target, Default, Default-only Item Count.
Toolbar actions:
| Action | Behavior |
|---|---|
| Create Storage Area | Opens the create modal. |
| Edit | Opens the edit modal for the selected row. Requires exactly one row selected. |
| Retire | Prompts for confirmation, then marks the storage area inactive. Records are never physically deleted. A default placeholder cannot be retired if it is the only default for its warehouse. |
Create / Edit Storage Area Modal
Both create and edit use the same form. In edit mode, the Storage Area ID is shown as read-only — it was assigned at creation and cannot change.
Form fields:
| Field | Required | Notes |
|---|---|---|
| Storage Area Name | ✅ | The display label in PT and in the ERP. |
| Warehouse | ✅ | Autocomplete from active warehouses. |
| ERP Type | ✅ | Location, Cell Group, or Placeholder. Changing type resets the other link field. |
| Inventory Class | ✅ | INV, WIP, or AMS. Defaults to INV. |
| ERP Location | Context | Shown when ERP Type is Location. Autocomplete from active ERP material locations. |
| Cell Group | Context | Shown when ERP Type is Cell Group. Autocomplete from active cell groups, sorted by slug. |
| MRP Nettable | Checkbox. Defaults to checked. Controls whether PT includes this area's stock in net requirements. | |
| Constrained | Checkbox. Defaults to unchecked. | |
| Notes | Optional free text. Not sent to PT. |
ERP Location and Cell Group are mutually exclusive. Only one field is visible at a time based on ERP Type. Switching types clears the previously chosen value.
Validate / Readiness Modal
Click Validate / Readiness in the main toolbar to open this modal. It displays four counters plus a row-level issue list.
| Counter | What it flags |
|---|---|
| Warehouses Missing Default | Warehouses with no active placeholder storage area marked as default. |
| Items Missing Storage | Item/warehouse pairs with no ItemStorage row — these will fail PT import. |
| Inactive Location Links | Storage areas of type Location whose linked mat_loc_cell row is no longer active. |
| Inactive Cell Group Links | Storage areas of type Cell Group whose linked cell group is no longer active. |
The issue list provides row-level detail: the issue code, a plain-language message, and the affected Storage Area ID if applicable.
This modal is read-only. Resolve issues by correcting the underlying storage area, location, or cell group data, then run the check again.
Preview Ensure Item Storage Modal
Click Preview Ensure Item Storage to see which item/warehouse pairs currently lack an ItemStorage row. The modal shows the row count that would be inserted and a table of the affected item/warehouse/storage area combinations.
This is preview-only. No data is written when you open this modal. The actual ensure operation requires a separate approval step and is run through a database function before export.
Use this preview as a pre-export check to confirm all items are covered before kicking off a PT import.
Setup Tools — Cell Groups
Click Show Setup Tools in the main toolbar, then Show Cell Groups to manage cell groups and their mappings.
Cell Groups grid toolbar:
| Action | Behavior |
|---|---|
| Create Cell Group | Opens the cell group form in create mode. |
| Edit | Opens the form for the selected cell group. |
| Retire | Marks the cell group inactive. Blocked if an active storage area currently references this cell group. |
| Show All (incl. Inactive) / Show Active Only | Toggles visibility of inactive cell groups. |
Cell group form fields:
| Field | Required | Notes |
|---|---|---|
| Name | ✅ | Human-readable label. |
| Slug | ✅ | Uppercase letters, digits, and hyphens only. Drives the CELLS-{slug} storage area ID. Must be unique. |
| Description | Optional. | |
| Notes | Optional internal notes. |
Cell Group Mappings grid:
Selecting a cell group row filters the Mappings grid to that group's rows. Each mapping covers one bank/range.
| Action | Behavior |
|---|---|
| Add Mapping | Opens the mapping form. Select a bank and enter column/row ranges. |
| Retire | Removes the mapping row from the active set. |
Mapping form fields: Bank (autocomplete from ERP racking banks), Col From, Col To, Row From (optional), Row To (optional), Notes (optional).
6. Phase 1 Scope: What's Used and What's Not
| Feature | Phase 1 Status | Notes |
|---|---|---|
| Storage area create / edit / retire | ✅ Used | Full CRUD via Inventory Manager Setup tab. |
| All three ERP Types (Location, Cell Group, Placeholder) | ✅ Used | All supported. |
| Cell group create / edit / retire | ✅ Used | Managed in Setup Tools. |
| Cell group bank/column/row mappings | ✅ Used | Add / retire mapping rows per cell group. |
| Validate / Readiness check | ✅ Used | Four-counter check plus row-level issue list. |
| Preview Ensure Item Storage | ✅ Used | Pre-export coverage check. |
| ERP location editor (create/edit ERP locations) | ❌ Deferred | Locations are read-only lookup targets in Phase 1. |
| Racking cell / cell range preview | ❌ Deferred | Phase 2 Setup Tools expansion. |
| Legacy Material setup functions | ❌ Deferred | Ported from Tcl in a later phase. |
| PT write-back (PT → ERP storage area changes) | ❌ Not in scope | ERP is authoritative; PT is a read-only consumer for Phase 1. |
7. Summary: The Minimum You Need Before Items Can Export
Before PlanetTogether can successfully import item and inventory data, the following must be true:
- ✅ Every active warehouse has at least one default placeholder storage area.
- ✅ Every active storage area of type
Locationlinks to a currently active ERP material location. - ✅ Every active storage area of type
Cell Grouplinks to a currently active cell group with at least one mapping row. - ✅ Every item/warehouse pair that will be exported has at least one
ItemStoragerow — confirm with Preview Ensure Item Storage before running the export. - ✅ Validate / Readiness shows zero issues in all four counters.
Missing any of these will cause PT to reject the affected items and all dependent sales orders, work orders, and job materials during import.