General -> Product URL property sometimes not saved

A forum to discuss the implementation of a good Materials system in FreeCAD
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: General -> Product URL property sometimes not saved

Post by bernd »

the problem with the tree structure is, my one is different from your one and I do not se a solution for this yet.

But anyway the bugs and inconsistences in Material needs to be fixed to make it useble. I am nearly ready with this.
JellyPalm
Posts: 157
Joined: Sun Mar 29, 2020 12:22 am

Re: General -> Product URL property sometimes not saved

Post by JellyPalm »

Hello,
I am surfing the Forum for unrelated matters and came across this old post which seems to have come to no particular conclusion - since my latest FCv19 Materials card has no field for price (empty or filled).

Anyhoo, my 2cents: I think an unfilled field for price would be usefull in a build project - it is up to the user to populate it as required at the time required.
This would enable 'indicative' pricing.
Later if these prices would change, then the model can be copied and updated prices included.

To make this updating easy I suggest that the Material card be linked to a spreadsheet.
Each time a new material is created in a project it creates a spreadsheet (if there isnt one already available) and then each new material, its quantity and its UNIT price information in whatever form or denomination chosen by the user gets added there too.

The user can quickly appraise the materials used, and the prices used by looking at the spreadsheet (and change them on the spreadsheet if neccesary).
In LibreOffice, obviously.

To explain:
When I worked as a building estimator, we used to have a formula based on weight for estimating steel ($5/kg, I vaguely remember).
Since steel manufacturers broadly fix price by the weight of steel - there was a correlation between the unit weight (per meter) of the steel product, and the price. (A 4kg/m bar was 2x the price of a 2kg/m bar for eg).
So It didn't matter what type of steel product you specified there was a simple calculation : length x weight-per-length x price-per-unit -weight.....to get price. (eg; 2m x 4kg/m x $5/kg = $40)

When the price moved (never by much) it was a simple matter to update the single price-per-unit weight factor of generic mild steel (the $5 part, above) and all the steel profiles prices were automatically updated.

In timber the "factor" used was based on volume ($50/m3 - pine) - which was the unit used by timber-mills to set prices.
Concrete seems to be priced by volume too, with a few additions dependent on final MPa.

There may be dozens of potential products and profiles - but grouping materials by class using this method quickly reduces the complexity of the problem.
As long as the object is to give indicative pricing , rather than final accounting figures , then it is a useful exercise.

In Arch/FC, If the Material card had unit of measure(for pricing), a factor to standardise its unit of measure (Kg, m3..) and a price factor - all of which export to a pricing spreadsheet then the rest would be easy.

Attached is a shot of our steel pricing spreadsheet - its just an dropdown XLS based on the unit weight x a factor for each steel profile x $5/kg.
Attachments
Unit Pricing.PNG
Unit Pricing.PNG (31.92 KiB) Viewed 7792 times
Post Reply