Source: ledgersmb
Version: 1.6.9+ds-1
Severity: wishlist
Hi,
Upstream has made numerous new upstream releases since 1.6.9. From
what I can tell there's an 1.8.x branch already.
Please consider packaging new versions.
Chris
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.8.17
* Align filters between UI and the database on draft transaction search (#5692)
* Correctly present manual tax and invoice total on reversing invoice (#5721)
* Repeatedly saving a draft invoice pops up an SQL error (#5679)
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.8.17/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.8.17
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.8.17
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.8.17
These are the sha256 checksums of the uploaded files:
b1eabf07226041216fe286b68d7204b2ac7925bef56140bc15b2897587e247c9 ledgersmb-1.8.17.tar.gz
fcb5994b391716b8c8c51b04977717ca9d8df5edd8789a864d1afdb380a683c5 ledgersmb-1.8.17.tar.gz.asc
Hi David,
On Mon, Jul 12, 2021 at 12:04 PM lsmbdev <lsmbdev(a)sbts.com.au> wrote:
> 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"
>
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.
> 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.
>
Right. Or maybe other criteria that the sales has been mandated for.
> Without storing all three items of data it becomes difficult, if not
> impossible, to correctly report on this with enough detail to be useful for
> basic oversight let alone malicious behaviour.
>
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/816e740f0702af2a2192dfe4832dc3e…).
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.
> I've run into other use cases in the past as well.
>
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").
Regards,
Erik.
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Erik Huelsmann <ehuels(a)gmail.com>
> Date: 12/7/21 15:09 (GMT+08:00)
> To: lsmbdev <lsmbdev(a)sbts.com.au>
> Cc: devel(a)lists.ledgersmb.org, John Locke <john(a)freelock.com>, "Yves
> Lavoie, GaYLi" <ylavoie(a)yveslavoie.com>
> 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 <lsmbdev(a)sbts.com.au> wrote:
>
>> Shouldn't the linetotal be returned within the calculated block rather
>> than the user supplied block?
>> Doing otherwise seems like a massive rounding nightmare.
>>
>
> 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).
>
>
>> As for handling db side changes during the life cycle of the invoice (eg:
>> price and tax changes) I'm not sure I see an easy solution.
>> We currently have a problem here anyway.
>> If we follow a full quote => order => invoice workflow you expect a price
>> as shown on a quote to be static throughout the sequence.
>> However it will most likely change if any source info changes along the
>> way.
>>
>
> 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.
>
>
>> Personally, I think a specific request to update a line is required.
>> To that end, I think each line should (as the first element) contain a
>> boolean "recalc" element and a "lastcalc" timestamp
>> As should the entire invoice.
>>
>
> 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.
>
>
>> Regardless, there probably needs to be 3 sets of price data presented.
>> - user overrides
>> - system calculated
>> - actual data for use
>>
>
> 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?
>
>
>> All of the above should be permanently stored in the db. (FYI, we should
>> be doing this even for non API entries as well.
>> This preserves the data. Allowing better auditing and diagnostics)
>>
>
> 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.
>
>
>> There is probably more to consider, but there's a start for discussion
>>
>
> Regards,
>
> Erik.
>
>
>>
>> Regards
>> David G
>>
>> -------- Original message --------
>> From: Erik Huelsmann <ehuels(a)gmail.com>
>> Date: 6/7/21 04:56 (GMT+08:00)
>> To: devel(a)lists.ledgersmb.org
>>
>> Hi,
>>
>> Over the past months, I've been working on a webservice for LedgerSMB to
>> post invoices. The current status can be viewed here:
>> https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout…
>>
>> Summarizing what I have achieved so far:
>>
>> * An endpoint /erp/api/v0/invoices/, which accepts POST requests
>> * The "specification" of the payload can be found here:
>> https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout…
>> * The toplevel keys "eca", "account", "dates", "lines", "taxes",
>> "currency", "description",
>> "invumber", "ordnumber", "ponumber" are supported
>> * The pricematrix is consulted when determining pricing
>> * Customers and vendors are supported (each with their own type of
>> pricematrix)
>>
>> The endpoint has been coded defensively, throwing an "unacceptable input"
>> error on anything that's not consistent with what the database should
>> expect. A lot of things are currently not supported:
>>
>> * Invoices will end up in "draft" state and cannot be Post-ed
>> * Payments are not processed
>> * Rounding (in the price matrix, but also of the line-totals) isn't in
>> place
>> * Complex taxes have limited support ("simple taxes only")
>> * No multi-currency support yet
>> * No support for "taxes included" tax extraction calculation (from the
>> gross invoice amount)
>> * I have no idea what happens with Cost Of Goods Sold calculations
>> * No support for shipping addresses
>> * No support for printing/mailing/etc.
>> * All invoices are posted into the 'ar' table (oops!)
>>
>> That said, I have some questions with respect to what the functionality
>> needs to be able to do, especially with respect to saving invoices in order
>> to post them later. With respect to saving and posting invoices, I'm
>> envisaging the workflow to require a number (lots) of save actions on the
>> invoice in order to calculate its prices, i.e. to calculate the price
>> matrix. There may be other reasons to save the invoice in the mean time.
>> In the current invoice-entry process (running through "old code"),
>> there's a lot of code which tries to determine if anything changed in the
>> invoice based on the fields entered. If it did (or rather, if the deduction
>> code thinks it did), the invoice will be recalculated either partial or in
>> full.
>> This code causes lots of headaches, because most of the time the user
>> didn't expect their edits to trigger a full recalculation, or, the
>> recalculation didn't happen the way it should e.g. due to the fact that
>> prices had been overridden by the user.
>> To prevent similar complexity in the webservice, I've created a structure
>> where each line returns the data entered by the user (as provided on input)
>> as well as calculated data. It is up to the front-end to present that data
>> in a useful way to the user. Just as an example, the following structure
>> could be a line in the invoice:
>>
>> { "part": { "number": "p1", "description": "p1 desc", "price": 1.23 },
>> "quantity": 5,
>> "description": null, "price": null, "linetotal": 6.15, "discount":
>> null }
>>
>> The above line means to say that the user didn't enter a price,
>> description or discount. The part has been configured with a price of $1.23
>> for the current customer/vendor and the quantity on the line is 5 (as
>> entered by the user). If the user enters a description, the description
>> field in the line itself gets filled with that, e.g. "bike rental fees".
>> Assuming that the user saves the above line without further input and
>> continues by posting the invoice, I'm thinking that the posting action
>> should copy the description and price from the part configuration to the
>> invoice.
>> This poses a timing challenge: what if in the mean time the part
>> configuration gets changed and the price is updated to 5.23? Then the
>> actual invoice posted goes from a linetotal of 6.15$ to 25.15$. Seems
>> unacceptable.
>> So, the other option is: create a "calculate the price matrix for this
>> invoice without actually storing it" endpoint and do the "copy data from
>> part" step on save instead of on posting. Here, I'm running into a problem
>> too: lets assume the user wants to save the invoice only to work on it more
>> tomorrow? In that case, all the prices have been filled and the price
>> matrix calculation won't work anymore, because it doesn't work due to the
>> "price" fields no longer being 'null'.
>>
>> The above problem exists not only for parts, but also for taxes; maybe
>> other scenarios too.
>>
>> By posting this, I hope to get some good discussion on the topic (and
>> hopefully some good additional ideas)!
>>
>>
>>
>>
>> --
>> Bye,
>>
>> Erik.
>>
>> http://efficito.com -- Hosted accounting and ERP.
>> Robust and Flexible. No vendor lock-in.
>>
>
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
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 <lsmbdev(a)sbts.com.au> wrote:
> Shouldn't the linetotal be returned within the calculated block rather
> than the user supplied block?
> Doing otherwise seems like a massive rounding nightmare.
>
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).
> As for handling db side changes during the life cycle of the invoice (eg:
> price and tax changes) I'm not sure I see an easy solution.
> We currently have a problem here anyway.
> If we follow a full quote => order => invoice workflow you expect a price
> as shown on a quote to be static throughout the sequence.
> However it will most likely change if any source info changes along the
> way.
>
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.
> Personally, I think a specific request to update a line is required.
> To that end, I think each line should (as the first element) contain a
> boolean "recalc" element and a "lastcalc" timestamp
> As should the entire invoice.
>
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.
> Regardless, there probably needs to be 3 sets of price data presented.
> - user overrides
> - system calculated
> - actual data for use
>
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?
> All of the above should be permanently stored in the db. (FYI, we should
> be doing this even for non API entries as well.
> This preserves the data. Allowing better auditing and diagnostics)
>
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.
> There is probably more to consider, but there's a start for discussion
>
Regards,
Erik.
>
> Regards
> David G
>
> -------- Original message --------
> From: Erik Huelsmann <ehuels(a)gmail.com>
> Date: 6/7/21 04:56 (GMT+08:00)
> To: devel(a)lists.ledgersmb.org
>
> Hi,
>
> Over the past months, I've been working on a webservice for LedgerSMB to
> post invoices. The current status can be viewed here:
> https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout…
>
> Summarizing what I have achieved so far:
>
> * An endpoint /erp/api/v0/invoices/, which accepts POST requests
> * The "specification" of the payload can be found here:
> https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout…
> * The toplevel keys "eca", "account", "dates", "lines", "taxes",
> "currency", "description",
> "invumber", "ordnumber", "ponumber" are supported
> * The pricematrix is consulted when determining pricing
> * Customers and vendors are supported (each with their own type of
> pricematrix)
>
> The endpoint has been coded defensively, throwing an "unacceptable input"
> error on anything that's not consistent with what the database should
> expect. A lot of things are currently not supported:
>
> * Invoices will end up in "draft" state and cannot be Post-ed
> * Payments are not processed
> * Rounding (in the price matrix, but also of the line-totals) isn't in
> place
> * Complex taxes have limited support ("simple taxes only")
> * No multi-currency support yet
> * No support for "taxes included" tax extraction calculation (from the
> gross invoice amount)
> * I have no idea what happens with Cost Of Goods Sold calculations
> * No support for shipping addresses
> * No support for printing/mailing/etc.
> * All invoices are posted into the 'ar' table (oops!)
>
> That said, I have some questions with respect to what the functionality
> needs to be able to do, especially with respect to saving invoices in order
> to post them later. With respect to saving and posting invoices, I'm
> envisaging the workflow to require a number (lots) of save actions on the
> invoice in order to calculate its prices, i.e. to calculate the price
> matrix. There may be other reasons to save the invoice in the mean time.
> In the current invoice-entry process (running through "old code"), there's
> a lot of code which tries to determine if anything changed in the invoice
> based on the fields entered. If it did (or rather, if the deduction code
> thinks it did), the invoice will be recalculated either partial or in full.
> This code causes lots of headaches, because most of the time the user
> didn't expect their edits to trigger a full recalculation, or, the
> recalculation didn't happen the way it should e.g. due to the fact that
> prices had been overridden by the user.
> To prevent similar complexity in the webservice, I've created a structure
> where each line returns the data entered by the user (as provided on input)
> as well as calculated data. It is up to the front-end to present that data
> in a useful way to the user. Just as an example, the following structure
> could be a line in the invoice:
>
> { "part": { "number": "p1", "description": "p1 desc", "price": 1.23 },
> "quantity": 5,
> "description": null, "price": null, "linetotal": 6.15, "discount":
> null }
>
> The above line means to say that the user didn't enter a price,
> description or discount. The part has been configured with a price of $1.23
> for the current customer/vendor and the quantity on the line is 5 (as
> entered by the user). If the user enters a description, the description
> field in the line itself gets filled with that, e.g. "bike rental fees".
> Assuming that the user saves the above line without further input and
> continues by posting the invoice, I'm thinking that the posting action
> should copy the description and price from the part configuration to the
> invoice.
> This poses a timing challenge: what if in the mean time the part
> configuration gets changed and the price is updated to 5.23? Then the
> actual invoice posted goes from a linetotal of 6.15$ to 25.15$. Seems
> unacceptable.
> So, the other option is: create a "calculate the price matrix for this
> invoice without actually storing it" endpoint and do the "copy data from
> part" step on save instead of on posting. Here, I'm running into a problem
> too: lets assume the user wants to save the invoice only to work on it more
> tomorrow? In that case, all the prices have been filled and the price
> matrix calculation won't work anymore, because it doesn't work due to the
> "price" fields no longer being 'null'.
>
> The above problem exists not only for parts, but also for taxes; maybe
> other scenarios too.
>
> By posting this, I hope to get some good discussion on the topic (and
> hopefully some good additional ideas)!
>
>
>
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.8.16
* Fix incorrectly encoded UTF-8 characters on journal entry (#5583)
* Fix multiple updates in payment screen resetting user input (#5614)
* Improve error message when missing cash discount configuraition (#5632)
* Fix payment information for credit accounts which are Persons (#5632)
* Fix memos sometimes being associated with incorrect payment rows (#5646)
* Fix wrong fx value due to formatted exchangerate used in calculation (#5656)
* Fix decimal places setting not applied for AR/AP transactions (#5657)
* Fix duplicated income statement figures due to reversed year end (#5682)
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.8.16/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.8.16
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.8.16
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.8.16
These are the sha256 checksums of the uploaded files:
17a2e068e6655b833e209aa954b51bc6b8bb82fa4ea87bade9abefdc98cadff2 ledgersmb-1.8.16.tar.gz
7f0cd165beb22953712a11c2380dc587966e588bfc25cca75166e7d94bba3a93 ledgersmb-1.8.16.tar.gz.asc
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.7.32
* Fix multiple updates in payment screen resetting user input (#5614)
* Improve error message when missing cash discount configuraition (#5632)
* Fix payment information for credit accounts which are Persons (#5632)
* Fix memos sometimes being associated with incorrect payment rows (#5646)
* Fix wrong fx value due to formatted exchangerate used in calculation (#5656)
* Fix decimal places setting not applied for AR/AP transactions (#5657)
* Fix duplicated income statement figures due to reversed year end (#5682)
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.7.32/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.7.32
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.32
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.7.32
These are the sha256 checksums of the uploaded files:
22fb6f99d68c7a1372949f7a7ecef5f76c3ce8ebec610f73d6076a44b19b266a ledgersmb-1.7.32.tar.gz
9c13b3bf6fbb13d61c4adef3e342eb86c8027808dddedbab30cae4027fe1d9d3 ledgersmb-1.7.32.tar.gz.asc
Hi,
Over the past months, I've been working on a webservice for LedgerSMB to
post invoices. The current status can be viewed here:
https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout…
Summarizing what I have achieved so far:
* An endpoint /erp/api/v0/invoices/, which accepts POST requests
* The "specification" of the payload can be found here:
https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout…
* The toplevel keys "eca", "account", "dates", "lines", "taxes",
"currency", "description",
"invumber", "ordnumber", "ponumber" are supported
* The pricematrix is consulted when determining pricing
* Customers and vendors are supported (each with their own type of
pricematrix)
The endpoint has been coded defensively, throwing an "unacceptable input"
error on anything that's not consistent with what the database should
expect. A lot of things are currently not supported:
* Invoices will end up in "draft" state and cannot be Post-ed
* Payments are not processed
* Rounding (in the price matrix, but also of the line-totals) isn't in
place
* Complex taxes have limited support ("simple taxes only")
* No multi-currency support yet
* No support for "taxes included" tax extraction calculation (from the
gross invoice amount)
* I have no idea what happens with Cost Of Goods Sold calculations
* No support for shipping addresses
* No support for printing/mailing/etc.
* All invoices are posted into the 'ar' table (oops!)
That said, I have some questions with respect to what the functionality
needs to be able to do, especially with respect to saving invoices in order
to post them later. With respect to saving and posting invoices, I'm
envisaging the workflow to require a number (lots) of save actions on the
invoice in order to calculate its prices, i.e. to calculate the price
matrix. There may be other reasons to save the invoice in the mean time.
In the current invoice-entry process (running through "old code"), there's
a lot of code which tries to determine if anything changed in the invoice
based on the fields entered. If it did (or rather, if the deduction code
thinks it did), the invoice will be recalculated either partial or in full.
This code causes lots of headaches, because most of the time the user
didn't expect their edits to trigger a full recalculation, or, the
recalculation didn't happen the way it should e.g. due to the fact that
prices had been overridden by the user.
To prevent similar complexity in the webservice, I've created a structure
where each line returns the data entered by the user (as provided on input)
as well as calculated data. It is up to the front-end to present that data
in a useful way to the user. Just as an example, the following structure
could be a line in the invoice:
{ "part": { "number": "p1", "description": "p1 desc", "price": 1.23 },
"quantity": 5,
"description": null, "price": null, "linetotal": 6.15, "discount": null
}
The above line means to say that the user didn't enter a price, description
or discount. The part has been configured with a price of $1.23 for the
current customer/vendor and the quantity on the line is 5 (as entered by
the user). If the user enters a description, the description field in the
line itself gets filled with that, e.g. "bike rental fees".
Assuming that the user saves the above line without further input and
continues by posting the invoice, I'm thinking that the posting action
should copy the description and price from the part configuration to the
invoice.
This poses a timing challenge: what if in the mean time the part
configuration gets changed and the price is updated to 5.23? Then the
actual invoice posted goes from a linetotal of 6.15$ to 25.15$. Seems
unacceptable.
So, the other option is: create a "calculate the price matrix for this
invoice without actually storing it" endpoint and do the "copy data from
part" step on save instead of on posting. Here, I'm running into a problem
too: lets assume the user wants to save the invoice only to work on it more
tomorrow? In that case, all the prices have been filled and the price
matrix calculation won't work anymore, because it doesn't work due to the
"price" fields no longer being 'null'.
The above problem exists not only for parts, but also for taxes; maybe
other scenarios too.
By posting this, I hope to get some good discussion on the topic (and
hopefully some good additional ideas)!
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
