Browse Budget Warnings - NUUPWD
The Nucleus (NU) Browse Budget Warnings (NUUPWD) page is system-populated when over-budget authorize transactions occur. This page is used to view and maintain over-budget authorize conditions stored by the system.
Mask: Mask used to get original error. (e.g., GLJEUB)
BT20 Object Name: BT20 Object Name of source. (e.g., BT20.GLATransDetail)
Unique Key: Unique Key on source record from which the over-budget transaction occurred.
Error ID: ID from error catalog.
Error Number: Number from error catalog.
Error Text: Error/warning text presented to user.
Ledger: Ledger Code on over-budget transaction.
Org Key: Org Key on over-budget transaction.
Object: Object Code or Group on over-budget transaction.
Level: Budget Level that budget authorize occurred on.
Date: Transaction date or effective date on over-budget transaction. In CCYYMMDD format.
Amount: Transaction amount on over-budget transaction. This amount is left justified and has two decimal places.
Subsystem: Subsystem that over-budget message was issued from. (e.g., GL)
Over By: The amount the transaction was over-budget by. This amount is left justified and has two decimal places.
N/A: Reserved for future use. This field should contain "N/A".
Status: The approval status of the current record. The possible statuses are:
- PENDING – The entry has not been approved or rejected.
- APPROVED – The approver has approved the entry via Workflow.
- REJECTED – The entry has been rejected by the approver via Workflow.
Created By: The BusinessPlus User ID to which the error was issued.
Create Date: The Date and Time the error was issued.
Updated By: The BusinessPlus User ID that last updated this record.
Update Date: The Date and Time this record was last updated.
Creating Workflow Instance for Over-Budget Conditions
Clients who are using 7i and Workflow can use this method of budget authorization handling. When a budget authorize error is encountered (warn/block level is "A") the following will occur:
The system will check for an existing entry in the WARN_DTL table. An entry that contains the duplicate data for the following items is considered an "already existing entry":
WARN_MASK: Mask used to get original error
WARN_BT20: BT20 object name of source
WARN_UK: Unique key of source record
WARN_ID: ID from Error Catalog
WARN_NO: NO from Error Catalog WARN_PARM01Ledger
WARN_PARM02: Org, Key
WARN_PARM03: Object/Object Group
WARN_PARM04: Level (e.g., OB, G1, G2,..G8)
If an entry does not already exist then a new WARN_DTL entry will be created with the following values.
WARN_MASK: Mask used to get original error
WARN_BT20: BT20 object name of source
WARN_UK: Unique key of source record
WARN_ID: ID from Error Catalog
WARN_NO: Number from Error Catalog
WARN_TEXT: Warning Text presented to user
WARN_PARM01: Ledger
WARN_PARM02: Org, Key
WARN_PARM03: Object/Object Group
WARN_PARM04: Level (e.g., OB, G1, G2,..G8)
WARN_PARM05: Transaction Date (YYYYMMDD)
WARN_PARM06: Transaction Amount (e.g., 99.99)
WARN_PARM07: Subsystem
WARN_PARM08: Over Budget Amount (e.g., 99.99)
WARN_PARM09: Future Use (set to N/A)
WARN_PARM10: Status (set to "PENDING")
CREATE_WHO: BusinessPlus user when error created
CREATE_WHEN: Date/Time the error was created
UPDATE_WHO: Last user ID to update this entry
UPDATE_WHEN : Date/Time of UPDATE-WHO's last action
If the entry does exist and the transaction date (WARN_PARM05) and the transaction amount (WARN_PARM06) are both equal to the current entry and the status (WARN_PARM10) is "APPROVED" then the entry is considered to be authorized. Otherwise (entry exists but has a different transaction date and/or transaction amount) - the WARN_DTL entry will be updated with the new effective date (WARN_PARM05), amount of transaction (WARN_PARM06), over budget amount (WARN_PARM08), warning text (WARN_TEXT), and status (WARM_PARM10) will be reset to "PENDING."
If the entry is authorized, all processes will treat this error as a warning. "Authorized" will appear at the end of the warning text. This tells the user that the transaction has already been approved.
If the entry is NOT authorized, 7i will still treat the error as a warning. "Unauthorized" will appear at the end of the warning text. This tells the user that this will not post unless someone gives authorization.
WARN_DTL Maintenance
When entries are deleted from 7i, the system will check for entries in WARN_DTL that match the BT20 Object and Unique Key and delete the WARN_DTL entries that qualify. APPROVED and REJECTED entries will not be cleared by the system. The system administrator should periodically delete out-of-date entries (e.g., those that have been posted or more than a year old).
Workflow Authorization
The status (WARN_PARM10) field in the WARN_DTL indicates the state of the entry. There are three possible statuses:
- PENDING – The entry has not been approved or rejected. The entry should be sent to someone for approval.
- APPROVED – The entry has been approved. This status should only be set by Workflow.
- REJECTED – The entry has been rejected. This status should only be set by Workflow.
A workflow model should be created to handle these states.
Activation Note: At least one entry must be in the WARN-DTL table to cause the system to check for approvals from Workflow. To create this first entry, an unauthorized over-budget condition must be encountered on a 7i data entry page.