|
Attaching Supporting Documentation to Journals |
|
|
Monday, 18 December 2006 |
One of the Sarbanes Oxley impacts I’ve seen on the enterprise accounting side is how supporting documentation for journal entries must be saved and retained for many years. If done the old fashioned way of printing paper and filing it, this could go beyond simply killing trees and bring about deforestation on a global scale. I’m sure I saw something about this in Al Gore’s video.
My current client is a private company, but they’re considering going public and so they’re implementing PeopleSoft with SOX in mind. One of the things they wanted to know up front is whether or not they could attach supporting documentation electronically to the journal entries and thereby avoid having to manage so much paper.
Using PeopleSoft’s Attachment Server functionality, I was able to get a proof of concept up and running without too much effort. Here’s the screen shot:
From the user’s point of view, they navigate to the Enter/Update Journal Entries. Then they click on this Supporting Documentation tab where they can view existing documentation or add new files to the journal.
The Add button takes them to a page that lets them browse their computer for a file, and upload it to the web site. If you’ve ever used a web-based e-mail client and attached a file you get the idea.
Once the file is uploaded it is saved in the PeopleSoft database and associated to the Journal using the Business Unit and Journal ID keys. The user can enter a description of the file, and the Operator ID and date/time stamp is saved with the journal.
We also added business logic to keep users from adding or changing attachments after the journal has been posted. This may have to be relaxed to some extent to meet the realities of a closing cycle.
Okay, that’s enough boring business functional stuff. Let’s get technical!
If you’ve never used the attachment server, here’s what you need to know in bullet form:
- It can be set up to store attachments in a directory or in the database. In my opinion, the database method is better.
- What little bit is required to set up the attachment server is under Set Up Financials /Supply Chain > Common Definitions > File Attachments > Administer File Attachments. If you’re not using FSCM you’ll find it in a similar place in your application.
- It’s documented in different places in PeopleBooks, but a good place to start is PeopleBooks > PeopleCode Developers Guide > Understanding File Attachments and PeopleCode.
- If you’d like to see a delivered example, check out the LOAD_JRNL_PNL component (General Ledger > Journals > Import Journals > External Flat Files). If you don’t have PS Financials, you’ll have to find your own example.
- The PeopleCode built-in file attachment functions are AddAttachment, DeleteAttachment, and ViewAttachment. You’ll probably use the wrapper functions on the FILE_ATTACH_WRK record instead of calling them directly.
The steps I went through to create this proof of concept were:
- Created a new record to hold attachments called XX_JRNL_ATTACH. It had the following fields:
- BUSINESS_UNIT – Key Field for Journal
- JOURNAL_ID – Key Field for Journal
- ATTACHSYSFILENAME – Key Field. Unique System Identifier for the attached file. Making it a key field insures uniqueness.
- ATTACHUSERFILE – The name of the file from the user’s hard drive.
- DESCR – Allows the users to enter a description of the attachment so they don’t have to view it to see what it is.
- And of course the audit fields CREATED_BY_USER, CREATED_DTTM, LAST_UPDATED_BY and LAST_UPDATE_DTTM to track who modified something and when.
- Created the page to enter attachments on. BU and Journal ID were on level zero, AttachUserFile, Descr, and anything else related to the attachments were in the scroll area in Level 1.
- Inserted my custom page in the JOURNAL_ENTRY_IE component.
- Then I activated the necessary Component PeopleCode. I basically copied the releveant component PeopleCode from the LOAD_JRNL_PNL to the JOURNAL_ENTRY_IE component. You’ll find it under the FILE_ATTACH_WRK record in both components, and you’ll need to copy PeopleCode for all three fields ATTACHADD, ATTACHDELETE and ATTACHVIEW.
- I put some RowInit PeopleCode on the XX_JRNL_ATTACH record to logically gray out the Add or View buttons depending on whether or not a file was on the row. You can see an example of this at LOAD_JRNL_REQ.OPRID.RowInit.
- I also added RowDelete PeopleCode to call the DeleteAttachment function when a row is deleted. Then I made the decision to not include the DeleteAttachment button since a user could just as easily delete and re-add the row.
- Of course there is a little PeopleCode to correctly update the audit fields, but I’ll bet you don’t need my help with that piece.
That’s it in a nutshell. I certainly welcome your comments, questions and suggestions.
Comments () |
 |
|
|
|
 |
|
Last Updated ( Monday, 18 December 2006 )
|
| " " | MsgGetText(5825, 104, "Processing file...", &DataFileName));