Closed kobsam closed 2 years ago
[Update] A workaround is to set the "minshipment" field to the same value as the quantity of the demand. Then it will no longer split the manufactoring orders. But then there occurs another problem: If there is not enough capacity available on the day before the delivery date, even if "maxearly" is set to 100 days, it will switch immideatly to forward scheduling after the first day. The correct way would be to check the remaining 99 days for free capacity. (See the screenshot below)
As long as the requested quantity to the resource does not exceed the remaining capacity, the "maxearly" is considered.
Result of perfect fitting quantities (quantites of 50 in demand, capacity of 100 in resource):
And here the problem of not perfect fitting quantities:
The "maxearly" attribute of the resources is set to P100D and the resource has enough capacity available in this period.
Here are the files from the plans and outputs: plans.zip
Closed with pull request (I guess)
Hi, in the attached plan-split-bug.xml I have 2 resources (additionally 1 virtual resource to let the algorithm choose, with skills etc.), 2 items, 2 operations and 200 demands. Also I'm using the resource_buckets to plan by units per day. My problem is that I want to not allow splits, but when I execute the plan (with command line tool and allowSplits=False in the solver_mrp()-method), I get split operations and multiple manufactoring-orders for some operations ( I need exactly 1 manufacturing order per demand). The output.csv is the output that frepple generates for me, generated-operationplans.csv is a custom output for me to detect which demand/manufactoring order gets produced where and when. In the date I just need the day, i don't care about the specific time. Am I doing something wrong or is my model not right?
Here are my files I got this issue with: plan-split-bug.zip
[UPDATE] I got it to work with some other model, but I still don't know what the problem is. It's also that with some plans it works fine, but most of the time not.