[FR] Add labor time for build orders

[MIOsystems]

Please verify that this feature request has NOT been suggested before.

• I checked and didn't find a similar feature request

Problem statement

Time is money. When building thinks the cost of time will add to the cost of the bought components. To get a good inside to the real cost of the product, it is essential to involve its build time as well and accumulate it over the whole project.

Suggested solution

We can add values of time spend when we complete a build output. When the build is done there will be a total build time. Finally it can be average or range for each part. Same as the cost component.

Now we have a good price in indication for the bought components, but the build time is as much of a value as the money we spent on the components we bought.

Describe alternatives you've considered

Now we have a good price in indication for the bought components, but the build time is as much of a value as the money we spent on the components we bought.

Examples of other systems

No response

Do you want to develop this?

• I want to develop this.

[SchrodingersGat]

Hi @MIOsystems thanks for raising this. This makes sense and I can see how this would be a benefit to the system. The potential issues here are that we start to introduce complex pricing calculation options which are hard to document and maintain, and also do not directly benefit all users. Additionally, the new behaviours may run contrary to how other users wish to maintain pricing.

There are a number of similar outstanding issues related to custom pricing calculations:

• [FR] Add build cost #7949
• [FR] Packaging and shipment cost #7765
• [FR] Assembly pricing calculation without consumables #7603
• [FR] Support Actual Cost of Build Outputs based on Cost of Parts #7279
• [FR] Inbound shipping/logistics costs #3928

(and there are probably others too).

Where I think we should head is to rework the existing pricing calculation system, to allow for plugins to be able to calculate and augment pricing calculations. This way, "custom" pricing information such as labour costs, etc, etc, can be integrated as desired.

However, some consideration needs to be given to where the "injection points" for the plugin system should be and what power they have over pricing.

Currently, even just for calculating the "price range" for a given part there are a lot of complex options - which have been introduced in an attempt to accommodate multiple competing objectives for calculating prices. This has led to confusing settings and I think would be better served by being a bit more "generic".

There are other pricing calculations which could be exposed to the plugin system too:

• Calculation of incoming items via purchase orders
• Cost of a build order
• Sales pricing
• Depreciation of stock over time
• ???
• User permissions around pricing

@wolflu05 @matmair do you guys have any thoughts about this? I've been putting this off for a while but I think the plugins system is a better way to handle anything other than "basic" pricing considerations

[gunstr]

@MIOsystems, just a humble suggestion... I have solved adding the build cost by treating it just as any other part in the BoMs:

1. Create parts for relevant categories of build activites. I use assembly hours and testing hours. Set the internal price to the hourly rate you have for each category.
2. Add a large amount of stock for each "build activity part" and add more when needed
3. Add relevant build time to the different BoM's and allocate the same when you create build orders

For each part I can now see the complete cost including the predicted build cost. As a bonus I can also see how many hours of each category that has been allocated to build orders - basically upcoming work load.

This solution might not work exactly as you want for me it works very well.

[MIOsystems]

@gunstr, yeah that sound like a really good workaround. I will try that.

[matmair]

@SchrodingersGat I have ideas on how to address more complex pricing via plugins but this would have to be architected with taking into account all possible integration points and discussed fully before implementation can start; quick draws might hurt users in this space;

Should we form a draft epic around the mentioned issues and discuss this after we have addressed 1.0?

[SchrodingersGat]

Should we form a draft epic around the mentioned issues and discuss this after we have addressed 1.0?

Yes, absolutely. Would be interested in discussing this further, it's a big feature we need to address

[matmair]

@SchrodingersGat I created the epic in #8607 and added my general design ideas and some considerations I already made for my personal 3 year roadmap. I think we should discuss this and the general design further in the epic.