PO Approvals (including RSS)

Introduction

Scope

The purpose of this document is to detail the Cantara queries and functions of the Purchase Order Entry (POE) and Requisition Self-Service (RSS) modules. These modules are included in the Rinami Purchase Order Approvals mobile application.

Note

This document does not currently include details of the Cantara objects used to retrieve and update JDE Media Objects.

Background

The underlying structure for the main POE and RSS transaction tables is similar, in that both modules have a header and detail table, but there are material differences in the columns contained in each of the related tables. For example, the PO Detail table (F4311) contains 228 columns whilst the RSS Detail table (F43E11) only contains 64 columns.

From a functional perspective each module allows a user to enter an order/requisition by entering header information and then individual line information such as item number, quantities etc. Based on approval configuration that has been setup, the order (and its individual lines) can then be auto-approved or set to a pending status whilst waiting approval from an approved authority.

One of the primary differences between a standard PO order and an RSS order is that PO orders are entered against a single supplier whereas an RSS order does not have a supplier on the header and each order line can be fulfilled by one or more suppliers.

Another major difference between the two types of orders is the underlying approvals engine that is used. Standard PO orders retrieve approvals information from JDE Order Holds table (F4209) whilst RSS orders utilize the JD Edwards workflow engine and employee, employee group or commodity-based approvals hierarchies with approvals thresholds, escalation, and delegation functionality. The differences here are substantial, however the Cantara services have been written to try and remove much of that complexity.

Major JDE Tables

Purchase Order Entry (POE) – Cantara Objects

The objects created in Cantara for standard Purchase Order approvals make up part of the Rinami Logistics module, and as such, are named with the LOG_ prefix.

There are two Cantara queries and a single Cantara function that are used to retrieve orders awaiting approval and perform approve or reject operations on those orders at an Order Header level ONLY.

Queries

LOG_GetOrdersAwaitingApproval

Description

The GetOrdersAwaitingApproval query is based on the JDE V4309C Business View which is a join between the PO Order Header (F4301) and Held Orders (F4209) tables.

The query will return a list of orders awaiting approval for a specific approver and list of Order Types (eg. OP, OR) and will be the first query that the mobile app will use to fetch approvals data for standard purchase orders.

Input

Output

JSON payload containing Order Header details (KCOO, DOCO, DCTO & SFXO) for orders awaiting approval for the requested Approver.

LOG_GetOrderLines

Description

The GetOrderLines query is based on the JDE F4311 Order Details table.

The query will return details for each order line for the order details matching the filter values passed. The filter contains the order key (KCOO/DOCO/DCTO) as well as a Next Status value so that only lines below the specified Next Status are returned.

The Next Status column in the PO Detail line is used to keep track of where each order line is as it moves through the system from initial entry to PO receiving and vouchering.

Input

Output

JSON payload containing Order Detail line information for the passed in order. Only lines that meet the NextStatus filter criteria value, range or list will be returned.

Functions

LOG_ApproveRejectOrder

Description

The ApproveRejectOrder function is based on the JDE Q35ApproveRejectOrder Named Event Rule (NER) business function in JDE. This NER is a custom Rinami JDE object.

If the order has been approved and additional approval is required based on configured approval limit hierarchies, a new approvals record will be written to the Order Holds table (F4209). If no further approvals are required, the order lines on the order will be moved to the Next Status as specified in the JDE Order Activity Rules for the order type being processed.

If the order is rejected, the order lines will have their Next Status moved to the status specified in the JDE processing options for version specified in the P43081 version passed in the request payload.

Input

Output

JSON payload containing details of the parameters passed in the request payload as well as details of any errors returned by the function after being processed by JD Edwards.

Requisition Self-Service (RSS) – Cantara Objects

The objects that have been created in Cantara for Requisition Self-Service are relatively new and are expected to be included in the Rinami Logistics module. For the moment, the Cantara service definitions have been prefaced with LOG_.

There is a single query and four functions that are used to retrieve orders awaiting approval and perform approve or reject operations on those orders at an Order Header or Order line level depending on how RSS in JD Edwards has been configured.

Queries

LOG_GetOrdersAwaitingApproval

Description

The GetOrdersAwaitingApproval query is based on the JDE V98860D Business View which is a join between the JDE Process Instance (F98860), Task Instance (F98865) and Task Assignment (F98866) tables. These are the key primary tables for the JDE workflow engine.

The query returns a list of workflow instances for the requested approver and from this information we can extract details of the RSS order lines awaiting approval.

The order header or line information pertaining to a particular workflow instance is contained in the OrderKey (ISTKEY) attribute in the response payload. It will be in one of two formats:

The segments for the OrderKey (ISTKEY) attribute are as follows:

The OrderKey attribute is the single attribute required to be passed to either the RSS_Q35GetRSSReqHeader or LOG_GetRSSReqLine Cantara function to retrieve order header or line details. For details of these functions, refer to LOG_CheckRSSApprovals and LOG_GetRSSReqHeader.

Input

The approver address book number (AN8) will need to be passed in the request payload in the following attributes:

Output

JSON payload containing workflow instances awaiting approval for the requested approver. The task assignment (WFTaskInstanceID) required for approval or rejection of this workflow task will also be returned in the response payload. This value should be stored as it will be required if/when the user attempts to approve or reject the RSS line.

{
    "name": "LOG_GetOrdersAwaitingApproval",    
    "Message": {        
        "type": 0,        
        "value": "Transaction Successful",        
        "sessionId": "",        
        "cantaraSid": "c166a12c-95bf-4f01-88a6-42bdd92562af",        
        "aisToken": "",        
        "origin": "fb1b1a00842e"        
    },    
    "id": "72fdf84c-d2a5-49c3-a86d-4c99396ba6c9",    
    "debug": null,    
    "Query": {        
        "handle": "",        
        "size": 3,        
        "startIndex": 1,        
        "endIndex": 3,        
        "xmlList": false,        
        "QueryRow": [            
            {                
                "Parameter": [                    
                    {                        
                        "name": "WFProcessID",                        
                        "value": "K43E08"                        
                    },                    
                    {                        
                        "name": "WFTaskInstanceID",                        
                        "value": "J5F5066000239-00003208-00000051-00000000000000000000FFFF0A23013A"                        
                    },                    
                    {                        
                        "name": "OrderKey",                        
                        "value": "|1076|OR|00200|000|1.000|"                        
                    },                    
                    {                        
                        "name": "OriginatorAN8",                        
                        "value": "61161"                        
                    },                    
                    {                        
                        "name": "ApproverAN8",                        
                        "value": "2026"                       
                    },                  
                    {                      
                        "name": "WFTaskStartDateTime",                        
                        "value": "2020-09-03T03:41:52Z"                        
                    }                    
                ]                
            }            
        ]        
    }    
}

Functions

LOG_CheckRSSApprovals

Description

The CheckRSSApprovals function is based on the JDE Q35CheckRSSApprovals NER function in JDE. This NER is a custom Rinami JDE object.

The function will return a count of RSS workflow instances requiring approval for the approver ID passed in the request payload. Tasks awaiting approval could be either at a header or a line level

Input

Output

JSON payload containing the number of workflow tasks requiring approval for the requested Approver.

{   
    "name": "LOG_CheckRSSApprovals",    
    "Message": {        
        "type": 0,        
        "value": "Transaction Successful",        
        "sessionId": "3116.1599186308.3501",        
        "cantaraSid": "c166a12c-95bf-4f01-88a6-42bdd92562af",        
        "aisToken": "",        
        "origin": "fb1b1a00842e"        
    },    
    "id": "e3efa46b-925a-4dfd-8806-373274a74195",    
    "debug": null,    
    "Parameter": [        
        {            
            "name": "RSSTaskCount_PORC",            
            "value": "3"            
        }        
    ],    
    "JdeError": []    
}

LOG_GetRSSReqHeader

Description

The GetRSSReqHeader function is based on the JDE Q35GetRSSReqHeader NER function in JDE. This NER is a custom Rinami JDE object.

The function will return the attributes for the RSS header requested from the F43E01 table in JD Edwards.

Input

For the structure of the OrderKey (ISTKEY) parameter, refer to LOG_GetOrdersAwaitingApproval.
For this function, the last segment of the ISTKEY attribute should be zero. This indicates that we are referencing the order header and not individual detail lines.

Output

JSON payload containing details of the requested RSS Order header.

LOG_GetRSSReqLine

Description

The GetRSSReqLine function is based on the JDE Q35GetRSSReqLine NER function in JDE. This NER is a custom Rinami JDE object.

The function will return the attributes for the RSS line requested from the F43E11 table in JD Edwards.

Input

For the structure of the OrderKey (ISTKEY) parameter, refer to LOG_GetOrdersAwaitingApproval.
For this function, the last segment of the ISTKEY attribute should contain the line number being requested.

Output

JSON payload containing details of the requested RSS Order line.

LOG_ApproveOrRejectRSSReq

Description

The ApproveOrRejectRSSReq function is based on the JDE Q35ApproveOrRejectRSSReq Named Event Rule (NER) business function in JDE. This NER is a custom Rinami JDE object.

If the order has been approved and additional approval is required based on configured approval limit hierarchies, a new approvals record will be written to the JDE workflow tables and the appropriate notifications will be sent to responsible persons. If no further approvals are required, the order lines on the order will be moved to the Next Status as specified in the JDE Order Activity Rules for the order type being processed.

If the order is rejected, the order lines will have their Next Status moved to the status specified in the JDE processing options for the order type being processed.

Input

Output

JSON payload containing details of the parameters passed in the request payload as well as details of any errors returned by the function after being processed by JD Edwards.