I still believe the 3 sets of numbers are required.
You need to be able to see the
- actual price sold at (actual data for use)
- system calculated @ time of sale
- user overrides
"User overrides" may well be zero, even when the other two numbers don't match.
This would occur when using price freeze on a quote for example.
With regards to rate of change of prices, there are enough vendors that issue monthly price list updates for that to be an issue.
One of the things I'll be working on soon is pricelist import (direct to db) for a number of Andrews vendors that make monthly price changes.
Sent from my Galaxy
-------- Original message --------
From: Erik Huelsmann <..hidden..>
Date: 14/7/21 04:52 (GMT+08:00)
To: lsmbdev <..hidden..>
Cc: ..hidden.., John Locke <..hidden..>, "Yves Lavoie, GaYLi" <..hidden..>
Subject: Re: Progress on Invoice webservice (discussion solicited)
On Mon, Jul 12, 2021 at 12:04 PM lsmbdev <..hidden..> wrote:
Ok. To be able to do that, I don't see more than the requirement for 2 sets: the actual data used in the invoice (which is already there now) and the numbers calculated by the system. If the numbers have not been overridden by the user, the "variation" is zero.
Right. Or maybe other criteria that the sales has been mandated for.
Ok. I can see how this would be convenient for oversight. However - assuming the business doesn't change its prices daily (but rather more quarterly or less often) - the data required to do oversight should be there when the oversight is effective: short after the actual sale. At that time, the data is all there. The pricematrix price derivation is even in the database now (see https://github.com/ledgersmb/LedgerSMB/blob/816e740f0702af2a2192dfe4832dc3e4a0b2cf1d/sql/modules/PriceMatrix.sql#L18). So, assuming sufficiently constant prices, you could retrieve the oversight data nicely. All the data needed to report e.g. an average sales price (per part) is also there.
Ok. I was thinking to introduce the ability to track the applicable pricing at a given point in time, so as to be able to provide an audit trail on how invoice prices were determined. With the schema currently proposed, there will at least be an indicator that the person compiling the invoice either set their own price, or that the price was inherited from an order/quote (as contrasted by "taken from the pricing mechanism/calculated by the software").
_______________________________________________ devel mailing list -- ..hidden.. To unsubscribe send an email to ..hidden..