Release 3.1.0 (#168)

* base conditional requiremet on oed source type (#159) * base conditional requiremet on oed source type * CR level 1 don't create requirements * Update README.md Fix #147 * Update README.md updated major and minor descriptions * Update README.md a couple more small updates to the read me * Oed v3.1 collected non-breaking changes (#167) * added paragraph on optional versus CR filter fields * Update Changelog.rst Issues added for OED v3.1 anything I've missed @johcarter ? * Add files via upload Updates made for v3.1 highlighted in yellow. * Delete OpenExposureData/Docs/Open_Exposure_Data_v2.1.0.pdf Removed pdf doc as it was out of date and all chapters are being maintained as .rst anyway. * Add files via upload * Delete OpenExposureData/Docs/OED_v3.1_fallback codes.xlsx * Delete OpenExposureData/Docs/OpenExposureData_Spec_v3.1.xlsx * Add files via upload updates made to the 'versioning' tab * Delete OpenExposureData/Docs/OpenExposureData_Spec_v3.1.xlsx * Add files via upload * Add files via upload * Update README.md Updates to Readme for versioning and back compatibility * Split policy conditions documentation into a new section (#169) * added policy conditions documentation * moved conditions into new section * example fixes * example 10 and 11 * example 10 fix * clarifications * update following MD review * added loss examples * corrections and more loss examples * few corrections * spacing * edits following AK review * more corrections * reviewed excel spec and replaced previous version with 3.1 version * revert implentation of issue 162 (breaking) and added a few issues to changelog * Delete OpenExposureData/Docs/OpenExposureData_Spec.xlsx removing file as made small changes to data brackets * Create Spec * Add files via upload Adding updated spec of v3.1 * Delete OpenExposureData/Docs/Spec removing blank file * Add files via upload * Add files via upload changes to NumberofStoreys data range --------- Co-authored-by: Joh Carter <[email protected]> Co-authored-by: MattDonovan <[email protected]> * Versioning info (#166) * Added versioning sheet * added versioning sheets * versioning info grouped by version * removed the unused 'Other' category * if no versioning info, create empty dict * example schema for adding versioning information * Fix CI testing * added codes to revert to OED v2.2 and v2.0 * Removed test schema * fallback 1256 and 1305 -> 1104 & 5503 -> 5501 * 5309, 5310 -> 5100 * new codes (agriculture) * Fix CD release * Disable guard * Revert "Disable guard" This reverts commit 0b14734. * Replaced spec xlsx file * Corrected field "number of storeys" * Add files via upload --------- Co-authored-by: Sam Gamble <[email protected]> --------- Co-authored-by: Stephane Struzik <[email protected]> Co-authored-by: Marco Tazzari <[email protected]> Co-authored-by: MattDonovan <[email protected]> Co-authored-by: Joh Carter <[email protected]> Co-authored-by: Nicola Cerutti <[email protected]>
OasisLMF · Nov 9, 2023 · ae83a8d · ae83a8d
1 parent d8236b3
commit ae83a8d
Show file tree

Hide file tree

Showing 12 changed files with 818 additions and 236 deletions.
diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml
@@ -134,7 +134,7 @@ jobs:
         echo "run_status=${{ job.status }}" >> $GITHUB_OUTPUT
 
   slack:
-    uses: OasisLMF/OasisLMF/.github/workflows/notify.yml@master
+    uses: OasisLMF/OasisLMF/.github/workflows/notify.yml@main
     secrets: inherit
     needs: release
     with:

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
@@ -9,7 +9,7 @@ on:
         required: false
 
 env:
-  ods_tools_branch: ${{ github.event_name != 'workflow_dispatch' && 'develop' ||  inputs.ods_tools_branch }}
+  ods_tools_branch: ${{ github.event_name != 'workflow_dispatch' && 'main' ||  inputs.ods_tools_branch }}
 
 jobs:
   build_spec:
@@ -18,11 +18,11 @@ jobs:
 
   build_package:
     needs: build_spec
-    uses: OasisLMF/ODS_Tools/.github/workflows/build.yml@develop
+    uses: OasisLMF/ODS_Tools/.github/workflows/build.yml@main
     secrets: inherit
     with:
       oed_spec_json: ${{ needs.build_spec.outputs.spec_filename }}
-      ods_branch: ${{ github.event_name != 'workflow_dispatch' && 'develop' ||  inputs.ods_tools_branch }}
+      ods_branch: ${{ github.event_name != 'workflow_dispatch' && 'main' ||  inputs.ods_tools_branch }}
 
   test:
     name: Run Pytest

diff --git a/Changelog.rst b/Changelog.rst
@@ -1,5 +1,15 @@
 ODS Changelog
 ==================
+`v3.1.0`_
+---------
+* (https://github.com/OasisLMF/ODS_OpenExposureData/issues/129) - Occupancy is only property oriented (can we include motor?)
+* (https://github.com/OasisLMF/ODS_OpenExposureData/issues/153) - Add INSEE Code as a valid GeogScheme value
+* (https://github.com/OasisLMF/ODS_OpenExposureData/issues/160) - RI Scope Required Fields to be updated
+* (https://github.com/OasisLMF/ODS_OpenExposureData/issues/161) - Additional OccupancyCode values for commercial low/mid/high-rise blocks
+* (https://github.com/OasisLMF/ODS_OpenExposureData/issues/165) - Additional Occupancy code values for Commercial Banks and financial institutions
+* (https://github.com/OasisLMF/ODS_OpenExposureData/issues/171) - Updated policy conditions documentation 
+* (https://github.com/OasisLMF/ODS_OpenExposureData/issues/170) - Small data field valid value corrections 
+* (https://github.com/OasisLMF/ODS_Tools/issues/64) - Backward compatibility when adding new codes in OED. A new 'versioning' tab has been added to the OED Spec .xlsx to show mapping of occupany and contruction codes between older versions of OED
 
 `v3.0.0`_
 ---------

diff --git a/Docs/ODS_Update_of_Versioning_v1.pdf b/Docs/ODS_Update_of_Versioning_v1.pdf
diff --git a/OpenExposureData/3_OED_Import_Format.rst b/OpenExposureData/3_OED_Import_Format.rst
@@ -136,5 +136,7 @@ If there is no reinsurance, the reinsurance scope import file is not required. I
 The minimum fields required are: **ReinsNumber**, at least one of the ten filter fields, and **CededPercent** for surplus treaties.
 The full set of fields in a reinsurance scope import file can be found by filtering on ‘ReinsScope’ in the Input File column of the *Open Exposure Data Spec* spreadsheet. There are over 10 potential fields that could be used within the reinsurance scope file. However, it is not mandatory to use a field that contains no data. 
 
-For a list of the reinsurance financial terms available and examples about how to specify such terms see the reinsurance section and associated examples. **<insert links here>**
+These filter fields are mostly optional and can be included in the scope file and used as needed. The exception is when specifying filters using **LocNumber** and **PolNumber**, the fields **AccNumber** and **PortNumber** are conditionally required and must also be populated, and **PortNumber** is required to be populated when **AccNumber** is used as a filter.  These field dependencies are expressed as 'Conditionally Required' 'CR' codes and included in the 'OED CR Field Appendix' tab of the *Open Exposure Data Spec*.
+
+For a list of the reinsurance financial terms available and examples about how to specify such terms see the reinsurance section and associated examples.
 
diff --git a/OpenExposureData/6_OED_Financial_Details_Primary.rst b/OpenExposureData/6_OED_Financial_Details_Primary.rst
@@ -127,28 +127,13 @@ Policy Special Conditions
 
 Policy special conditions are financial structures that apply to only a subset of locations within a policy. They apply after all location terms, but before any blanket policy terms or layer terms.
 
-These require four types of information: (1) the scope of the condition telling us which locations are included, (2) the financial terms of the condition, (3) the classification of the condition and (4) the order in which the special conditions apply – i.e. does a special condition apply before or after other special conditions that apply to the same locations.
-
 The scope of each special condition is specified using a **CondTag** on each location (in the location input file) that corresponds with the **CondTag** in the account input file.
 
 A unique set of financial terms and a classification is identified by the **CondNumber** field in the account file.
 
 The specification of the financial details of the condition is done in the same way as any other financial structure within OED but using the field names starting with ‘Cond’. All of the coverage values deductible and limit types and codes can be used for a special condition to specify how the special condition financial structures work. 
 
-Furthermore, there are two classifications of special conditions which are identified by the **CondClass** field in the account file. A value of 0 means 'Sublimit' and a value of 1 means 'Policy restriction'. The difference between them is what happens to losses for locations under the account that are not under the scope of the condition.
-
-* When the condition is a sublimit - the locations that are outside of scope of the condition **will** contribute loss to the policy on the account.
-* When the condition is a policy restriction - the locations outside of scope of the condition **will not** contribute loss to the policy on the account.
-
-Policy restrictions can be used to vary the locations that contribute loss to each policy under the same account, by having a different condition for each policy.
-
-Special conditions are defined in the OED account input file and must have a **CondNumber** and **CondTag** in this input file. If multiple special conditions apply within the same policy, then multiple rows (with the same **PortNumber**, **AccNumber** and **PolNumber** but different **CondNumber** and **CondTag**) must be used. The same **CondNumber** may be applied to more than one **CondTag**, if the financial terms are identical.
-
-If the special condition financial terms vary by policy, then a different CondNumber should be used for each unique set of terms. However, the **CondTag** should not vary for each **CondNumber**, and the locations should be tagged with **CondTag** only once per location in the location file. 
-
-There is one exception to this rule where there are multiple heirarchal conditions on the same location.  The order in which special conditions apply is specified through the **CondPriority** field in the account input file: if multiple special conditions **at different priorities** apply to the same location then multiple rows must be used in the location input file. Each location row will be identical apart from **CondTag** and which denote the special conditions grouping applying to the location for each condition.
-
-See example 4 in the financial structures' examples section for an illustration of how special conditions are specified.
+See the Financial Details Policy Conditions section for a detailed description of how special conditions are specified, and some examples.
 
 |
 
@@ -323,84 +308,7 @@ The account table above shows one of the flexible features of the OED – the po
 
 |
 
-**Example 4 – Commercial lines – multiple locations per policy with location and policy deductibles but with a sublimit for tier 1 wind**
-
-The tables below show an example of a commercial portfolio with 1 account containing 6 locations. The policy covers earthquake and wind with the same overall policy limit for both perils. However, for certain locations two different sub-limits apply for wind. We show two examples of this below, firstly where the sub-limits are not nested (e.g. Florida wind sub-limit and Texas wind sub-limit), and secondly where the sub-limits are nested (e.g. Texas tier 1 wind sub-limit and Texas overall wind sub-limit).
-
-|
-
-OED Account file:
-
-.. csv-table::
-    :widths: 20,30,30, 30,30,30,30,30,25
-    :header: "AccNumber",	"PolNumber",	"PolPeril",	"PolLimit6All",	"CondTag", "CondNumber",	"CondPriority",	"CondPeril",	"CondLimit6All"
-
-    "1",	"1",	"QQ1;WW1",	"1,500,000", "1",	"1",	"1",    "WW1",	"250,000"
-    "1",	"1",	"QQ1;WW1",	"1,500,000", "2",	"2",	"1",	"WW1",	"500,000"
-
-|
-
-OED Location file:
-
-.. csv-table::
-    :widths: 15,15,20,25,20,15
-    :header: "LocNumber",	"AccNumber",	"BuildingTIV",	"LocDedType1Building",	"LocDed1Building",	"CondTag"
-
-    "1",	"1",	"1,000,000",	"0",	"10,000",	"1"
-    "2",	"1",	"1,000,000",	"2",	"0.01",	    "1"
-    "3",	"1",	"1,000,000",	"1",	"0.05",	    "2"
-    "4",	"1",	"2,000,000",	"0",	"15,000",	"2"
-    "5",	"1",	"2,000,000",	"0",	"10,000",	
-    "6",	"1",	"2,000,000",	"2",	"0.10",	
-
-|
-
-In the tables above, special condition 1 (**CondNumber** = 1 in the account table) applies to **CondTag** = 1 which is the group of locations 1 and 2 (**CondTag** = 1 in the location table) whereas special condition 2 applies to locations 3 and 4.
-
-In the account table, note again the use of a second row for the same account and policy to specify a second special condition. This feature of OED means that essentially an unlimited number of special conditions are possible. The **CondPeril** field in the account table indicates the peril (or perils) to which the special condition financial terms apply. 
-In this example the special conditions are not nested – meaning that each location has no more than one special condition. In this situation the special conditions do not need an order and so the **CondPriority** should be the same for both conditions.
-
-In the location table, **CondTag** denotes the scope of the special condition (or conditions) which is a group of locations. **CondTag** must match with **CondTag** in the account table. 
-
-If two special conditions are nested or overlap – meaning that some locations have two applicable special conditions (e.g. Texas tier 1 wind sub-limit of 250,000 (**CondNumber** = 1) and Texas overall wind sub-limit of 500,000 (**CondNumber** = 2)), the tables would be specified as shown below. The example below assumes that locations 1 and 2 are in the Texas tier 1 region, locations 3 and 4 are within Texas but not in the Tier 1 wind region, and locations 5 and 6 are outside Texas.
-
-|
-
-OED Account file:
-
-.. csv-table::
-    :widths: 20,20,30,30,20,20,20,25,25
-    :header: "AccNumber",	"PolNumber",	"PolPeril",	    "PolLimit6All",	 "CondTag",   "CondNumber",	"CondPriority",	"CondPeril",	"CondLimit6All"
-
-
-    "1",	"1",	"QQ1; WW1",	    "1,500,000", "1",	"1",	"1",	"WW1",	"250,000"
-    "1",	"1",	"QQ1; WW1",	    "1,500,000", "2",	"2",	"2",	"WW1",	"500,000"
-
-|
-
-OED Location file:
-
-.. csv-table::
-    :widths: 12,12,15,20,15,10 
-    :header: "LocNumber",	"AccNumber",	"BuildingTIV",	"LocDedType1Building",	"LocDed1Building",	"CondTag"
-
-    "1",	"1",	"1,000,000",	"0",	"10,000",   "1"
-    "1",	"1",	"1,000,000",	"0",	"10,000",	"2"
-    "2",	"1",	"1,000,000",	"2",	"0.01",	    "1"
-    "2",	"1",	"1,000,000",	"2",	"0.01",	    "2"
-    "3",	"1",	"1,000,000",	"1",	"0.05",	    "2"
-    "4",	"1",	"2,000,000",	"0",	"15,000",	"2"
-    "5",	"1",	"2,000,000",	"0",	"10,000"
-    "6",	"1",	"2,000,000",	"2",	"0.10"
-
-The location table now has two extra rows for locations 1 and 2 to specify a second special condition applying to these locations, with two distinct values of **CondTag**. The **CondPriority** field in the account file is used to specify the order in which these special conditions apply. The method of adding an extra location row to specify an extra hierarchy of special condition means that the OED design can cope with an unlimited number of nested special conditions. Overlapping special conditions (e.g. Texas wind sublimit and multi-State tier 1 wind sublimit) can also be specified in this way. 
-
-Although not shown in the examples above, the field **CondName** can also be specified in the account table to provide a text description of each special condition.
-
-
-|
-
-**Example 5 – Policy layers**
+**Example 4 – Policy layers**
 
 The tables below show an example of a commercial portfolio with 1 account containing 6 locations and two policy layers. Each location has a coverage deductible and each policy has an underlying deductible applying across all coverage types.