You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Jacopo Cappellato (Jira)" <ji...@apache.org> on 2026/06/04 16:29:00 UTC
[jira] [Commented] (OFBIZ-13434) Production Scheduling AI Agent for OFBiz
[ https://issues.apache.org/jira/browse/OFBIZ-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18086133#comment-18086133 ]
Jacopo Cappellato commented on OFBIZ-13434:
-------------------------------------------
[~swash78] , thank you for the proposal. I think the use case is interesting, but I believe some clarification would help better define the scope and technical approach.
The current proposal seems to mix three different concerns:
* scheduling/planning computation
* operational analytics and root cause analysis
* conversational interfaces
For example, the proposal states that traditional planning/scheduling systems struggle with dynamic disruptions and cascading bottlenecks, and suggests that an LLM-based agent could address these limitations.
However, the prerequisite section already requires:
* comprehensive audit trails
* detailed maintenance logging
* granular calendar modeling
* standardized lead times and routing information
These prerequisites are also the foundational requirements that traditional scheduling systems require to produce good results.
This creates an ambiguity: are the limitations primarily algorithmic, or primarily caused by missing/incomplete operational data?
Additionally, the later functional sections describe capabilities such as:
* detecting capacity conflicts
* computing downstream scheduling impact
* finding earliest feasible production slots
These appear to be classical constraint/scheduling problems rather than language problems.
The proposal currently explains _what_ should happen but not _how_ the LLM component would actually perform scheduling computations or why an LLM approach would be preferable to constraint solvers, heuristics, APS techniques, or existing scheduling logic.
My impression is that the strongest part of the proposal is the conversational / explanatory layer (natural-language root cause analysis, explanations, auditability, operator interaction), whereas the scheduling computations themselves still appear to rely on traditional planning logic.
It may help to clarify whether the goal is:
A) AI-assisted scheduling algorithms replacing/extending classical scheduling approaches
or
B) conversational and explanatory interfaces built on top of existing scheduling/planning mechanisms
Clarifying this distinction would make the proposal easier to evaluate technically and architecturally.
> Production Scheduling AI Agent for OFBiz
> ----------------------------------------
>
> Key: OFBIZ-13434
> URL: https://issues.apache.org/jira/browse/OFBIZ-13434
> Project: OFBiz
> Issue Type: New Feature
> Reporter: Swapnil Shah
> Priority: Major
>
> h2. *Context*
> In highly dynamic manufacturing environment, planners often need to balance customer demands volatility against finite plant floor capacities on daily basis. While traditional Planning and Scheduling or Material Requirements Planning (MRP) systems handle static mathematical constraints well, they often struggle with real-time operational disruptions, unstructured floor logs, and downstream cascading bottlenecks.
> With onset of rapid transformation in generative LLM capabilities, an AI Agent for *Production Scheduling* can be game changer for Floor planner, operators trying to manage real-time disruptions on shop-floor with a manufacturing execution system like OFBiz.
> h2. *System Prerequisites & Data Foundations*
> To ensure the AI Agent can generate accurate insights and avoid predictive errors, the underlying Apache OFBiz instance must meet the following baseline data integrity requirements:
> * *Comprehensive Audit Trail Activation:* System-wide logging must be active. Any modifications to production run statuses, machine assignments, or estimated schedules must be recorded chronologically within history logs (e.g., {{{}WorkEffortStatus,WorkEffortNote{}}}).
> * *Active Maintenance Logging:* Floor operators and maintenance technicians must log unscheduled machine downtimes and maintenance completions in real time within the {{FixedAssetMaint}} entity, including descriptive comments for root-cause context.
> * *Granular Calendar Modeling:* All target {{FixedAsset}} resources must be mapped to valid {{TechDataCalendar}} records, with explicit overrides for holidays, weekends, and planned shutdowns documented in {{{}TechDataCalendarExcDay{}}}.
> * *Standardized Lead Times:* Master routing tasks must contain baseline operational data—specifically setup times and unit run times—to allow the agent to calculate processing windows accurately.
> h2. *Functional Specification*
> h3. *1. Conversational Auditor*
> *Objective:* Provide clear explanations of systemic supply chain failures.
> * *Feature:* Offer Root Cause Analysis through a conversational interface for technical auditing.
> * *Trigger:* When a user inquires about a delay in an outbound shipment (for sales, distribution, or transfers).
> * *Action:* Synthesize planned versus actual data from production run status logs and offer natural-language explanations.
> *
> ** _Example:_ "Production Run #440050 was delayed at Work Center 'CNC Milling' because Machine #2 suffered a breakdown on Tuesday, pushing back the operation by 14 hours."
> * *DB Entities:* {{{}WorkEffort{}}}, {{{}WorkEffortStatus{}}}, {{{}WorkEffortNote{}}}, {{{}FixedAsset{}}}, {{{}FixedAssetMaint{}}}, {{{}TechDataCalendar{}}}, {{{}TechDataCalendarExcDay{}}}{{{}, TechDataCalendarWeek, {}}}{{{}WorkEffortGoodStandard{}}}, {{{}OrderHeader{}}}, {{{}OrderItem{}}}, {{{}OrderShipment{}}}, {{ShipmentStatus}}
> h3. *2. Capacity Alerter*
> *Objective:* Detect resource over-allocation during manual scheduling overrides.
> * *Feature:* Alert users to potential capacity overloads on assigned resources and list the downstream production runs affected by the cascading domino effect.
> * *Triggers:*
> *
> ** When setting or updating the estimated start/end dates of a production run that conflicts with resources already consumed by other scheduled production runs.
> *
> ** When updating the planned quantity of a scheduled production run in a way that leads to resource over-allocation on the planned dates.
> * *DB Entities:* {{{}WorkEffort{}}}, {{{}WorkEffortAssoc{}}}, {{{}WorkEffortFixedAssetAssign{}}}, {{{}FixedAsset{}}}, {{{}TechDataCalendar{}}}, {{{}TechDataCalendarExcDay{}}}{{{},TechDataCalendarWeek{}}}{{{{}}{}}}
> h3. *3. Slot Predictor*
> *Objective:* Find the earliest mathematically viable start date based on resource availability.
> * *Feature:* Suggest the next available date-time slot to initiate production runs that face scheduling delays.
> * *Trigger:* When a resource capacity bottleneck is detected.
> * *Action:* Predict the next available date-time slot to start a production run based on the planned/remaining quantity to produce, operational lead times, and resource calendars.
> * *DB Entities:* {{{}WorkEffort{}}}, {{{}FixedAsset{}}}, {{{}TechDataCalendar{}}}, {{TechDataCalendarExcDay,TechDataCalendarWeek}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)