October20 Release notes

Dynamic Planning: Group Access API

The Group Access API can be used to update Group Access permission when the number of groups exceeds the UI limit of 20 groups.

POST: /api/modeling/model//groupAccess/update HTTP/1/1

Content-Type: application/json or application/xml

Accept: application/json or application/xml

X-ACCESS-TOKEN: $ACCESS_TOKEN_GUID$

Request Payload

Request payload can include only a subset of the current permissions. Permissions included into request payload will be updated; those not included will keep their current values.

Request Payload JSON

{
 "permissions”:  [
                            {"groupName": "Alpha",
                            "artifactType": "Model",
                            "artifactName": "Test Model",
                            "modelName": "", "access": "Yes"},
 
                             {"groupName": "Beta",
                             "artifactType": "View",
                             "artifactName": "Test View",
                             "modelName": "Test Model",
                             "access": "Yes"},
 
                             {"groupName": "Gamma",
                             "artifactType": "Report",
                             "artifactName": "Test Report",
                             "modelName": "", "access": "No"}
                  ]
}

Request Payload XML Sample

<payload>
     <permissions>
         <permission>
             <group-name>Alpha</group-name>
             <artifact-type>Model</artifact-type>
             <artifact-name>Test Model</artifact-name>
             <model-name></model-name>
             <access>Yes</access>
         </permission>
         <permission>
             <group-name>Beta</group-name>
             <artifact-type>View</artifact-type>
             <artifact-name>Test View</artifact-name>
             <model-name>Test Model</model-name>
             <access>Yes</access>
         </permission>
         <permission>
             <group-name>Gamma</group-name>
             <artifact-type>Report</artifact-type>
             <artifact-name>Test Report</artifact-name>
             <model-name></model-name>
             <access>No</access>
         </permission>
     </permissions>
</payload>

Parameters

1. $groupName (group-name) -Name of the group. Group name should be a valid name and case insensitive.

2. $artifactType (artifact-type) –Artifact type should be one of the following:

   • Model

   • Calculation

   • View

   • Report

3. $artifactName (artifact-name) - Name of the artifact.

4. $modelName (model-name) -Model name must be a valid name for Calculation and View. It will be ignored for all other artifacts.

5. Access - Access should be one of the following:

   • Yes

   • No

Response Payload

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <payload>
                    <permissions>
                <permission>
             <group-name>Alpha</group-name>
             <artifact-type>Model</artifact-type>
             <artifact-name>Revenue</artifact-name>
                <model-name></model-name>
             <access>Yes</access>
                </permission>
                <permission>
             <group-name>Beta</group-name>
             <artifact-type>Report</artifact-type>
             <artifact-name>Sample Model Report</artifact-name>
             <model-name>Sample_Model</model-name>
             <access>Yes</access>
                </permission>
                <permission>
             <group-name>Gamma</group-name>
             <artifact-type>View</artifact-type>
             <artifact-name>template</artifact-name>
             <model-name>Revenue</model-name>
             <access>Yes</access>
                </permission>
                    </permissions>
</payload>

Dynamic Planning: Additional Text Functions

Middle

This function returns the characters from the middle of a text string, given a starting position and length.

Syntax: MID(text, start_num, num_chars)

For example, let’s say you want characters from the middle of a text string given a starting position and length, and you have created a model for it as shown in the following image.

This Text function will return the characters based on the given length and position of the text as shown in the following image.

Proper

Syntax: PROPER(text)

This function converts a text string to proper case; the first letter in each word to uppercase, and all other letters to lowercase.

For example, let’s say you want to convert the text fields to a proper case and you have created a model for it as shown in the following image.

This Text function will convert all the text fields to proper case as shown in the following image.

Platform: Introduced Transactions V2 for Data Load Rule

With this release, Transactions Data Version 2 has been introduced to the data load process.

Business Value

Transaction Data Version 2 provides fast and more efficient processing of the Data Load Rule. The Transaction Data Load Rule process is not changed only the processing speed has been increased with this release.

A Transaction Data V2 has been introduced to the Load Sub Item drop-down list. You can select the Transaction Data V2 option from the Load Sub Item drop-down list on the New Data Load Rule page.

Clear Data check box for Attribute in the Define Overall Rule Settings Page

With this release, the Include in Clear Data column has been introduced in the Define Overall Rule Settings page. This functionality provides a more granular ability to clear data.

The Clear all data prior to the new data load checkbox has been removed with this release. The check box is now available against Attributes in the Include in Clear Data column.

The image below displays the Include in Clear Data column.

Prior to this release, the Clear all data prior to the new data load check box was used to clear all data at once so incremental data load was not possible.

Now, you have the ability to clear data at the Attribute level and load data incrementally. Additionally, this functionality allows you to load Transaction from multiple ledger systems.

The sub-ledgers Transactions are recorded separately using attributes as unique keys such as Journal ID, Transactions Reference, and so on. This functionality provides the ability to merge Transactions based on Attributes which helps to avoid duplicate records being loaded into the system.