Lean Specification Document
DC_I_PROC_WATERSHED_INVOICE_
APPROVAL_ROUTING_OUTBOND
|
Document Identification |
INT_iProc_001 |
|
Document Name |
DC_I_PROC_INVOICE_ APPROVAL_ROUTING_OUTBOND |
|
Project Name |
|
|
Client |
|
|
Document Author |
|
|
Document Version |
1.0 |
|
Document Status |
Draft |
|
Date Released |
|
Document Edit History
|
Version |
Date |
Additions/Modifications |
Prepared/Revised by |
|
1.0 |
|
Initial Draft |
|
|
|
|
|
|
Document Review History
|
Date |
Name |
Organization/Title |
Comments |
|
|
|
|
|
Distribution of Final Document
The
following people are designated recipients of the final version of this
document:
|
Name |
Organization/Title |
|
|
|
Sign-off of Lean Spec
Lean spec
design details and requirements have been signed off by:
|
Date |
Name |
Organization/Title |
Comments |
|
|
|
|
|
1.2 Integration
Description and Overview
2.2 Data
Selection, Population, Key Logic, Sorting and Bursting
2.6 Configuration
Prerequisites
3.1 Overview
– Technical Design
3.2 Detailed
Technical Design and Data Flow
3.6 Additional
Technical Information
1
Introduction
1.1
Purpose/Justification
This functional
specification document is intended to provide the developer all the key
information, assumptions, rules, and logic that are required to develop the
interface to update Pay Group on invoice header based on the invoice
distribution lines through ‘AP Paygroup Update’ Process
This functional
design document covers the following:
·
Process of Watershed Invoice Approval Routing
1.2
Integration
Description and Overview
|
DeKalb County has the Watershed department needs a
system that will allow them to add, update and/or remove names of employees
who have been assigned to approve iSupplier invoices. The approvals are set up by PO Number. Each Purchase Order (PO) that needs
approval can have up to ten approvers assigned to it. The system should allow for changes to the
list of approvers. Therefore, names
that have been added can also be removed as well as sequenced. two bank accounts from which payments are issued –
General Fund and Watershed. This
procedure will automate the proper recording of AP invoices to facilitate
payment of those invoices out of the appropriate bank account, without
requiring manual intervention from the user.
|
The
Watershed bank account will be used to pay supplier invoices that have all
distributions attributable to Watershed fund numbers. The Payment process uses the supplier pay
group to select invoices for payment as well as to default from which bank
account the payment is to be processed.
While pay group is specified at the supplier level, the AP Paygroup Update Process will update the pay group on
the invoices header based off of the invoice distribution lines. The procedure will update the pay group on
the invoice when all distributions associated with Watershed as defined in the
FND_LOOKUP FUND_PAY_GROUP. Additionally,
the program writes all updated invoices to a backup table and creates an output
file with all invoices that were considered during this process (unpaid
invoices with a status of validated or requires revalidation) and the outcome
of the program as it pertained to a particular invoice
The
benefits to DeKalb County by interface are:
- Auto update to Pay group on Invoice Header
from Invoice Line Distributions.
- Reduced manual intervention.
To facilitate this integration seamlessly, an outbound interface shall
be created and scheduled to run at predefined intervals.
2
Functional design
2.1
Integration
Details
|
Integration
Name |
|
|
Integration
Source |
Oracle Cloud |
|
Integration
Target |
I Procurement |
|
Delivery
or Retrieval Method |
NA |
|
Full
Extract / Changes Only |
|
|
Expected
Volume |
TBD |
|
Run
Frequency/Schedule |
TBD |
|
Distribution
List |
TBD |
|
Integration
Notifications |
Email
Notification |
|
File
Name |
TBD |
|
File
Format |
TBD |
|
PII/Confidential
Data |
NA |
|
Owning
Department |
Procurement |
2.2
Data
Selection, Population, Key Logic, Sorting and Bursting
Below is a description of requirement selection criteria for Watershed
Invoice Approval Routing process
• The system will provide a search of any open purchase order in the
system (**Note, the search results should only include watershed POs as
identified by fund/ cost center on PO distribution). A list of values will be
provided to display the existing purchase order numbers. The LOV should not consider cancelled or
finally closed Pos.
• Once a purchase order is selected, the system will allow the user to
add and delete the name of valid employees who have permission to approve
invoices/ work confirmation. No end
dated employees should appear in the list of values. Contingent workers should be available for
selection in the list of values and these contingent workers should be able to
approve transactions.
• The system will allow the user to enter the approver’s name and the
order in which to place them in the approval chain.
• Only ten people can be assigned to a PO
• A custom table stores a unique record id, the PO number, Sequence, HR
Person ID, Approver Name, Creation Date, Last Update Date, Last Updated By, and
Created By data.
• The approver records will be displayed on screen and each record will
give the option to update or remove the listed approver.
• The same approver can be added more than once to the approver sequence
• When an approver is added with a sequence, the sequence should not be
available to select when a subsequent approver is added
• When an approver is removed or re-sequenced, the sequence they were
removed from should be available to select when a subsequent approver is added
• There will be a create and remove button above the table. The user will be able to select an
approver and remove it by clicking the
Remove button.
• Currently this form is available in DeKalb IP Public Works Water and
Sewer Responsibility
2.3
Assumptions
This Interface approach is based on the following assumptions.
·
Oracle ERP Cloud will provide the data extract based on the mapping
information provided in this specification and any additional data
translation/cross-references required will be performed at Wells Fargo.
·
All the invoices entered must have appropriate pay group captured for
payment processing.
·
Payment data will be generated in the following order:
·
Process invoices in Accounts Payable
·
Execute Payment Process Request (PPR) for suppliers
·
Review and approve payments
·
Process payment
·
The payment process request will be initiated by the Payables Manager
·
Custom payment format will be created to generate payment files
·
The payment process request will have following stages:
a.
Review selected invoices for payment
b.
Build payments
c.
Format payments
d.
Confirm payments before transmitting the payment files to Wells Fargo
·
Reconciliation of Payments released from Wells Fargo with Oracle Cloud
Payables will be done outside the scope of this Interface.
2.4
Launch
Parameters
Enter job name and select the following parameters and click Submit
· Select Option
· Select VendorName
· Select Invoice Number
2.5
Data
Mapping
2.6
Configuration
Prerequisites
Following configurations that needs to be present for this interface:
·
Procurement and Financials offerings should
be enabled
·
Enterprise structure setup including Legal
Entity, Business Units should be completed
·
SCM configurations related to Procurement.
·
HCM configure all employees and contingent
worker approval list.
2.7
Error
Handling Logic
· Email notification will be sent with error details to
common group accordingly, resolve the errors and rerun the interface.
2.8
Dependencies
NA
2.9
Sample
Output/Input File
NA
2.10
Security
Considerations
TBD
3
Technical design
3.1
Overview
– Technical Design
<Explain a high-level technical
design/architecture about how this requirement will be developed in ERP Cloud.
This should cover a high-level overview of key design elements, (such as tool
used to develop integration/report (BIP, OTBI, FRS etc.), any middleware, any
component external to ERP Cloud etc.)>
3.2
Detailed
Technical Design
and Data Flow
· Explain a detailed design of how the technical object
will be developed. This should cover a detailed description of all design
elements, (such as tool used to develop integration/report( BIP, OTBI, FRS
etc., any middleware, any component external to ERP Cloud etc.), how the data
flows between them and any key technical considerations.
· Bullet points are recommended.
·
A flow/architecture diagram is recommended in case of
complex integration/report design.
3.3
Integration
Design
<Provide details related to the
integration/report>
|
Integration/Report Design |
|
|
Integration/Report Name |
<Name
of the integration/report as in ERP Cloud> |
|
Type |
Inbound N/A – (E.g. reports) |
|
Tool |
OTBI BIP FRS Inbound Tool <please specify> REST Services Others <please specify> |
|
Data Source |
ERP Cloud Custom Report <Insert Report Name> Web Service <insert WWS name or external
web service> File Inbound into Oracle <insert inbound source
and file name> |
|
Transformation |
Doc Transformation eText None <Any other – please mention> |
|
Delivery / Retrieval Service/ File
Handling |
<Mention how the output/input
file will be processed, transferred, file destinations> |
|
Output/Inbound Filename |
Name of the output file. Mention applicable file
extensions, such as .txt, .pdf etc. Mention any sequence of date/time
format needed in file name, E.g., INT01_MMDD.vv |
|
File Format |
<Mention the format of the
output file> |
|
Field Delimiter |
<Delimiter of the fields in the
file, E.g., comma, Tab, Fixed Length etc.> |
|
Compression/Encryption |
Please mention any compression
(Zip etc.) or encryption needed of the output file. |
|
Archiving Options |
Number of days saved in directory |
3.4
Sample
Output File
<Please attach a
sample interface file or sample report. Ensure to remove confidential data>
3.5
Custom/Customized
Component List
Cover components such as:
·
OTBI Subject Area
·
BIP Report Name
·
Template Name
·
Data Model Name
|
Component Name |
Component Type |
Purpose |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.6
Additional
Technical Information
·
Mention details of any technical development/tools/components
which are part of this integration/report, but not covered in previous sections
·
Examples may include, middleware details, ICS Configuration,
etc.
3.7
Error
Handling
·
Mention details of how program errors will be handled.
·
Capture details of any error report or log file needed.
·
Mention exceptions and acceptable errors based on agreed upon
assumptions.
3.8
Launch
Parameters
Mention the launch parameters of the interface/report e.g.
· Changes Only
· Default Values
·
List
of Values
4
Test Scenarios
|
Scenario |
Expected Result |
|
Validate that
only the invoices that have General Fund and Watershed bank account are
selected |
Only invoices
having General Fund and Watershed bank account are selected |
|
Validate the
Pay Group updated in Invoices is in sync with Supplier |
Pay Group
updated on the Invoices is in sync with the Supplier |
|
Validate the
date format for Invoice Date |
Date format should
be MM/DD/YYYY |
|
Validate that
Watershed bank account is used to pay Supplier invoices having all
distributions attributable to Watershed fund numbers |
Watershed
bank account is being to pay Supplier invoices having all distributions
attributable to Watershed fund numbers |
|
Validate if
the program has selected any paid invoices |
Program has
excluded Paid invoices |
5
Open Decision Items
|
Date
Reported |
Status |
Question |
Answer |
Due
Date |
Responsible
Party |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.
Comments
Post a Comment