LedgerSMB
The foundation for your business
Hi Erik, Once again on my phone so top posting. Regarding my suggestion for 3 sets of price data to be stored against each invoice line. There is another reason (other than the obvious) I'm suggesting that. It allows accurate reporting on sales "variations" For example a salesperson may vary the price by applying a discount or manually changing the price on an item. In general thats good sales practice as long as the net sales margin from a customer is above some target level. Without storing all three items of data it becomes difficult, if not impossible, to correctly report on this with enough detail to be usefulfor basic oversight let alone malicious behaviour. I've run into other use cases in the past as well. Sent from my Galaxy -------- Original message -------- From: Erik Huelsmann <..hidden..> Date: 12/7/21 15:09 (GMT+08:00) To: lsmbdev <..hidden..> Cc: ..hidden.., John Locke <..hidden..>, "Yves Lavoie, GaYLi" <..hidden..> Subject: Re: Progress on Invoice webservice (discussion solicited) Hi David, Thanks for your response. We've discussed my earlier mail on the chat channel as well; I'll summarize in response to your mail. On Tue, Jul 6, 2021 at 4:22 AM lsmbdev <..hidden..> wrote:
Yes, it should (and will); I was posting an unfortunate combination of request and response structures. (since the response is just a superset of the request, it's hard to separate the two in my mind).
That's a good point. Yes, I too expect the current implementation to apply price-changes during that life cycle. Thanks for pointing that out: Evaluating the solution to the original problem discussed on the chat channel, I think that with a few minor changes we can support this workflow the way it's expected to work.
The solution we discussed on the chat channel is just as simple as effective: John proposed we add a boolean to each invoice line which indicates the price in that line should be excluded from pricematrix calculations; e.g. named 'pricefreeze'. That way, the line gets excluded from pricematrix calculations and won't be updated when the invoice gets saved. How the UI gets to set the 'pricefreeze' boolean, is out of scope of the current consideration. It didn't feel right to add another checkbox on the already crowded invoice input screen. We came up with other ways to set the value. But, as said, that's to be dealt with later. Applying this solution to your "full quote > invoice" workflow, I think the expected behaviour can be had by setting the 'pricefreeze' parameter on orders spawned from quotes and invoices spawned from orders.
The response is currently expected to hold just the price used for calculation. I was originally expecting to send the list price or the price matrix price too, but I found that to be confusing, because: which price do you send when there's a price matrix price for the current vendor and invoice line, but the user has overridden the price manually?
I was considering the option to add a time-dimension to the parts table, allowing various parts uses to reference explicit lines in the table, with the price data as it applied at the specific time of modification of the quote/order/invoice. It's quite complex though, because: do you create a full copy of the price matrix too? and what about the parts line itself when e.g. a line in the makemodel table is changed? I decided that storing a full audit trail on modified parts data is probably a good idea, but not something to be addressed while creating the invoice API. For now, I'm really happy with John's "pricefreeze" suggestion as it allows us to move forward on the implementation without endless complexities.
Regards, Erik.
-- |
_______________________________________________ devel mailing list -- ..hidden.. To unsubscribe send an email to ..hidden..