Enhanced Email Approvals (EEA)
Enhanced Email Approvals (EEA) provides transaction approvers with new HTML emails that contain links to approve or disapprove directly from the email. This opt in feature saves approvers time by allowing them to avoid logging into the application and approving unless they desire more information or other reasons for a detailed approval. The new emails also contain links to let the approvers easily navigate to the application and log in as well.
Configuration
Enhanced Email Approvals is a feature that clients may chose to use or not. To enable the feature an administrator must log into the application and navigate to the Configuration tab. Once there they will find a new Company Preference titled “Enable Enhanced Approval Emails”. They simply check the box and Save the Company Preferences and the feature is then enabled and emails for approvers moving forward will contain the new functionality.
Approving/Disapproving
Now with the feature enabled the following approval types will generate the new approval emails for requisitions, packing lists and invoices:
- SAF Approvals
- UBA Approvals
- Category Approvals
- Delegate Approvals
Once the approver receives the email they simply click with Approve or Disapprove and then a browser page will open confirming their action and that it was completed successfully or not. Since a disapproval requires comments from the approver we do insert an automatically generated comment for them which says either “Approved via Email” or “Rejected via Email” depending on their action.
The above is an example for a requisition approval. The email is identical for other transaction approvals with the exception of some text differences. Once an approval action is chosen they are presented with this page.
The links are of course one time use and once used they expire. If an expired link is clicked they will be routed to a web page that shows the below.
Purchase Order Imports
We have added some new functionality to the POI feature. There are now three new columns available in PO imports:
- Allocation Details Section
- Department Name
- Department ID
- Order Section
- User Email
These columns will help expand the flexibility of the feature by allowing clients that import to segregate and identify data more effectively.
Previously a client would use the Shipt To ID or Bill TO ID to allocate line items to multiple departments. However we realized this was somewhat of a shortcoming in that clients may want to have those values be distinctly different than how the line is actually allocated. The new Department Name and Department ID allow clients to allocate independently of the Ship to or Bill to departments.
Similarly clients would identify the user that a PO should be attributed to by using the Ship To name previously. Again we recognized a need that a PO could belong to a user that is not the user it was being shipped to. Now clients may handle that scenario as we will use the User Email in the Order section to determine what user a PO belongs to. Also using email, which is a forced unique value in the application, fairs better than using names as those can be the same between two or more users possibly.
We also made a slight adjustment to the logic about how a user is assigned a PO. We first look in the file for the User Email column, and if it is found and the user is valid that user is then used. If the user is invalid then we error out and send a notification. If no User Email field is found in the file we then make use of the Default User set up in the Company Preferences for POI.
Email Change
We made a small change to the emails received when a PO is generated. Previously the emails read:
We had some client complaints that this language was misleading as there is action required as someone must place the PO to send it to the vendor, either emailing, faxing, printing or punching out for example. In light of that we have removed the last sentence from these emails.
Bug Fix Notes
Issue |
Description |
CAP-3660 | CustomExportBuilder.aspx : Debit-Credit Field Not Aggregating Correctly in File Header/Footer Sections |
An issue was found where Debit-Credit fields added to export templates were not aggregating their totals correctly depending on the level they were added at. This is now corrected and Debit-Credit fields may be used on all levels and display the proper totals. |
CAP-3635 | POI: Mapping Builder: Should change 'Bill-To department name' to 'Bill-To Name' in error message |
There was a column text name that was missed in the move from the term Business Unit to Department in the Customize PO page. This has been corrected. |
CAP-3612 | Missing Unassigned Invoice Queue for CreditMemo |
An issue was found where credit memos when added to the Unassigned Invoice Queue would not display like a standard invoice does. This has been corrected and now both transaction types display the same. |
CAP-3608 | Unable to process ACH Invoice due to Daily Limit |
An issue was found where deprecated daily limits were being triggered erroneously during the accounting review of ACH invoices. This has been corrected and invoices are no longer being held up in accounting review. |
CAP-3588 | CentralOrdering.aspx : Ext and US Ext amounts are Doubling on Page |
An issue was found that for users that are multiple types of approver, say both SAF and a category approver, we would duplicate, triplicate amounts in the Generate PO page. This was display only, and has been corrected now. |
CAP-3409 | CEB - Incorrect DateFormat for txt format |
A client request concerning the difference in how we format stored dates (Due Date, Posting Date, Invoice Date) between file types in the Custom Export Builder. These have now been corrected and unified across file types to M/DD/YYYY. |
CAP-3285 | CEB - Unable to export custom dimension in concatenated field |
An issue was found where you could not concatenate Custom Dimensions. They would just not appear if you did so in a Customer Export builder template. This has been corrected. |
CAP-2014 | Transactions/inbox/detail: 'Uncaught SyntaxError' on Accounting Review rejection |
Various invoices were getting stuck upon accounting review on the accounting review page and not loading the check request page correctly. While the invoices were being processed in the background correctly the page would not change. This has been corrected. |
QA/Automation Notes
CAP-3720 | QA Automation: Add department code |
CAP-3716 | QA Write test cases: Enhanced Approval Emails - Requisition and Invoice |
CAP-3700 | QA Automation: Fix POI tests - Department name or number is required now and breaking tests |
CAP-3696 | QA: Write test cases for Central Ordering, Category Approver |
CAP-3687 | QA Automation: Invoice Approval Reject - verify the rejected invoice is back to invoice page under disapproval |
CAP-3682 | QA Automation: Update the test - QA API User, Category endpoint: PUT/POST request should return the valid UserID, CategoryID |
CAP-3675 | update pipeline version |
CAP-3670 | QA: Write Test cases for Debit-Credit Field |
CAP-3669 | QA: Write test cases for CAP-3588 US Ext Amounts are doubling on page |
CAP-3668 | QA: Write Test cases For Credit Memo invoice bug CAP-3612 |
CAP-3666 | QA Automation: Credit Memo invoice - CAP-3612 |
CAP-3657 | View Transactions page : Add data-qa |
CAP-3655 | QA API: Create Department: Set each department with unique department id |
CAP-3652 | QA Automation: Fix message verification for test_finalize_requisition_page_cdim_when_project_is_required |
CAP-3651 | QA Automation: Fix test_invoice_attach_files |
CAP-3644 | POI: PO Import Settings: Utilize Default User |
CAP-3642 | EE : Language/Text Changes |
CAP-3640 | EE : PO PDFs - Add Pdf lib |
CAP-3628 | QA Automation: Troubleshoot/Fix screenshots on Azure Pipeline |
CAP-3592 | QA Automation: Update the due date required test to sort the invoices by Date Created. |
CAP-3517 | QA Automation: POI: Allocation Percentage |
CAP-3514 | QA Automation: Import PO and confirm it in report |
CAP-3486 | QA Automation: Turn on POI feature via API |
CAP-3485 | QA API: User/Category/GLAccount endpoint - Include UserID, CategoryID, GLAccountID to Response Body |