WELLS FARGO UPLOAD PROCESS

1. WELLS FARGO UPLOAD PROCESS Session: 101890

2. Wells Fargo & Company • Wells Fargo & Company (NYSE: WFC) Wells Fargo & Company is a diversified financial services company providing banking, insurance, investments, mortgage, and consumer and commercial finance through more than 9,000 stores and more than 12,000 ATMs and the Internet (wellsfargo.com) across North America and internationally serving over 70 million customers. • We employ over 280,000 team members in more than 35 countries across our 80+ businesses • Current population consists of • 265,000 full-time employees • 16,000 part-time employees • 1300 flexible employees

3. PeopleSoft Installations • Operate on a DB2 platform • Initially installed PeopleSoft version 2.0 in 1993 (HR/Payroll/Benefits) • Multiple upgrades to 4.5, 6.0, 7.5, and 8.3 throughout the years • Installed home grown version of Manager Self-Service (Staff Management) in 2003 • 3rd party Time & Attendance System (Time Tracker) • Installed Benefits Administration in 2002 • Installed Automated Terminations Processing in 2006 • Upgraded to PS version 8.9 in 2007 Future Plans • Upgrade to version 9.2 projected go live May 2014

4. Issue • Many different types of Payroll uploads • HR wanted new upload created for repetitive JOB tasks (i.e. Leave processing) • Current approach cumbersome, specialized for each upload • Better auditing support • Speed of implementing upload

5. Use Excel to CI • Why not? • Cumbersome for the technologically challenged user • Audit/Security issues with login since we don’t maintain passwords in PS • Having another id with a password violated Wells Fargo security standards • Auditability issues

6. Solution • Build a custom uploads process • Make it reusable • Include audit capabilities • Make it configurable • Include data validation • Decouple the upload using messaging and CI’s to insert the data • Decrease time required to create a new upload • Solution allowed us to create a new W2C upload and move it to Production in 2 weeks • Allow the business to upload using an Excel spreadsheet

7. Upload Process Flow

8. Excel Upload Requirements • Audit required no changes be made to the Excel file in order to upload • PS Excel read needs MS Office installed on the app servers. Security plan at Wells didn’t allow this. • Instead we used the MS Access engine Excel API’s to convert the file to .csv using a custom .NET app, then the .csv is loaded to the staging table • The original Excel file is retained in an attachment field for the request • The process will have code to edit the Excel data as it’s loaded to the staging table • This allows corrections to be made before the data is loaded to the system by deleting the upload, correcting the Excel file and reloading • The Excel file should be specific for the upload, only fields pertaining to the current upload should be on the file

9. Online Pages – File Layout • Create File Layouts that store configuration information about the upload • Identify the Staging record • Identify the Pre-Edit App Class used for editing the data as it’s loaded • Identify the Load App Class used to process the system load • List fields being uploaded. Only fields used on spreadsheet • Allows creation of Excel template for the Business to use

10. Online Pages - Upload Request page • Stores the upload request information • View Layout is where the Excel template for the business can be downloaded • Displays staging table record count and the number of records in each status • If errors are encountered in the edits on the spreadsheet upload it can be deleted, the spreadsheet corrected, and re-uploaded

11. Staging Table Page • Each Staging Table page is specific for the upload • Displays fields dynamically based on file layout • This allows multiple uploads to use the same staging record • Page doesn’t need to be updated if a field is added to the upload • Data is edited during the system upload • Errors are stored in a common table and accessed through the Error link

12. Staging Tbl Page – Upload Complete • Displays audit information • Tracks when the upload was created and when it was last updated • No changes allowed after the upload is complete

13. Staging Table Setup • Staging records contains 2 standard sub records • Upload Keys SBR • Audit and Status SBR • The staging record can be shared with multiple uploads • the file layouts determine which specific fields are used for the upload

14. App Package PeopleCode • Shared code is stored in an App Package • Uploads_Utilities is a class used by all the uploads • Contains load utilities like the system load code for messaging and record edits (field type, length, etc) used during load • Each upload area also has it’s own class for code specific to that particular upload • There are a set of standard Methods needed that the upload uses • These can be coded for a group of uploads and use different private methods for specific uploads

15. Upload Edits • Each upload group can have it’s own edits • If specific code is needed for an upload the file layout can determine which upload is being run • Errors are loaded to a common error record that all uploads share

16. Load App Engine • A shared App Engine is used to submit the upload request for processing • Uses the information on the File Layout page • Creates the edit and load App Class • Sets the staging record • Gets the rows in the staging table using SQL.Fetch • Executes the load with the Edit_and_Load method that creates a message (asynchronous approach)

17. Using a Message to load data • This is called from the Edit_and_Load method in the specific upload Class • Copy data from the staging record into the message record • Create and publish an asynchronous message for each row of data

18. Message Code • OnNotify Message PeopleCode is generic and used by all uploads • Uses the File Layout setup to identify the staging record and App Classes • Uses the Process_DB_Load method that is in the upload class

19. Load PeopleCode • Called from the OnNotify method of the message • The load PeopleCode is specific to each upload area to allow specific processing • Execute the Edits again to make sure the data is still valid • We do this to save processing time. It’s quicker to edit outside the CI than during the CI • Calls the CI to upload the data into the system • Insert any errors into the common error record

20. Message for CI load • The message can be specific for each upload or a more generic one for a common component • The message executes the CI that loads the data into the system

21. Upload Process Flow

22. Wrap Up • Code modules kept small • Allows greater flexibility on what standard code you can use and what you want to replace with code specific for the upload • Messaging allows processing to be controlled • CI enforces online edits • The Staging table is a group of uploads with some commonality • The file layouts are the specific upload fields • This allows multiple uploads to use the same staging table (we have 3 separate Job uploads sharing a staging table) • Each upload spreadsheet can then contain only the fields necessary for that upload

23. Upload Statistics • Implemented first upload using the new process late April 2012 since then: • 789 Upload Requests that loaded • 53,863 Position rows uploaded • 2,011 Benefit rows uploaded • 7,600 Garnishment rows uploaded • 15,134 Job rows uploaded • 8,004 Officer Codes uploaded • 8,163 Tax Overrides uploaded • 22,031 W2C’s uploaded

24. Contacts • Matthew.Stukel@wellsfargo.com • (612) 667-6836 • Wayne.Fuller@wellsfargo.com • (612) 667-4668 Please complete your evaluation: Session 101890 Thank you!

25. Upcoming Wells Fargo Sessions

26. Save the Date APRIL 7-11, 2014 Sands Expo and Convention Center Las Vegas, Nevada QuestDirect.org/COLLABORATE COLLABORATE 14- Quest Forum is THE source for PeopleSoft roadmaps & news. It matters where you register! All PeopleSoft education and events run through Quest