Release Notes 7.030.0

The following updates have been made to the Application / Cancel / Transfer / Acreage Reporting Form - Apiculture (API) and Pasture, Rangeland, Forage (API / PRF Combo Form) for all years:

NOTE: If the grower wants to have different Productivity Factors and County Base Value per Acre by Practice, they will need to indicate that they have an IRR coverage and NIRR coverage so the different values will apply.

NOTE: It was found that the Insurable Acres / US Colonies printing in the SOI Crop Summary Section were incorrect. TFS #84771 (in a future release) will ensure that the correct Insurable Acres / US Colonies for PRF or API coverages are printing in the SOI Crop Summary Section.

RMA released the 2019 Document and Supplemental Standards Handbook (DSSH) and one of the updates to the DSSH was an update to the Non-Discrimination Statement (NDS) for forms which is also shared with the RMA Statements hyperlink found in the footer of the System. The NDS on forms and on the RMA Statements hyperlink has been updated with the 2019 DSSH Form NDS for all Crop Years.

SCO: Previously, not all coverages that had the SCO option elected were printing on the SCO Supplement Page / Section when it had been selected to print with the MPCI Application or the Policy Change Form. The SCO Supplement Page / Section was updated to print all coverages that have elected the SCO option when the SCO Supplement Page / Section is selected to print with the MPCI Application and Policy Change Form. These changes apply to all Crop Years.

Perennials: With this ticket, the new PAW format was incorporated on the Perennial Combo Form. The following changes were made to this form for the 2018+ Reinsurance Years (RYs):

eSign: It was discovered during regression testing that if a Grower or Authorized Signer's Name ended with a period, a bug prevented that name from being displayed as an available Signer in the Print Forms eSign Select Signee section. For example, a grower name of "Mike Farmer." would not display as a Signee option. This has been corrected so that a name value ending in a period will still be displayed within the eSign Select Signee section.

eSign: The following issues have been resolved with this ticket:

A 2019 ADM update was made by the RMA and has been implemented in the System. The following tables have been updated for 2019:

An ICE 2014 update was made by the RMA and has been implemented in the System. The following table has been updated for 2014:

An ICE 2015 update was made by the RMA and has been implemented in the System. The following table has been updated for 2015:

An ICE 2019 update was made by the RMA and has been implemented in the System. The following tables have been updated for 2019:

An ICE 2017 update was made by the RMA and has been implemented in the System. The following table has been updated for 2017:

An ICE 2016 update was made by the RMA and has been implemented in the System. The following table has been updated for 2016:

An ICE 2018 update was made by the RMA and has been implemented in the System. The following tables have been updated for 2018:

A 2019 ADM update was made by the RMA and has been implemented in the System. The following table has been updated for 2019:

An ICE 2014 update was made by the RMA and has been implemented in the System. The following table has been updated for 2014:

An ICE 2015 update was made by the RMA and has been implemented in the System. The following table has been updated for 2015:

An ICE 2016 update was made by the RMA and has been implemented in the System. The following table has been updated for 2016:

An ICE 2017 update was made by the RMA and has been implemented in the System. The following table has been updated for 2017:

An ICE 2018 update was made by the RMA and has been implemented in the System. The following table has been updated for 2018:

PTY: Previous functionality for Personal T-Yields (PTY) required the user to select to create the PTY Summary Units from the Additional Functions dropdown on the Detail Lines tab. Once the Summary Units had been created, if updates were required to any underlying APHs, the user had to delete the PTY Summary Units, make the changes to the underlying APHs, and then recreate the PTY Summary Units. A request was received to provide functionality to allow users to update underlying APHs without first having to delete the PTY Summary Units. Then, once updates are made to the underlying APHs, the user will need the ability to recalculate the PTY Summary Units.

The following changes have been implemented within the scope of this ticket:

PTY/MY: When a user selects to create PTY Summary Units or Master Yield (MY) Summary Units, the System displays a message on the page that the PTY/MY is being created from and then refreshes the Detail Lines tab to display the new PTY/MY Summary Units. An issue was reported where, when multiple coverages existed on the policy, if the user created PTY/MY Summary Units on one coverage, then when the Detail Lines tab refreshed, the System was displaying another coverage from the policy rather than the coverage for which the user was actually creating the PTY/MY. The logic that creates PTY/MY Summary Units has been updated so that after the Detail Lines tab refreshes, the System will remain on the coverage for which the user selected to create the PTY/MY Summary Unit(s).

Margin Protection: Beginning in the 2019 RY, RMA has updated the Margin Protection policy to state the base coverage cannot have SCO. System functionality that allows users to associate a Margin Protection coverage with a base MPCI coverage has been updated to no longer allow a base coverage with SCO elected to be associated with a Margin Protection coverage. To account for this change, the following System updates have been implemented:

Perennials: An issue was found with the PAW's Setout Date and Grafting Date where the System was allowing future dates (dates past the current System date) to be entered and saved. Logic has been updated to not allow Setout Dates and Grafting Dates greater than the current System date.

WFRP: Beginning in the 2019 Reinsurance Year, RMA is adding a new field to the AgrRate table for WfrpCommodityCode. This code differs from the existing AgrCommodityCode and will be used to consolidate like commodities for the purposes of the Total Commodity, Qualifying Revenue Threshold, and Qualifying Commodity Count calculations. For example, Irrigated Cotton has an AgrCommodityCode of 1003 and Non-Irrigated Cotton has an AgrCommodityCode of 1004; however, both have a WfrpCommodityCode of 002100. Previously, using the AgrCommodityCode, RMA would have considered Irrigated and Non-Irrigated Cotton as two unique commodities. While the AgrCommodityCode will continue to be used to determine the rates for each individual commodity, the WfrpCommodityCode will now be used to determine the unique commodities on a policy; therefore, Irrigated and Non-Irrigated Cotton will now be considered one crop since they are both Cotton and share the same WfrpCommodityCode.

In order to account for these changes, System logic that currently uses the AgrCommodityCode to determine unique commodities was updated to instead use the WfrpCommodityCode. The System calculations affected by these changes are the Total Commodities, Qualifying Revenue Threshold, and Qualifying Commodity Count calculations. All other rating logic will continue to use the AgrCommodityCode values.

Fast Edit CLU: When the Fast Edit CLU page displays, the FSN/Tract banners (banner bars) display with the FSN + Tract + Legal Description, but the banners were not sorting in ascending order. There is a navigation option that exists to allow the user to select from an ascending list of FSN/Tracts to expand only a single FSN/Tract for focused user entry. However, if a user chooses not to use this navigation tool (the Land ID dropdown at the top of the Fast Edit CLU page), they must scroll to find the FSN/Tract desired. With this ticket, the Fast Edit CLU page now sorts in ascending order by FSN + Tract.

APH: An AIP reported they were having a difficult time processing the "J" temporary yield. Once a "J" Yield Type was entered, the APH database was going from 10 to 5 crop years and a message was received stating the "J" Yield Type is only allowed in the most recent year of database. Changes were made to the temporary yield APH override logic in the System, and this Yield Type is now working correctly.

Exception: If you need to process an APH with the temporary yield procedure, complete the process in the legacy APH. During internal testing, a few bugs were found in the APH Drawer within the Fast Edit PR page when triggering the temporary yield functionality. TFS #94002 was set up to address this scenario.

Coverage by Practice: During internal testing, a display issue was identified with the Irrigated and Non-Irrigated Coverage Level dropdowns when the Coverage Levels by Practice option was elected. When the user selects Coverage Levels by Practice, the System displays two fields to select the Coverage Level, one for Irrigated and another for Non-Irrigated. These fields previously displayed on the same line. The display issue identified occurred when the selected Crop was "Grapes" and Coverage Levels by Practice was selected. Rather than the Irrigated and Non-Irrigated Coverage Level dropdowns displaying on the same line, the Non-Irrigated dropdown element was wrapping to the next line while the Irrigated dropdown and the Irrigated and Non-Irrigated labels remained on another line. The display of the Irrigated and Non-Irrigated Coverage Levels has been updated to a stacked display with the Irrigated Coverage Level dropdown element and label displaying on one line and the Non-Irrigated Coverage Level dropdown element and label displaying on the next.

A change was made for Replant Option policies for the Schedule of Insurance and Confirmation of Coverage form so the Practice will print as "All" since, when setting up a Replant Option policy, the user does not select an practice.

MPowerD: As part of the MPowerD calculation, the Expected Revenue was trying to pull the MPowerD price from a Price Custom field in the sales record. This was the incorrect field, which caused an invalid value to calculate on MPowerD claims. The System has been updated to have the MPowerD Price calculated from comparing the winning interval against the MPCI Project Price + Max Price Movement. This MPowerD Max Price will now be used in the Expected Revenue calculation as part of the overall MPowerD calculation. This value will also be displayed in the claims header section.