Accurate quantities for sale reporting: Conceptually wrong

By chance I stumbled over Issue 9191: Accurate quantities for sale reporting - Tryton issue tracker : For ‘accurate quantities’ the develomnet wants to ‘store on the line the actual quantity shipped or invoiced as the maximum of both.’

This leads to data duplication AND wrong figures. Mixing up delivery and invoice quantities is not a good idea, and why the ‘maximum of both’ should be accurate? No idea.

Better use a report or a lean BI solution…

Hi Axel,

Nice to see you here another time.

Well it seems that this is the second time you stumble on this issue.. So probably not so much chance :wink:

But this details are not so revelant, let’s dig into the issue:

Ok we are wrong but what will be in your opinion the right answer to the problem? What is the actual quantity of a sale line?

Indeed, this is not needed as the quantities can be customized. It is already possible for the current versions (we’ve did for some customers that have some customs shipment and invoice methods) and it will be simplier on new versions.

I must say that I agree with Axel. For me, there’s no such concept as the right quantity of a sale line.

When I want to analyze quantities sold I must decide what information I want which is at least:

  • Quantity Requested: the one that sales manage
  • Quantity Shipped: the one that shipments / stock moves manage
  • Quantity Invoiced: the ones in invoices

Of course, in all cases I must know what we’re looking for (typically the state of the document – or even the states in which it has been):

  • If we want the quantity requested we can be interested in quotations only, quantities actually ordered, etc
  • For shipped quantities, we may be interested in quantities yet to be delivered or only the shipped ones
  • For invoiced quantities, something similar those that will be invoiced, those actually posted, etc

So when customers ask us to provide an report with their sales, we first ask the to clarify what “Sales” means to the in the context of that specific report. In most cases it is posted invoices, but not always. Invoices have the advantage that usually better match accounting information.

For me, trying to bring that information to the sale is a mistake but of course, it depends on what you’re trying to analyze.

We are talking about the quantities used to compute the sale revenue.

Those are diferent quantities that are not currently used for reporting. For example one may create a report that incluedes the variation between all of them and this will not afect the actual quantity.

Could you elaborate on: which information and what are your tryting to analyze*¿

Computing the revenue by using the quantity delivered instead of the quantity invoiced is wrong IMHO. You may or may not invoice the delivered quantity and so the revenue would be incorrect.

I can not understand what is the workflow you are describing. How can you ship a product and not invoice it? And why would you do that?

Tryton allows the invoice to be cancelled and don’t regenerate it again.

These three events can have different timely relations as well, mostly

  • at time of sales order entry
  • at time of requested or confirmed delivery date
  • at time of invoice creation

So what business wants to report at what point in time is usually result of in-depth discussions.

Albert, dont you have a small BI solution (babi) in place?

But why would you do that if you shipped the product?
And which quantity do you want to use for reporting?

For example, there can be a case in which the customer cancelled the order right after finishing the shipment. In this case I would recommend the user to cancel the invoice and create a new sale with quantities in negative that brings the products back and marking the Invoicing Method as Manual.

There I’d ask the user what she wants to analyze. That said, if I had to make a decision I’d use the invoiced quantity because if I’m computing the revenue, there’s usually no revenue without invoice.

I do not think it is the proper way because you are breaking all the reporting possible. You break the relation between stock moves and invoice lines in both sales.
But also you create a much more complex workflow for the user which has to know/check if the returned lines was or not invoiced. And you prevent to really use the sale complaints which reuse the same methods as the original sale.

But then you get inaccurate reporting for all the sale partially shipped and not yet invoiced. It is quite common to invoice for example at the end of the month.

Any way, I see nothing wrong with the proposal as it covers all those cases even the bad one.