Compute margins

One of the objectives of implementing and ERP system is to know how much money the company is earning. This can be computed in several costs levels:

  • Globaly on the company (using Profit and Lost)
  • Per cost center or similar (using Analytic account)

But one may be interested on computing the profit at document/line level. Normally this is computed using the following formulas:

  • Profit = Sale Price - Cost Price
  • Profit % = Profit / Sale Price = (Sale Price - Cost Price) / Sale Price

We could develop a new module that computes both formulas at sale line.
It will also be interesting to have this information available on document level.

I’m wondering how we should use to compute the Cost Price:

  • Saving the current product cost_price on the sale line
  • Using the product_cost_history to retieve the product cost_price at the date of the move
  • Using the cost_price of the move sale price (only for goods).

To make the feature complete, I think we should also include the profit amount in the Sale Reporting, so one will be able to easly search which customers/products/categories are more profitable.

1 Like

Hello,
We are also thinking about the possibility of a profit calculation module at the sales and reporting level.
I find the proposal interesting and we would be interested in participating.
I will prepare a summary of our needs / ideas early next week to complete this discussion.

Great to read this!

We will wait for your comments.

Thanks!

What are the goals? Who is ready this information?
Why does it have to be on the sale? All the information are already available on the stock moves.

The cost price change over time so it is not a good idea.

So why not use the cost price on the move?

I do not think the reports should be mixed because it is not the same person that consults them.

Because this is not usefull just for reporting but also to create rules contrains. For example:

  • Require the authorization of the sale manager if the estimated profit it’s lower that a threhold.
  • Add a warning when confirming sale where it is expected to have a negative profit.

Which makes me think that aybe it should be interesting to compute the estimated profit vs the real one.

Because I thought we should support also profit calculation for services.

I think is relevant to have profit in SaleReporting because it give full details about how the customer/product impacts the profits of the company and the objective of the company is to increase the profits :money_mouth_face:.

For example having a product that has a big number of sales (or revenue) may not produce a big impact on the profits of the company. With this information in hand the company manager may decide the price of the product to increase it’s impact on the profit. Same applies other way arround, you have a product with a big percentage of margin but not so much sales. The company may decide to invest on marketing to increase the number of sales of this product which will produce a big impact on the sales

You do not need to store the value for such usage. It should be managed with a similar design of sale_credit_limit.
And you will not base such constraint on the always changing cost price but instead put a lower limit on the sale price.

Not before having New invoicing method when selling both goods and services

But this is not the targets of the sale group that’s why for me it has nothing to do with sales.

So in this case you think we should use the product_cost price at the moment of computing the sale to compute the expected profit of a sale?

I’m specially interested in this part. So if it does not have nothing with sales how do you propose to show such information to the company manager in Tryton?

No I think you do not need to compute the profit of the sale to have such control.

For me, this report is useful to the product administration group because they are those we setup the sale price (on the product or the price lists).
The report should be based on the stock moves to provide an accurate and updated cost price and unit price. (by the way a similar report could be on incoming move could be useful).

Sounds good to me.

I do not understand why you say it could be usefull. Isn’t the unit_price and the cost_price of an incoming move aren’t the same?

No the cost price is usually the average cost price so you can point which move deviate a lot from the average.

I see but this is a report that should focus on the move detail. For product profit I think we should not dig into the detail by default but show a grouped report:

  • Profit per Category
  • Profit per Product

And follow the sale reporting pattern:

  • Use a range of dates to filter moves
  • Have an line to show the evolution of profit
  • Allow to have subtotals of different periods (using time-series model)
  • Include the number of moves
  • Include the total amount (using quantity * unit_price)

I’m not sure if it will be good to have a filter by warehouse, is it too complex? Does it makes sense to allow to compare the profits of the different warehouses?

Using parent_of on location should not be a performance problem thanks to the MPTT.

Probably especially if we have Issue 9312: Add module to compute product cost per warehouse - Tryton issue tracker

I started to work on an implementation based on stock move: Issue 9665: Ad cost, revenue and margin reporting - Tryton issue tracker

I have uploaded a first version to get early feedback.

I’m thinking about including a contextual switch to include or not the cost of the product sent to lost&found over the period. This should be useful for product kind that expire (or who are damageable).