Creating Decision Models for Fees

This topic describes the requirement of creating a decision model after creating fee items and before creating a fee schedule. You use OCI Process Automation to create decision models.

Prerequisites

Before you create a decision model, you need to create any required fee items that will be associated with the decision model.

For more information on fee items, see Setting Up Fee Items.

Configuring Decision Models

You can set up inputs and decisions any way you like following the guidelines provided in the documentation for OCI Process Automation. For more information on using OCI Process Automation to create decision models, see Model Decisions..

The configuration discussed here for output data types is required for setting up the interaction between the decision model and the fee schedule in Oracle Permitting and Licensing.

To configure decision models:

1. Create a fees list of values (LOV) with the fee item names.

   Currently, there is no direct integration of configuration data, such as fee items, between OCI Process Automation and Oracle Permitting and Licensing. Although creating an LOV is optional, any fee item names added to a decision model output need to be entered exactly as they appear in Oracle Permitting and Licensing. When you use the LOV and enter values in a decision output. OCI Process Automation validates the entry and displays a warning if your entry does not match an item in the LOV.

   This example illustrates the list of values used to validate fee items entered in the Decision Table. Select list of values in the Constraint options when you’re adding the data type definition.

   

   Note: If the field type in the application intake form is a Check box set or a Multi-select list and the field will be used to drive fee calculations, then the fee model input should be configured as a list type. As in, select the is List? check box when defining the decision model input data.

2. (Required) Set up the complex data type output to include these attributes: FeeItem and FeeAmount.

   The FeeItem attribute should use the fees LOV that you created. The FeeAmount attribute uses numbers that you enter on the decision model.

   Note: This step is important because the FeeItem and FeeAmount attributes are used to map the fee items on the fee schedule to the decision model.

   This example illustrates the complex data type output that you set up for your decision model. You must define FeeItem and FeeAmount attributes.

   

3. (Required) Add the output data type name to every decision and use allowed values in the Decision Table grid.

   To edit a decision, click the decision menu button and select Edit.

   Select the defined output type from the Output Type list.

   This example illustrates the output data type name Fees added to the Residential_Alteration decision. The output type provides constraints on which values are allowed in the decision model.

   

   This is an example of the final decision values based on the output type.

   The decision output type in the Residential_Alteration decision is Fees. The validation ran on the Fees values entered in the Decision Table, and no errors were returned.

   

4. (Required) You must also configure the services in the Services panel to the left of the decisions, and activate the model.

   For more details, see Exposing Decisions as Services.

When the Oracle Permitting and Licensing service submits a request to OCI Process Automation, after running the request against the decision model, the application returns the fee item name and the fee item amount.

After you have set up your decision model, you need to reference the decision model from the appropriate fee schedule. For more information on fee schedules, see Setting Up Fee Schedules.

Configuring Late or Recurring Fees for Code Enforcement

If the mapping source on a fee schedule line is set to either Code Enforcement Violation Fees or Code Enforcement Overdue Fees, you need to associate the fees generated by the decision model to a reference transaction, like an existing fee item. For an existing fee, you can link additional late fees to the existing fee through the associated reference transaction. When either of these mapping sources are selected, an additional field, Map Fee Reference, will appear, where you an select ReferenceID, for example.

The decision model will also need input and output attributes for ReferenceID field. The following example illustrates how you can use the ReferenceID in your calculations.

Operation	DMN Code
if	Violation.Days Overdue >= 7
then	{FeeItem: "CE_RECR_FINE", FeeAmount: floor(Violation.Days Overdue / 7) * Violation.Rate * CheckPct(PenaltyPct), ReferenceID:Violation.ReferenceID}
else	FeeItem: "N/A", FeeAmount: 0, ReferenceID:Violation.ReferenceID}

Configuring GIS-Based Fees

You can define fee calculation criteria using spatial data coming from the Map Layer Content field group in your intake forms. For example, agency staff can define in a decision model that a district improvement fee is required if the project location falls within a specific district.

To incorporate GIS attributes into your fee decision models, you need to:

• Include these field groups in your intake form:

  • Property or Business Location

  • Map Layer Content

• Create a DMN model that includes GIS-related inputs configured as a "list," which can accept multiple input values.

• Map the attributes to intake form fields as usual within the Intake Form Designer.