Odyssee Mobile

API User Guide

Prices, discounts and rules

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.

Synch them or not

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.

Difference between Article (Part) and Invoicable timeesheets

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)

Article Pricing

The current API doesn’t contain all price rules for Articles. You have only 1 price that can be specified, this is the global article price (article.entered_price).

Invoicable timesheets

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 feelist_price).

You have to assign a feelist to a company using the field company.feelist_id.

A feelist has a default price (feelist.default_price) that will be used if no specific rule is found.

FeeList Price

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

  1. hour_type_id, job_type_id, equipment_family_id
  2. hour_type_id, job_type_id
  3. hour_type_id
  4. if nothing is found, it will use the feelist.default_price