Looking for the ideas around Equipment Object Cost/Revenue Analysis page available in App9 and Cloud. The information in this page is generated when the costs and revenue are generated, and doesn’t reflect based on any subsequent changes on the structure.
Ex. Serial Obj - X incurs a labour cost of $100. Now when you view this in the above page you can see the cost of $100. Next, say you change the Serial Obj X and add a Belongs To Object - Y (A functional object). Now when you view Functional Object - Y in the navigator, it can’t see the structure cost as $100. This is because the parent child relationship was created after the cost was committed.
Is there a way to show the cost of $100 on the parent level?
TIA.
Page 1 / 1
@athasanka I think you could create this as an idea for IFS R&D to develop. I’d give an upvote for it.
The core solution does not have the capability to display historical costs incurred before the establishment of a parent-child relationship. However, once this relationship is created, costs are displayed at the parent level. This mechanism prevents double costing for serial objects.
For example, assume Object X was initially part of Parent Object Z before being moved to Object Y. The $100 cost is only accumulated in Parent Z. Accumulating the $100 cost in Object Y after it is moved would result in double costing.
------- ---- ---Costs on objects are accumulated, and revenues are generated throughout their lifetime. A serial object may be associated with multiple parent objects over its lifetime, with costs and revenues varying at each placement. Additionally, the total costs incurred for an object can include project-related costs. Therefore, it is crucial to have a mechanism that allows viewing and analyzing costs and revenues based on the object's placement within a structure. ---- -----(product documentation)
BTW what is your use case here?
@athasanka I think you could create this as an idea for IFS R&D to develop. I’d give an upvote for it.
Thanks. Unfortunately, the problems that I have now need answers yesterday. Even if (big if) the idea realizes eventually after a few years, by then this won’t be a problem anymore. Cheers
The core solution does not have the capability to display historical costs incurred before the establishment of a parent-child relationship. However, once this relationship is created, costs are displayed at the parent level. This mechanism prevents double costing for serial objects.
For example, assume Object X was initially part of Parent Object Z before being moved to Object Y. The $100 cost is only accumulated in Parent Z. Accumulating the $100 cost in Object Y after it is moved would result in double costing.
------- ---- ---Costs on objects are accumulated, and revenues are generated throughout their lifetime. A serial object may be associated with multiple parent objects over its lifetime, with costs and revenues varying at each placement. Additionally, the total costs incurred for an object can include project-related costs. Therefore, it is crucial to have a mechanism that allows viewing and analyzing costs and revenues based on the object's placement within a structure. ---- -----(product documentation)
BTW what is your use case here?
It won’t double up if the costs were rolled up dynamically. The cost should then be picked from the object and the rolled up costs will be added on whichver the parent that’s applicable for the current time. The issue with the current setup is it creates x no of records for each level on the structure all the way to the parent. They become then static even if the node is broken after. In the below example, the yellow highlighted one is the actual object cost line. The others are generated to roll up the costs for each level up until the top level - AU.
Two use cases:
Someone forgot to add the link in the 3rd row, and then they add it after some transactions were committed. Now when you look down from “AU” level, some transactions were missing - and the user doesn’t have an idea what those are.
Say the 3rd line which belongs to VIC-EAST-METRO is changed to VIC-EAST due to recategorization of geo boundaries and discontinue using VIC-EAST-METRO. A manager who is looking after the costs for VIC-EAST now can’t see any costs for the equipment in this node.
Hi @athasanka,
Thank you for your clarifications.
Rolling up costs dynamically has not been considered in the current design. While it might be an option for some cases, it should NOT be the default. There is a conceptual risk in making it the default option. For example, as mentioned in your second use case, assume there is a pump (serial object) that has been rotated between two plants (Cost Centers A & . If this pump is repaired when it is located in Plant A, the cost should be accumulated in Plant A/Cost Center A. Later, when the pump is moved to inventory and then placed in Plant B/Cost Center B, it would not be correct to roll up the repair costs from Cost Center A to Cost Center B by default. This presents a business challenge in implementing such a feature in the system. The same logic applies to revenues; at one customer it might charge $100 per unit, while another charges $125 per unit.
I hope this information is helpful.
P.S.: I completely agree with @Marcel.Ausan's suggestion to post this as an idea, so we can evaluate this requirement with a larger audience and potentially push R&D to consider it.
. If this pump is repaired when it is located in Plant A, the cost should be accumulated in Plant A/Cost Center A. Later, when the pump is moved to inventory and then placed in Plant B/Cost Center B, it would not be correct to roll up the repair costs from Cost Center A to Cost Center B by default. This presents a business challenge in implementing such a feature in the system. The same logic applies to revenues; at one customer it might charge $100 per unit, while another charges $125 per unit.