Open quantthingy opened 4 months ago
Hi! Just to be sure - are you setting
Both is necessary to get past cashflows in the report. The first flag controls the general filter on past cashflows and the second flag enables past cashflow info generation for scripted trades.
If you are using both flags already, could you kindly post an example to reproduce the issue? Thanks!
Both flags are included. Provided an example based on Example 52 from the release, using 1.8.12.1 version
Input and Output files are included.
Thanks for looking into it.
The trade is considered "expired" in this case and therefore excluded from all reports.
I'll change the behavior so that the trade never expires if IncludePastCashflows is active for scripted trades. This change should appear on the master branch soon.
Please note that this change won't change the behavior of non-scripted trades which will still be excluded from the reporting if they are expired.
A few more notes:
There is a typo in the parameter name in ore.xml, it should be
<Analytic type="cashflow">
...
<Parameter name="includePastCashflows">true</Parameter>
</Analytic>
The example script does not produce a cashflow. I changed
<Number>
<Name>GuaranteedFixings</Name>
<Value>0</Value>
</Number>
to get a flow for testing.
Thanks for the change.
Some brainstorming:
. Autocallable: I was referring to any Scripted trade with a Knock-out barrier. From a financial point of view, the expiry date is the Knock-Out date and not the the last potential Settlement date. This is the same logic for any barrier instrument.
in ored/portfolio/autocallable_01.hpp , the Trade Autocallable_01 is such an example
Yes, but if the autocallable is knocked out on a date d <= asof then it should not generate non-zero cf info after d?
On Wed, 10 Jul 2024 at 09:11, Julien Musset @.***> wrote:
. Autocallable: I was referring to any Scripted trade with a Knock-out barrier. From a financial point of view, the expiry date is the Knock-Out date and not the the last potential Settlement date. This is the same logic for any barrier instrument.
in ored/portfolio/autocallable_01.hpp , the Trade Autocallable_01 is such an example
— Reply to this email directly, view it on GitHub https://github.com/OpenSourceRisk/Engine/issues/253#issuecomment-2219728856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAT4HLMP5DSJUZRVRUEJMODZLTNDNAVCNFSM6AAAAABKQECXHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJZG4ZDQOBVGY . You are receiving this because you commented.Message ID: @.***>
Agree. To be precise:
Assuming an autocallable with 3 autocall observation dates: 1 Jan 2023, 1 Feb 2022, 1 March 2022 If the autocall happened on 1 Feb 2022 (and therefore no cashflow on 1 March 2022), then I got the following in my test:
case 1: Value date on 15 Feb 2022: historical cashflow table generated at the instrument level case 2: Value date on 15 Mach 2022: no historical cashflow table generated at the instrument level
Your solution will solve this inconsistency.
(apology dont have an example to share, as all the test were in c++)
ok sounds good, we'll try to push out an update on master so that you can test the fix
how to reproduce:
result:
expected result:
I can provide an example if needed.