The Pricing is one of the most complex objects to synchronize between systems because there’s never one global rule that can be applied in every case and each ERP develops its own custom rules. Because Odyssee is a generic system, we need to handle all possible different ways of price computing and discount.
The first question that need to be asked is: “Do you want to synchronize the prices?”. In some scenarios, the prices / discounts on Odyssee are not useful and don’t give any benefits.
For example, if you are using Odyssee for your technicians on the road and they only do maintenance jobs where timesheets and parts will not be invoiced to the customer, you can avoid synchronizing the price.
In some systems, there is a mix between the parts that are used and the time spent on the job that will be invoiced to the customer: the time spent is in fact an article, without any stock. For us, we have a clear distinction between these objects:
Articles have their own pricing rules (with price labels and custom discount)
Timesheets have an
hour_type_id and are using the feelist and feelist price (specific prices depending on the context of the job)
The current API have one way to handle article price, it's using
article_price_label(an admin table that has one default value already).
Timesheets are using the concept of FeeList. A Feelist is a sort of “configuration” that determines what will be the price for 1 working hour depending on the context of the work order (JobType,EquipmentFamily, etc). It’s using a matrix of prices (table
You have to assign a feelist to a company using the field
A feelist has a default price (
feelist.default_price) that will be used if no specific rule is found.
This is the matrix where all the price rules are stored. The system always tries to use the most specific rule for a case, and if not found then it tries using a more global rule.
This is the list of possible rules and the order in which they are evaluated