| Summary: | Shares always use the current rate/value | ||
|---|---|---|---|
| Product: | [Applications] skrooge | Reporter: | Bernhard Scheirle <bernhard+kde> |
| Component: | general | Assignee: | Stephane MANKOWSKI <stephane> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | stephane |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | 25.1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/skrooge/a475f59838af3a100090d56ac212077ca0fbd5e5 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
kmymoney graph
skrooge graph |
||
|
Description
Bernhard Scheirle
2017-05-25 13:26:37 UTC
Created attachment 105708 [details]
kmymoney graph
Created attachment 105709 [details]
skrooge graph
(In reply to Bernhard Scheirle from comment #0) > But the amount should be computed with the exchange rate of the date of the > operation. In fact, for shares, 3 dates can be interesting: 1- The date and time when the shares have been bought. To be able to compute the price. 2- The date when the shares have been bought. To have an estimation of the shares value at the beginning. 3- Today. To have the current estimation of the shares value. > > This wrong amount also has a huge impact on reports. > It is not possible to track the development/value of an investment. > > Compare the two attached screen-shots of the same investement (Every year a > small amount of shares get sold). > In KMyMoney you can see the value of the investement for each year [No > operations entered for 2009-2012]. > Skrooge displays values which have nothing to do with reality. > It reflects the sold shares but does not take into account that a single > share changes its value. Skrooge displays something true: the current value of your shared date after date... ... but I can understand that is not what you want. In the "Unit" page, you can have the value of the share date after date. This is not what you want too. If I well understand, you would like to have: The history values of your shares. This history can be modified due to the number of shares or its value. Skrooge is not able to display that. > > Related https://bugs.kde.org/show_bug.cgi?id=283842 > > (In reply to Stephane MANKOWSKI from comment #1) > > This is the expected result else totals will be wrong. > > So, we don't want to change this behavior. > > (In reply to Stephane MANKOWSKI from comment #3) > > Just an example: > > You have an account with 100 ZARCHF (current rate 1 ZARCHF = 1 EURO) > > You buy something for 10 ZARCHF (current rate 1 ZARCHF = 2 EURO) > > > > INITIAL TOTAL = 100 ZARCHF = 100 EURO > > -10 ZARCHF = -20 EURO > > NEW TOTAL = 90 ZARCHF = 80 EURO (This value is wrong). > > The result should be 180 EURO. > > > > So, all amounts must be computed with the same rate. > > I don't understand why you compute the total from the EUR values. > Why not simply sum up the shares and than multiply with the exchange rate?: > > INITIAL TOTAL = 100 ZARCHF (= 100 EUR) > -10 ZARCHF (= -20 EUR) > NEW TOTAL = 90 ZARCHF = 180 EUR (computed via 90 * 2 and NOT 100 - 20) > > Other programs (like KMyMoney) also manage to calculate a correct total and > display per operation the corresponding EUR value (at that time). Hi, I can not sum up the shares because I don't have guarantee that all operations of the report are in the same unit. I don't know how to sum apples and bananas. That's why, all operations are computed in primary unit (€) and then mathematical operations can be done. My first feeling is that the "Report" page is too generic to be able to cover your request. I will think about "how to give you the expected report" and come back to you with a proposal. Regards. (In reply to Stephane MANKOWSKI from comment #3) > In fact, for shares, 3 dates can be interesting: > 1- The date and time when the shares have been bought. To be able to compute > the price. > 2- The date when the shares have been bought. To have an estimation of the > shares value at the beginning. > 3- Today. To have the current estimation of the shares value. True, that one and two are two different things wasn't on my radar. > If I well understand, you would like to have: The history values of your > shares. > This history can be modified due to the number of shares or its value. > Skrooge is not able to display that. Yes, that is what I want. > [...] > I can not sum up the shares because I don't have guarantee that all > operations of the report are in the same unit. I don't know how to sum > apples and bananas. That's why, all operations are computed in primary unit > (€) and then mathematical operations can be done. You can not sum them up directly, but indirectly it is possible. Example: * 2 shares: Apples and Bananas * On day 1 we buy 10 Apples for 2€ each, 7 Bananas for 5€ each and in the evening one more Apple for 2.5€. * On day 2 we put 5 € directly into the account, sell 2 Apples for 3€ each and buy 3 Bananas for 0.5€ each. Operations: ----|--------|--------|---------------|------------------------------|---------------------------------- Day | What | Amount | Cost per Unit | Value at creation date/time | Value (as of now = end of day 2) ----|--------|--------|---------------|------------------------------|---------------------------------- 1 | Apple | 10 | 2.00 € | 20.00 € [10 * 2.00 €] | 30.00 € [10 * 3.00 €] | Banana | 7 | 5.00 € | 35.00 € [ 7 * 5.00 €] | 3.50 € [ 7 * 0.50 €] | Apple | 1 | 2.50 € | 2.50 € [ 1 * 2.50 €] | 3.00 € [ 1 * 3.00 €] ----|--------|--------|---------------|------------------------------|----------------------------- 2 | € | 5 | 1.00 € | 5.00 € [ 5 * 1.00 €] | 5.00 € [ 5 * 1.00 €] | Apple | -2 | 3.00 € | -6.00 € [-2 * 3.00 €] | -6.00 € [-2 * 3.00 €] | Banana | 3 | 0.50 € | 1.50 € [ 3 * 0.50 €] | 1.50 € [ 3 * 0.50 €] --------------------------------------|------------------------------|----------------------------- Overall Total: | Sum would be obviously wrong | 37.00 € | See below for correct total | Sum of above values --------------------------------------|------------------------------|----------------------------- Overall Total: 1. Sum up the amount of each share individually. (Total column) 2. Compute current value for each share. (Value column) 3. Sum up the Value column. -------|-----------------|-------------------------- What | Total | Value (as of now = end of day 2) -------|-----------------|-------------------------- € | 5 [ 5 ] | 5.00 € [ 5 * 1.00 €] Apple | 8 [10 + 1 - 2] | 27.00 € [ 9 * 3.00 €] Banana | 10 [ 7 + 3 ] | 5.00 € [10 * 0.50 €] -------------------------|------------------------- Total: | 37.00 € [ 5.00 € + 27.00 € + 5.00 €] -------------------------|------------------------- Daily Total (Day 1): Same computation as for the overall, monthly, ... total -------|-------------|-------------------------- What | Total | Value (as of end of day 1) -------|-------------|-------------------------- € | 0 [ ] | 0.00 € [ 0 * 1.00 €] Apple | 11 [10 + 1] | 27.50 € [11 * 2.50 €] Banana | 7 [ 7 ] | 35.00 € [ 7 * 5.00 €] ---------------------|------------------------- Total: | 62.00 € ---------------------|------------------------- Computed overall total matches the overall total skrooge currently computes. But the daily, monthly, ... total is different from the skrooge daily, monthly, ... total. The new daily, monthly, ... total would represent the value of the account at the given date/time (respecting the shares value at that time). And therefore the reports would get the desired form. > My first feeling is that the "Report" page is too generic to be able to > cover your request. I don't think that is the case. Either just use the new total computation (I currently see no use case for reports with the old total. But that doesn't mean that there isn't one.) or add an option so the user can select what values/totals should be used as input. Anyhow thank you for your time and if you see any flaws in my suggestion please let me know, because I'm by no means a financial expert. With the current way of working:
-------|--------------------------|--------------------------
What | Day 1 | Day 2
-------|--------------------------|--------------------------
€ | 0.00 € [ 0 * 1.00 €] | 5.00 € [ 5 * 1.00 €]
Apple | 33.00 € [11 * 3.00 €] | -6.00 € [ -2 * 3.00 €]
Banana | 3.50 € [ 7 * 0.50 €] | 1.50 € [3 * 0.50 €]
-------|--------------------------|-------------------------
Total: | 36.50 € | 0.50 €
-------|--------------------------|-------------------------
Each operation amount is computed with the last value of its unit.
Reports are easily computed (and with good performances) just by adding amounts.
With the current way of working in "cumulative mode":
-------|--------------------------|--------------------------
What | Day 1 | Day 2 (Cumulated)
-------|--------------------------|--------------------------
€ | 0.00 € | 5.00 € [ 5.00 € + 0.00 €]
Apple | 33.00 € | 27.00 € [ -6.00 € + 33.00 €]
Banana | 3.50 € | 2.00 € [ 1.50 € + 3.50 €]
-------|--------------------------|-------------------------
Total: | 36.50 € | 34.00 €
-------|--------------------------|-------------------------
The cumulative reports are just a sum of previous columns + the current one. (easy and good performances)
With your proposal:
-------|--------------------------|--------------------------
What | Day 1 | Day 2
-------|--------------------------|--------------------------
€ | 0.00 € [ 0 * 1.00 €] | 5.00 € [ 5 * 1.00 €]
Apple | 27.50 € [11 * 2.50 €] | -6.00 € [ -2 * 3.00 €]
Banana | 35.00 € [ 7 * 5.00 €] | 1.50 € [3 * 0.50 €]
-------|--------------------------|-------------------------
Total: | 62.50 € | 0.50 €
-------|--------------------------|-------------------------
Each operation amount is computed with the value of its unit at the date of the operation.
This way of computation is not good for performances because the value of the unit won't be always the same.
With your proposal in "cumulative mode":
We can sum euro (as today)
-------|--------------------------|--------------------------
What | Day 1 | Day 2 (Cumulated)
-------|--------------------------|--------------------------
€ | 0.00 € | 5.00 € [ 5.00 € + 0.00 €]
Apple | 27.50 € | 21.50 € [ -6.00 € + 27.50 €]
Banana | 35.00 € | 36.50 € [ 1.50 € + 35.00 €]
-------|--------------------------|-------------------------
Total: | 62.50 € | 62.00 €
-------|--------------------------|-------------------------
The cumulative reports are just a sum of previous columns + the current one. (easy and good performances)
But, I think that this is not you want.
We can sum quantities
-------|--------------------------|--------------------------
What | Day 1 | Day 2 (Cumulated)
-------|--------------------------|--------------------------
€ | 0.00 € | 5.00 € [ 5 * 1.00 €]
Apple | 27.50 € | 27.00 € [ (11-2) * 3.00 €]
Banana | 35.00 € | 5.00 € [ (7+3) * 0.50 €]
-------|--------------------------|-------------------------
Total: | 62.50 € | 37.00 €
-------|--------------------------|-------------------------
The computation of a cell is no more just a sum of €. This is a sum(quantity) * unit amount at the date of the cell.
But if the column is a month, what is the date to take into account? The date of the operation? The last day of the month? The first day of the month?
I think, this should be the last day of the month. It means that the operation doesn't have an amount but many amounts based on the report.
This could be confusing because the report sell with display an amount and when the user will double click on the sell to see the corresponding operation he will see an other amount !!!
Just to continue the discussion, you must know that some users have 2 accounts, one in euro and an other one in dollars.
All reports/advice are computed based on the same value of the unit (the last value).
If for example, this user spend 10 dollars in January and 10 dollars in February, he doesn't have an alert.
Now, with your proposal, if the value of dollars change a lot, he will have an alert saying he spent more (or less) than in the previous month.
So, I still have an important question:
-What is the amount of an operation?
-R1: As today, the quantity * last value of its unit
-R2: As in your proposal, the quantity * value of its unit at the date of the operation
In this case:
Is it really what you want for report having periods of time?
How can I compare values? (example: 10 dollars in January ad 10 dollars in February)
-R3: An operation doesn't have an amount. The amount is computed dynamically based on the report.
In this case, the impact on Skrooge could be huge !!!!
My proposal could be this one:
- The amount on an operation is still the quantity * last value of its unit.
- No impact on advices
- No impact on reports
- No impact on balance
- No impact on monthly report
-In the unit page, you will be able to define if you want to see the graph of:
- The history of the value of the selected unit (as today)
- The history of the amount owned of the selected unit (as expected)
This solution has a limited impact and should answer to your request.
Thank you in advance for your answer and point of view.
Git commit a475f59838af3a100090d56ac212077ca0fbd5e5 by Stephane Mankowski. Committed on 01/06/2017 at 21:27. Pushed by smankowski into branch 'master'. Shares always use the current rate/value. On unit page, you can choose if you want to see the history of the unit value or the history of the amount owned M +1 -0 CHANGELOG M +14 -1 plugins/skrooge/skrooge_unit/skgunitpluginwidget.cpp M +1 -0 plugins/skrooge/skrooge_unit/skgunitpluginwidget.h M +3 -2 skgbankmodeler/skgdocumentbank.cpp https://commits.kde.org/skrooge/a475f59838af3a100090d56ac212077ca0fbd5e5 Thanks for the in depth reply (and sorry for my late reply). (In reply to Stephane MANKOWSKI from comment #5) > We can sum quantities > -------|--------------------------|-------------------------- > What | Day 1 | Day 2 (Cumulated) > -------|--------------------------|-------------------------- > € | 0.00 € | 5.00 € [ 5 * 1.00 €] > Apple | 27.50 € | 27.00 € [ (11-2) * 3.00 €] > Banana | 35.00 € | 5.00 € [ (7+3) * 0.50 €] > -------|--------------------------|------------------------- > Total: | 62.50 € | 37.00 € > -------|--------------------------|------------------------- > > The computation of a cell is no more just a sum of €. This is a > sum(quantity) * unit amount at the date of the cell. > But if the column is a month, what is the date to take into account? The > date of the operation? The last day of the month? The first day of the month? > I think, this should be the last day of the month. I too. > It means that the operation doesn't have an amount but many amounts based on the report. > > This could be confusing because the report sell with display an > amount and when the user will double click on the sell to see the > corresponding operation he will see an other amount !!! Yeah that could be confusing. > So, I still have an important question: > -What is the amount of an operation? > -R1: As today, the quantity * last value of its unit > -R2: As in your proposal, the quantity * value of its unit at the date of > the operation > In this case: > Is it really what you want for report having periods of time? > How can I compare values? (example: 10 dollars in January ad 10 dollars > in February) > -R3: An operation doesn't have an amount. The amount is computed > dynamically based on the report. > In this case, the impact on Skrooge could be huge !!!! I agree that both R1 and R2 have disadvantages and R3 is probably to expensive (time consuming) to implement. > My proposal could be this one: > - The amount on an operation is still the quantity * last value of its unit. > - No impact on advices > - No impact on reports > - No impact on balance > - No impact on monthly report > -In the unit page, you will be able to define if you want to see the graph > of: > - The history of the value of the selected unit (as today) > - The history of the amount owned of the selected unit (as expected) > > This solution has a limited impact and should answer to your request. That sounds good (and thanks for already implementing it). But why not have this switch in the report page instead of the unit page? That would allow some really nice/advanced reports, like: Report of how a whole portfolio/asset allocation shifted over time e.g.: - Input: Multiple shares - Columns: Year/Month/... - Mode: Percentage (column) - Diagram type: circle |