Any idea what this means? I have been using Manager for more than 2 years and this is the first time I have noticed this.
Does this help Production order reference / priority label
1 Like
Thanks @Joe91 Yes it helps to understand the change. However, I have 472 inventory items and 879 production orders. Why is this not applied prospectively? Do I need to amend the production stage for all 472 inventory items to fix this or is this something that can be done in the background? @lubos Please advise.
you can do a batch update of your inventory items and make all your output items have a greater production stage number than their input item.
for example, if all your input items have a production stage of 1, you can change all your output items to have a production stage 2.
1 Like
@applet there will be a button to set recommended production stage number for all your items automatically based on already entered production orders. No need to manually update them one by one.
1 Like
The latest version (20.5.97) can elevate production stage for inventory items in bulk.
Then click Batch Update button.
1 Like
Thanks. I performed the batch update on the backup business and it resulted in a minor difference in cost of sales. Should it?
Yes. This is why production stage is important. It makes inventory cost calculations actually correct.
1 Like
Hey i batch updated all the pages it recommend
However 21 items are continiously demanding batch update repeatedly, it showed current stage is 8, recommended is 9, so i kept going. And now its on stage 15 but Still its demanding more to 16
@fahadalarab, you need to examine your production orders using those items. I believe you will find circular usage. In other words, A is required to produce B, B is required for C, but C is required for A. Manager wants C to be elevated, but that in turn requires A to be elevated. You can never catch up.
Using production stages requires careful thinking about inputs and outputs at each stage of production. No finished item at a stage higher than 1 can be an input to a stage 1 item. Problems like you describe cannot be resolved by automatic elevation. You will need to manually edit these 21 items. If I were you, I would first reset them all to 1.
@lubos can we please have a solution for this. I have approx. 70 inventory items which are in circular mode. I manually changed all to stage 1 but this doesn’t resolve the issue.
Note that I did not say resetting everything to stage 1 would resolve the problem. That was meant as a suggestion to get back to a starting point where you could analyze your production workflow in detail. After your analysis, you will still need to manually edit stages.
I appreciate your input on this @Tut but it’s not practical to analyze the past transactions to resolve this issue which triggered due to the upgrade. These production stages are not required for my business and would rather prefer to have a system based solution to fix this as opposed to the manual fix.
1 Like
Then ignore them. But understand this: Manager is suggesting elevating stages because you have created production orders with input items that are themselves the output of other production orders. If you enter such production orders on the same day, the calculated cost of inventory could be wrong. But, if you never create more than one production order per day, never run out of input inventory items, and always receive all purchased inventory items before including them on a production order, you will have no problems. Can you honestly say those things will always be true? If not, production stages are required.
If ignoring is the solution, I am fine with that.
@Tut I understand the logic of why these stages are required, however, given the nature of my business, slightly inaccurate cost doesn’t bother me. If this is something that can be prospectively applied, I can adapt to this but I don’t see the benefit of going back and fixing it manually. Thanks.
It might bother your auditors or tax authority, as the result can be misstatement of profit. And depending on what you purchase and the exact flow of events, the the difference might not be slight.
I will be looking at some solution to make it easier to resolve. The current screen just makes it easier to resolve if there is no circular dependency. If there is circular dependency, the system could give you better interface.
2 Likes
I can’t see how this can occur, if we re-write the illustrated example, A is required to produce B, B is required for C, but C is required for A, then you have this:
A (Level 1) is required to produce B (Level 2)
B (Level 2) is required for C (Level 3)
C (Level 3) is required for A (Level 4)
Item A, can’t be both a Level 1 and a Level 4 at the same time.
If a User has Item A as both, then their Inventory quantities and average cost would be non-sensical
Then can I suggest that you have a sub-process not being clearly separated from other sub-process’s. That is, within a particular production order the inputs and outputs have the same Level status (say level 2). whereas there needs to be an output distinction. Using the following example:
- Raw material A + B (Level 1) to create Semi Process H (Level 2)
- Raw material C + D (Level 1 ) to create Semi Process I (Level 2)
- Raw material E (Level 1) + Semi Process H (Level 2) to create 2nd Semi Process J (Level 3)
- Semi Process I (Level 2) + 2nd Semi Process J (Level 3) to create Final Batch (Level 4)
- Final Batch (Level 4) + Packaging Items (Level 1) to create Finished Goods.(Level 5)
Semi process H & I and Semi Process J can’t have the same status Level.
1 Like
I am not sure what you are saying here, @Brucanna. Are you taking issue with @lubos’s statement, “If there is circular dependency…”, because you think he is describing a method to make it work? Or are you emphasizing that they cannot be made to work?
I don’t think @lubos was suggesting they could be made to work. I think he was suggesting the need for a better resolution method than just bumping up production stage levels in an endless cycle.
If your intent was to convey the second point of view, you are completely correct. Circular dependencies cannot be made to work. That is why I stressed the need for manual editing—at least with current problem resolution capabilities.
Simply, that the example as provided, is impractical, as it just doesn’t function.
Initially, C doesn’t exist until after B has being created, so B can only contain straight A.
Subsequently, if C is added to A, then B contains a combination A+C, a new item, not straight A.
Furthermore, C could never be a consistent item of output, as each time C is added back into self (via A) it would always be of a varying percentage. Without showing the mathematical modelling.
Initially C would consist of B (A + other B inputs) + other C inputs
Subsequently, C would consist of B ((A+C(A+B inputs + C inputs)) + other B inputs) + other C inputs.
Therefore the consistency of item C would be continually changing with each production cycle, as the B & C other inputs would be compounding upon themselves. For example, if B has an input X, then you don’t just have X being added to each B, but a varying proportion of X would be added back via the C being added to A back into B. So C receives BX + the returning C(BX).
Not at all, I was just highlighting that circular dependency hadn’t occurred within the example. Item A hadn’t remained Item A but had become Item A+C.