https://bugs.kde.org/show_bug.cgi?id=380187
--- Comment #7 from Bernhard Scheirle <bernhard+...@scheirle.de> --- 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 -- You are receiving this mail because: You are watching all bug changes.
