Top Banner
HopkinsOne BP FI GL Blueprint Version 0 1/10/2005 at 11:02 AM Page 1 of 28 Security Restrictions if Necessary 9.4 GENERAL LEDGER ACCOUNT 9.4.1 Overview Various subledgers and other modules in the integrated SAP environment update the General Ledger (GL) module. The GL area is responsible for the master data objects: Business Area, Chart of Accounts, transaction data: journal entry types, accruals, open item managed accounts, foreign currency transactions and other key processes such as month end and year end closing, fiscal year carryforward and interface reconciliation. The General Ledger Blueprint Design includes all facets of recording, classifying and managing financial transactions within SAP. A series of focused Design Sessions were conducted in the following areas: § Business Area – To define those enterprise organizational entities that require business area functionality and determine a logical schema for numbering. § Chart of Accounts – To define the listing of General Ledger accounts that the enterprise will require to record business transactions and determine a logical schema for numbering. § Journal Entries – To discuss the various ways financial transactions will be posted in SAP and identify document types necessary to classify those transactions. § Open Item Management – To discuss the strategy for managing open items within SAP. § Foreign Currency – To discuss SAP functionality within the scope of the HopkinsOne project. § Fiscal Year and Posting Periods – To define the posting periods within the enterprise fiscal year and discuss the use of SAP’s special posting periods to facilitate GL closing. § General Ledger Closing – To discuss the sequence of events that are required to close the General Ledger within SAP. 9.4.2 Detailed Functional Scope See Business Process Master List in appendix C for detailed functional scope. 9.4.3 Business Requirements See Requirements in appendix D for detailed requirements. 9.4.4 Questions & Answers See appendix H for Questions and Answers 9.4.5 Leading Practices The following leading practices were discussed as part of the overall Business Blueprint. Listed below are the leading practices that have been incorporated into the design. 9.4.5a Incorporation of Leading Practices Description Adoption Consolidate and maintain one Chart of Accounts. Yes Use a standardized, intelligent numbering scheme to classify accounts. Yes Maintenance of the Chart of Accounts is centralized to ensure integrity of the intelligent numbering scheme and account strategy. Yes The account code numbering scheme consists of the lowest level of detail necessary to meet the various reporting Yes
28
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 1 of 28 Security Restrictions if Necessary

9.4 GENERAL LEDGER ACCOUNT 9.4.1 Overview Various sub­ledgers and other modules in the integrated SAP environment update the General Ledger (GL) module. The GL area is responsible for the master data objects: Business Area, Chart of Accounts, transaction data: journal entry types, accruals, open item managed accounts, foreign currency transactions and other key processes such as month end and year end closing, fiscal year carry­forward and interface reconciliation.

The General Ledger Blueprint Design includes all facets of recording, classifying and managing financial transactions within SAP. A series of focused Design Sessions were conducted in the following areas:

§ Business Area – To define those enterprise organizational entities that require business area functionality and determine a logical schema for numbering.

§ Chart of Accounts – To define the listing of General Ledger accounts that the enterprise will require to record business transactions and determine a logical schema for numbering.

§ Journal Entries – To discuss the various ways financial transactions will be posted in SAP and identify document types necessary to classify those transactions.

§ Open Item Management – To discuss the strategy for managing open items within SAP.

§ Foreign Currency – To discuss SAP functionality within the scope of the HopkinsOne project.

§ Fiscal Year and Posting Periods – To define the posting periods within the enterprise fiscal year and discuss the use of SAP’s special posting periods to facilitate GL closing.

§ General Ledger Closing – To discuss the sequence of events that are required to close the General Ledger within SAP.

9.4.2 Detailed Functional Scope See Business Process Master List in appendix C for detailed functional scope.

9.4.3 Business Requirements See Requirements in appendix D for detailed requirements.

9.4.4 Questions & Answers See appendix H for Questions and Answers

9.4.5 Leading Practices The following leading practices were discussed as part of the overall Business Blueprint. Listed below are the leading practices that have been incorporated into the design.

9.4.5a Incorporation of Leading Practices Description Adoption

Consolidate and maintain one Chart of Accounts. Yes

Use a standardized, intelligent numbering scheme to classify accounts. Yes

Maintenance of the Chart of Accounts is centralized to ensure integrity of the intelligent numbering scheme and account strategy.

Yes

The account code numbering scheme consists of the lowest level of detail necessary to meet the various reporting Yes

Page 2: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 2 of 28 Security Restrictions if Necessary

Description Adoption requirements of an organization.

Only “complete” (debit=credit) documents can be posted. SAP will not allow posting of unbalanced documents in the general ledger.

Yes

Minimize the use of suspense accounts to auto­balance entries. Yes

Auto­create inter­company accounts receivable and payable. Yes

Perform monthly and annual close Yes

Develop and communicate comprehensive monthly and annual closing schedules Yes

Establish a pre­close meeting early in the closing cycle to discuss any unusual results with management and auditors

Yes

Establish monthly cutoffs to facilitate timely monthly closings Yes

Closing should be centrally controlled and managed to ensure that all steps are completed timely and in sequence Yes

Practice year­end closing steps well in advance of year­end with production data in a testing environment Yes

Closing schedule includes the closing of all modules and the closing should be controlled by Finance Yes

All adjusting entries should be posted in the ERP system Yes

System should allow extended periods for adjusting entries to be posted. Yes

All ledgers and sub­ledgers should be updated real time simultaneously to eliminate reconciliation issues. Yes

Transactions should be entered at the lowest level necessary to meet enterprise reporting requirements. Yes

Transactions should be entered at the point of origin within the enterprise. Yes

9.4.6 “To­Be” Design (Sub­Process) The following sub­processes are discussed further in this section:

§ Chart of Accounts

§ Journal Entries

§ Open Item Management

§ Fiscal Year and Posting Periods

§ General Ledger Closing

§ Foreign Currency

§ General Ledger Security

9.4.6.1 Sub­process 1 ­ Chart of Accounts 9.4.6.1.1 Overview General Ledger (GL) accounts are the structures that classify debit and credit values for accounting transactions in the SAP Financials (FI) module and form the basis for creating financial statements and fulfilling other regulatory reporting requirements.

In order to properly use the FI functionality, GL accounts must represent types of financial postings (assets, liabilities, equity, revenues, expenses and transfers) and are created at the lowest possible level to capture financial information, both for internal and external reconciliation, analysis and reporting. The data posted in various GL accounts can be grouped together using GL reporting groups for higher level reporting within the SAP Special Ledger (SL) module.

Page 3: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 3 of 28 Security Restrictions if Necessary

The GL accounts created for Johns Hopkins will be categorized by recommended best business practices and result from feedback obtained from GL Master Data Design Sessions. Each of the GL accounts will be assigned to a GL Account Group. GL Account Groups will help determine the number range for GL accounts, categorize the accounts within logical categories, provide security for management of GL accounts and determine suppress, display, optional and required fields within each GL account master data screens. The numbers for GL accounts will be sequentially assigned by the system within the parameters and pre­defined ranges controlled by the GL Account Group. The field length for GL account is 10 characters. The recommended configuration of the GL account master records for Johns Hopkins is 6 numeric digits as represented in the table below

9.4.6.1.1a Configuration of General Ledger Accounts General Ledger Account Number Ranges Number attributes

Assets: 100000 – 199999 Liabilities: 200000 – 299999 Equity: 300000 – 399999 Revenues: 400000 – 499999 Fund Balance/Net Asset Transfers: 500000 – 599999 Expenses: 600000 – 699999 Unassigned: 700000 – 799999 Conversion Items:800000 – 899999 Secondary Cost Elements 1 : 900000 – 999999

Secondary Cost Elements are created and maintained in the CO module. This listing represents the reservation of the number range for that purpose.

• Six (6) digit numeric only externally generated logical numbering

• Number ranges (first digit) defined for major financial statement categories

• Additional digits (second, third,) are defined for further breakdowns within major financial statement categories where appropriate.

The standard data requirements to establish a GL account in SAP are as follows:

9.4.6.1.1b Standard Settings for Master Data Date Fields Comments

General Ledger Account Number XXXXXX digit number

Company Code Company Code JHEN defaulted

Account Group Classify GL accounts into categories for authorization and number range controls.

P&L or Balance Sheet Account Defines if the GL account is a P&L or Balance Sheet account.

GL Account Short Text Description of GL account useful to identify the account using matchcode, lookup or search.

GL Account Long Text Detailed description of GL account

Account Currency Account Currency USD will default from Company Code

Field Status Group* Helps identify types of fields that are required on documents in SAP when posting using the GL account.

Commitment Item Commitment Items classify the budget according to functional criteria.

*Field Status Group suppresses, displays, and requires entry or makes entry optional based on GL accounts.

Page 4: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 4 of 28 Security Restrictions if Necessary

9.4.6.1.2 Process Flow The maintenance of the Chart of Accounts will be a centralized function. The following process flow depicts GL account creation.

Figure 9.4­1 GL Account Creation

New GL Account is requested.

GL Account request is reviewed.

GL Account is approved?

GL Account Master is created.

SL Configuration is updated.

Derivation rules are updated.

GL Reporting Groups are

updated in SL.

Requestor is notified.

Requestor is notified. No

Yes

Account Assignment is updated for all relevant SAP modules.

Create and link Commitment Items and Cost Elements.

Page 5: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 5 of 28 Security Restrictions if Necessary

9.4.6.1.3 Inputs and Outputs 9.4.6.1.3a Inputs and Outputs

Input to the Process Output to the Process Request for new GL account Newly created GL account

GL account GL account validation file (3 rd party systems)

Derivation rules

Cost Elements for P&L account

Commitment items

9.4.6.1.4 Other Considerations There are no other considerations noted for Chart of Accounts.

9.4.6.2 Sub­process 2 ­ Journal Entries 9.4.6.2.1 Overview The Journal Entry process within the General Ledger includes transactions posted that are not originated in an SAP sub­ledger (A/P, A/R), to record audit adjustments, adjustment postings to correct previously posted transactions, reversal of documents and certain recurring transactions and interface postings. SAP creates a document for each transaction posted in the system. Unique transaction codes are maintained in the system to process journal entry and accruals. Following are some data attributes that will be required to process a journal entry in SAP system.

§ GL Account (Required)

§ Commitment item (Derived from GL account)

§ Business Area (Derived from CO object or entered manually)

§ Fund (May be derived for JHHS)

§ Functional Area (Derived)

§ Cost Center/ Internal Order/ WBS Element (Optional depending on type of GL account processed. i.e. P&L)

§ Fund Center (Derived from cost center)

§ Grants (Derived from CO object)

§ Funded Program (Derived from WBS element)

§ Network from CO object or defaulted)

Document Types Document types differentiate business transactions and control document sorting. Key uses of document types within SAP include:

§ A number range for documents is specified based on each document type. One number range can be used for several document types. Document types are defined within each SAP module for the entire enterprise (company code level).

Page 6: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 6 of 28 Security Restrictions if Necessary

§ Document type can be assigned to an authorization group. Thus, JH can use document types to control the security on postings.

§ Document types assist in reporting.

The following document types are currently identified specific to the General Ledger:

9.4.6.2.1a General Ledger Document Types SAP Doc Types Description of Business Accounting

Events Document Number Range

SA Journal Entry Document Type 1000000000­1099999999

ZF Foreign Currency Journal Entry Document Type 1000000000­1099999999

AB Reversal Entry Document Type 1700000000­1799999999

AI Accrual Posting Document Type 1000000000­1099999999

ZH Interface Document Type for JHHS 1000000000­1099999999

ZU Interface Documents Type for JHU 1000000000­1099999999

In addition to the General Ledger specific document types, document types will be defined for the following areas within FI:

§ Accounts receivable

§ Accounts payable

§ Asset accounting

§ Consolidation

§ Materials Management and Sales and Distribution for: Goods receipt and issue, Incoming and outgoing invoices

§ Invoicing

§ Travel Management

§ HR/ Payroll

Document Reversals If a document has to be reversed, the document can be reversed through automated SAP reversal transactions and a new document can be entered. SAP never deletes a document from the system. A document can be reversed only if the following conditions are met:

§ Contains no cleared items

§ Contains only vendor, customer, or G/L line items

§ Was posted within the FI system

§ Values, such as business areas, cost centers, and fund are still valid within SAP master data environment

The reversal of accrual documents (documents entered this month and reversed next month) will be processed with a SAP reversal transaction code.

When a document is reversed, the user will have to provide a reason code for the reversal for reporting and audit purposes. There are standard reason codes provided in SAP. Enterprise­wide reversal codes

Page 7: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 7 of 28 Security Restrictions if Necessary

will be established if required in configuration. When a new SAP reversal document is generated, the user can drill down to the original document from the reversal document. Document date, posting date, user information and system data entry date will be maintained as an audit trail. Within General Ledger document reversal functionality will be used on as needed basis.

GL Transaction Posting Help Multiple techniques and mechanisms exist within SAP to facilitate the posting process, simplifying data entry for the user. Some of the techniques discussed during the sessions are noted below.

Match Codes SAP provides users with help to identify field values through the match code search screen. Matching criteria details differ by field attribute. The user can also search within match code field utilizing wild cards. For example while searching in a 610xxx series GL account, a user can type 610* in the search field and the system will return a list containing all 610xxx series of account numbers.

Park and Hold Document The user can use preliminary postings to enter and store incomplete documents in the system. Preliminary postings do not update any data in the system, such as amounts. The two types of preliminary postings are:

§ Parked Document

§ Hold Document

Parked documents provide the user with the ability to create a posting document, save it to facilitate additional processes such as manager approval prior to posting. Parked documents can be posted either individually or via a list. When posting several parked documents via a list, the system issues a list that details each parked document’s disposition, detailing a reason if the document could not be posted. Should a parked document reject upon posting, the list can be used to facilitate correction. A batch input (SAP’s ability to process multiple documents simultaneously.) session can be created from the list to subsequently post the parked documents. Parked documents data is stored in a separate table from standard posting data. When a parked document is actually posted, the data from the parked document is deleted from the parked documents database. The document data is then written to the standard documents posting database; and the appropriate data is updated. Parked documents can be selected for reporting purposes and their status should be evaluated as part of the monthly close process.

Hold documents are user defined and managed. They are intended to be temporary in nature offering the user the ability to save incomplete documents when necessary. Workflow functionality can not be configured for hold documents. Hold documents can only be displayed and posted by the user that created them. Hold documents should be cleared as part of the monthly close process.

Recurring Documents (also known as Recurring Entries) Recurring entries are business transactions that are repeated regularly, such as rent or insurance expenses. The following data never changes in recurring documents in SAP:

§ Posting Keys

§ GL Accounts

§ Line Item Amounts

When created, the Recurring Document itself does not post the accounting entry contained within it. The Recurring Posting Program uses the Recurring Document as the basis for creating the actual Accounting

Page 8: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 8 of 28 Security Restrictions if Necessary

Document via batch processing. The Recurring Document specifies exactly when the system should process a posting using the data contained in it. The validity period (date range) must be defined.

The three steps necessary to generate a recurring posting are:

§ Create a Recurring Document. Enter the data necessary for posting the Accounting Document such as the posting keys, account numbers and amounts. Enter the control information that sets the posting frequency or run schedule.

§ Run the Recurring Posting Program at the required times. The system will determine which Recurring Documents are to be processed during each run period. The system will create a batch input session that contains data required posting the Accounting Documents and data needed to update the scheduling information in the Recurring Documents including the next run date, number of runs processed so far and, if necessary, a deletion indicator.

§ Process the batch input session. The batch input session will post the Accounting Documents (the accounting entry is actually made) and update the scheduling information in the Recurring Documents.

Sample Documents A Sample Document is a model document that can be copied into a new SAP posting; it is like a template that is stored in the system. In the Document Entry screen, a user can select a Sample Document that will automatically populate applicable fields. Once a Sample Document has been created and saved, only the amounts can be changed. Line Items cannot be added into the sample document itself. To accommodate new line items, a new Sample Document would have to be created that contains all of the desired Line Items; however, line items can be added to a FI document that is referencing a sample document.

When posting a document, only one Sample Document can be used at a time. Its Document Number in the Document Entry Screen accesses it by utilizing the Post with reference function. Sample documents have a separate number range. When you create a sample document, the system stores the document but does not update any transaction figures.

Account Assignment Model An Account Assignment Model is a pattern for document entry. It can contain any number of line items and may include posted amounts. The Account Assignment Model is more flexible than Recurring Documents or Sample Documents since it permits the user to add more line items and to change all the pre­assigned fields. The Account Assignment Model allows the user to enter items in list form using screen templates that are user­defined. Account Assignment Model will be primarily used for proprietary entries. Some of the complex assignments that have many lines will be set up as account assignment.

The posting in the Account Assignment Model does not need to be complete. For example, in the document lines, the accounts may be pre­assigned in the model, but the cost center and amount fields are left blank. These fields are filled when the model is actually used. The only mandatory field on the header of an Account Assignment Model is the Name that is given by the user. Optional fields in the Account Assignment Model include Currency, Chart of Accounts, Sample Text, Authorization and Equivalence Number Option. With the Account Assignment Model, multiple field assignments can be posted at one time. However, before a model can be created, a screen template must be defined. The screen template (variant) is where the user identifies the desired fields for the line layout.

At the time of posting, combination of multiple Account Assignment Modes can be copied within one document to add the same lines over and over again to create one SAP document posting. Other

Page 9: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 9 of 28 Security Restrictions if Necessary

Account Assignment Models can be used during the same posting and more lines can be added manually.

Document Reversals If a user has entered an incorrect document, the document can be reversed through automated SAP reversal transactions and a new document can be entered. The reversal of accrual documents (documents entered this month and reversed next month) will be processed with a SAP reversal transaction code. When a new SAP reversal document is generated, the user can drill down to the original document from the reversal document. Document date, posting date, user information and system data entry date will be maintained as an audit trail. Within General Ledger document reversal functionality will be used on as needed basis. A graphical representation of this flow is presented below.

9.4.6.2.2 Process Flow The Journal Entry process within the General Ledger includes transactions posted that are not originated in an SAP sub­ledger (A/P, A/R), to record audit adjustments, adjustment postings to correct previously posted transactions, reversal of documents and certain recurring transactions and interface postings. SAP creates a document for each transaction posted in the system. Unique transaction codes are maintained in the system to process journal entry and accruals. A Process flow has been defined for journal entry posting, which will include original postings, adjustment entries, accruals, internal postings from other SAP modules and external interface postings from third party systems. A graphical representation of this flow is presented below.

Figure 9.4­2 GL Journal Entry

Recording Journal Entry On­ Line In SAP Adjustment entries Accruals etc.

CO DOCUMENT P&L Postings

Crosswalk

Transaction FB50 Journal Entry Document

Recorded In SAP Modules Impacted and

Documents Created by GL Posting in SAP

Inbound Interface Posting Journal Entry in SAP FI­GL Module BAI file bank recon entry Patient Accounting System Interface etc.

FM DOCUMENT Funds Update

Special Ledger Document Split Grant,

Business Area, Fund

GRANT DOCUMENT ­If Applicable

Spreadsheet Upload (CATT)

Real Time Update

Page 10: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 10 of 28 Security Restrictions if Necessary

9.4.6.2.3 Inputs and Outputs 9.4.6.2.3a Inputs and Outputs

Input to the Process Output to the Process SAP R/3 General Ledger JHHS Keane Account Validation File (SAP Account string

validation)

SAP R/3 General Ledger JHBMC Meditech Account Validation File

IDX Account Validation File

JHHCG Horizon Account Validation File

JHBMC CARE Account Validation File

JHU ISIS Account Validation File

JHU ECSI Account Validation File

JHHC OAO Account Validation File

9.4.6.2.4 Other Considerations There are no other considerations noted for journal entries.

9.4.6.3 Sub­process 3 ­ Open Item Management 9.4.6.3.1 Overview A GL account is considered Open Item Managed when an original debit or credit posting is expecting to be cleared by an offsetting matching credit or debit posting. Standard SAP transactions will be used to process and analyze open item managed accounts. Examples of accounts where this functionality is employed are the Goods Receipt/ Invoice Received (GR/IR) clearing account related to purchasing and accounts payable, bank clearing accounts and tax accounts.

SAP General Ledger Master Data includes an indicator that identifies all of the General Ledger accounts that are open item managed. A Sort Key is also identified. The sort key facilitates the input of certain attributes in those transactions that the GL account is associated with. The attribute is entered in the Assignment Field within the transaction line item. The attribute varies depending on the nature of the open item management activity that is associated with the GL account. For example, the GR/IR account attribute would be P.O. number while the bank clearing account attribute would be the check number. When the GR/IR Open Item Management clearing transaction is executed, the sort key and amount fields are matched on the goods receipt and the invoice receipt and the item is cleared and no longer open in this account. It is important to note that cleared items are not deleted. Following are the three open item managed accounts identified in the Blueprint Phase.

§ GR/IR Reconciliation Account 299xxx

§ Bank Reconciliation Clearing Accounts 1xxxx4 (all the G/L accounts will be mapped 1:1 to individual bank accounts in realization.)

§ Tax Accounts 4xxxxx (all the G/L accounts will be mapped 1:1 to individual tax accounts in realization.)

When an open item report is generated for analysis, only open items are selected and cleared items are not displayed.

Page 11: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 11 of 28 Security Restrictions if Necessary

9.4.6.3.2 Process Flow Figure 9.4­3 GL Open Item Management

Identify Open Item Managed GL Account Numbers In SAP, for example: 1) GR/IR Reconciliation Account 2) Bank Reconciliation Clearing Accounts (Per Bank Account) 3) Tax Accounts

Transaction F­03 Execute Auto Clearing Program To Clear Dr and Cr

Items On Open Item Managed Accounts

Treatment of items that do not reconcile

Output 1) Line Items That Match and Clear (Based on criteria like Check Number and Amount for Bank Clearing, PO Number and Amount for GR/IR clearing account etc) 2) Report On Dr and Cr Line Items That Do Not Reconcile

For example: Items for Purchasing department to analyze (for GR/IR Account) Items for Cash Management/ Bank Custodians (for Bank Accounts)

9.4.6.3.3 Inputs and Outputs 9.4.6.3.3a Inputs and Outputs

Input to the Process Output to the Process Postings to open managed accounts Debit or Credit balance in open managed accounts

Clearing program execution to manage open item accounts Matching Debit and Credit cleared (not deleted) from the GL account line items (Cleared items are marked with flag cleared and do not display in open item listing.)

9.4.6.3.4 Other Considerations There are no other considerations noted for open item management.

9.4.6.4 Sub­process 4 ­ Fiscal Years & Posting Periods 9.4.6.4.1 Overview In order to post transactions in SAP R/3, it is necessary to define the Fiscal Year and the Posting Periods that will comprise the fiscal year. Fiscal year may correspond to calendar year if necessary. The fiscal year is typically made up of twelve posting periods although it could be less than twelve periods under special circumstances (shortened fiscal year). In addition to the twelve posting periods that make up the fiscal year, SAP allows the definition of up to four special periods (Currently planned to be used) that are used to facilitate year end processing. HopkinsOne will have a single fiscal year that will start on July 1

Page 12: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 12 of 28 Security Restrictions if Necessary

and end on June 30. In addition, HopkinsOne will have twelve posting periods that correspond to the twelve calendar months and four special periods. These definitions will be saved in a Fiscal Year Variant that will be assigned to the JHEN company code. (Note: A variant is a pre­defined set of parameters or selection criteria that is saved for future use.)

9.4.6.4.1a Fiscal Year Variant

Posting Period Calendar Month Period Dates 01 July July 1 – July 31

02 August August 1 – August 31

03 September September 1 – September 30

04 October October 1 – October 31

05 November November 1 – November 30

06 December December 1 – December 31

07 January January 1 – January 31

08 February February 1 – February 28 or 29

09 March March 1 – March 31

10 April April 1 – April 30

11 May May 1 – May 31

12 June June 1 – June 30

13 Special Period June 1 – June 30

14 Special Period June 1 – June 30

15 Special Period June 1 – June 30

16 Special Period June 1 – June 30

Each posting period will have a starting and ending date. Based on the posting date that is required on every SAP transaction, the system will automatically determine the posting period. The special periods allow transactions to be posted subsequent to the end of the fiscal year but reflect posting dates within that year. Transactions entered during all special periods must have a posting date that falls within the last regular posting period. Typically, only one posting period is open and available to end users for posting at a time although SAP does not limit the number of periods that can be open at one time.

SAP R/3 Funds Management (FM), Controlling (CO) and Materials Management (MM) modules also utilize posting period functionality independent of Financial Accounting (FI). In order to assure the integration between modules the opening and closing of posting periods will be centrally managed and controlled. Posting transactions in both regular posting periods and special periods is controlled through the definition of Posting Period Variants. The posting period variants are linked to Authorization Groups to determine the types of accounts that users have permission to post transactions. Authorization groups are used by SAP to organize user roles and security to facilitate granting user access to specific functions within the system. Posting Period Variants must be defined separately for FI, FM, CO and MM. The following table represents several FI Posting Period Variants.

9.4.6.4.1b FI Posting Period Variants

Posting Period Variant GL Account Type Authorization Group M Material To Be Determined

Page 13: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 13 of 28 Security Restrictions if Necessary

Posting Period Variant GL Account Type Authorization Group A Asset To Be Determined

C Cash To Be Determined

K Liability To Be Determined

D Revenue To Be Determined

S Expense To Be Determined

+ All GL Accounts Closing Specialist Group

9.4.6.4.2 Process Flow Figure 9.4­4 Fiscal Years and Posting Periods

Company Code Fiscal Year Variant

Regular Posting Periods (12) July to June Special Periods (4) All posted in June

Posting Period Variant

GL Account Types

9.4.6.4.3 Inputs and Outputs No inputs/outputs exist.

9.4.6.4.4 Other Considerations No other considerations noted for Fiscal Year and Posting Periods.

9.4.6.5 Sub­process 5 ­ General Ledger Closing 9.4.6.5.1 Overview HopkinsOne has proposed a common closing procedure and closing calendar to be used throughout the enterprise. The closing processes are defined separately for month end and year end.

Month End Close The month end close process starts on the last working day of the current period and will continue for several days into the subsequent period. The process will be managed by allowing the current period to remain open while also opening the subsequent period to allow the posting of relevant transactions to the new period. Transaction postings in any period can be limited to certain account types and users in order to assure postings are made to the appropriate period. The calendar of events related to the close will be determined during realization at which time the security related to posting transactions will also be defined. A summary of the steps required for closing has been developed and is presented in the table below. The summary will be further refined and the closing steps and processes developed during realization.

Page 14: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 14 of 28 Security Restrictions if Necessary

9.4.6.5.2a Monthly Close Summary

No. Closing Activity 1 Post Payroll

2 Execute Depreciation

3 Execute Recurring Entries/Postings

4 Execute Parked and Held Documents

5 Clear Workflow Backlog

6 Upload Bank BAI Files

7 Maintain GR/IR Account

8 Post Accruals

9 Execute CO Allocations

10 Execute FI/CO Reconciliation Ledger

11 Extract data to BW (SEM­BCS for consolidations)

12 Execute month end reports

13 Execute Technical SAP closing steps and programs

14 Close Posting Period

15 Period Management: Open New Period

Year End Close Fiscal year end closing will follow the month end close process closely but will include several additional processes. The year­end close will also utilize the special periods that will eliminate the requirement to keep the last regular posting period open. Using the Posting Period Variants and Authorization Groups in conjunction with the special periods, the closing processes and activities can be further segregated and organized in a way that is not available for month end processing. For example, routine closing processes such as the final payroll posting, recurring entries, and accrual entries could be assigned to period 13 while allocations could be assigned to period 14 and audit and other adjustments could be assigned to period 15. Period 16 would be reserved for running the technical year­end close processes which close out the year and prepare the carry­forward of balances to the new fiscal year.

9.4.6.5.3a Special Periods

SAP Posting Period Posting Date Comments 12 June 1 – June 30 Perform all pre­closing steps (on or before June 30)

13 June 1 – June 30 Perform routine closing steps (after June 30)

14 June 1 – June 30 Execute allocations (after June 30)

15 June 1 – June 30 Final adjustments and corrections (e.g. audit) (after June 30)

16 June 1 – June 30 Year End Close program (after June 30)

00 July 1 – July 01 Balances carried forward and system ready for posting in new fiscal year (01)

Page 15: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 15 of 28 Security Restrictions if Necessary

The table below represents a summary of the year­end closing activities for HopkinsOne. The summary will be further refined and the closing calendar, detailed closing steps and detailed processes developed during realization.

9.4.6.5.3b Year End Close Summary

No. Closing Activity 1 Post Payroll

2 Execute Depreciation

3 Execute Recurring Entries/Postings

4 Execute Parked and Held Documents

5 Clear Workflow Backlog

6 Execute Interface Documents

7 Upload Bank BAI Files

8 Maintain GR/IR Account

9 Post Accruals

10 Execute Allocations

11 Execute FI/CO Reconciliation Ledger

12 Open Period 13

13 Execute and Analyze Reports

14 Close Regular Posting Period

15 Open Period 1 in New Fiscal Year

16 Period 13

17 Process interfaces not available for processing in the regular posting period

18 Process accruals and adjustments not available for processing in the regular posting period

19 Extract data to BW

20 Open Period 14

21 Close Period 13

22 Period 14

23 Execute allocations (if needed)

24 Execute FI/CO Reconciliation Ledger (if needed)

25 Extract data to BW

26 Open Period 15

27 Close Period 14

28 Period 15

29 Post final adjustments (if any)

30 Execute allocations (if needed)

31 Execute FI/CO Reconciliation Ledger (if needed)

32 Extract data to BW (consolidations in SEM­BCS)

Page 16: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 16 of 28 Security Restrictions if Necessary

No. Closing Activity 33 Open Period 16

34 Close Period 15

35 Period 16

36 Execute Final Closing Programs

37 Execute Archiving Programs

38 Close Period 16

39 Open New Period In next Fiscal Year

40 Extract data to BW (final consolidations in SEM­BCS)

41 Execute Year End Reports

In addition to activities and processes related to the external audit of the financial statements of the various HopkinsOne legal entities and affiliates, the year end close processing includes a series of steps designed to prepare the account balances to be carried forward into the new fiscal year. Separate programs are executed to carry forward the balances for GL accounts (balance sheet and profit & loss), customer accounts (A/R) and vendor accounts (A/P).

The balances for balance sheet, customer and vendor accounts are simply carried forward into the new fiscal year to their same respective GL accounts. Profit & Loss accounts are carried forward to retained earnings/net asset accounts. The balances in the profit & loss accounts are set to zero. HopkinsOne has defined a series of four retained earnings/net asset accounts. Each profit & loss account will be mapped to one of the retained earnings accounts. The four accounts are:

§ 311000 – Unrestricted Net Assets

§ 312000 – Temporarily Restricted Net Assets

§ 313000 – Permanently Restricted Net Assets

§ 320000 – Retained Earnings

Page 17: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 17 of 28 Security Restrictions if Necessary

9.4.6.5.2 Process Flow Figure 9.4­5 Steps for Configuring and Process Closing

Configure Fiscal Year Variant V6 July 1 to June 30th 4 Special Periods 13­16

Configure Assign Variant to Specific Posting Period Intervals By criteria of Authorization Group (Security) GL Account Type

Configure Assign Company Code JHEN to variant V6

Configure Define Fiscal Year Variant Specific For Posting Period

Configure Assign Posting Period Variant to Company Code

Open and Close Period Every Month In SAP

Execute Closing and Carry Forward Programs in SAP

Carry Out Pre Closing and Closing Steps/ Procedures

In SAP

Generate Month End and Year End Reports. Extract Data For Consolidation and Eliminations to SAP­BW

System

9.4.6.5.3 Inputs and Outputs No inputs/outputs exist.

9.4.6.5.4 Other Considerations There are no other considerations noted for the Year End closing process.

Page 18: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 18 of 28 Security Restrictions if Necessary

9.4.6.6 Sub­process 6 ­ Foreign Currency 9.4.6.6.1 Overview The Blueprint design for foreign currency is presented within the context of the scope defined for the HopkinsOne project. Specifically, direct access to SAP R/3 will not be permitted outside of the United States.

HopkinsOne will enable foreign currency data entry within vendor invoices to record expenses and replenishment request related to foreign imprest bank accounts (Replenishment in USD). The current system to track and process transactions from foreign imprest fund accounts will continue (Quickbooks where applicable.) To facilitate reimbursement, these transactions will be summarized and uploaded to SAP Accounts Payable to create a vendor invoice. The invoice will subsequently be paid via the standard SAP payment program which will be configured to issue the disbursement according to the business needs of the foreign business unit requesting reimbursement. The upload of the foreign currency transactions will be automated wherever possible.

When the vendor invoice is recorded, it will be recorded against the GL Account and Grant(s) that are funding the imprest fund account. It will also record the funds and cost center (or other cost object) to track the organizational entity that owns the imprest fund and to track the funding sources for the disbursement. When payment is issued for the invoice, multiple invoices can be combined together to issue a single payment. According to current policy, payments will always be issued in USD.

The set up required in SAP to enable replenishment to foreign currency accounts is as follows:

Vendor Master Data Setup Each of the foreign currency imprest fund accounts will be set up as a vendor in SAP. Information like the vendor address for the check, bank name and account, wiring information, and the custodian of the account will be derived from vendor master data when the replenishment requests are recorded.

Foreign Exchange Rate Setup Within the SAP configuration each of the exchange rates for each currency pair (exchange to and from the foreign currency) has to be defined. HopkinsOne will also define the exchange rate valuation method (spot rate or average currency exchange rate) to be used to derive the conversion at the time of the payment. Although the exchange rates must be maintained in SAP, all the exchange rate pairs do not have to be maintained in SAP. HopkinsOne can use functionality called the inversion tool to calculate the opposite rate from a defined exchange rate. This method can be used only if the spot exchange rate method is used to calculate currency translation.

Recording Transactions HopkinsOne will configure SAP to enable posting of transactions in foreign currency. Line item reporting in foreign currency will be available, but will be limited to transactions that were entered in foreign currency. The HopkinsOne Company Code currency (for financial reporting) will be USD. No open item management of foreign currency transactions will occur in the SAP system. All payments will be issued in USD only. Specific document types will be developed to support this process within the FI module of SAP (both GL and AP).

Page 19: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 19 of 28 Security Restrictions if Necessary

9.4.6.6.2 Process Flow Figure 9.4­6 Foreign Currency

Special Ledger Document Created in USD for financial reporting

AP Invoice FB60 Summarized Expenses recorded against foreign imprest account. Transaction in USD.

Standard SAP Payment Program Pays Foreign Disbursement Invoices. Generates Checks, Wires in USD currency only for replenishment.

Expense and Replenishment of foreign imprest fund bank account data received in US via Quicken flat file or manual reports.

Translation to USD done outside of SAP

AP Invoice FB60 Summarized Expenses recorded against foreign imprest account. Foreign currency used to record invoice transaction.

Special Ledger Document Created in USD for financial reporting

Open Item translated to USD at time of payment based on exchange rate and foreign currency valuation method maintained in SAP foreign exchange table

Disbursement request sent to bank

9.4.6.6.3 Inputs and Outputs No inputs/outputs exist for Foreign Currency.

9.4.6.6.4 Other Considerations There are no other considerations noted for Foreign Currency.

9.4.7 Internal Control Considerations 9.4.7a Internal Control Considerations

Process Objective Potential Risks

Expected/Suggested Controls to Mitigate Risk

Process 9.4.6.1­ Chart of Accounts Only valid changes are made to the General Ledger master records. (validity) The General Ledger Chart of Accounts reflects Group requirements. New accounts will be added to the Chart of Accounts only if they are necessary and have been approved to help ensure efficient system processing and accurate transaction processing.

Invalid changes are made to the General Ledger master records.

Preventative Automated & Manual A procedure is established that all changes to the General Ledger master record are approved by Senior Management. SAP standard functionality will insure that account numbers do not proliferate within the specified account group ranges.

Page 20: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 20 of 28 Security Restrictions if Necessary

Process Objective Potential Risks

Expected/Suggested Controls to Mitigate Risk

Process 9.4.6.1­ Chart of Accounts All valid changes to General Ledger master records are processed. (completeness)

Not all valid changes to the General Ledger master records are input and processed.

Preventative/Detective Manual and Automated SAP standard functionality does not allow for incomplete records to be posted. Standard SAP Reports will be available to verify changes made.

Process 9.4.6.1­ Chart of Accounts Changes to the General Ledger master records / Chart of Accounts will be communicated to the user community in a timely manner to prevent processing errors.

System interruptions. Misallocations.

Corrective Automated (e.g. email) A list of users affected by the changes made to General Ledger master records should be maintained. Before performing a change, the official making the change should notify and verify the change with all these users to ensure that the change will be properly implemented without causing system interruption. Standard SAP Reports are available to view changes.

Process 9.4.6.1­ Chart of Accounts General Ledger master record information is recorded in a consistent and complete fashion.

Incomplete data may be entered in the General Ledger master records. Critical fields that must be entered are not specified as mandatory.

Preventative Automated (Checklist approach) SAP standard functionality prohibits creation of incomplete master records. These specific fields will be identified during realization.

Process 9.4.6.1­ Chart of Accounts Modifications/ changes to General Ledger master records are correctly processed. (accuracy)

Changes to General Ledger master records may be incorrectly processed.

Preventative Manual & Automated The official (responsible for maintenance of General Ledger master records) shall process all requests for modification of the General Ledger master records after having checked the contents and the accuracy of the data supplied. Each change to General Ledger master records is prepared from appropriate source documents. SAP edits and validates General Ledger master records online, identified errors are corrected promptly.

Process 9.4.6.1 Chart of Accounts An audit trail will exist for all changes to the Chart of Accounts. All changes to, and deletion of General Ledger master records must be properly logged, documented and retained.

Unauthorized changes to General Ledger master records (including creation or deletion of accounts) may go undetected. Errors in capturing General Ledger master records are not timely identified. No responsibility is assigned for regularly reviewing audit trails of change information. (No master data amendment report is generated to ensure that the information processed is correct and accurate.) Changes to General Ledger master records are not supported by valid documentation. Required documentation is not retained for mandatory retention periods.

Detective Manual & Automated The Financial Accountant reviews the General Ledger account change report on a monthly basis to ensure changes are performed in compliance with General Ledger maintenance requests. Changes to critical General Ledger master details are reviewed by senior management. A master data amendment report showing data before and after changes is approved (based on a comparison to source documents where appropriate) by an independent person. A SAP report is generated with date and time of change, old and new values for fields and also the user who entered the change. Procedures exist to retain all documentation on any Chart of Accounts maintenance requests.

Page 21: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 21 of 28 Security Restrictions if Necessary

Process Objective Potential Risks

Expected/Suggested Controls to Mitigate Risk

Process 9.4.6.2­Journal Entries All adjustments are recorded when identified and are subsequently accounted for as having been processed to the General Ledger. (completeness) Journal entries are subject to controls over completeness of processing.

Adjustments may not be recorded. Omission of valid journal entries may occur. Some required (necessary) journal entries are not posted each month.

Preventative Automated SAP will not permit processing of incomplete journal entries. Updates to the general ledger are real­time.

Process 9.4.6.2­ Journal Entries Adjustments are accurately processed. Journal entries should be prepared accurately. (accuracy)

Incorrect line item details (business area, tax code, cost centre) or amount are entered. Entries may be incorrectly made. Adjustments may be incorrectly prepared or processed. Misstatement of General Ledger account balances.

Preventative Automated The officials (responsible for journal entries) shall only process journal entries after having checked the contents and the accuracy of the data supplied. Each journal entry is prepared from appropriate source documents. SAP standard functionality requires that all transactions are in balance prior to being posted to the General Ledger.

Process 9.4.6.2­ Journal Entries Adjustments and journal entries are processed to the correct account. (classification) All journal entries include adequate identification of the accounts in which they are to be recorded.

Adjustments are processed to the incorrect account. Incorrect document types or posting keys are entered resulting in posting to the incorrect account. Insufficient account identification.

Preventative Manual Unique General Ledger account codes are in use. Review and approval of General Ledger entries by appropriate management level. SAP Authorization and Approval.

Process 9.4.6.2­ Journal Entries Adjustment and journal entry information is recorded in a consistent and complete fashion. Entered transaction data is complete.

Essential fields are not designated as mandatory to ensure complete data is captured and recorded. Edit and validation routines are not used during data entry to ensure transactions are valid.

Preventative Manual Standard SAP edits and validates input data on­line. SAP is configured to require mandatory fields when capturing transaction records through use of the field status variants. Some of the key fields within this area are General Ledger account number, General Ledger account name, Short Text, Type of account (i.e. Balance Sheet, Income Statement, etc).

Process 9.4.6.2­ Journal Entries Adjustments (Journal entries) are adequately explained and supported. (validity) Explanation and support for an entry should be sufficient to enable the person responsible for its review and approval to reasonably perform this function.

Manual entries are not appropriately documented on a valid source document. Invalid entries may be made.

Preventative Manual All journal entries (including non­ systematic journals) are supported by adequate narratives and documents, and are reviewed and approved by management.

Process 9.4.6.2­ Journal Entries General Ledger Journal entries should be captured separate from the person initiating the initial transaction. Preparation and approval functions for journal entries are segregated.

Fraud and error due to no segregation of initiation, execution, authorization and recording of transaction.

Preventative Automated Segregation of initiation, execution, authorization and recording of General Ledger transactions. Review of General Ledger process is segregated from the processing function. SAP Role Authorization and Approval.

Page 22: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 22 of 28 Security Restrictions if Necessary

Process Objective Potential Risks

Expected/Suggested Controls to Mitigate Risk

Process 9.4.6.2­ Journal Entries Reversal documents are appropriately reversed.

Reversal documents are processed with inaccurate amounts and not properly justified or compliant with JHU cost transfer policy and procedures

Detective Automated & Manual Standard SAP functionality requests a reversal reason code for every document and documents may only be reversed automatically within the same period. Manual policy to be implemented for tracking changes to documents from other periods.

Process 9.4.6.2­ Journal Entries Interface document types are appropriately recorded to ensure integrity and validity of the journal entry.

All interface journals should be received and processed in a timely manner.

External interface postings from 3rd party systems may not be authentic and incorrectly recorded in the GL system.

Postings are not identified or recorded timely.

Preventative Detective Automated & Manual All entries to SAP from interfaces will have their own document type and error reports from interface entries that do not come over for any reason will be available in real time.

Process 9.4.6.2­ Journal Entries Rejected items require re­entry on a timely basis subject to the same input controls as new transactions. (completeness)

Rejected items not re­entered. Detective Manual All rejected items should be reviewed for errors and re­entered in the same manner under management supervision.

Process 9.4.6.2­ Journal Entries Open items, held or parked documents are resolved and processed timely.

Open items, held or parked documents are not resolved and processed timely.

Detective Manual Procedures are established to ensure that all "parked" documents are investigated and either deleted or processed by established cut­off times prior to closing the accounting period. Un­posted documents are either deleted or accrued as a part of the monthly closing checklist.

Process 9.6.4.3 Open Item Management All essential actions are completed prior to closing and reporting.

Closing activities in other applications are not completed before the deadline for financial reporting. Payable and Receivable balances are not confirmed (inter­company and discrepancies with business partner records are not resolved). (Inter­business area confirmations, vendor and customer reconciliations). No adjustments for payables, receivables or the GR/IR clearing account are made to ensure the balance sheet is correct. Balances and open items in foreign currencies are not valuated before reports are generated. Open batch sessions are not closed on a monthly basis.

Detective Manual & Automated The Financial Accountant will validate that all closing activities are completed timely throughout the close process. This will help to ensure that all necessary activities are completed in the proper sequence prior to period end.

Process 9.6.4.3 Open Item Management All General Ledger suspense account balances are properly reallocated prior to closing the accounting period to help ensure that the period end ledger balances are correctly reflected.

General Ledger balances are misstated (transactions processed in the incorrect period).

Detective Manual & Automated There are no suspense accounts built into the general ledger going forward. Users are expected to post to appropriate source accounts.

Page 23: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 23 of 28 Security Restrictions if Necessary

Process Objective Potential Risks

Expected/Suggested Controls to Mitigate Risk

Process 9.6.4.3 Open Item Management All journals entered will be posted prior to the accounting period close to ensure that all current period activity is reflected in the financial statements.

General Ledger balances are misstated (transactions processed in the incorrect period).

Detective Manual The Financial Accountant will validate that all closing activities are completed timely throughout the close process.

Process 9.4.6.4­Fiscal Year and Posting Periods Notifications of changes to General Ledger master records are processed timely. (proper period) All new accounts will be added in a timely manner so they are available for transaction processing in the correct period.

Changes to the General Ledger master records are not processed timely. Payroll may be incorrectly computed for the relevant period.

Preventative/Manual A procedure should be established that the change to General Ledger master records is made within an established time period after the source document has been received. By processing the change immediately after the source document has been received, the General Ledger master record is kept current and the possibility of incorrect changes being made is minimized. Requests to change General Ledger master record data are logged. The log is reviewed to ensure that all request changes are processed timely.

Process 9.4.6.4­ Fiscal Year and Posting Periods Adjustments and journal entries are processed promptly and within the correct accounting period. (proper period)

Incorrect posting dates are entered and entries posted to the wrong period. Entries may be processed in the incorrect accounting period.

Preventative/Manual Financial documents can only be posted in periods which are opened in the SAP system. In SAP the Financial Calendar functionality can be used to schedule activities / programmers that have to be performed / run on certain dates (like the creation of recurring entries). Definition of the actual calendar and scheduling the dates is performed for the entire client, and not per company. Reconciliation of General Ledger accounts.

Process 9.4.6.5­ G/L Closing Reconcile books and records to ensure their internal consistency. (completeness, accuracy and validity) All necessary accounts are reconciled to provide assurance on the reporting results.

Key General Ledger accounts (particularly control accounts) are not reconciled to source documents or ledgers on a regular basis. Errors or irregularities may not be detected. (Note: Risks for this objective vary, depending on the reconciliation procedures and the nature of the information being reconciled. Accordingly, reconciliation procedures are identified, where appropriate, in other cycles). Reconciliation tasks are insufficient to result in accurate financial statements. Differences (e.g. long outstanding items) are not investigated, and / or explained ­ corrective action is not taken.

Preventive Manual or Automated Reconciliation of opening balances and current activities to current period closing balances. Compare critical details of each reconciliation entry to establish criteria. Comparison may be done manually or by use of computer validation techniques. All differences are investigated, followed up and corrected on a timely basis.

Process 9.4.6.5­ G/L Closing General Ledger reconciliations are prepared promptly by an authorized company official.

Reconciliations are not performed timely. Invalid adjustments are not identified timely. Misallocated postings are not identified timely.

Preventive Manual or Automated Pre­determined set time tables for the completion and review of reconciliations.

Page 24: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 24 of 28 Security Restrictions if Necessary

Process Objective Potential Risks

Expected/Suggested Controls to Mitigate Risk

Process 9.4.6.5­ G/L Closing Reconciliations of General Ledger accounts are reviewed by management for accuracy, validity and completeness and the necessary adjustments made.

Reconciliations are not subject to review to identify anomalies. Review process is not formalized and accountability cannot be allocated.

Preventive Manual or Automated All General Ledger reconciliations are reviewed, signed off and approved by authorized management levels.

Process 9.4.6.5­ G/L Closing Processes are in place to ensure a complete, accurate and timely closing and reporting activity. Allocations will be processed in the proper sequence of the month end close so calculations are computed correctly.

Closing schedules and procedures for month­end and year­end are not defined, published nor followed. Closing procedures are not adequate to guide users in performing job responsibilities in accordance with management's intentions. Appropriate approvals are not required prior to closing a posting period. Periods are not closed after all activity and reporting are complete.

Preventive Manual or Automated A detailed closing calendar including the identification of responsible parties is developed and maintained for month / year end closing by the Financial Accountant. SAP technical closing steps were done at a very high level and a preliminary closing calendar was identified during the blueprint. The calendar lists all period closing tasks to be completed in sequential order and who has the responsibility for the completion of each task. For the year­ end closing, the following step is considered for inclusion into the developed year­end target process. (Note: some of the below steps may also be included in Month End): Carry forward customer and vendor balances to next year. Carry forward profit or loss and General Ledger account balances to next year. Close the last month (posting period) of the business year. Process inter­business area elimination entries. Post adjustments to the General Ledger. Re­value open items posted in foreign currency. Re­value foreign currency General Ledger account balances. Sort and summarize open items by ranges of due date. Post any other required adjustments. Process Allocations. Print balance sheet and profit and loss account.

Process 9.4.6.5­ G/L Closing All essential actions are completed prior to closing and reporting.

Closing activities in other applications are not completed before the deadline for financial reporting. Payable and receivable balances are not confirmed (inter­ business area and discrepancies with business partner records are not resolved). (Inter­business area confirmations, vendor and customer reconciliations). No adjustments for payables, receivables or the GR/IR clearing account are made to ensure the balance sheet is correct. Balances and open items in foreign currencies are not valuated before reports are generated. Open batch sessions are not closed on a monthly basis.

Preventive Manual or Automated The Financial Accountant will validate that all closing activities are completed timely throughout the close process. This will help to ensure that all necessary activities are completed in the proper sequence prior to period end.

Page 25: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 25 of 28 Security Restrictions if Necessary

Process Objective Potential Risks

Expected/Suggested Controls to Mitigate Risk

Process 9.4.6.5­ G/L Closing All General Ledger suspense account balances are properly reallocated prior to closing the accounting period to help ensure that the period end ledger balances are correctly reflected.

General Ledger balances are misstated (transactions processed in the incorrect period).

Detective Manual or Automated There are no suspense accounts built into the general ledger going forward. Users are expected to post to appropriate source accounts.

Process 9.4.6.5­ G/L Closing All journals entered will be posted prior to the accounting period close to ensure that all current period activity is reflected in the financial statements.

General Ledger balances are misstated (transactions processed in the incorrect period).

Detective Manual or Automated The Financial Accountant will validate that all closing activities are completed timely throughout the close process.

Process 9.4.6.5­ G/L Closing The General Ledger is periodically balanced with the subsidiary Ledgers (AA, AP, and AR) and other modules of SAP (e.g. CO) to ensure proper reporting. All amounts from subsidiary records are accurately recorded in the General Ledger. Transactions are only posted to detail accounts because posting to summary accounts will result in inaccurate roll up of financial data.

The General Ledger may be incomplete or may contain other inaccuracies.

Preventive Manual or Automated Timely reconciliation of all subsidiary records to the General Ledger. All reconciling items are identified, investigated and cleared on a timely basis. Management reviews all reconciliations and follows up on unusual matters. All financial data will be entered through FI (Design decision). Information for entities not using Scope will be entered in Summary form, to accomplish needed consolidations.

Process 9.4.6.6­ Foreign Currency Translation and consolidation of financial reports should be accomplished accurately and promptly. Subsidiaries are accurately recorded in the consolidated financial statements.

Misstatement of the financial statements due to: clerical errors, use of incorrect exchange rates, omission / incorrect, elimination and reclassification entries.

Preventative Automated Management reviews the accounting for its subsidiaries for consistency with applicable and recent accounting pronouncements. Implement standard elimination and reclassification entries. Implement standard translation and consolidation formats. Consolidation, reclassification, and other adjustments of General Ledger balances into financial statement formats should be explained and documented. Comparison of the number and amounts of reclassification, translation and elimination entries for the current period with the prior period. Foreign Currency entries will have their own document type and tables will be maintained on a regular basis.

Process 9.4.6.6­ Foreign Currency Foreign exchange gains and losses are calculated correctly and posted to the correct account.

Taxes and foreign exchange gains and losses are calculated incorrectly or posted to the incorrect account.

Preventive Automated SAP can be configured and per foreign currency how much the exchange rate on the document header may differ from the exchange rate currently known in the system.

Page 26: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 26 of 28 Security Restrictions if Necessary

Process Objective Potential Risks

Expected/Suggested Controls to Mitigate Risk

Process 9.4.6.7­ G/L Security Only authorized users can access General Ledger functions.

Authorizations for General Ledger transaction activity (e.g. posting documents, adjustments, reversing entries recurring entries, inter­business area transfers, open item clearing) are inappropriately assigned. The authority to change current settings (open or close posting periods, maintain currency translation rates) is inappropriately assigned. The authority to view, enter, change or delete General Ledger related information in the system is not appropriately restricted. Access to configuration information (e.g. General Ledger account assignments, field status variants, field status codes, account groups) is not appropriately restricted.

Preventive Automated/ Manual Through the use of SAP security authorizations, access is restricted. Transactions for General Ledger master record maintenance: FS01 ­­> FS06 ­ Create, Change, Mark for deletion etc. Transactions for General Ledger posting: F­02 General Ledger account posting, F­ 04 Post with clearing, FB02 Change document, FBDL Recurring document.

Process 9.4.6.7 G/L Security Adjustments are reviewed and approved by a responsible official (authorization). All journal entries are reviewed and approved by designated individuals at appropriate levels in the entity. Approval should be given to all, and only, those transactions / journal entries that meet management's guidelines.

Unauthorized adjustments may be processed. Processing of journal entries that are unacceptable to management. Manual entries are not approved. Journal entries may be made for the purposes of misstating account balances or concealing irregularities.

Preventative Manual Check and approval of each journal entry (prior to processing) by supervisory personnel who did not participate in its preparation.

Process 9.4.6.7­ G/L Security Review of General Ledger process is sufficiently segregated from the processing function.

Fraud and error due to no segregation of initiation, execution, authorization and recording of transaction.

Preventative Manual/Automated Review of General Ledger process is segregated from the processing function. Through the use of SAP security authorizations.

Process 9.4.6.7­ G/L Security Access to records, critical forms, processing areas, processing procedures and computer system should be permitted only in accordance with management's criteria (which should provide for segregation of duties).

Records may be destroyed or lost; this could result in an inability to prepare reliable financial and operating reports. Records may be misused or altered, to the detriment of the entity or other parties (vendors, customers, employees). Unauthorized access which could lead to fraud and error. Confidential information viewed by unauthorized persons.

Preventive Manual/ Automated Access to records, critical forms, processing areas, computer systems and processing procedures should be limited to authorized personnel. Physical controls exist which limit access to financial records to authorized employees (Strong rooms, safes and lockable rooms should be used for storage and filing. Keys should be allocated to authorized employees and kept in a safe place.) SAP access to FI and other modules should be restricted to authorized employees.

Process 9.4.6.7­ G/L Security Remote printers or report distribution sites are secured.

Remote printers or report distribution sites are not secured.

Preventive Manual Access to remote printers and report distribution sites is adequately secured and restricted.

Page 27: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 27 of 28 Security Restrictions if Necessary

9.4.8 Gaps 9.4.8a Gaps in functionality provided from SAP

GAP description C L E 3 rd W P Recommended Solution Not Applicable

C – Criticality, L – Level of Effort, E – Enhancement indication, 3 rd ­ 3rd Party Software, P – Pending PMO approval, W – Process solution

9.4.9 Open Design Issues 9.4.9a Open Design Issues

Issue Description Impact Additional Information

Identification of Detailed Closing Steps High

The implementation of a single enterprise wide closing calendar will require the identification of the detailed steps required to execute the monthly and year end closing. Detailed closing steps and their dependencies will be identified in Realization phase. SAP Schedule Manager may be utilized to manage HopkinsOne Closing Schedule based on the detailed requirements.

PMO decision to require monthly GAAP statement will assit in standardization of closing process in realization phase.

Howard County General Hospital Consolidation with JHHS High

Currently, the plan is to record HCGH monthly financial activity in SAP on a summary level which would not provide enough detail to identify all of the elimination entries needed for financial statement consolidation. During Realization, detail analysis will be performed to identify what level of detail needs to be interfaced into SAP based on Consolidation reporting requirements.

Applied Physics Lab Consolidation with JHU High

Currently, the plan is to record APL monthly financial activity in SAP on a summary level which would not provide enough detail to identify all of the elimination entries needed for financial statement consolidation. During Realization, detail analysis will be performed to identify what level of detail needs to be interfaced into SAP based on Consolidation reporting requirements

Foreign Access to SAP High

Some foreign business offices have limited access to current systems and it is not yet clear whether those offices will retain that same level of access to SAP. Also, the current scope definition addresses data entry limitations but not data viewing. If foreign offices are to have data viewing capabilities it is not clear how that will be accomplished. Detail design will be finalized based on PMO’s review and approval of white paper issue currently written up by the International working group.

The School of Medicine , other divisions, as well as Health System affiliates may automatically “Tax” on Investment Income for Certain Endowments and Gifts.

High

For Investment Income on certain Endowments and Gifts, the School of Medicine, other divisions, as well as Health System affiliates assess a "Tax" of 15%. The "taxed" dollars increase an established sinking fund account. The requirement is that we build a validation in SAP that requires establishing the 15% tax upon recognition of the investment income on the identified Endowments and Gifts. This is an open design issue.

Non­Payroll Cost Transfers Aged Greater Than 90 Days

Medium

Additional explanation required for transfers done more than 90 days past the original transaction. Enhancement is identified but not approved. This will be tracked by the HopkinsOne Sponsored Projects Team

Page 28: FI+Blueprint

HopkinsOne BP FI GL Blueprint

Version 0 1/10/2005 at 11:02 AM Page 28 of 28 Security Restrictions if Necessary

Issue Description Impact Additional Information Non­Payroll Cost Transfers – Data Capture

Medium

Fields will be required for this process (date field, reason/reference code, and the document number at the line item level) Possible enhancement is identified (if existing fields cannot accommodate the needed data capture)

Non­Payroll Cost Transfers – Additional Information

Medium

Additional information will be required for certain reason codes or GL accounts. Enhancement is identified but not approved. This will be tracked by the HopkinsOne Sponsored Projects Team

9.4.10 Authorization and User Role Considerations Roles identified within GL area are as follows:

§ Role 1 Chart Of Accounts Master data Administrators

­ Approval process for all master data objects must be defined in policy procedure documentation.

­ Creation must be centrally controlled (SAP central support group­FI team members).

§ Role 2 Finance data viewer

­ All GL accountants with SAP user ID can review all data including master data, transactions and documents across entire FI module.

§ Role 3 Finance senior accountant

­ GL accountant can prepare and post Journal entry.

§ Role 6 Finance technical interface processor.

­ This functional role will be responsible for handling technical error in the interface.

­ A system accountant will handle different types of errors like,

­ If the interface does not execute, follows up on those issues.

­ Interface is executed but some transactions fail – creates error log

§ Role 9 Finance closing specialist

­ SAP central support group will handle the close process/ programs centrally. However functions that will be performed/supported outside the SAP central group like ability to post in special period 13­16 in SAP for adjustments, accruals etc, will be performed by this role.

§ Role 10 Finance report viewer

­ One role mapped to execute and view financial reports within core SAP R/3 system.

§ Role 11 Finance report configuration specialist

­ This person will be trained on report writer tool and can create report groups etc in SAP system. Also this can role can provide access to some reports that Role 10 above is restricted from accessing in FI system.

­ Please refer to Authorization Role Spreadsheet for role mapping to specific transaction codes.