fico bbp for sap is retail implementation

FINANCE & CONTROLLING

SAP IS-RETAIL IMPLEMENTATION TO-BE BUSINESS PROCESS SCRIPTS VERSION NO – 2.0

LOCATION : GURGAON PAGE 1

FINAL BBP – FICO ISSUED TO ANKITA (PWC) FOR SOLMAN UPLOAD PURPOSE DATED -31ST

JULY

Project: Surge

Business Blueprint For

SAP IS-Retail Implementation

Planet Retail Gurgaon





JULY

Planet Retail Organization structure .............................................................................................................................................................................................. 4 1.1 Company Code ......................................................................................................................................................................................................................... 4 1.2 Controlling Area ........................................................................................................................................................................................................................ 9 1.3 Credit Control Area ................................................................................................................................................................................................................... 9 1.4 Profit Center ............................................................................................................................................................................................................................ 10 1.5 Cost Center ............................................................................................................................................................................................................................. 15 1.6 Key Changes / Improvements in Business Processes ........................................................................................................................................................... 19 General Ledger Accounting .......................................................................................................................................................................................................... 21 2.1 General explanations.............................................................................................................................................................................................................. 21 2.2 SAP GL Component ............................................................................................................................................................................................................... 24 2.3 Key Changes / Improvements in Business Processes ........................................................................................................................................................... 40 2.4 Additional Points (from Open Items list and SAP Recommendations) .................................................................................................................................. 40 Accounts Payables ........................................................................................................................................................................................................................ 47 3.1 General Explanations and SAP FI – AP Component Overview ............................................................................................................................................... 47 3.2 SAP Solution Component – Accounts Payables .................................................................................................................................................................... 47 3.3 SAP Solution Technical Details – Document Type, Number Ranges and Posting Key ........................................................................................................ 63 3.4 Key Changes / Improvements in Business Processes ........................................................................................................................................................... 65 3.5 Additional Points (from Open Items list and SAP Recommendations) ................................................................................................................................... 65 Accounts Receivables ................................................................................................................................................................................................................... 68 4.1 General Explanations ............................................................................................................................................................................................................. 68 4.2 SAP Solution Component – Accounts Receivables ............................................................................................................................................................... 69 4.3 SAP Solution Technical Details – Document Types, Number Ranges and Posting Key ....................................................................................................... 92 4.4 Key Changes / Improvements in Business Processes ........................................................................................................................................................... 96 4.5 Additional Points (from Open Items list and SAP Recommendations) .................................................................................................................................. 97 Bank Accounting ......................................................................................................................................................................................................................... 101 5.1 General Explanations............................................................................................................................................................................................................ 101 5.2 SAP FI – Bank Accounting ................................................................................................................................................................................................... 101 5.3 Key Changes / Improvements in Business Processes ......................................................................................................................................................... 107 5.4 Additional Points (from Open Items list and SAP Recommendations) ................................................................................................................................. 107 Asset Management ...................................................................................................................................................................................................................... 109 6.1 Asset Classification .............................................................................................................................................................................................................. 109 6.2 Master Data ......................................................................................................................................................................................................................... 111





JULY

6.3 Account Determination ........................................................................................................................................................................................................ 112 6.4 Depreciation Overview ........................................................................................................................................................................................................ 113 6.5 Asset Valuation ................................................................................................................................................................................................................... 116 6.6 Depreciation Processing ..................................................................................................................................................................................................... 117 6.7 Amortisation......................................................................................................................................................................................................................... 119 6.8 Budgetary Control for Asset Acquisition` ............................................................................................................................................................................ 120 6.9 Asset Transactions .............................................................................................................................................................................................................. 120 6.10 Key Changes / Improvements in Business Processes ......................................................................................................................................................... 125 Cost Centre Accounting .............................................................................................................................................................................................................. 126 7.1 General Explanation ............................................................................................................................................................................................................ 126 7.2 SAP CO – Cost Center Accounting ..................................................................................................................................................................................... 126 7.3 Key Changes / Improvements in Business Processes ........................................................................................................................................................ 137 Internal Order ............................................................................................................................................................................................................................... 138 8.1 General Explanation ............................................................................................................................................................................................................ 138 8.2 SAP CO – Internal Orders ................................................................................................................................................................................................... 138 8.3 Key Changes / Improvements in Business Processes ....................................................................................................................................................... 142 Profit Center Accounting ............................................................................................................................................................................................................ 144 9.1 General Explanations .......................................................................................................................................................................................................... 144 9.2 SAP CO – Profit Center Accounting .................................................................................................................................................................................... 144 9.3 Key Changes / Improvements in Business Processes ....................................................................................................................................................... 156 Annexure....................................................................................................................................................................................................................................... 157 ANX 1 SAP Observations / Recommendations / PwC‟s response .............................................................................................................................................. 157





JULY

Planet Retail Organization structure

Planet Retail group comprises of several individual legal entities. IS-Retail project will address the logistics and financial tracking of the following 3 company codes – 1. Planet Retail Holdings Private Limited 2. Supreme Tradelinks Private Limited 3. Quest Retail Private Limited Comprehensive financial statements will be drawn for the three company codes. Trial Balance will also be available at Sites through Profit Center grouping by enabling the “New GL” functionality of online split with “Zero balancing” for Profit Center scenario. For internal monitoring purposes, individual responsibility centers have been identified against which operating profitability will be measured together with Accounts Receivable, Accounts Payable, Stock etc.

1.1 Company Code

It is the smallest organizational unit for which a complete self-contained set of accounts can be drawn up for purposes of external reporting. The process of external reporting involves recording all relevant transactions and generating all items and supporting documents required for legal financial statements (Balance Sheet and Profit and Loss statement). Only a legally independent company is normally represented by a Company Code in the SAP system. In financial accounting, business transactions are always entered at the Company Code level and processed further. The costs are also managed at the Company Code level. By using internal CO organizational structure, it is possible to divide this even further in Controlling. In IS Retail system, company code is the lowest-level entity where the Statutory Profit and Loss Statement as well as Balance Sheet will be generated under Schedule VI to the Companies Act, 1956. Financial statements at company code level comply with tax and legal requirements.





JULY

Company Code Description Company Code

Planet Retail Holdings Private Limited 1000

Supreme Tradelinks Private Limited 1100

Quest Retail Private Limited 2000

In the following documentation, we will refer all scenarios with reference to Company Code Planet Retail Holdings Private Limited (PRHPL). All scenarios will work identically for the other 2 company codes also. Wherever differences arise, we will refer in explicit. Basic financial statement consolidation will be carried out by leveraging the IS Retail functionalities. However, the comprehensive and full-fledged consolidation functionalities, provided by SAP advanced component SEM (Strategic Enterprise Management) will not be covered during this phase.

Fiscal Year and Accounting Posting Period

A Fiscal Year is generally a period of 12 months for which the company produces financial statements and takes inventory. It may or may not correspond to the calendar year. A Fiscal Year variant specifies the number of periods and special periods in a Fiscal Year and how the system is to determine the assigned posting periods. Planet Retail group‟s Fiscal Year is April to March. The end of a period is the last day of the calendar month.





JULY

PRHPL will use the standard SAP Fiscal Year Variant „V3‟ with 12 normal posting periods.

Posting Period Variant

Once a Fiscal Year is defined, it is possible to specify whether a period is allowed for posting or not. In order to standardize maintenance of accounting period especially across the group, SAP system allows the specification of „open‟ or „close‟ status to be maintained via a posting period variant. Separate posting period variants will be created for the 3 company codes. It will add the flexibility of separately managing period opening and closing for individual company codes.


Name Company code

1000 Planet Retail Holdings Private Ltd. 1000

1100 Supreme Tradelinks Private Ltd. 1100

2000 Quest Retail Private Ltd. 2000

Chart of Account

The Chart of Accounts is a classification scheme consisting of a group of general ledger (G/L) accounts. It provides a framework for the recording of values, in order to ensure an orderly rendering of accounting data. The G/L accounts can be used by one or more Company Codes. Every Company Code must be assigned a Chart of Accounts. For each G/L account, the Chart of Accounts contains the account number, the account name and other technical information. A Chart of Accounts must be assigned to each Company Code and will be used in both financial accounting and cost accounting.





JULY

All 3 company codes will use a common chart of account to manage accounting in consistent manner. GL Account Creation Process Step 1 – Create GL account in Chart of Account (GL Code, Description, Balance Sheet account / P&L account) Step 2 – Extend GL account to individual company codes

Chart of Accounts Description Chart of Accounts

PR Chart of Accounts PR00

Following is the proposed Chart of Account structure for Planet Retail -

Nature Account Group Group Code From To

Liabilities Shareholders‟ Funds SHAR 100000 109999

Loan Funds - Secured LNSE 110000 119999

Loan Funds - Unsecured LNUN 120000 129999

Current Liabilities CULI 130000 139999

Provisions PROV 140000 149999

Assets

Fixed Assets FIXD 200000 209999

Investments INVS 210000 219999





JULY

Inventories INVE 220000 229999

Debtors DEBT 230000 239999

Loans & Advances ADVA 240000 249999

Cash & Bank BANK 250000 259999

Deferred Tax DTAX 260000 269999

Misc Expenditures not Written Off MENW 270000 279999

Income

Revenue REVE 300000 309999

Other Income OTIN 310000 319999

Expenses

Cost of Goods Sold COGS 400000 409999

Employees Cost EMPL 410000 419999

Gen & Administrative Expenses ADMN 420000 429999

Selling & Distribution Expenses SELL 430000 439999

Interest & Finance Charges FINA 440000 449999

Depreciation DEPR 450000 459999

Provision for Taxation PTAX 460000 469999

The above mentioned account groups will be revisited during the realization phase, and will be firmed up.





JULY

1.2 Controlling Area

Controlling area is an Organizational Unit within a company, which is used to represent a system for management accounting purposes. A controlling area may include single or multiple Company Codes. These Company Codes must use the same operative Chart of Accounts & the same Fiscal Year. All internal allocations refer exclusively to objects in the same Controlling Area. Internal business transactions are portrayed in the Controlling Area. Primary costs are transferred from external accounting and classified according to managerial accounting perspectives. All these will help the company track specific information for cost monitoring, business decisions and sales control. One controlling area “PR00” is recommended for Retail operations to facilitate internal reporting requirements.

Controlling Area Description Controlling Area

PR Controlling Area PR00

1.3 Credit Control Area

A Credit Control Area can establish and monitor credit limits for customers assigned to one or several Company Codes. A Company Code is assigned to one Credit Control Area, which monitors its credit limits. More than one company codes can be assigned to a common Credit Control Area to carry out group-level collective credit management. One Credit Control Area “PR00” will be defined and attached to the 3 company codes.





JULY

Credit Control Area Description Credit Control Area

PR Credit Control Area PR00

1.4 Profit Center

A Profit Center is a management-oriented Organizational Unit used for internal controlling purposes. Dividing the company into Profit Centers allows analyzing areas of responsibility. Profit Center Accounting supports a division of the enterprise into areas of responsibility. The standard hierarchy of Profit Center is defined as a tree structure for grouping all Profit Centers, which belong to a Controlling Area. Each Profit Center must be assigned to a group (node) of the standard hierarchy. In addition to the standard hierarchy, various alternative hierarchies can be defined for use in the information system and other functions. The Standard Profit Center Hierarchy for Controlling Area PR00 will be defined taking into account company code, concept, brand and individual sites. By creating Profit Center groups, the aggregated data can be analyzed at higher levels in the hierarchy. Lowest level in the Profit Center hierarchy is identified as site (stores). In this manner, each store is configured as a Profit Center. (This is the majority scenario for Planet Retail. However, we have a slightly different approach for some of the stores such as Debenhams, FashionCube etc) In case of Debenhams, every store has 2 profit centers to address the separate tracking needs of „Debenhams Brands‟ and „non-Agency Brands‟. FashionCube profit centers are segregated among PRHPL, STPL and QRPL depending upon individual brand. Also within a company code, FashionCube has more than one profit center for a single store to separately track individual brand. (please refer to hierarchy template for more clarity). A broad template for profit center hierarchy is as follows (the individual profit centers are emphasized with yellow background)-





JULY

Planet Retail

PRHPL

PRHPL - Common

Debenhams

Debenhams - Common

Store 1

Store 1 – Debenhams Brands

Store 1 - Non-Agency Brands

Store 2



DC-Debenhams

Next

Next - Common

Store 3

Store 4

DC - Next





JULY

PRHPL-FashionCube

FashionCube-Common

Store 5 – Guess

Store 5 - Next

Store 5 - Accessorize

STPL

STPL - Common

M&S

M&S - Common

Store 6

Store 7

DC-M&S

STPL-FashionCube

Store 5 – M&S





JULY

QRPL

QRPL - Common

TBS

TBS - Common

Store 8

Store 9

DC-TBS

QRPL – FashionCube

Store 5 – Body Shop

Store 5 – Sole Effect

Code Structure:- Other than for stores such as Debenhams and FashionCube, Individual stores will be configured as profit centers. The treatment for Debenhams and FashionCube has been discussed hereinbefore. In SAP, profit center codes can be 10 characters long. The following is the approach for profit center codification.





JULY

XX XX XXXX XX ______ ___

COMPANY CODE

CONCEPT

SITE CODE

BRAND CODE (In case of stores like FashionCube and Debenhams)

Concept codes and Site Codes are being discussed and once finalized, Profit Center Codes will be drawn-up. However, the structure will be as explained above.





JULY

1.5 Cost Center

Cost Center is the lowest Organizational Unit on which Cost can be collected, planned and analyzed. The Cost Center hierarchy is the repository of all the Cost Centers that are applicable for processing, monitoring and reporting costs. The Cost Centers are assigned at the lowest node of a tree structure representing the hierarchy of the cost structure in the company. The Cost Center Hierarchy will be defined on the same lines as Profit Center Hierarchy. Key difference is that the individual cost centers will be defined at functional department level also (Accounts, HR, IT etc). By creating Cost Center groups the aggregated data can be analyzed at higher levels in the hierarchy.

The Cost Center Hierarchy is structured as follows:

Planet Retail

PRHPL

PRHPL – IT

PRHPL – Accounts

PRHPL - HR

Debenhams





JULY

Debenhams - Common

Store 1



Store 2



DC-Debenhams

Next

Next - Common

Store 3

Store 4

DC - Next

PRHPL-FashionCube

FashionCube-Common

Store 5 – Guess

Store 5 - Next

Store 5 -





JULY

Accessorize

STPL

STPL – IT

STPL – Accounts

STPL - HR

M&S

M&S - Common

Store 6

Store 7

DC-M&S

STPL-FashionCube

Store 5 – M&S

QRPL

QRPL – IT

QRPL – Accounts

QRPL -





JULY

HR

TBS

TBS - Common

Store 8

Store 9

DC-TBS




Code Structure: - Individual sites will be configured as Cost Centers (except for Debenhams, FashionCube, DC and corporate office). In case of Debenhams, every store has 2 cost centers to address the separate tracking needs of „Debenhams Brands‟ and „non-Agency Brands‟. FashionCube cost centers are segregated among PRHPL, STPL and QRPL depending upon individual brand. Also within a company code, FashionCube has more than one cost center for a single store to separately track individual brand. (Please refer to hierarchy template for more clarity). SAP provides 10 character long codes for cost centers. Following is the approach for cost center codification.





JULY


COMPANY CODE CONCEPT SITE CODE BRAND CODE (In case of stores like Debenhams and FashionCube)

Site Codes are being discussed and once finalized, Cost Center Codes will be drawn-up. However, the structure will be as explained above.

1.6 Key Changes / Improvements in Business Processes

1. SAP organization structure comprehensively captures requirements of all organizational functions such as finance, costing,

purchase and sales 2. SAP organization structure is adaptable to changes in physical business and reporting considerations 3. Profit center hierarchy and cost center hierarchy address reporting requirements from the lowest level i.e. cost center to the

highest level i.e. company code





JULY

4. Other than Profit Center Standard hierarchy and Cost Center Standard Hierarchy, alternate hierarchies of profit centers and cost center enable flexible reporting for all permutations and combinations of organization levels.

5. All elements of organization structures work in conjunction with each other. The extensive integration among all organization structure elements enables various organizational departments to have a common view of organization.





JULY

General Ledger Accounting

2.1 General explanations

The central task of G/L accounting is to provide a comprehensive picture for external accounting. Recording all business transactions in a software system that is fully integrated with all the other operational areas of a company ensures that the accounting data is always complete and accurate. Essentially, the G/L-accounts serve as a complete record of all business transactions. It is a centralized, up- to-date reference for the rendering of accounts and relevant information. Actual individual transactions can be checked at any time in real-time processing by displaying the original documents, line items and monthly debits and credits at various levels such as: -

Account Summary of monthly debits and credits (balances)

Balance sheet/profit and loss evaluations

Other analysis

The values posted to the G/L accounts appear in the financial statements, which provide the Balance Sheet, Profit and Loss Statement. This section outlines the master data structures, business processes and related configuration parameters required for the General Ledger module for PRHPL. However, General Ledger module is also heavily involved in other business process designs from other modules and how they

post into the General Ledger. These issues are covered in the relevant sections in Account Receivable, Account Payable,

Purchasing, Inventory Management and Logistic Invoice Verification.





JULY

Key improvements to be realized from this implementation includes:-

Reduction in data redundancy: The shared master data concept in SAP will inevitably reduce duplication of data stored and used in the business processing

Greatly reduced administration: through the elimination of re-keying, reconciliation and manual collation of data. This gives the finance staff the time to analyze the figures rather than spending the majority of their time performing administration tasks

Better control of data: through the validation of the data at point of entry.

Seamless Integration: a complete integrated system will provide better control and reduce data entry errors and also provides a complete audit trail for the organization.





JULY

The processes and its integration can be summarized in a diagram as follows:-





JULY

2.2 SAP GL Component

2.2.1 GL Master Record

Each account used for posting is defined in the general ledger and contains information that reflects or describes its function. This information is stored in the master record of an account. It controls how business transactions are entered and posted to the account as well as how posting data is processed. G/L account master data is divided into two areas: -

Chart of accounts area: This area contains information that applies to the complete master record (G/L account number, account name, profit and loss account, or balance sheet account). In addition, you use it to store data that controls the creation of a master record in the company code (account group and screen layout). Company code-specific area: This area contains data that controls the entry of business transactions for the related account and account management in the respective company code (currency; open item management).

Line Item Display

A line item display provides an overview of the open, cleared, and parked items from an account. You determine which information about the individual line items is to be displayed on the screen. However, you can also change the view dynamically after the list of items has been processed. Various sort options (by assignment, document number, or clearing data) allow you to interactively select, vary, total and the required documents on the screen. Search and summarization functions are available on the initial screen as well, so it is not necessary to display all items. Line item display functions are available for all accounts in a company code, and also it can be enabled from any document at any time. A line item list can also be exported and processed further using a spreadsheet. You can file it as a PC file or you can store it directly in Microsoft Excel format and then process it in Excel.





JULY

Account Balance

Whenever documents are posted to an account, the system automatically updates the account balance. For GL accounts with line item display, it also indicates which items from a document are posted to the account. You can display the account balance and – depending on the account attributes – the line items for each account. The account balance offers an overview of transactions figures for each period by debits and credits. Possible differentiating criteria include account number, company code, fiscal year and currency.

2.2.2 GL Account Posting

Each transaction relevant to posting must be entered in the originating area of the company in compliance with all applicable posting rules. The precise, reliable, and complete recording and entering of all required data is only possible at the point of data origin. General ledger postings may be the result of:

Operational transactions (for example, issue of goods causes material issue posting) if the SAP Logistics system is active and integrated

Posting transactions in subsidiary ledgers (asset acquisition in fixed assets) if the SAP Asset Accounting (FI-AA) system is active and integrated

Transactions originally assigned to the general ledger, if the General Ledger (FI-GL) system is active

At the same time, interrelationships with Controlling and its components can be taken into account. The extent and type of the integrated systems used determine how entries, account assignments, and updates are processed for business transactions.





JULY

2.2.3 Reconciliation of Subsidiary Ledger

The chart of accounts, with its primary asset and balance sheet accounts provides the central posting link between the general ledger and the related subsidiary ledgers. The general principle of posting via reconciliation accounts is that each business transaction is simultaneously reflected in the subsidiary ledger as a line item and as a totals item in the general ledger via the assigned reconciliation account which is balance sheet account. As a result, updating is timely and automatic. Moreover, it ensures that:

General ledger and subsidiary ledgers are always reconciled

The effects of each posting on assets, liabilities and profit and loss are used immediately by the financial information system

2.2.4 Open Item Management

Open item management can be activated for each G/L account. It allows you to clear debit and credit postings by document.

Accounts with open item management can be updated when business transactions are processed/entered or by means of a

separate maintenance program.

2.2.5 Field Status Variant

Field Status Variant is grouping of individual Field Status Codes for a company code. A Field Status code is entered at the level of

GL account master data. It determines the screen layout during document entry. It controls which fields should be mandatory,





JULY

optional or suppressed at the time of data entry into any particular GL account. In this way, field status serves as a very effective

control mechanism to ensure completeness of data entry.

2.2.6 Posting GL Documents

In a manual process, ledger books are maintained to store accounting entries. In contrast, SAP uses document principle whereby accounting entries are kept in document database and can be referred to via document number. On data integrity side, SAP allows only balanced transactions to be posted. Additionally, changes are allowed for permitted fields such as text information. It is possible to post G/L documents via:

G/L document posting

Recurring entry Recurring entries are business transactions that are repeated regularly, such as rent etc. Recurring entry document is a reference document which contains data necessary for posting accounting documents, such as the amount, account number, and posting key. Control information such as Day of the first run, day of the last run, and scheduling dates are contained as part of the reference document. Using this document we can create the same entry at regular intervals as specified at the time of creating the entry.

Account assignment model Large transaction are sometimes time consuming and where the same has to be posted every month for example distributing telephone expenses to cost centers, SAP provides for a solution, where in these transaction can be stored in a skeleton mode and can be called upon for posting. An account assignment model can contain any number of G/L account items and can be used for creating a GL transaction. It is a set of GL account codes which are captured and stored and will be used for posting transactions using the same as reference.





JULY

Sample document Sample documents can be created which can be used as reference document for posting GL documents

Minimum data normally required to post a G/L document are:

Document header information e.g. posting date, posting period, document date etc.

G/L account number

Cost object assignment (for profit and loss elements)

Amount

Since sometimes not all the required data are immediately available, SAP also provides an option to temporarily keep the posting as statistical entry. Upon completion of all required data, the entries can be posted. This functionality is termed as Parking Document. It is recommended to use the Park document functionality to ensure that the document posting process will be monitored and postings are done after checking has been done. In addition, data from Park document can also be used for evaluation The following processes are proposed for GL document posting:





JULY

Start

Assign appropriate account codes and other information

Determine document type

Park the document

Verify the parked document

Post the document

Post the document

Is approval

required?

Approved?

No

Yes

Yes

No





JULY

Process Overview Explanation

Step Procedures

1 Assign appropriate account codes and other required information on the journal voucher.

2 Determine the nature of transaction and the relevant document type.

3 Create park journals based on the journal voucher. If the approval is not needed and all the details are available post the GL document and record the document number. If the document is parked do the following steps

4 Record document number generated by the system.

5 Edit/Verify parked documents.

6 Post parked documents if there is no error found.

2.2.7 Online Split

Document splitting enables a complex display of documents. Line items are split here for selected dimensions. This ensures that you can draw up complete financial statements for the selected dimensions at any time.





JULY

Using the document splitting procedure, you can also create a segmented display of a (partial) balance sheet according to a legal requirement (for example, IAS) or according to areas of responsibility. In addition, you can allocate at the time of posting additional costs (such as realized or valuated exchange rate differences) to the CO account assignment objects that incurred the costs. Assets can also be subsequently capitalized at the time of posting.

Define Zero-Balance Clearing Account Here you define a clearing account for account assignment objects for which you want to have a zero balance setting when the balance is not zero.

Define Document Splitting Characteristics for General Ledger Accounting

2.2.8 Month End Processing

Month-end closing comprises all activities involved in closing a posting/accounting period. Accounting period is a division of a company‟s fiscal year. The number of periods and definition of period are to be determined during configuration. Each posting into the system must be associated with an accounting period. This is to ensure that each transaction can be reported in the corresponding period. In the same token, periods must be controlled to ensure validity of the reports. The checklist for month end process will be documented after the Realization Phase of this project. The below proposed flow for month-end processing shall be used as a guideline for this blueprint as the activities may not be finalized until Realization phase.





JULY

Post outstanding general ledger entries

Execute recurring entry program

Execute foreign currency line item revaluation program

Execute GRIR clearing

Close past posting periods and open new opening period

Start

End





JULY


Step Procedures

1 Execute the recurring program and process the batch session.

2 Complete all the outstanding journal entries related to month end closing.

3 Process manual / electronic bank reconciliation.

4 Execute GR/IR clearing program to clear the matched GR/IR clearing transactions.

5 Revaluation of Foreign Exchange transactions

6 Close posting period to ensure no transaction can take place in that period and open new posting period.

7 Generate monthly reports:

Trial Balance

Profit & Loss statement

Balance sheet etc.





JULY

2.2.9 Fiscal Year and Accounting Posting Period

A fiscal year is generally a period of 12 months for which the company produces financial statements and takes inventory. It may or may not correspond to the calendar year. A fiscal year variant specifies the number of periods and special periods in a fiscal year and how the system is to determine the assigned posting periods. PRHPL‟s fiscal year is April to March. The end of a period is the last day of the calendar month. PRHPL will use the Fiscal Year Variant „V3‟ with 12 normal posting periods and 4 special periods to enable year end adjustment entries


Once a fiscal year is defined, it is possible to specify whether a period is allowed for posting or not. In order to standardize maintenance of accounting period especially across the group, SAP R/3 system allows the specification of open or close status to be maintained via a posting period variant. Separate posting period variants will be created for the 3 company codes. It will add the flexibility of separately managing period opening and closing for individual company codes.

Posting Period Variant Name Company code

1000 Planet Retail Holdings Private Ltd. 1000





JULY

Posting Period Variant Name Company code

1100 Supreme Tradelinks Private Ltd. 1100

2000 Quest Retail Private Ltd. 2000

2.2.10 Posting Key

A posting key is a two-character numerical key that controls the entry of line items. It is defined at client level and therefore applies to all company codes in SAP system. It is differentiated by the account types. It also controls the posting at the line item level. Standard SAP posting keys will be used.

2.2.11 Document Types

A document type is a key that is used to classify accounting documents and distinguish between business transactions to be posted. The document type is entered in the document header and applies to the whole document. The document types control the following: Document Numbering (external or internal), Account Types (Debtors, Materials, Assets, G/L accounts and Creditors) that can be entered in the document. PRHPL would use the standard SAP document types for the various types of transactions. Additional document types will be created if required.





JULY

Document Number Ranges

A document number range is linked to the document type via a unique key. It identifies the document number for each document type posted in the SAP. PRHPL will use the internal numbering for all the documents. Number ranges are specific to a fiscal year.

2.2.12 Retained Earnings Accounts

Before creating income statement accounts in the chart of accounts, it is required to specify the retained earnings account to which

profits or losses are carried forward. There is a special program designed to carry forward these amounts to this account, which is

part of procedures to opening of a new fiscal year in the system.

One income statement account type will be created for Planet Retail.

2.2.13 Account assignment with Customer types

Sales transactions with any of the Customer types are mapped to GL through Account assignment keys. The GL accounts identified to record sales of trading goods to any of the Customer types are as under:





JULY

Customer

Type

GL Account

description

System

Customer – Domestic

- Institutional

Sundry Debtors –

Domestic- Institutional

IS - Retail

Customers – Domestic

- Others

Sundry Debtors –

Domestic- Others

IS – Retail


- Consignment

Sundry Debtors –

Domestic- Consignment

IS – Retail

Customer - One time Sundry Debtors – One

Time

IS – Retail

Customer - Group

Companies

Sundry Debtors –

Group Companies

IS – Retail

Customer - Export Sundry Debtors - Export IS – Retail

Customer – POS One

Time -

POS





JULY

For sales through POS, customers may offer tender types having external Service providers e.g. Visa/Master/Amex etc., For

all external Service providers separate GL accounts will be maintained. For internal tender types e.g. Credit Note, Gift

Vouchers etc. tender type wise GL Accounts will be maintained. These GL Accounts will be non-Reconciliation Accounts and

will be open item managed.

2.2.14 Account assignment with Vendor types

Purchase transactions with any of the Vendor types are mapped to GL through Account assignment keys as well as Reconciliation account (control account). The GL accounts identified to record purchases to any of the Vendor types are as under:

Vendor Account Group Description

GL Account description

Vendor - Trade Domestic

Sundry Creditors – Trade - Domestic

Vendor - Trade Import

Sundry Creditors - Trade – Import

Group Company – Trade

Sundry Creditors - Trade - Group Companies

Vendor - Non-trade Domestic

Sundry Creditors - Non-Trade-Domestic

Vendor - Non-trade Import

Sundry Creditors - Non Trade – Import

Group Company - Non Trade

Sundry Creditors – Non Trade - Group Co





JULY

Vendor - CAPEX Domestic

Sundry Creditors – Capital Goods - Domestic

Vendor - CAPEX Import

Sundry Creditors – Capital Goods - Import

Vendor – Service Sundry Creditors – Services

Vendor - Rental Sundry Creditors - Rental

Vendor - Employee

Sundry Creditors – Employees

Vendor - One Time Sundry Creditors - One Time

Control GL account will be within number range (130000-139999). Special GL indicator transaction will be mapped based on requirement to account the advances received and paid and deposit made and received accordingly.

2.2.15 Cash Journal

SAP provides the functionality of Cash journal for petty cash management. Cash journal provides a very precise method for petty cash management with simplified transactions for cash expense and cash revenue. Functionalities such as opening cash, total cash expense, total cash revenue, closing cash for particular periods (day, week, month) etc are available readily. By definition, cash journal is used for petty cash management and as such, cash journal doesn‟t provide functionalities for vendor or customer account clearing at the time of data entry. Planet Retail maintains petty cash at individual stores. Therefore, a separate cash journal will be maintained in the IS Retail system for each individual store. Every store will intimate corporate office about cash transactions which will then be entered into the system. Triversity cash management functionalities are also being explored to aid in the cash management process and making entries at the store level.





JULY


1. SAP introduces structured and integrated approach to GL accounting 2. GL Master Data definition facilitates control mechanism such as mandatory or optional fields whenever there is any

posting into a GL account. 3. Document types and corresponding number ranges depend upon the business transaction under consideration which

assists in ease of use and reporting. 4. Concept of Posting Period facilitates centralized management of transaction entry. 5. SAP enables fast data entry with tools such as recurring entries and sample documents. 6. SAP follows the concept of sub-ledgers for accounts receivables, accounts payables and asset accounts leading to

transparent management of accounting entries.

2.4 Additional Points (from Open Items list and SAP Recommendations)

Area Approach Status

Fiscal year extension to be checked.

Will be demonstrated Closed - can be done. Core team has to develop expertise for such changes in the basic system design. PwC will provide training towards that.

Current balance should be shown while entering the voucher

Standard SAP doesn't show balances on document entry screen.

Closed by PRHPL





JULY

Vehicle wise costing - Fuel expenses, repairing (in case of different cost elements.), employees cost with more than one cost element, details of telephone expenses location wise and employee-wise.

Solution proposed - Usage of internal orders.

Closed – It would be done through internal orders

Activity Analysis of Cost elements. i.e. advertisement expenditure may be bifurcated into PR, Direct Marketing, Newspaper, Radio, SMS etc.. Likewise legal & professional fee and others.

Solution proposed - Usage of internal orders.

Closed –it will be done through internal orders

Insurance tracking-Open Insurance/ tracking of inventory/cash in chest etc. and expiry.

No development is required at this stage. It will be routed through service entry sheet. However reports should be available.

Closed

A Separate Trial Balance showing un approved entries in separate column

GAP Closed

Drilldown reporting required up to lowest level

Standard reports are available Closed

Consolidated Balance Sheet of holding company and subsidiaries

SAP component SEM (Strategic Enterprise Management) can address consolidation requirements. SEM is outside the project scope. Summation of financials will be available at GL level in standard SAP system, but

Closed





JULY

elimination of common transaction balances will be done manually.

Allocation of common Corporate / divisional expenditure to different brands/companies may be made on the basis of certain parameters given to system.

Possible. Details will be handled during realization phase.

Closed

Trial balance and financials (for internal reporting purpose) should have provision of memorandum entries (off line) which have not to be passed instantly in the books of accounts. There may be two columns extra as additional amt. for adjustment in financials in trial balance offline the books.

GAP. (SAP provides functionality for Noted Items. But noted items will not appear in Structured Financial Statements (transaction F.01).

SAP suggests usage of Parked document facility. PwC is not certain about the applicability of park documents for the purpose. PwC is of the opinion that z-development is required. In any case, core team should take decision only during realization phase.

Reports-CF/ fund position on daily basis, CMA data, Inventory reports / other reports

SAP provides cash flow for existing data. Standard SAP system doesn't provide projected cash flow. Projected cash flow will be a Z report. Projected cash flow may be entered into system and system will give variance report. Projected Cash flow cannot be prepared in the system. Actual cash flow as desired would be available.

Closed

BBP doesn‟t contain anything on travel management. Complete

Functionalities such as down payment for travel and subsequent actual

Closed





JULY

information on employee wise travel cost with fields such as place of travel, period, mode of travel, fare, conveyance, hotel and other expenses are required.

expense bookings are available in standard system. However, z-development is needed to capture details such as place of travel, period, mode of travel, fare etc.

FBT process requirement has not been defined in the BBP document; We have learned that for each FBT liable expenses additional GL account will be created for identification of FBT.

SAP has suggested a different approach to manage FBT using tax codes. We agree with the suggested approach, and core team will be provided both the options.

Closed

Custom Reports – PwC will provide a list of standard report (with details) and on that basis, custom reports will be decided.

Custom reports will be decided during realization.

We understand that business place and section code will be created for each of the company code. However BBP document is silent on the number of business place and section code will be created.

Exact codes for Business Place and Section Codes will be part of configuration document, and not the blueprint document.

Ok. State wise information will be provided

Period End process is discussed in isolation in various BBP. Implementation of fast close and schedule manager is not discussed in BBP.

Fast close and Schedule Manager are User Convenience tools which will be discussed during realization phase.

Ok





JULY

Master data template needs to be identified.

Master data templates will be defined during Realization Phase.

Ok

Schedule VI requirement for the external reporting requirement should be identified as development.

Agreed.

Ok

Roles and responsibility details for end users needs to be finalized.

These will be completed during 'Go-Live Preparation" phase.

Ok

Consolidated reporting required for multi-brand concepts like FashionCube i.e. consolidation of all brands of one store irrespective of company code

Will be provided by using Profit Center Accounting component

Closed

Business Plan at Group Level, Company wise Brand wise store wise. Allocation of expenditure and consolidation.

Business plan would require budget processing in SAP. Budget planning cannot be fully automated on SAP as budget planning requires human judgement and intervention. Budget functionality will be demonstrated on SAP to core team. For allocation of expenditure, it is possible.

Closed - Budget preparation should be outside SAP system on Excel. Prepared revenue and expense budgets can be entered into SAP system at the level of individual profit center and cost center. SAP can track actual revenue and expenses, and provide variance reporting.

Calculation Deferred Tax/ Income tax etc.

Not possible with standard SAP. Z development required

Closed

Reporting of expenditure and Standard reports are available Closed





JULY

earnings in foreign currency

Cost accounting for manufacturing activities

As per standard SAP Closed

Interest Calculation on ICDs/ Unsecured Loans / FDs/ Investments/Debtors & creditors/ Buyers Credit/business deposits

Standard interest calculation functionality will be used

Closed

Financials –Monthly basis in prescribed format at Group level, company level, Brand level, Store level, Concept level, Zone level, Division level like retail/wholesale.

Will be made available by using Profit Center Accounting

Closed

TDS entry should be after making gross amount or a separate report should be there to reconcile vendor account.

Vendor account will be credited by net of TDS amount as per standard SAP. For reconciliation purposes, a z report can be developed specifying gross amount, TDS and net amount.

Closed

There should be advance expenses and prepaid expenditure module separately for running to pass necessary entries regarding adjustment of advance of prepaid expenses in respective month.

Ok Closed

Advertisement exp – PO will be raised and invoices will be booked as per IV. System will provide tracking of PO, activity analysis and event tracking

Service entry sheets along with Internal Orders will be used to address the requirements.

Closed





JULY

Trial balance may have column s for opening balance, MTD, YTD. It should also have facility for multiple MTDs.

Standard reports will be studied. If deemed unsatisfactory, z-report may be developed if needed.

Closed

Day books and reports containing voucher numbers, amount etc


Closed

System should support extraction of reports/ information / account for more than one year in one shot


Closed

Filtering system on date or transaction or amount wise. Access of voucher directly through ledger.


Closed

Depiction of check no, date, invoice no, date etc along with offset account in ledger/reports


Closed

Report on unapproved vouchers Ok Closed

Query module to know entries pertaining to certain amount, document no etc

Ok Closed

System should not allow any invoice no or check no twice

Ok Closed

Reports like GL, sub-ledger, trial balance main a/c, sub-ledger trail balance, complete trial balance sub-ledge wise, trial balance site wise, division wise, cash position etc

Ok Closed





JULY

Accounts Payables

3.1 General Explanations and SAP FI – AP Component Overview

Accounts payable maintains the records relating to all the vendors and it is closely integrated with the procurement and

inventory management system. Any transaction in procurement, which has a financial implication, would have to automatically

be reflected in accounts payable as well as the general ledger. It would also require settling payments against appropriate

outstanding and settling advances against appropriate invoices.

3.2 SAP Solution Component – Accounts Payables

3.2.1 Master data creation

Vendor Master Data (General data, Company Code data, and Sales Area/Purchase Org. data) will be created centrally. The

vendor number range will be controlled by the Vendor account group. Certain fields in Vendor Master will be used to indicate

purchases from Group Companies & SSI vendors.

The vendor master record contains all the information a company needs for its business relationships with vendors. This data

controls the posting transaction as well as the processing of posting data. Both the accounting and purchasing departments use





JULY

the master record for this purpose. Vendor master records are centrally stored in the system. This ensures that data is always

consistent, up-to-date and without duplication.

The following Vendor types & Vendor Account groups have been identified:

Vendor Account Group Description Vendor Account Group

Vendor - Trade Domestic ZVTD

Vendor - Trade Import ZVTI

Group Company – Trade ZVGT

Vendor - Non-trade Domestic ZVNT

Vendor - Non-trade Import ZVNI

Group Company - Non Trade ZVGN

Vendor - CAPEX Domestic ZVCD

Vendor - CAPEX Import ZVCI





JULY

Vendor – Service ZVSE

Vendor - Rental ZVRE

Vendor - Employee ZVEM

Vendor - One Time ZVOT

3.2.2 GL Master – Account assignment

Purchase transactions with any of the aforesaid Vendor types are mapped to GL through Account assignment keys. The GL

accounts identified to record purchases from any of the aforesaid Vendor types are as under:

Vendor Account Group Description

GL Account description GL Code

Vendor - Trade Domestic

Sundry Creditors – Trade -Domestic

Vendor - Trade Import

Sundry Creditors - Trade – Import

Group Company – Trade

Sundry Creditors - Trade - Group Companies

Vendor - Non-trade Domestic

Sundry Creditors - Non-Trade-Domestic





JULY

Vendor - Non-trade Import

Sundry Creditors - Non Trade – Import

Group Company - Non Trade

Sundry Creditors – Non Trade - Group Co

Vendor - CAPEX Domestic

Sundry Creditors – Capital Goods - Domestic

Vendor - CAPEX Import

Sundry Creditors – Capital Goods - Import

Vendor – Service Sundry Creditors – Services

Vendor - Rental Sundry Creditors - Rental

Vendor - Employee

Sundry Creditors – Employees

Vendor - One Time Sundry Creditors - One Time

The account numbers will be in the number range (130000-139999) in accordance with the chart of account defined in BBP-GL

section.

Master data maintenance (edit, updation) & authorization

Core team will identify the strategy for Vendor Master Data maintenance under guidance from PwC consultants. Importantly, any

change in credit period, credit limit, tax status, tax code, discounts offered, bank details etc. will have to be finally authorized by

Finance & Accounts department.





JULY

3.2.3 Goods Receipt, Invoice Verification & Accounting in A/P

The Accounts Payable module is integrated with the Purchasing (MM) module.

The process of goods receipt involves the followings steps (fully dealt with in SAP MM BBP document) applicable to Vendor

types Trade Domestic, Non-Trade Domestic, Trade Import, Non-Trade Import, Capex Domestic, Capex Import & One Time

Vendors.

For Vendor types Employee & One Time Vendors (non-GRN related) invoices are to be recorded in A/P.

For Trade Vendors/One time Vendors –

(On receipt of goods)

Inventory Dr

To GR/IR A/c (Vendor type wise) Cr

(On invoice verification)

GR/IR A/c (Vendor type wise) Dr (Recording of Invoice)

Input VAT A/c Dr (Where VAT is applicable)

To Sundry Creditors (Vendor type wise)





JULY

For Non Trade/Service Vendors

(Non GRN Purchases)

Expenses A/c Dr (Relevant G/L Account)

To TDS A/c (Where Applicable)


For Capital Goods Vendors

Purchase of asset

CWIP A/c Dr

To Sundry Creditors- Domestic / Import Capital Goods

(With statistical posting to Internal Order where budget values are maintained)

For Employees

Salaries A/c Dr

To Sundry Creditors- Employees or Salary payable

To TDS (Salary deductions)

To PF Payable

To ESI Payable

To Employee Housing Loan





JULY

To Advance against Exp / Loan

3.2.4 Payments to Vendors

Payment modes

Payments to Vendor type Trade Domestic, Non-Trade Domestic, Trade Import, Non-Trade import, Capex Domestic, Capex Import,

Service Vendors & One Time Vendors may be made using the following payment modes:

1. Cash - This will be a FI entry upon payment & posted to vendor sub-ledger.

2. Cheque – Vendor payment to settle the domestic vendor invoices is usually carried out by cheque

3. Demand Draft

4. Wire Transfer

5. Bank Letter

6. RTGS

7. NEFT

8. Buyers‟ Credit

9. Letter of Credit (LC) – For Imports, Letter of Credit is the normal mode of securing payment to vendors. Depending on the

terms of L/C, the negotiating bank will deliver documents of title to the import consignment to PRHPL & debit PRHPL A/c for

remittance of the invoice proceeds to the vendor.

(In case of additional requirements, new payment methods may be created.)





JULY

Payment process

SAP uses document principle to store transaction entries. In the case of vendor, transaction of invoices will be stored as open

items. Open items are in fact outstanding transactions.

The open items of an account can only be cleared when an identical offsetting amount to the account is posted. The balance

resulting from the items allocated to each other must therefore be zero. Correspondingly, the offsetting entry here represents

outgoing payment to vendor (bank).

In SAP, manual outgoing payment is generally performed for a small number of payments on ad-hoc basis.

Payment made to vendors may not always be straightforward; therefore the system is configured to handle various scenarios as

follow:

Partial Payment, where the original open item and the partial payment remain as open documents on the account. When user posts the remaining amount for the invoice, both the partial payment and the invoice are cleared.

Contra of vendor and customer balance is handled automatically by the system. In order to activate contra balance, vendor and customer have to be linked in the vendor and customer master record.

The following process is proposed for manual outgoing payment





JULY

Start

Identify the vendors and invoices to be paid

Determine the bank account and check lot

Identify whether to use complete payment, partial payment

or residual payment method for each invoice

Park the payment document

Post the document

Approval

required?

Approved?

No Post the document

Yes

Yes

No





JULY


The designation of bank accounts for payments, creation of House Bank for APP, loading of cheque for APP printing run etc. will

follow standard SAP A/P process.

For payments to vendors, the following accounting entries will be passed: Sundry Creditors (vendor type wise) Dr.

To Bank -Payment (designated bank)

For bank accounts having automated bank reconciliation facility, the payment entry will be mapped to Bank - Payment A/c in the

GL.

Advance payment to Vendor (Vendor Down Payment Processing)

Normal payment to vendor is carried out against claim for goods delivered or services rendered i.e. payables. However sometimes

vendors might request payment before delivery of goods or services.

This type of payment is known as down payment and is shown on the asset side in the balance sheet as advance to suppliers. In

the normal business flow, down payment should be cleared with the closing invoice upon delivery of goods or services.





JULY

For Advance payment to Vendor, the following entry will be passed:

Sundry Creditor (vendor type wise)………Dr.

To Bank – Payment a/c

However, a Special GL indicator will be used for the advances paid to vendors for segregation of Dr. balances in vendor A/c.

3.2.5 Purchase return & adjustment of Vendor account

Purchase return to Vendor types Trade Domestic, Non-Trade Domestic, Capex Domestic, Trade Group Companies, Non-Trade

Group Companies & One Time Vendors will be handled at DC. Generally damaged, short expiry or defective goods will be returned

to Vendors by way of Return Order at DC. Vendor account will be directly debited on the basis of the Return Order at the DC. The

following accounting entry will be passed on purchase return:

Sundry Creditors (Vendor type wise) Dr.

To Input VAT A/c

To inventory A/c

3.2.6 Purchase of Fixed Assets

Most of Purchase of Fixed Assets will be carried out at HO. However, some purchases may be effected at stores also.

For Fixed Assets, GR will be based on invoice / challans signed by Projects evidencing delivery & acceptance.





JULY

Upon invoice verification IR will be raised at HO for posting to vendor A/c.

For Asset Class Plant & Machinery Input VAT may be availed of for which the necessary entries will be passed. The Input VAT will

be posted to a separate GL A/c & credit availed of in installments.

For Store capex, going through a period of construction, all purchases are pooled in CWIP A/c. With effect from the date of store

launch, the Fixed Assets are capitalized by transfer of accumulated costs to the relevant Asset A/c & crediting CWIP.

For discrete Fixed Assets, all purchases will be routed to CWIP A/c. These will be capitalized on the date(s) put to use by transfer

of cost from CWIP A/c to the respective Asset A/c.

3.2.7 Off Invoice Recoveries from Vendors

Vendors/Manufacturers also routinely offer special discounts / turnover discounts linked to off-take of a specified SKU e.g. %

rebate on total purchases in a month/quarter/year etc.

Quantity or value based rebates are also offered by some vendors/manufacturers for specific periods e.g. buy x quantity of a

product and get Rs. y off on each, redeemable only after x quantity has been lifted.

Vendors/ Manufacturers participate in the monthly promotions carried out in the stores where they agree to fund the promotions

specific to their products. Such funding is done by either reimbursing the discounts / promotional offer or on the total quantity

purchased. Reimbursement could be by way of payment against debit notes to be raised or by providing free goods to the value of

promotions.





JULY

All such „off-invoice‟ rebates & discounts are a part of the agreed terms of trade linked to purchases & will be maintained as

purchase price conditions in the Price Master in SAP MM module at article level & tracked against the relevant parameters viz.,

volume & value of purchases. Vendor wise Rebates & Discounts will be accrued every time a GR/IR or IV happens with respect to

the article/vendor/site (DC) or site group combination. FI will execute the relevant program to generate the Debit Notes. These will

be automatically recorded in A/P. The following illustrative accounting entry will be passed to record R&D Income:

Sundry Creditors – Trade Domestic……….Dr

To Rebates & Discounts

3.2.8 Purchase on Consignment

PRHPL buys goods on consignment under purchase on sale/approval basis. Vendor supplies the goods to company. Company

physically receives the goods/articles into its stores whereas the liability towards vendor is not booked at the goods receipt stage.

Model 1: Articles on consignment will be accepted on the basis of purchase price agreements with consignor & follow the standard

SAP goods on consignment process. The agreed purchase price will be maintained as Purchase Info Record. The articles on

consignment will be taken into stock by non-valuated GR & tracked by quantity only. Accounting of consignment purchase will be

made on the basis of sales.





JULY

On the basis of sales, PO will be raised for consignment purchase corresponding to quantity sold at the purchase price maintained

in the Purchase Info Record. The consignor will be required to furnish his invoice based on the PO. The following accounting entry

will be passed to regularize the consignment purchase.

(i) Inv A/c ………Dr.

To GR IR A/c

(ii) GR IR A/c………………………. Dr.

Input VAT A/c ………………… Dr.


The system should take care of goods return from end-customers and adjust inventory and vendor accounts accordingly.

Model 2: Vendor sends the goods to company for sales, and company is paid commission at rates as per agreement. The accounting entry is slightly different at the sales stage. Instead of crediting sales revenue account, the vendor account is debited and commission revenue account is credited.

Cash A/c Dr

To Sundry Creditors (vendor type wise)

Sundry Creditors (vendor type wise) Dr

To Commission on consignment a/c





JULY

There should also be provision to capture minimum guarantee amount for both the above cases.

(Model 2 will be explored in details during the realization phase.)

3.2.9 Recurring entries, Accrual of liability & reversals

Expenses of a recurring nature & fixed amounts that are accrued monthly/periodically during the fiscal year may be accounted for

using the standard SAP Recurring Entry module in A/P. These would typically relate to Rent, Rates & Taxes, License Fees etc.

The accounting entry will be:

Expense A/c…………………………Dr.

To Prov. for Liability – Non-Trade Services

Upon receipt of invoice for services rendered & verification thereof the following entry will be passed:

Prov. for Liability – Non-Trade Services……Dr.

To Sundry Creditors – Non –Trade Services

3.2.10 Vendor outstanding ageing analysis

Ageing of Vendor accounts will be done from invoice date(s) of open invoices following standard SAP application. Ageing of

unadjusted Debit notes may also be done by using separate filter by document type in the Vendor account. Standard SAP system

doesn‟t provide reports for ageing analysis based upon receipt date (GRN date), due date and statement account date. Ageing

analysis report runs on the basis of posting date of invoice. Z-report may be developed if ageing analysis is required on the basis of

dates other than Posting date.





JULY

3.2.11 Staff Advance and Claim Processing

This process involved the preparation and submission of staff advance and follow by the claim processing. The claim will be

matched with the advance to determine the next step of action. A special GL indicator will be created to track different types of staff

loans & advances.

3.2.12 Period End Processing

Once all documents are completely posted and payments for the month are completed, the posting period for vendors can be

closed. This is to prevent the occurrence of back posting invoices to the previous period after reports are generated.

Before posting period can be closed, other month end processing activities such as executing the recurring program need to be

performed if applicable.


Step

Procedures Responsibility

2. Accounts Executive posts the outstanding documents including parked documents

3. Execute recurring program, if applicable.

4. After completion of all the additional postings, close AP posting period and open the new period.

5. Generate month end reports:





JULY

a. Vendor Balances b. Open Items, etc

3.3 SAP Solution Technical Details – Document Type, Number Ranges and Posting Key

Document Type and Number Ranges

The document type classifies accounting documents. It is noted in the document header.

The document type is used:

To differentiate business transactions

To control what type of account can be posted to (customer, vendor, general ledger, asset or material)

To control document number assignment

As a search criterion for document information The following standard document types will be used by for AP postings: -

Document type

Description Number range

KA Vendor document

KG Vendor credit memo

KR Vendor invoice

KZ Vendor payment

Posting Keys

The posting key describes the type of transaction, which is entered in a line item.





JULY

Posting key controls document entry. The important properties that are derived from the posting key are:

The account type

The allocation to the debits or credits side

The possible or necessary specifications which are to be entered in the line item The following SAP standard posting keys will be used: -

Posting Key Description Debit/Credit

Account Type

21 Credit memos Debit Vendor

22 Reverse invoice Debit Vendor

24 Other Receivables Debit Vendor

25 Outgoing payment Debit Vendor

26 Payment difference Debit Vendor

27 Clearing Debit Vendor

28 Payment clearing Debit Vendor

29 Special G/L debit Debit Vendor

31 Invoice Credit Vendor

32 Reverse credit memo

Credit Vendor

34 Other Payables Credit Vendor

35 Incoming Payment Credit Vendor

36 Payment difference Credit Vendor

37 Other Clearing Credit Vendor

38 Payment Clearing Credit Vendor





JULY

Posting Key Description Debit/Credit

Account Type

39 Special G/L credit Credit Vendor


1. Vendor master data management is centralized with finance and materials management using the same data about vendors.

2. SAP enables real time integration of purchase with accounts leading to immediate reflection of business transaction into accounts.

3. Real-time integration of FI and MM facilitates elimination of redundant data entry as well as auto-reconciliation of purchase and vendor accounts.

4. Vendor payment process is structured and in alignment with global best practices. 5. Maintenance of supplier account in multiple currencies. 6. Matching functionalities are available for payables such as custom duty, clearing & forwarding charges etc (direct

expenses paid / accrued and charged to inventory). 7. Automation of foreign exchange fluctuation at the time of payment. 8. PO wise tracking for advance payments to vendors.



Pay Batch Advice Process and approval process

User has to be aware of the House Bank which is to be used prior to specifying which invoices are being cleared. SAP doesn't provide facility to change house Bank later.

Closed - follow standard practice.

Auto reco of supplier accounts It is not recommended to upload statements Closed - Take data from





JULY

received from your business partners into SAP system. However, if you want to do this, we need to identify a format in which your business partners will provide the account statements.

SAP, and do reconciliation on Excel.

The system should give indication in case of major differ in costing and existing weighted average rate.

GAP Closed - Non merchandise will be through purchase info.

Purchase returns with information of invoice number and actual rates/scheme effected in last 12 months

If reference to purchase return is not available, system will show a list of purchase made of that particular article for last 12 months. User will take further action based upon the displayed list.

Closed

In case of electricity payments the report may also give information about meter reading if possible

It will be done through Statistical Key Figures (SKF)

Closed

PDC Management in case of PDC issued as well as PDC received and accounting treatment and Reports showing PDC Received, Banked, PDC in hand and due for banked for a particular date

Standard SAP doesn‟t have any dedicated functionality for PDC as PDC are a form of guarantee (and not an actual accounting transaction). As a workaround, a separate payment method can be created for PDC which will allow entries into account such as PDC Issued and PDC Received.

Very limited use of future dated PDC is recommended (two months max.) and testing to be done when system becomes ready. Or though recurring entry system.

Report – related to filing Return of TDS on Salary – Form 24 &

HR-Payroll component. (in second phase) Closed





JULY

other TDS Returns

Statement of outstanding/dues invoice wise and also showing PDC cheques received or paid

Will start with standard report and if need, will go for z development later.

Closed

TDS processing in case of advance payments and invoicing – whichever is earlier

Standard process OK

Issue of money receipt Reports to be developed Closed

Payment Advice Possible Closed

BOE should be prepared by the system for tallying with actual BOE or E filing.

Third party application. To be discussed with GCI

Closed

Reports pertaining to Bank Guarantee/LC-Issue date expiry date, Margin money with bank etc. likewise buyers‟ credit etc. FD tracking with LC.

Basic SAP demonstration will be done if not suitable then z development will be thought, if needed.

Closed

A facility to generate advice of outstanding to employees / debit note/ credit note to parties.

Standard report will be demonstrated. If not suitable, Z- Development, if needed.

Closed

A report of vendors showing SSI/ MSI for balance sheet purpose

Ok Closed

INR account of supplier should have foreign exchange rates

Standard report will be demonstrated. If not suitable, Z- Development, if needed.

Closed





JULY

Accounts Receivables

4.1 General Explanations

Accounts receivable will record and manage the accounting data relating to all customers. It is closely integrated with the sales management component. Any transaction in sales, which has a financial implication, will be automatically reflected in accounts receivables as well as the general ledger. Also, different G/L accounts will be affected based on the nature of the transaction. The events in this process are:

Generation of accounting document for receivables based on an invoice or credit memo.

Receipt of advances

Monitoring of outstanding in customer accounts.

Collection from customers.

Accounting of collection from customers against relevant outstanding.

Credit Management for customers

Tender type collection process





JULY

4.2 SAP Solution Component – Accounts Receivables

4.2.1 Master data

Customer Master Data (General data, Company Code data, sales Area data) will be created centrally. A customer maser record contains all the information that a company needs for carrying out business with the customer. This data controls the invoice posting procedure and subsequent processes such as receipts. Central management of customer master data leads to availability of consistent and up-to-date information to all functional departments of the organization. The following Customer types & Customer Account groups have been identified:

Customer Type Account Group Sales thru

Customer – Domestic –

Institutional

ZCIN IS -Retail

Customers – Domestic -

Others

ZCOT IS –Retail

Customers – Domestic –

Consignment

ZCCO IS –Retail

Customer - One time ZCON IS –Retail

Customer - Group

Companies

ZCGC IS –Retail





JULY

Customer - Export ZCEX IS –Retail


Time

- POS

4.2.2 GL Master – Account assignment

Customer masters are assigned with the reconciliation account based on customer type mapping as below – (GL account code

numbers will be in the range (230000-239999))

Customer

Type

GL Account

description

GL

Account

Customer – Domestic

- Institutional

Sundry Debtors –

Domestic- Institutional


- Others

Sundry Debtors –

Domestic- Others


- Consignment

Sundry Debtors –

Domestic- Consignment

Customer - One time Sundry Debtors – One





JULY

Time

Customer - Group

Companies

Sundry Debtors –

Group Companies

Customer - Export Sundry Debtors - Export


Time -

4.2.3 Master data maintenance (edit, updation) & authorization

Customer Master Data maintenance is centralized with both SD and FI contributions. However, any change in credit period, credit

limit, tax status, tax code, discounts offered, bank details etc. will have to be finally authorized by Finance & Accounts department.

4.2.4 Credit control & management

Customer credit management offers the option of making order acceptance dependent on an assessment of a customer‟s creditworthiness. This is done through a credit limit. The limit is checked in financial accounting and sales upon posting. If the limit is exceeded, the system issues a warning or an error message, depending on setup. Other actions can follow. An example would be an examination of the customer or a block on the master record. Credit limits may be assigned at various levels. Credit limits are assigned and monitored using “credit control areas." A credit control area consists of one or more company codes. If a credit control area has been set up and a preset value has been indicated for a customer, then the credit master record is automatically set up when a customer master record is set up.





JULY

4.2.5 Accounting of POS Sales

4.2.5.1 Tender Types

For sales made through POS, account receivable from service providers will be accounted through Tender Types. Service

Providers Account will be maintained in GL for each tender types. These GL Accounts will be Non-Reconciliation accounts and

will be open item managed.

To capture and for clearing transactions store wise unique MIDs will be used.

The following Tender types for receipt are envisaged:

i) Cash – Legal tender in INR notes and coins.

ii) Credit card/Debit card – Generally accepted debit/credit cards approved by HO and readable by EDC machines e.g.

Visa/Master/Amex.

iii) Cheque / DD/Pay order

iv) Gift Voucher – This is a special Tender type. These vouchers will be redeemable within a limited validity period.

Accordingly a note will have to be given on the gift voucher.

v) Credit note – Issued to any customer for return of articles sold to be exchanged for fresh article.

Any combination of the above tender types will be activated at POS.

4.2.5.2 Accounting of Sales

Accounting of sales to customers billed through POS will be as under:





JULY

At POS day-end, the aggregated POS data containing item wise sales total & sales returns will be sent to SAP from POS back-

end;

Sales data from POS will be recorded using the following scheme of entries:

Sales Clearing A/C (site as a Customer) …..Dr.

To Sales Retail A/c

To Output VAT/Sales Tax payable (Site wise) A/c

4.2.5.3 Accounting of Tender types

For Tender type payment card, separate GL accounts will be maintained for the respective service providers, for site wise

identification of the service providers unique MID (Merchant ID) nos. will be assigned. Account and the transactions under this

account for any store will be identified with a unique MID. The same MID will be given to POS for correct accounting of receipts

through Triversity. These GL accounts will not be reconciliation accounts in nature & and will only be open item managed on the

basis of these unique codes.

The credit entries will be captured MID/Store ID wise & collections cleared against the respective MID/Store ID.

On the basis of the aggregated cashier declaration and the reconciliation of the sales with collection (as per the tender type) the

following illustrative entry will be passed -

Cash at Store A/c……Dr. (For tender type Cash store wise)





JULY

Credit Card Receivables-Bank….. A/c ….Dr. (For tender type Debit/Credit Card store and bank wise)

Gift Voucher Redeemable A/c Dr.

Credit Note Payable A/c Dr.

Discount ……..…. Dr. (For all promos/discounts offered at POS – discount type wise including GV coupon scheme)

Cashier Shortage/Excess A/c….Dr. (For aggregated daily shortage)

To Sales Clearing (site as a Customer) A/c

To Gift Voucher Redeemable A/c

To Credit Note Payable A/c

4.2.6 Accounting of Wholesale

Sales to Customer types Institutional, Group Companies etc will be recorded using the following scheme of entries:

Sundry Debtors (type wise).. Dr.

Discount on Sales (type wise)…Dr. (For all discount and promotions)

To Sales – Wholesale

To Output VAT/CST Payable

Sales to Customer type Export Customer will be recorded using the following scheme of entries:





JULY

Sundry Debtors – Export Dr.

To Sales - Export

4.2.7 Accounting of incoming payments from customers

Incoming payments from Customer types Institutional, Group companies etc will be recorded using the following entry:

Cash /Bank – Receipt A/c Dr

To Sundry Debtors (type wise)

Incoming payments from Customer type Export Customer will be recorded using the following entry:

Bank – Receipt A/c Dr

Bank Charges Dr

Exchange Loss A/c Dr. (On account of loss due to exchange fluctuations)

To Sundry Debtors - Export

To Exchange Gain A/c (On account of gain due to exchange fluctuations)

For recording incoming payments from Customers, the standard SAP incoming payments entry process will be used.

4.2.8 Accounting of advances from customers

Advance payments from Customers (applicable to Customer types Institutional, Group Companies, Export Customers etc) will be

recorded using standard SAP down payment entry & down payment clearing process using Special GL indicator.





JULY

4.2.9 Discount on Sales

Vendors/Manufacturers routinely offer promotions/schemes to customers at PRHPL stores. While these promotions are run by

PRHPL & offered to end-customers by way of Rebates & Discounts, these are backed by written arrangements with vendors /

manufacturers & are reimbursable by them. The different types of Rebates & Discounts, account assignment & accounting

treatment are as under:

Discounts (R&D) offered to end-customers

R&D such as price offs, schemes like buy one get one free, value offers, free gift etc. recoverable from the

vendors/manufacturers either fully or partially depending on the arrangement with PRHPL.

R&D such as exchange notes, paper cuttings/inserts, scratch and win offers etc. recoverable from the

vendors/manufacturers on the basis of physical copies of the offer documents.

System can keep track of such kind of promotions. SAP will provide reports with details under such promotions. Subsequent

reimbursements will have to be calculated on the basis of such reports, and entered into the system.





JULY

4.2.10 Display Income

PRHPL routinely offers various merchandising options to its trading partners for display & promotion of their articles/brands in the

stores. These are called Display-space Assets (DA) e.g. Bay Headers, 5-Tier Bins, Gondolas, Floor stacks, Aisle Banners etc. By

executing the relevant program, Debit Notes will be generated on the vendors/manufacturers & recorded in the A/R by passing the

following entry:

Sundry Debtors……….Dr (type wise)

To Display Income……….Cr

4.2.11 Sale of Gift Vouchers

PRHPL offers Gift vouchers/Coupons to customers, redeemable against purchases made at any store. The Gift vouchers/Coupons

will be created as articles in the SAP MM module. These articles will be batch managed to carry information such as GV serial no,

issue date, quantity, denomination etc. These articles will be carried at zero value. Bulk sales to corporate may be at HO. Stores

will normally sell Gift vouchers/Coupons singly. On sale of Gift vouchers/Coupons at HO in bulk, the following accounting entry will

be passed:

Bank/Cash………………………Dr.

Discount on Gift Vouchers A/c …..Dr.(For bulk discounts offered to corporate)

To Gift Voucher Redeemable A/c





JULY

If gift vouchers are bar coded, SAP BW will be required to manage reporting if number of gift vouchers becomes very high leading

to enormous quantity of data. As of now, we do not foresee such high numbers of gift vouchers. Therefore it can be managed

without BW. If in future, number of gift vouchers becomes very high, the POS has to send back the details of sales along with the

bar code details to be updated on the SAP BW module. Similarly, Gift vouchers/Coupons sold from HO will be updated in the SAP

BW module.

4.2.12 Redemption of Gift Vouchers

Customers may produce Gift vouchers/Coupons for redemption at any store at the time of settlement of sale transactions. Upon

redemption, the serial number of the gift voucher redeemed will be captured at POS and sent to IS Retail for matching against the

serial numbers of gift vouchers sold to derive the outstanding liability on account of gift voucher by serial numbers. This will also

facilitate a check on pilferage or fraud. At the time of redemption the following entry will be passed:

Gift Voucher Redeemable A/c……..Dr.

To Sales – Retail A/c

Since Gift vouchers/coupons is a Tender type, the above entry will be combined with the normal sale entry described earlier.

4.2.13 Treatment of Items issued for repairing / free sample / consumption / non-return samples etc

Planet Retail issues sample articles which may be returnable or non-returnable. The returnable items may be issues to employees.

Planet Retail has to keep track of articles issued in such manner till the time they are returned back. From financial accounting

point of view, issuance of returnable articles should not trigger any entry in the nature of material consumption. Logistics





JULY

component will manage issuance of returnable articles in a manner that will assist in real-time reporting of returnable articles. On

the other hand, issuance of non-returnable articles would trigger an accounting entry whereby inventory account should be

credited and a corresponding debit entry would appear in material consumption (or sample expenses) account.

Material Consumption or Expense a/c Dr To Inventory Cr

4.2.14 Sale of Fixed Assets

When a Fixed Asset has been identified for retirement by way of sale & a customer identified for disposal thereof, a sale invoice

will be generated from the SAP SD module. The account assignment & scheme of entry will be as under:

Sundry Debtors (type wise)…Dr. (full value of consideration including Tax)

To Sale of Assets

To Output VAT/Sales Tax

Corresponding exclusively FI entries will be as under:

Acc. Depreciation A/c………………Dr. (by Asset class in GL)

Loss on sale of Fixed Assets………..Dr. (where sale value is less than net value)

Sale of Asset Offset A/c…………..Dr. (with full value of consideration

To Fixed Asset A/c (by Asset class in GL)

To Profit on sale of Fixed Assets…where sale value is more than net value)

The credit entry to Sale of Fixed Assets A/c will be offset by the matching debit entry in Sale of Asset Offset A/c.





JULY

4.2.15 Scrapping of Fixed Assets

When a Fixed Asset has been identified for retirement by scrapping & no value is expected to be realized, the following FI entries

are to be passed:

Acc. Depreciation A/c……………..Dr. (by Asset class in GL)

Fixed Assets written off A/c……… Dr.

To Fixed Asset A/c (by Asset class in GL)

4.2.16 Sale of Scrap/Waste Material

When a scrap dealer is identified & rate fixed for the scrapped lot, invoice will be generated & will be recorded by passing the

following entry:

Sundry Debtor – B2B sales………Dr. (scrap value)

To Sale of Scrap/Waste Material

To Output VAT / Sales Tax payable A/c

4.2.17 Incoming Payment Processing

The system is able to handle customer payments in different modes such as cheque, cash payment etc. The incoming payment process can be done using a one step or two step methods:





JULY

Posting without Clearing - The receipts will be posted using the normal document entry functions i.e. there will be no selection of open items available. At frequent intervals the customer account will be cleared whereby the payments document will be matched against the invoice document. A clearing document will be created.

This method is only useful when at the point of entry, the user is uncertain for which open item the customer is paying. Otherwise, it is advisable that user adopt the second option.

Posting with Clearing - Open items are cleared at the point of posting incoming payments. This results in the selected line items being “cleared”. All cleared items will not be available to knock off other open items. In other words, the incoming payment document is the clearing document of the customer invoice.

Payment received from customer may not always be straightforward; therefore the system is configured to handle various scenarios as follows:-

Partial Payment, where the original open item and the partial payment remain as open documents in the account. When user posts the remaining amount for the invoice, both the partial payment and the invoice are cleared.

Contra of customer and vendor balance is handled automatically by the system. In order to activate contra balance, customer and vendor have to be linked in the customer and vendor master record.





JULY

Determine

customer account

Start

No

Yes Post incoming

payment – with

clearing

Identify invoice

being paid?

End

Post incoming

payment – without

clearing

Manually match

the payment with

invoices once can

be identified





JULY


Step Procedures Responsibility

1 The Accounts Assistant will determine the customer account number for the payment received.

2 If the invoices can be identified for the payment received, the Account Assistant will post the incoming payment in SAP and clear the invoices.

3 If the invoices cannot be identified during payment received, the Account Assistant will post the payment without clearing any outstanding invoices.

4 Once the invoices for the payment can be identified, the Account Assistant will manually match the payment with the invoices in SAP system.

4.2.18 Down Payment processing

There are certain business transactions that should be posted to the customer but not updated in the line item of receivables from goods and services in the general ledger. An example of this is advances from customers (down payments). These are identified separately in the balance sheet as advance received from customers. Special G/L indicator is used to identify such special G/L transactions





JULY

4.2.19 Accounting of partial payments

For processing partial payments, the standard SAP Partial payment application will be used. However, the partial payment

residual items rule (for assigning the partial payment against an open invoice & creating a new open invoice for balance

outstanding) may also be explored. The partial payment will be assigned against the relevant open invoice & manually cleared

upon receipt of the balance invoice amount.

4.2.20 Accounting of Output VAT

Accounting of Output VAT will originate from sales entries as described above, as per the tax conditions maintained in the tax

calculation schema.

4.2.21 Sales Returns & adjustments by way of Credit Notes

Sales returns by Customers types such as One time Customers etc will be at stores & will be handled by raising Credit Notes.

Sales returns will be handled at customer service counter where credit notes will be issued. Customers will be entitled to

replacement article of their choice or refunds on production of the Credit Notes (which is considered as a Tender type). When the





JULY

day-end POS data flows back to SAP, store wise Credit Note data will be captured in SAP SD module & the following final entry

will be passed (after getting routed through Sales Clearing A/c):

Sales-Retail………Dr.

Output VAT/ Sales tax Payable… ……Dr.

To Customer Credit Note A/c

The corresponding COGS entry for sales return will be automatically passed. When the Credit Note is redeemed by the customer

against fresh articles, the following entry will be passed:

Customer Credit Note A/c……………Dr.

To Sales Retail

To Output VAT/ Sales tax Payable

Sales return by Customer types such as Institutional, Group Companies etc will be at the DC & Credit Note will be raised on SAP

SD module by creating a Return Order & Post Goods Issue will be reversed. Thereafter, passing the following entry will raise

Credit Note:

Sales - Wholesale………Dr

Output VAT/CST Payable………Dr.

To Sundry Debtors (type wise)

4.2.22 Consignment Sale





JULY

Consignment goods are goods which are stored at the customer location but which are owned by Planet Retail. Consignment stocks still form part of PR‟s valuated stock until sales take place.

In inventory management, the consignment stock is managed as special stock in PR‟s inventory and is assigned to specific customers.

From FI perspective, the consignment accounting schema is a follows –

On consignment Fill – Up (transfer of material to consignee location):

Inventory Dr (Consignee location)

Inventory Cr

The following 3 models have been identified ---

Model 1 – Case such as VAMA: Goods will be transferred from Planet Retail to location VAMA using stock transfer. VAMA store is

using Planet Retail‟s POS system. As such, Planet Retail has access to POS data. Based on POS sales data received in SAP

system, sales order in favor of VAMA store will be created (possibly through BDC tool which will be explored during realization

phase). Normal sales process i.e. delivery, PGI (post goods issue) and billing will be executed to generate invoice in favor of

VAMA store.





JULY

Model 2 – Case such as JK: Goods will be transferred from Planet Retail to location JK using stock transfer. Items will be sold

from POS to end-customer by JK (consignee). This sale will directly be booked in the books of Planet Retail. A percentage of the

entire sales will be given to the third party as a commission. System will provide sales reports to assist calculation of commission.

The commission entry will be passed through FI.

Model 3 – This model is similar to the model 1. The difference is that the consignee agent is using its own POS system, and this

POS data is not available in SAP system. Goods will be transferred from Planet Retail to consignee using stock transfer.

Consignee will sell goods through the POS to end-customer. Planet Retail will receive sales data from consignee in mutually

agreed format. Based on this data, sales order in favor of consignee will be created by user. Normal sales process i.e. delivery,

PGI (post goods issue) and billing will be executed to generate invoice in favor of the consignee agent.

4.2.23 Customer outstanding ageing analysis & dunning

Ageing of Customer accounts will be done from invoice date(s) of open invoices following standard SAP application. Standard SAP

ageing report runs with reference to posting date (invoice date). If ageing is required to be carried out with reference to any date

other than posting date (such as delivery date, due date or statement date), z-report needs to be developed.

4.2.24 Customer Correspondence

Examples of the standard SAP correspondences generated by the system are as follow:





JULY

Account Statement and Open Items List

The account statement created for your customers is an extract from the customer account, which enables him to check the items there or for information purposes. The account statement displays the balance carried forward, all items in the chosen period and the closing balance of the account.

The open items list is a special form of account statement. It is also sent to the customer for verification or information purposes. Occasionally, the list is also used as a reminder letter. The open items up to the chosen key date are displayed in this list.

Both letters contain the document number or reference document number, the document date, the document type, the currency and the amount for every item as well as the balance of the open items at the key date.

Standard SAP Correspondence type will be used by PRHPL. Dunning process will be configured as per the requirements during realization phase.

4.2.25 Period End Processing

Each SAP module has its own period-end and year-end closing procedures. Opening the new period and closing the previous period are two parts of the closing procedure. Opening and Closing of FI period is usually given to the G/L users who will ensure that the previous period for each account types (A – assets, D – customers, K – vendors, S – G/L accounts) are closed first before generating the financial statements for the previous period. For transactions entered in Accounts Receivables, the system will check that the posting period entered for a customer transaction is open to posting as specified in the „From period‟ and „To period‟ fields for account type D (such as debit a customer) and account type S (such as credit a revenue account). Otherwise, the system will prompt an error message that the period is not open to posting.





JULY





JULY

Process Overview

Start

End

To post/delete

parked documents

Execute recurring

program

Close AR posting

period and open

new period

Generate month

end reports





JULY

Process Overview Explanation Once all invoices are completely generated, the posting period for customers can be closed. This is to prevent the occurrence of back posting invoices to the previous period. Once the period is closed, customer invoices will be generated in the new period.

Step Procedures Responsibility

1 Accounts Executive executes and posts / deletes the outstanding parked documents through parked document program.

2 Execute recurring program, if applicable.

3 After completion of all the additional postings, close AR posting period and open the new period.

4 Generate month end reports: c. AR Ageing d. Customer Balances e. Open Items, etc





JULY

4.3 SAP Solution Technical Details – Document Types, Number Ranges and Posting Key

Receipt Mode There are various modes of receipt, Receipt mode is divided into Retail sales & Institutional sales:

Tender type Condition A/c Key Data required Process Flow

Cash MID will be created for each Site referring to site code

Transaction date will be capture as Posting date

End of day “I Doc” will be generated and accounted the aggregated data to “Cash at Store account” crediting Sales clearing a/c (site as customer)

End of day cash pick up (deposit to bank) information will generated from the POS in I doc with MID, deposit slip no and “Value date” to clear the “Cash at Store account” and debited to respective House bank “Bank - Receipt account”.

Manual bank statement will upload through BDC with information MID, deposit slip no. and “Value date”. Based on the algorithm maintained in posting rule “Bank - Receipt account” will be credited and debited to „Bank-Main account‟.

Credit Cards

Service provider wise GL will be created and each service provider to a site will be MID.

At the end of the day the information of credit card sales is available in the POS – Triversity.

GL Account is maintained for „Credit Card Receivables‟.

At the end of the day through I Doc, amount is accounted in the GL along with the information of MID. The posting date in the R/3 is the transaction date in POS. The information of MID is stored in the reference field of the accounting document

Automatic clearing process has to be executed for clearing the line items.

Credit Note Credit notes are generated in both back end and front end POS.





JULY

Tender type Condition A/c Key Data required Process Flow

At the end of the day the accounting for Credit Notes is generated in SAP through I DOC.

Condition type for Credit Note is maintained to capture to liability account

Redemption of Credit note is treated as collection of tender type like GV

At the end of the day the realization of credit note is captured for means of payment and through I Doc

The posting date will be the transaction date.

Gift Vouchers Gift Voucher is created as Articles. At the time of sale of gift voucher through SD account determination it will be accounted as payable. At the time of redemption through means of payments debits will adjust to liability created at the time of sale.

Advance from customs for stock reservation

Condition type for Advance from customs for stock reservation is maintained.

Separate GL Accounts are maintained for “Advance from customs for stock reservation”

At the end of the day I Doc The amount is accounted in the GL along with the information of MID and stores ID. The posting date will be the transaction date.

Special receipt will be issued against the value

. At the time of redemption through means of payments debits will adjust to liability created at the time of collection of advance

Automatic clearing process has to be executed for clearing the line items.





JULY

Document Type and Number Ranges Document type is used to categorize documents according to their distinguishing features. Each document type will have its own number range assigned internally or externally. Typical examples of document types are invoice, credit memo, debit memo and incoming payments. The document type is used:

To differentiate business transactions

To control what type of account can be posted to (customer, vendor, general ledger, asset or material)

To control document number assignment

As a search criterion for document information The following document types will be used by PRHPL: -

Document type

Description Number range

Reversal document type

DA Customer document

DG Customer credit memo

DR Customer invoice

DZ Customer payment

Posting Keys

The posting key describes the type of transaction, which is entered in a line item. Posting key controls document entry. The important properties, which are derived from the posting key, are:





JULY

The account type

The posting to the debit or credit side

The possible or necessary specifications which are to be entered in the line item

The following SAP R/3 standard posting keys will be used by PRHPL:-

Posting Key Description Debit/Credit Account Type

01 Invoice Debit Customer

02 Reverse credit memo Debit Customer

03 Bank charges Debit Customer

04 Other receivables Debit Customer

05 Outgoing payment Debit Customer

06 Payment difference Debit Customer

07 Other clearing Debit Customer

08 Payment clearing Debit Customer

09 Special G/L debit Debit Customer

11 Credit memo Credit Customer

12 Reverse invoice Credit Customer

13 Reverse charges Credit Customer

14 Other payables Credit Customer

15 Incoming payment Credit Customer

16 Payment difference Credit Customer

17 Other clearing Credit Customer

18 Payment clearing Credit Customer

19 Special G/L credit Credit Customer





JULY

Interfaces POS Interface for sales transactions .Interfacing of POS functionality with data field mapping is to be evaluated.


1. SAP enables real time integration of sales with accounts leading to immediate reflection of business transaction into

accounts.

2. Real-time integration of FI and SD facilitates elimination of redundant data entry.

3. Reconciliation of POS and accounts receivables in SAP is automated.

4. Accounting of tender types is consistent across all tender types i.e. cash, credit/debit cards etc.

5. Gift vouchers are tracked across the system with link of sales of gift vouchers and redemption.

6. In case of wholesale, credit management is improved with dynamic credit tracking.

7. Customer receipts in case of wholesale leverage global best practices in accounts receivables.

8. SAP allows getting several accounts under one group for the purpose of reconciliation and position of outstanding may be

instantly known at one place.

9. CST entries would be reported separately for taking input VAT benefit.

10. System can provide report to calculate turnover discount on the basis of sales figures.





JULY



Auto reconciliation of debtors account It is not recommended to upload statements received from your business partners into SAP system. However, if you want to do this, we need to identify a format in which your business partners will provide the account statements.

Closed - Take data from SAP, and do reconciliation on Excel.

Export sales invoice including exp. and involving multi currency

Possible Closed

Merchandise/Non-merchandise items issued for repairs / free samples/returnable samples / for charging to expenditure

Non returnable - direct debited to cost centre and returnable - through internal order or sub contracting.

Closed

Manual billing in case of retail sales- bills should be raised by PC off line. There should be a Report containing manual bills raised with reasons and entered into POS later on their against with details of outstanding manuals bills to be punched in.

Not possible Closed - Whenever system will up store manager will punch in manual bill into the system and reported in DSR.

Sales return limit as % of sales/ fixed amt. The system should allow sales return note in case of excess only after authorisation.

Standard process will be used and standard reports will be used.

Closed

Employees coupons accounting Through loyalty cards Closed





JULY

Sales returns with information of rates /scheme effected in last 12 months with respective debtor

In case of Retail Sales Return -Sales return will have reference of invoice. In Wholesale - Reports would be available for past sales prices.

Closed

Taxation- C/F forms ,waybill tracking A reports should be available for all C form Sales. To be discussed with GCI. In case of unavailability in GCI, Z report can be developed if required.

Closed

Statement of outstanding/dues invoice wise and also showing PDC cheques received or paid

Will start with standard report and if need, will go for development later.

Closed

The system should give report indicating impact of Mark Down to analyse the impact of mark down at the level of inventory

Possible in BIW - Phase II Closed

There is no tracking system of Gift Vouchers (sale/uses in voucher scheme and redemption). The system should give this report having GV issued, redeemed and unredeemed with expiry date Accounting of GVs.

As discussed in blueprint, GVs will be created as articles. These articles will be batch managed to carry data such as GV serial no, issue date etc. This will assist in reporting about GVs and enable auto-reconciliation.

Closed

Drilldown reporting required up to lowest level

Standard reports are available

Debit / Credit note book / day book. Issue of Debit / Credit note

Use standard functionalities Closed

There should be a system of taking credit card number (compete digits) with card holder name and invoice number in

Under progress Final decision will be taken during realization phase.





JULY

record and access of such report should be very limited persons. Store persons should not be in position to access this report.

Credit note Tracking/reconciliation – for expired and unredeemed credit notes with expiry date.

System creates a credit note document which will carry data such as expiry date at the time of return of goods. Credit note will be treated as tender type in system at the time of redemption. In the event of redemption, credit note number will be entered into system during sales entry. This will create a link between issuance and redemption to assist in reporting. Available in Triversity and it will be done – Ok

Closed

Freight outward tracking –docket no., weight, no. of cartons etc.(LTO/SI etc. wise), Octroi Tracking, waybill tracking.

Could be done through standard routines and user exit or pricing Procedures. PR will give size of cartons, and formulae of volumetric weight calculation with rate. If not possible, z development will be done if required.

Closed

Promotional/discount schemes- complete analysis in terms of profitability and comparison.

Promotions will be created in the system. Sales data along with promotional details will flow into COPA component to enable flexible reporting. Comparative analysis involves comparison between MRP Vs promotional prices and historical data vs. sales data under promotional schemes. Analysis of this nature can be carried out only with z-reports. Exact requirement will be given by PR after demonstration of Triversity

Closed





JULY

Taxation-Auto Calculation of VAT, CST, WCT, FBT, service Tax etc and reports related thereto.

Auto-calculation is possible. To be discussed with GCI for reports. And will also analyse standard reports available in SAP

Closed

Report- for E filing of State wise Monthly VAT Return

To be discussed with GCI for reports. And will also analyse standard reports available in SAP

Closed

Goods In Transit – complete auto reco (site wise) WH- store transfers

User exits would be explored as suggested by SAP. Auto reconciliation will be made available

Closed

Cash Management System/ Posting of entries should be user friendly so that posting may be affected by retail admin rather that IT. Retail Admin may see the retail sales affected (till wise as well as consolidated) with tender/mode of payment and may tally with actual cash received by stores and credit settlement report. On satisfaction they may post by clicking Ok and system should post all entries. This will avoid maintenance of excel sheets being maintained by retail admin for reconciliation purpose.

Posting of retail sales is automatic. Triversity Demo is required.





JULY

Bank Accounting


The objective is to ensure compliance and standardization of bank related procedures across all locations so as to effectively manage bank transactions and funds.

5.2 SAP FI – Bank Accounting

All banks will be created as House Banks in SAP. Accordingly, Bank ID & Account ID of each of the designated banks will be maintained in the Bank Master data.

Pre-printed cheques of banks will be used by the system to print cheques for vendor payment & pre-printed stationery will be used to print payment advice.

Cheque number ranges of cheque lots need to be maintained for every House bank before commencing cheque printing.

Separate cheque lots may be maintained for payments for better control & ease of operation.

5.2.1 Collections

a) The POS sales collection accounting will be done at the POS back-office system, where the daily sales collection will be entered.

(1) For tender type cash, the collection will be first posted to the Cash at Store A/c‟ in the GL directly from POS. On cash pick up, POS will send data to SAP which will credit „Cash at Store a/c‟ and debit „Bank – Receipt a/c‟. When a corresponding deposit in the bank statement matches the entry, it will be cleared to the „Bank – Main a/c‟. Clearing will be done by linking the value credited by the bank against the hierarchy number (site/profit center code/site code issued by the bank to identify the location where the cash is being deposited) which will be matched for clearing the entries.

(2) For tender type Credit Card, the collection will be first posted to the „Credit Card Receivable A/c‟ in the GL directly from POS. Advice from bank will be uploaded into the system, and it will clear „Credit Card Receivable a/c‟ and





JULY

debit the „Bank – Receipt a/c‟. When a corresponding deposit in the bank statement matches the entry, it will be cleared to the „Bank – Main a/c‟.

b) In case of collections of DDs/ Cheques/other instruments, amount will be first debited to „Bank – Receipt a/c‟. On bank reconciliation, the amount will be cleared from „Bank – Receipt a/c‟ and debited to „Bank – Main a/c‟.

5.2.2 Payments

For vendor payment, SAP‟s manual payment process will be used (please refer A/P BBP doc).

The common bank transaction processes & the likely source documents are shown in the grid below:

Business Transaction

Activities Source document

Bank charges -

advice booking

Transaction charges such as DD Commission,

Cash/Cheque pick-up charges, Cheque printing charges,

additional statement issuing charges, Min. Balance

maintenance charge, roaming current account charge, stop

payment charges, cheque bouncing charge etc. will be

captured from the bank statement.

Import L/C opening charges, document negotiation

charges, remittance charges, etc & Export bill discounting

Payment Advice sent by bank / Bank Statement





JULY



charges, collection charges etc., will be levied by the Bank

as per FEDAI/RBI rules. Manual JVs will be passed after

receipt of Bank Advice/Statement

Reversal of

Bank charges -

advice booking

Bank charges wrongly deducted e.g. free Pay Order issue

up to certain limit is agreed but may still be debited by

Bank wrongly, may be reversed upon request.

Letter for Reversal / Bank Statement

Sales Cash deposit/Colle

ction from customer

with clearing

POS collection by Tender types reconciled & accounted for

in POS, will be uploaded into SAP. Open Item managed

GL account „Credit Card Receivables‟ will be maintained

for collection from the acquiring bank.

For SD billing, payment received from customers against

open invoice items in full or in partial settlement will be

credited to the customer account through open item

management using full /partial settlement. In this

adjustment mode, the open invoice amount will be

All Payment Methods





JULY



matched with the incoming payment & no further incoming

payment may be assigned to that invoice. In the case of

partial payment under this mode, only the balance amount

may be posted against the partial open invoice. The

cheque deposit will be posted to the intermediate „Bank –

Receipt a/c‟ & cleared on the basis of Bank

statement/advice.

Collection from

customer without clearing

Payment received from customer not assignable to open

invoice items will be credited using this mode. This mode

will be used only in case of lump-sum/on account/advance

payments received. The cheque deposit will be routed

through the „Bank – Receipt a/c‟ as explained above.

All Payment Methods

Cheque issue to vendor

Cheques will be issued to vendors based on due dates of

open invoice amounts. For mass transaction processing,

the APP process as per SAP standard application may be

used. Cheques, payment advice etc. will be printed using

the SAP standard process.

The „Bank – Payment a/c‟ will be cleared on the basis of

Bank statement upload by matching cheque numbers.





JULY



Manual cheque issued

against GL payables

In certain cases, manual Cheques may also issued to

accommodate out-of-turn/priority payments. Manual

cheque issue process may be used in the case of

treasury/GoI payments e.g. TDS Payment, Sales Tax /

VAT payment.

Upon issue of manual cheques, liability A/c will be debited

& „Bank – Payment a/c‟ will be credited, All such manually

issued cheques will be cleared on the basis of Bank

statement upload by matching cheque numbers.

Cash deposit

When cash is deposited into bank, the contra/transfer

account will be debited and cash account will be credited.

„Bank – Receipt a/c‟ will be debited & „Contra/transfer a/c‟

will be credited.

Interest debited by

bank

Interest charged by bank will be debited to „Interest a/c‟

and credited to „Bank – Main a/c‟. Bank Statement





JULY

5.2.3 Bank Reconciliation Process:

For each bank, apart from its main bank account, an intermediate receipt & payment bank account will be created. The Bank reconciliation process is based on the entries passed through the Bank sub account and main account. The process is dependent on the Bank Statement updating.

Any cheque deposited in the bank will be debited to the incoming bank account and will be credited to corresponding G/L or sub-ledger account such as customer account. Similarly, any cheque issued will be credited to the outgoing bank account and will be debited to the corresponding G/L or sub-ledger account. The bank statement will be uploaded in SAP system or a manual bank statement entry is done in the system. Bank reconciliation will be carried out based on the Cheque number or any other unique identification automatically captured or entered in the assignment field. Bank Main account balance is the actual balance as per the bank statement whereas the Bank sub accounts denote the reconciliation items. These sub accounts show those entries, which are not cleared in the bank statement.

5.2.4 GL Mapping Convention

Each bank transaction code will be mapped to the G/L account code and transaction type in the configuration setup. Following are the clearing accounts for Electronic Bank Statement (EBS)

Bank - Main account ++++++++0

Bank – Payment account ++++++++1





JULY

Bank – Receipt account ++++++++2


1. Bank accounting is integrated with accounts receivables and accounts payables.

2. Bank account determination is automatic in case of receipts as well as payments.

3. SAP facilitates global best practices in bank reconciliation processing with management of separate incoming and outgoing

bank accounts.

4. Bank reconciliation is automated with minimal input required from users



Interest calculation of bank a/c, term loans, FDs, CDs, Buyers‟ Credit etc.

Standard SAP functionality for interest calculation

Closed

Daily Fund Position report Standard reports can be used. Closed

Bounced Cheques Report Standard SAP method will be demonstrated. Closed

Treasury operation and business requirement not captured in the BBP document.

SAP component 'Treasury and Risk Management' is outside project scope.

Basic SAP demonstration will be done and work around will be made available

Investment - FD Reports with Basic SAP demonstration will be done if not Closed





JULY

maturity date , rate of interest etc. suitable then z development will be thought

Investment- Others with rate or maturity date

Basic SAP demonstration will be done and workaround suggested. If not suitable, then z development will be thought

Dropped by PR





JULY

Asset Management

6.1 Asset Classification

The proposed Asset Classes should conform to such reporting requirements namely Schedule VI to the Companies Act, 1956 and the Income Tax Act, 1962. Depreciation for Schedule XIV to the Companies Act should not be determined at the Asset Class level, rather they should be defined at each asset level. For Income Tax Act, depreciation could be defined at Asset Class level.

SAP Process Mapping

Asset Classes The Asset Class is the most important criteria for structuring fixed assets according to operational and legal requirements. Asset Classes are used to segregate assets by type, such as land, building, machinery, etc. Each asset master record is assigned to one and only one Asset Class.

The master data section of an Asset Class is defined once at the client level. The same Asset Class may apply to multiple company codes. Depending on the functions you want the Asset Class to have, the following criteria should be considered when defining the Asset Classes: One of the most important functions of the Asset Class is to establish the connection between the asset master records and the corresponding accounts in the general ledger in Financial Accounting. The account determination key in the Asset Class achieves this link. The screen layout and the field characteristics (required/ optional/ suppressed) of the asset master record can be specified at the Asset Class level. The Asset Class serves an important function in providing default values for the master records belonging to this class. In this way, the Asset Class can function as a sample master record, and makes it possible to create new asset master records simply and without errors. The assignment of asset numbers can be controlled at the Asset Class level. The Asset Class is a selection criterion in all standards reports in Asset Management. The Asset Class definition will be as follows --





JULY

The Asset Classes are mainly based on Company Law requirements and / or other MIS requirements. However the default depreciation key and useful life are defined according to the current practice of PRHPL. One Asset Class is defined for each individual Asset account. The model includes Asset Classes for LVA (low value assets or nominal value assets) according to the Companies Act and also Asset Classes for Assets under Construction





JULY

6.2 Master Data

Apart from the general details the following needs to be captured in the asset master record - To capture the date of installation in the asset master record - To capture the net landed cost as the asset cost (excluding cenvat / input VAT credit availed) - Subsequent additions to cost - Cenvat Credit / Input VAT credit availed on the Asset - Asset Serial Number (also equipment no of the asset) - Location of the Asset (cost center should define the location)

SAP Process Mapping

The asset master record contains tracking and accounting information for each individual asset created within the FI-AM module (class, description, cost center, useful life, supplier name, supplier invoice no, supplier invoice date, rate of depreciation, date of capitalization, asset no, equipment serial no, etc.).

The asset master record is structured according to the following field groups:

General information (description, quantity, serial no etc.)

Account assignment

Posting information (e.g. capitalization date)

Time-dependent assignments (e.g. cost center)





JULY

Information on the origin of the asset

Evaluation groups (evaluation groups are another way of asset classification which will be finalized during realization phase)

Some of these master record default values are defined at the class level. Asset master record numbers will be internally generated; that is, sequentially assigned by the system. Screen layout rules will be defined according to requirements, except for the following set of asset master record fields, which will be defined as mandatory for all Asset Classes:

Asset description

Qty

Cost center

Date of Capitalization

Depreciation rules (depreciation key and useful life)

6.3 Account Determination

Account determination keys will be created according to the Company Law requirements, establishing a one to one relationship between the Asset Classes and the account determination keys. No further distinction is required for local accounting purposes. The asset transactions will be automatically posted to the general ledger accounts predefined at the class level, so users will not need to provide account assignment information when entering individual transaction. One to one relationships would be maintained between account determination and Asset Class.





JULY

6.4 Depreciation Overview

Separate Depreciation Areas would be defined for compliance with the Companies Act and Income Tax. One more depreciation area will be maintained for Custom depreciation, which will be the primary Depreciation Area leading to entries for trial balance. The numbering convention would be as follows -

01 Book / Custom Depreciation 15 Income Tax Depreciation 25 Companies Act Depreciation

6.4.1 Depreciation Areas

Depreciation Areas can be viewed as “valuation areas” that show asset values for a specific purpose, such as, book, federal tax, cost, etc. They provide the means of maintaining multiple valuations for each fixed asset at a given point in time, based on the demands of governmental authorities, or based on organizational requirements. For example, different types of Asset Management values may be required for the balance sheet than for tax purposes. The necessary depreciation terms and values can then be managed in separate Depreciation Areas defined for these specific purposes. Two-digit numeric keys identify Depreciation Areas. The depreciation terms are defined in the Asset Class or directly in the asset master record of the particular asset for each Depreciation Area. This makes it possible, for example, the use of straight-line depreciation for internal controlling purposes and use of declining-balance depreciation for the balance sheet.





JULY

These Depreciation Areas are assigned to a Chart of Depreciation, which is a directory of Depreciation Areas (refer to the section on “Chart of Depreciation” for further details). SAP delivers country-specific Charts of Depreciation, which contain the most commonly used Depreciation Areas.

6.4.2 Chart of Depreciation

The Chart of Depreciation is a directory of Depreciation Areas. It enables the management of asset values and depreciation according to any country specific business and legal requirements. Therefore, Charts of Depreciation are usually country-specific and are defined independently of other organizational units.





JULY

The Chart of Depreciation “0IN” for the Country Version India inherent in SAP will be copied and a new Chart of Depreciation “PR00” will be created and assigned to all the company codes. Each company code will be assigned to one and only one Chart of Depreciation. Depreciation Areas not required will be deleted.





JULY

6.5 Asset Valuation

The valuation of fixed assets at a given point in time based on legal or business requirements is a significant function within any asset management system. Within SAP, these values are calculated in the Depreciation Areas. In addition to valuing assets for book purposes, the Depreciation Areas also make it possible to calculate asset values for specialized purposes, such as for investment support, insurance contracts, special reserves, etc. Two key concepts are particularly relevant for asset valuation. They are: Acquisition and Production Cost (APC) Net Book Value Acquisition and Production Costs (APC) The APC can be thought of the “Gross Book Value” of an asset. In SAP, the APC is normally used as the basis for calculating and posting depreciation values. Over the entire life of the asset, the system maintains the acquisition and production costs separately from the accumulated depreciation. In other words, depreciation is not deducted from the acquisition cost. For partial retirements of an asset, the system automatically determines depreciation (value adjustments) up to the point of retirement, and this amount is retired along with the partial asset.

Net Book Value The Net Book Value of an asset is the net asset value derived at any point in time from the original APC after adjustments for transactions directly affecting the APC as well as other values impacting the asset‟s book value (such as depreciation). In the absence of any other value adjustments to the asset, it can be described as the original APC minus the depreciation to date. It is a value that is not physically stored in the system in any table; however, it is calculated and displayed upon user request at any time. The Net Book Value is calculated at any point of time after the depreciation run is completed and posted in the following manner:





JULY

APC of the Asset less Accumulated Depreciation / adjustments (+ / -) for retirements / transfers less Depreciation for the year from the beginning of the year

6.6 Depreciation Processing

Book Depreciation to be posted periodically Book Depreciation will be posted in the books every month by Cost Center (posting will be monthly, but the depreciation can be carried out at fiscal year end also for all months of the year) Depreciation is to be specified at the asset level and not at the Asset Class level Retrospective Depreciation calculation & posting should be possible Depreciation on new assets to be from date of capitalization Depreciation on retirements / sale of assets to be done on the date in which retirement / sale had taken place.

SAP Asset Management allows the calculation of various types of depreciation within each Depreciation Area. This includes depreciation of an asset for normal wear and tear as well as any special or unplanned depreciation required. The “depreciat ion key” which contains the depreciation calculation methods and the parameters for depreciation calculation, controls the manner in which the actual depreciation calculations will be performed in SAP. With the help of the depreciation key, it is possible to automate the calculation of depreciation within each Depreciation Area.

6.6.1 Depreciation Keys

The depreciation key (valuation key) controls the valuation of the asset in the particular Depreciation Area Specifically; it controls the calculation of scheduled depreciation, special depreciation and interest by asset and by Depreciation Area. The depreciation key is defined by specifying an internal calculation key for the automatic calculation of interest, ordinary and special depreciation and various control parameters. While calculation keys are valid globally for the entire client, the depreciation keys are only valid





JULY

within the respective Chart of Depreciation. Therefore, if there is a need for any country-specific depreciation keys, they can be defined for each country. To differentiate the customized depreciation keys from those provided by SAP, any new depreciation keys should be defined with Y or X as their first character.

6.6.2 Document type for depreciation posting

The SAP system adheres to the document principle. This means that each posting is always stored in the form of a document. In SAP AM, a specific document type is required for depreciation postings. The number range assigned to this document type must be used for this document type only. It must be defined with internal number assignment. Document type AF has been defined for this purpose

6.6.3 Posting intervals and account determination for depreciation posting

Book Depreciation is to be posted Monthly/quarterly/semi-annually/yearly and will have assignment to cost objects

6.6.4 Depreciation Execution

The depreciation function in the SAP Asset Management system can take two different forms, automatic and manual. Automatic depreciation planning refers to the calculation of depreciation values by period (e.g., a month) based on the depreciation keys defined for each Depreciation Area. Manual depreciation planning makes it possible to increase or decrease these values. Simulation is the experimental changing of the depreciation parameters for all assets or for certain assets. In simulation, it is possible to vary all of the important depreciation terms (e.g., depreciation key, useful life, index series, etc.) and observe the effect of these changes on the depreciation values and asset values without actually posting these changes. These values may be analyzed and used for cost planning.





JULY

Automatic Depreciation will be used for most assets using depreciation keys. Manual Depreciation will be used to meet “unplanned” depreciation requirements Simulation will be used for observing effect of change in depreciation parameters on asset values and depreciation. The Default Depreciation Start Date will be the date of the Acquisition Posting, however the user can change the same if desired The Residual Value may be specified for all the assets except Low Value Assets, for which the residual value will be maintained as Re 1, and accordingly the depreciation calculation will stop once the threshold is reached Each asset needs to be assigned to a Cost Center for capturing the depreciation etc., to be posted to the Cost Center. The asset also needs to be related to a particular Profit Center in order to generate the Profit Center wise financial statements.

A Cost Center or Internal Order has to be entered in the asset master data of the asset (in the section for "time-dependent data"). The system also posts additional account assignment of the above business transactions to Profit Centers. The system determines the Profit Center to be posted by means of the Cost Center specified in the asset master record The account assignment object (Cost Center), from which the Profit Center is to be derived, has to be assigned itself to a Profit Center.

6.7 Amortisation

Planet Retail incurs expenditures such as franchise fees, events, advertisements and brand-building activities. These expenditures should be taken to balance sheet, and amortised over the following years. SAP provides functionalities to address these requirements. Individual asset masters should be created in the system to track expenses of the above-mentioned nature. When the expenses are booked, corresponding asset code should be specified. These asset masters will have depreciation keys in the master data which will control the amortization process in the same way as that of depreciation for tangible assets. A separate asset class will be created for assets of these natures. Separate gross value accounts, accumulated depreciation accounts and





JULY

amortisation expense accounts can be maintained in the system. Depreciation posting or simulation programs can be used for simulation and posting of amortisation.

6.8 Budgetary Control for Asset Acquisition`

Planet Retail should have facility to define budgets for capital acquisitions. Actual acquisition values should be tracked against these budgetary values. To address these requirements, Asset Accounting component should be used in conjunction with Internal Order component. Internal orders will be created to keep track of budgeted values. At the time of asset acquisition, user has to specify applicable internal orders. System can generate information messages as threshold limits are reached. It can also generate error messages if total acquisition value exceeds budgeted value, and stop further processing.

6.9 Asset Transactions

Transaction Types Transaction types represent classification of business transactions within Asset Management such as acquisition, retirements etc., for reporting and accounting control purposes. SAP provides several standard transaction types. Additional types may be defined, if required by the business. During configuration, transaction types may also restrict posting of transactions by Depreciation Area. Each transaction type is assigned to a transaction type group. The business transactions are subdivided on the basis of the transaction type group into: Transactions that influence the acquisition and production costs of fixed assets. These include: Acquisitions, retirements, and transfer postings, post-capitalization etc.





JULY

6.9.1 Acquisition

The primary business process in Asset Management is the purchase of assets and/or the capitalization of in-house produced goods or services. The SAP FI-AM component supports various methods of handling this business process. Acquisition through MM Acquisition of asset by purchase department, like other standard purchases in SAP is integrated with MM. The process is as follows. Create Asset Master in FI Create Material in MM duly filling the Excise related Particulars Create Purchase Order with Account Assignment Category A On receipt of goods, Fixed Asset is debited with the value and the GR/IR account credited. The Asset master is also updated with respect to the vendor details and the First Acquisition Date etc. Multiple assets acquired under a PO can be managed as separate assets or can be managed together with quantitative information. Posting them as additional acquisitions using the standard transactions can also do upgradation and additions to the same asset.

6.9.2 Assets under Construction

Acquisitions to fixed assets that are not permitted to be capitalized and depreciated immediately. Direct Capitalization: refers to asset acquisitions that do not have an asset under construction phase. Instead, they are capitalized and begin depreciation immediately.





JULY

Costs can be accumulated under purely technical aspects in an Asset under Construction. The later creation of the fixed asset has not to be considered at this point.

During the construction phase, all acquisitions for an investment in a single asset can be accumulated. These acquisitions include

External activity (acquisition from vendor)

Internal activity (internal order) or

Stock material (withdrawal from warehouse)

Auto-Allocation of Pre-Operative Expenses related to Project / Store Opening- Pre-operative expenses will be captured in a separate Asset under Construction master code. A separate AuC master code can be created for tracking pre-operative expenses related to opening of every store or for every individual project. Another alternative is also available where we can





JULY

create a common single AuC code for capturing all pre-operative expenses for all new stores or all new projects. Asset under Construction codes are line item managed. Therefore, every individual expenses entry can be allocated to the desired new asset on completion. At the time of booking of pre-operative expenses, expense account will be specified as well as the corresponding Asset under Construction code. SAP provides functionalities for auto-allocation of these expenses to individual assets upon completion. These allocation parameters are very flexible, and user can specify the proportion or some other allocation basis.

Material Issue to Asset under Construction – Planet retail issues non-merchandise items to asset under construction. Whenever some material is issued to an Asset under Construction, user will specify the code of the AuC at the time of data entry. The following entry will be passed –

Asset under Construction Dr

Non-Merchandise Inventory Cr

When using the collective management of assets under construction, it is possible to manage the individual acquisitions as open items over the course of several fiscal years. At completion, the line items must be cleared and then distributed to the various receivers. (Cost center, asset).

Separate Asset Classes will be defined for Assets under Construction. These Asset Classes are basically defined in the same way as the other Asset Classes, with the major difference that they are assigned the depreciation key 0000, so that no depreciation is calculated or posted for the AuC.

- Specific transaction types will be defined for the settlement of AuC - The AuC will be designed with line item management, so that the settlement to the final receivers (expense accounts or fixed

assets) can be managed individually as open items for settlement.





JULY

6.9.3 Asset Retirement

Asset retirement is the removal of an asset or part of an asset from the asset portfolio. This removal of an asset (or part of an

asset) is posted from a book keeping perspective as an asset retirement. Depending on the organizational considerations, or the business transaction, which leads to the retirement, you can distinguish the following types of retirement:

- An asset is sold, resulting in revenue being earned. The sale is posted with a customer. - An asset has to be scrapped, with no revenue earned.

The accounts required for posting gain or loss on asset retirements are defined at the Asset Class level (in the account determination). The account determination logic will be based on Accounting Standard requirement. The Entries related to the retirement will be reflected automatically in all the Depreciation Areas.





JULY

The SAP Asset Management Information System offers report selections in the form of a report tree. This report selection tree is a freely definable hierarchical structure. It is possible to call up a standard report just by double clicking on a node of this structure. All of the reports in the standard report selection tree are pre-defined with report variants. Therefore, when a report is called up, the initial selection screen appears in a simplified form. It is possible to control the information that appears on the final report with the help of the selections (asset number, asset class, cost center, location, etc.) made on the initial selection screen. Most of reporting requirements may be satisfied by the use of the standard reports provided by SAP.


1. SAP Asset Management component introduces structured approach towards asset management. 2. Asset can be categorized and classified on various dimensions. 3. Asset accounting is fully integrated with Materials Management and Sales & Distribution modules. 4. Depreciation calculation is flexible and automated. 5. Account determination is automatic and is driven by asset classes which enable asset class specific APC,

accumulated depreciation and depreciation expense GL accounts. 6. SAP provides comprehensive functionalities for management of Assets under Construction. 7. SAP provides real-time fixed asset register with complete details and other reports.





JULY

Cost Centre Accounting

7.1 General Explanation

To report actual cost incidence at various levels of the organization both cost center wise as well as for a group of related cost centers to provide effective and seamless management reporting tool aimed at monitoring and controlling costs.

7.2 SAP CO – Cost Center Accounting

To facilitate internal reporting for monitoring the operational efficiency of various organizational elements, sites (stores, DC), it is proposed to structure entire PRHPL into various cost centers in accordance with PRHPL organizational hierarchy.

All costs incurred in each of these responsibility areas are captured in cost centers against each GL code (Primary Cost Elements) and compared with the planned values for future analysis. However, this comparison of cost data is only statistical and cannot control unfavorable variances creeping in. Further from CCA design perspective, it should be structured in such a way that the derivation of Profit Centers is simplified and that each cost center can directly be associated with a relevant profit center. The data flow into CCA is automatic from the external transactions originating from Finance and Logistic Modules by way of account assignment to a Cost Centre on posting the line item itself.

7.2.1 Cost Centre Standard Hierarchy

Cost Center Standard Hierarchy is a tree structure representing all cost centers belonging to a Controlling Area. It contains the Cost Centers used by an organization along with their respective groups to represent the entire organization from a Controlling perspective





JULY

There will be one Standard Hierarchy for the entire Controlling Area. The Company Code will use the same Cost Center Hierarchy.

Standard Hierarchy Description Standard Hierarchy

PRHPL Standard Hierarchy PR00

Planet Retail

PRHPL

PRHPL – IT

PRHPL – Accounts

PRHPL - HR

Debenhams

Debenhams - Common

Store 1







JULY

Store 2



DC-Debenhams

Next

Next - Common

Store 3

Store 4

DC - Next

PRHPL-FashionCube

FashionCube-Common

Store 5 – Guess

Store 5 - Next


STPL

STPL – IT

STPL –





JULY

Accounts

STPL - HR

M&S

M&S - Common

Store 6

Store 7

DC-M&S

STPL-FashionCube

Store 5 – M&S

QRPL

QRPL – IT

QRPL – Accounts

QRPL - HR

TBS

TBS - Common

Store 8





JULY

Store 9

DC-TBS




Code Structure: -

Individual sites will be configured as Cost Centers (except for Debenhams, FashionCube, DC and corporate office). In case of Debenhams, every store has 2 cost centers to address the separate tracking needs of „Debenhams Brands‟ and „non-Agency Brands‟. FashionCube cost centers are segregated among PRHPL, STPL and QRPL depending upon individual brand. Also within a company code, FashionCube has more than one cost center for a single store to separately track individual brand. (Please refer to hierarchy template for more clarity). SAP provides 10 character long codes for cost centers. Following is the approach for cost center codification.





JULY


COMPANY CODE CONCEPT SITE CODE BRAND CODE (In case of stores such as Debenhams and FashionCube)

Site Codes are being discussed and once finalized, Cost Center Codes will be drawn-up. However, the structure will be as explained above. Cost Center Categories Cost center categories are a method to classify cost centers. Typical examples of cost center categories can be Finance, Administration, HR etc. Cost center category has to be entered in cost center master data. Cost center category field facilitates in reporting and is available as a selection parameter on all cost center accounting reports. Cost center categories will be finalized during realization phase.





JULY

7.2.2 Business processes in cost center accounting

7.2.2.1 Reposting Line items

The function of reposting line items enables you to repost specific line items from CO documents. The function is designed to enable you to correct primary postings that you assigned to wrong Cost Center. However you need to have the FI document number that has to be rectified. Once the document is rectified, a CO document gets created and it is linked to the original FI document. If after executing this function, you need to reverse the original FI document for some reason, you first need to reverse the CO document, which was reposted, and only then the FI document can be reversed. This is because the FI and the CO document are linked and a reversal of the FI document will need a reversal of the CO document.





JULY

Start

FI document posted with

incorrect cost center

Call CO transaction for

Line Item Reposting

Enter reference of the

original FI document

Enter the correct cost center

Post the CO document

End





JULY

7.2.2.2 Month End Processing

Cycles For allocation of costs from one Cost Center to another, the Sender/ Receiver relationships have to be described in the cycles. The creation of cycle is a one-time job. For allocation of costs, the cycles have to be executed periodically. Basis of allocation can be defined in a very user-friendly and flexible manner. Execution of Allocation Cycles For making allocations from one cost center to another, we have to execute allocation cycles. Cycles basically define the Sender/Receiver relationships and the method of allocation. There are two types of Allocation Cycles Independent Allocation Cycles - Their allocation does not depend upon the execution of other cycles. The Costs debited to the sender Cost Center in the Independent cycles are received from core modules. Between Independent cycles allocations may be made in any sequence but they should be allocated first before the Dependent cycles. Dependent Cycles – Their allocation depends upon the execution of Independent cycles. The sender Cost Centers of Dependent cycles are Receivers of costs from other allocation cycles. Those should run in a specific sequence. Those should run after Independent cycles.

The execution of the allocation cycles will be centralized at HO level. The respective Finance departments will execute each of the cycles. Please note that the execution of cycles should start only after the other core modules are closed. The creation of new cycles will be required only if new allocations are required from one Cost Center to another. The creation of new cycles will be centralized i.e. they will be created by the Finance department at HO level.





JULY

The allocations will be continued to be studied as the project progresses and will be finalized only in the realization stage. Intra-company (inter-brand/concept) allocation of expenses will be done by system based upon parameters specified by users. If expenses are traceable at the time of data entry itself, expenses will directly be taken to brand/concept specific cost centres. If expenses cannot be traced to individual brand/concept at the time of data entry, they will be booked in common cost centres, which will be allocated to brand/concept cost centres during month-end processing by executing Allocation Cycles.. Similarly in case of inter-company expenses, if expenses are traceable to individual company codes at the time of data entry, they will directly be booked to applicable company codes. If expenses cannot be traced to individual company codes, they will be booked in a common cost center, and will be allocated to individual company codes during month-end processing by execution of Allocation Cycles based upon flexibly definable parameters.

7.2.3 Planning Process

Cost Center Planning involves entering costs for a particular Cost Center and during a specific planning period. Variances can be determined by comparing actual with plan. These variances serve as a benchmark for making business process change. Planning will be for different time spans, three years forecast / Yearly Budgets / Quarterly / monthly targets. Currently the planning and calculation of variances is done manually. The Planning figures will be uploaded in the system in Version 0. A template will be given to the users to upload the planning data in the SAP system. The figures have to be in the format of Cost Element/ Cost Center. The planning will be done on annual basis. If the budgets are revised, it would be uploaded in Version 1. The planning process will be decentralized and will be done by Region / Brands / Sites for their Cost Centers. Planning has to be done at the cost element group level at every cost center.

7.2.4 Special organizational considerations

To track new store set-up costs, use of Internal Orders is envisaged.





JULY

7.2.4.1 Default Settings for Automatic creation of Cost Elements

Maintaining default settings for Cost Elements will create the Cost Elements automatically for the GL Accounts having P&L Account type. Maintenance of default settings will depend upon the Chart of Accounts. It is a one-time effort and all expense GL codes will be converted into Cost Elements at the time of realization phase. However, any subsequent GL code additions will have to be converted as Cost Elements manually, if required.

7.2.4.2 Number Ranges

In Controlling, the number ranges are linked to the nature of transactions. Every transaction posted in Controlling will have a document number, which will depend upon the number range, assigned to the nature of the transaction. For PRHPL, we would be using the SAP delivered Standard Number Ranges because they cater to our requirements.

Sr. No No Ranges Type of Transaction

1 0000000001 - 0099999999 Planning Transactions

2 0100000000 – 0199999999

Reposting (Actual) Transactions

3 0200000000 – 0299999999

Allocation (Plan and Actual) transactions

The number ranges will be revisited during realization phase, and finalized at that time.





JULY


1. Cost center hierarchy is aligned with organization structure.

2. CO module enables management viewpoint to financials which is independent of external reporting.

3. Allocation cycles enable automation of indirect cost allocation process with flexible parameters.

4. Extensive planning can be entered into system at the level of cost center – cost element.





JULY

Internal Order

8.1 General Explanation

There is a business need in PRHPL to monitor and control specific types of expenses incurred on special events / programs. These expenditure details are required to be maintained event wise without mixing up with other normal business expenses. Apart from maintaining the details of such programs / events on Internal Orders, the expenses should also be available on the relevant Cost Centers amongst all other expenses incurred on the Cost Centers.

8.2 SAP CO – Internal Orders

Internal Orders are used to collect costs according to the job that incurred them. Internal Order Management is the most detailed level of Cost and activity accounting. It helps in Cost monitoring and decision-making

1. Internal Orders are created to track and monitor various special business events and processes viz., Advertisement

Campaigns, New Store fit-out capex.

2. Plan the Costs of Campaign on the Internal Order.

3. Establish Budgets on each Internal Order and capture the expenses and reduce the budgets for the business transactions.

Internal Orders will get the actual cost and postings whenever an accounting document is posted with Internal Order as an account assignment. For example, in the case of Advertising campaigns, the campaign related costs could be booked directly to an Internal Order created for this purpose.





JULY

System generates the following documents when any expenditure gets posted.

a. Financial Accounting Document b. Cost Accounting Document

For Advertisement Campaign Costs:

Advertisement Account DR 100

Vendor / Cash / Bank Account CR 100

The Advertisement Account will have an assignment to the Internal Order at the time of Document Posting.

Internal Order will have an assignment to a Profit Center in the Master Data. Thereby automatic dataflow from Advertisement Account in GL to Internal Orders and Profit Centers will take place.

Internal Order Type Internal orders can be used to address a variety of objectives. Some of the different purposes are to track asset budgets, to act as sub-ledger for expenses such as advertisement (SMS, radio, television, outdoor, newspaper) etc. A different order type can be created for orders for these different purposes. User has to specify the order type at the time of creation of internal order itself. Internal order type controls the number range to be used for internal order master data. It also assists in reporting as Order Type field is available in standard reports as a selection parameter. For Planet Retail, internal Order Types will be finalized at the time of realization phase.





JULY

8.2.1 Business processes in Internal Order

8.2.1.1 Reposting Line Items

The function of reposting line items enables you to repost specific line items from CO documents. The function is designed to enable you to correct primary postings that you assigned to wrong Internal Order. However you need to have the FI document number that has to be rectified. Once the document is rectified, a CO document gets created and it is linked to the original FI document.

If after executing this function, you need to reverse the original FI document for some reason, you first need to reverse the CO document, which was reposted, and only then the FI document can be reversed. This is because the FI and the CO document are linked and a reversal to the FI document will need a reversal to the CO document

8.2.1.2 Budgetary Control Using Internal Orders

Budget can be set up for Internal Orders along with Availability Check. Before establishing the budgets on the Order, a Budget Profile has to be created and assigned to an Order type. The Budget Profile specifies up to what future and past years a budget can be set for an Order.

Budget Profile also controls whether the ‘availability control’ should run against the overall values or annual values. A budget defined on Overall values for an order indicates that the budgeted value is applicable for more than one year. To enable the system to work with ‘availability control’ against the budgeted amounts, tolerance limits have to be defined separately with respect to a Budget Profile and when the tolerance limits are reached in an order for a business transaction, the system can trigger specific actions like Warning or an Error Message.

An example of using internal orders for budgetary control is for asset acquisition. Planet Retail should have facility to define budgets for capital acquisitions. Actual acquisition values should be tracked against these budgetary values. To address these requirements, Asset Accounting component should be used in conjunction with Internal Order component. Internal orders will be created to keep track of budgeted values. At the time of asset acquisition, user has to specify applicable internal orders. System





JULY

can generate information messages as threshold limits are reached. It can also generate error messages if total acquisition value exceeds budgeted value, and stop further processing. Process Flow

Release internal order

Post-actual costs on the

internal order

Determine planned costs

on internal order

Creation of

Internal order

A/C POSTING – FICO DOC & ORDER STATUS - COSTED

ORDER STATUS - CREATED

ORDER STATUS - RELEASED

ORDER STATUS - PLANNED





JULY

8.2.1.3 Period End Processing

Further, upon completion of the business activity relating to the specific purpose for which Internal Order was created, it is suggested that the status of the Internal Orders be set to „Closed‟. Thereby no further expense booking can be made even erroneously once these are closed. This exercise can be taken up on a periodic basis as a month-end activity. Number Ranges

In Controlling, the number ranges are linked to the nature of transactions. Every transaction posted in Controlling will have a document number, which will depend upon the number range assigned to the nature of the transaction.

For PRHPL, we would be using the SAP delivered Standard Number Ranges because they cater to our requirements.


1 0000000001- 0099999999 Planning Transactions

2 0100000000 – 0199999999


3 0200000000 – 0299999999


These number ranges will be revisited and finalized at the time of realization.


1. CO module enables management viewpoint to financials which is independent of external reporting.

2. Internal orders allow expense tracking at levels other than cost center, thus enabling different cost perspectives.





JULY

3. Allocation cycles enable automation of indirect cost allocation process with flexible parameters.

4. Extensive planning can be entered into system at the level of internal order.

5. Internal orders can track actual postings against budgeted values.





JULY

Profit Center Accounting


PRHPL has retail operations where in profitability is required to be measured for each merchandise segment at each site (store, DC etc.). Profitability measurement would be required at these organization levels in addition to the sites. Finally, profitability is required to be measured for the entire business as a whole. A balance sheet and a profit and loss account are required at the format/concept/brand/store level. In order to achieve the above stated requirement it is proposed to make use of SAP‟s Profit Center Accounting component to organize the business into various responsibility centers with a view to measure the profitability of each of those areas periodically. Further, to report key balance sheet figures viz., Receivables, Payables, Stocks, Cash, bank, tax receivables and payables at each of these areas.

9.2 SAP CO – Profit Center Accounting

Profit Center Accounting (EC-PCA) lets you determine profits and losses by profit center. In the context of PRHPL all stores, distribution centers and corporate office are proposed as profit centers to enable determination of profits and losses at these points.

A profit center is a management oriented organizational unit used for internal controlling purposes. Dividing your company into profit centers allows you to analyze areas of responsibility and to delegate responsibility to decentralized units, thus treating them as “companies within the company”.

The profit center differs from a cost center. The cost centers merely represent the units in which capacity costs arise, whereas the person in charge of the profit center is responsible for its balance of costs and revenues.





JULY

The main aim of Profit Center Accounting is to determine profit for internal areas of responsibility. It lets you determine profits and losses at each profit centre.

Every profit center is assigned to the organizational unit Controlling Area. The profit centers in a company code belong to a standard profit center hierarchy that is also assigned to the Controlling Area.

All profit relevant business transactions are updated in the profit center hierarchy according to G/L account at the same time they are processed in the original module of the SAP system. This ensures that the entire flow of goods and services within a company is transformed in goods and services relationships between profit centers. This is true both with actual postings and in planning.

In SAP all P & L account postings originating from either Logistics or Finance will be passed on real time to CO – PCA.

9.2.1 Profit Center Standard Hierarchy

Profit Center Standard Hierarchy is a tree structure representing all Profit Centers belonging to a Controlling Area. It contains the Profit Centers used by an organization along with their respective groups to represent the entire organization from a Controlling perspective There will be one Standard Hierarchy for the entire Controlling Area. In addition to this, parallel hierarchy in the form of Profit Center Groups can be maintained in SAP. This concept is covered in detail in the follow on paragraphs. Standard Hierarchy PRHPL is suggested. This standard hierarchy contains all Profit Centers grouped in a hierarchical manner.

http://help.sap.com/saphelp_47x200/helpdata/en/eb/1374ac43c411d1896f0000e8322d00/content.htm

http://help.sap.com/saphelp_47x200/helpdata/en/eb/1373a343c411d1896f0000e8322d00/content.htm





JULY

Standard Hierarchy Description Standard Hierarchy

Planet Retail Standard Hierarchy PR00

Planet Retail

PRHPL

PRHPL - Common

Debenhams

Debenhams - Common

Store 1



Store 2



DC-Debenhams

Next

Next -





JULY

Common

Store 3

Store 4

DC - Next

PRHPL-FashionCube

FashionCube-Common

Store 5 – Guess

Store 5 - Next


STPL

STPL - Common

M&S

M&S - Common

Store 6

Store 7

DC-M&S





JULY

STPL-FashionCube

Store 5 – M&S

QRPL

QRPL - Common

TBS

TBS - Common

Store 8

Store 9

DC-TBS








JULY

Code Structure:- Other than for stores like Debenhams and FashionCube, Individual stores will be configured as profit centers. The treatment for Debenhams and FashionCube has been discussed in earlier section. In SAP, profit center codes can be 10 characters long. The following is the approach for profit center codification.


COMPANY CODE CONCEPT SITE CODE BRAND CODE

(In case of stores like FashionCube and Debenhams)

Concept codes and Site Codes are being discussed and once finalized, Profit Center Codes will be drawn-up. However, the structure will be as explained above.





JULY

The Profit center hierarchy as depicted in the enclosed diagram is only a representative one showing the structural relationship between various levels in the organization. This hierarchy will be modified for inclusion of additional Profit Centers every time when a new store is opened or a branch is set-up. In general, all costs will be allocated to the respective Profit Centers derived indirectly from the Cost Centers where they are incurred.





JULY

9.2.2 Profit Center Derivation Logic

Sl. No. Particulars Logic

1. Expenditure Cost of goods sold: Each article at site level is assigned to a Profit Center at the article master. At the time of booking of sale the Profit Center will be automatically derived from the article master. Internal consumption: At the time of booking of consumption, Cost Center is a mandatory field. This will in turn derive the Profit Center.

Inventory Shrinkage/Lost in transit: The same will be booked to a Cost Center, which in turn will derive the Profit Center. Other Direct and Indirect Expenditure: At the time of booking of expenditure Cost Center is to be given. This will in turn derive the Profit Center. The Cost Center field should be mandatory in case of booking of any expenditure.

2. Income Sale of article: Each article at site level is assigned to a Profit Center at the article master. At the time of booking of sale the





JULY


Profit Center will be automatically derived from the article master. Sale of scrap: Profit Center has to be manually entered at the time of booking of sale. Other operating income: In case of manual FI entry, Profit Center has to be manually entered at the time of entry. The same has to be a mandatory field.

3. Fixed Assets At the time of booking of fixed asset, Profit Center will be entered.

4. Inventory Each article at site level is assigned to a Profit Center at the article master.

5. Debtors The Profit Center will be derived from the offsetting line item. In case there are multiple offsetting line items, the system will break the debtors in the ratio of the offsetting line item.

6. Advance received from customers

Manual entry at the time of booking

7. Creditors

Same as Debtors

8. Advance given to vendors Manual entry at the time of booking

9. Share Capital Profit Center can be attached at the GL level





JULY


10. Secured and Unsecured Loans Profit Center can be attached at the GL level

9.2.3 Month End Processing

Execution of Allocation Cycles All common assets and liabilities and income and expenditure can be allocated among different profit centers. There are two methods of allocation viz., assessment and distribution. Assessment is done using a secondary cost element. In distribution, the original GL is retained.

For making allocations from one profit center to another, we have to execute allocation cycles. Cycles basically define the Sender-Receiver relationships and the method of allocation. There are two types of Allocation Cycles

Independent Allocation Cycles - Their allocation does not depend upon the execution of other cycles. The Costs debited to the sender Profit Center in the Independent cycles are received from Cost Center Accounting. Between Independent cycles, they can be allocated in any sequence but they should be allocated first before the dependent cycles. Dependent Cycles – Their allocation depends upon the execution of independent cycles. The sender Profit Centers of dependent cycles are receivers of costs from other allocation cycles. They should run in a specific sequence and after independent cycles. The execution of the allocation cycles will be centralized. The Finance department will execute each of the cycles. Please note that the execution of cycles should start only after the other core modules are closed.





JULY

The creation of new cycles will be required only if new allocations are required from one Profit Center to another. Transferring Receivables/Payables:

The Receivables / Payables are updated online in real-time basis i.e. as and when the transaction happens a PCA document is generated. The system posts balance postings directly to Profit Center Accounting from online postings which directly affect the balances of Receivables / Payables.

The assignment of payables and receivables to various profit centers is basically derived from the offsetting entry line of the FI document to which they belong Transferring Stock Balances:

The balance sheet item Stocks can be updated online in real-time basis.

The system posts balance postings directly to Profit Center Accounting from online postings which directly affect the balances of materials.

9.2.4 Planning Process

Profit Center planning will be required to be done for sales and cost of goods sold. Planning for other expenses will be done at Cost Center level, which in turn will reflect in Profit Center reports.

Profit Center Planning involves entering costs for a particular Profit Center and during a specific planning period. Variances can be determined by comparing actual with plan. These variances serve as a benchmark for making business process changes

Number Ranges





JULY

In Controlling, the number ranges are linked to the nature of transactions. Every transaction posted in Profit Center Accounting will have a document number, which will depend upon the number range, assigned to that nature of transaction. For Planet Retail, we would be using the SAP delivered Standard Number Ranges because they cater to our requirements.


1 0000000001- 0099999999 Planning Transactions

2 0100000000 – 0199999999


3 0200000000 – 0299999999


These number ranges will be revisited during the realization phase.

Internal Goods Movement among Profit Centers

To depict intra company goods movement, 3 additional types of accounts are required. These accounts appear only in Profit Center Accounting documents and Income Statements. These do not appear in External Accounting i.e. FI. Scenario – Stock transfer of material M1 from site A to site B. Material price is 1000 INR. Profit Center of site A is PCA and profit center of site B is PCB.

FI Posting – Account Amount Profit Center Inventory a/c Dr 1000 PCB





JULY

Inventory a/c Cr 1000 PCA PCA Postings – (made internally by the system)

Account Value Profit Center Internal Revenue 1000- PCA Internal Change in Stock 1000 PCA Delivery from Other Profit Centers 1000 PCB Internal Change in Stock 1000- PCB


1. Profit center accounting provides extensive financial reporting at levels other than company codes, thus enabling

management-oriented reporting.

2. Integration of Profit center accounting with FI automates management reporting.

3. PCA allows separate management reporting which is independent of FI.

4. Allocation cycles enable automation of indirect cost and revenue allocation process with flexible parameters.

5. Extensive planning can be entered into system at the level of profit centres.





JULY

Annexure

ANX 1 SAP Observations / Recommendations / PwC’s response

S. No.

SAP - Observations/Recommendations PWC Response Remarks after discussions Status

1 Since Consolidation requirement process not finalized yet, different approach to consolidation will trigger creation of additional organization element for consolidation.

SAP IS Retail provides functionalities for consolidation. But for extensive and full-fledged consolidation, SEM component is required.

Summation of financials would be available at GL Level in standard SAP but elimination of common transaction balances will be done manually.

Closed

2 The level of reporting – whether P&L or Balance Sheet or both for each of the organizational elements defined should be agreed and documented. Documentation of these integration points gives clarity on the reporting and process definitions

Reporting Levels - Comprehensive Balance Sheet and Income Statement at the level of Company Code. Income statement will be generated at the level of individual profit center.

BS and P & L a/c will be made available at Group Level, Company wise, Profit Centre wise. Net Profit at Division level like at Retail and wholesale division.

Closed

3 Segment identification and its design needs to be discussed with customer and to be documented in BBP document.

We do not see any need for 'Segment Mapping' as defined in SAP product. We are leveraging profit center accounting to address our needs.

Presently we are dealing with in only one segment as per statutory requirement.

Closed





JULY

4 Cost Center Categories not identified yet. Cost center categories can be used for the locking or unlocking posting to the cost center such as primary cost posting, secondary cost posting, planning, revenue posting etc. It can also be used for the activity type planning; in activity master we enter cost center categories.

It‟s a low-level detail which should be addressed at the time of Realization

Ok Closed

5 Internal Order types, number range and its usage not documented adequately. Number of internal order types and its usage together with its number range should be finalized and detail for the same needs to be included in the BBP document. BBP document prepared for planet retail has been indicative on proposed usage in brief. It is strongly recommended that number of internal order types to be created together with number range and its intended usage needs to be documented in detail.


Ok Closed

6 Field status variant has not been discussed with the core team member. The field status group determines which fields are ready for input, which are required entry fields, and which are hidden during document entry. In this view we strongly recommend that details of the field status group needs to be discussed with customer and upon finalization of field status variant same needs to be documented adequately


Ok Closed





JULY

7 Core team is in the process of vetting the BBP documents. Changes that may come over in this process can have impact on timelines. Core team to complete the vetting of FICO documents considering the time factor for blueprint phase.

Ok it will be done on deadlines Closed

8 Not all the business processes of planet retail are included in BBP document. There are no of business processes in open issue list which has not been discussed in BBP at all. All the applicable business process for Planet Retail needs to be discussed in BBP. Detail solution for the same also needs to be documented adequately in BBP doc.

The 'Open Issue List' is conceptualized as an annexure to blueprint itself. The purpose of 'Open Issue List' was to capture and document requirements which are very specific in nature. Additionally, the list is not just a compilation of issues, it also contains the visualized approach to meet the requirements. In any case, we intend to reallocate the items in 'Open Issue List' to individual chapters of blueprint.

The issues mentioned in the annexure will be put in appropriate place in respective sub modules by PWC

Closed

9 New GL functionality with document splitting not discussed with core team in detail. Document splitting is proposed. New GL concepts and implication of document splitting needs to be discussed with business and finalized document splitting criterion and business scenarios to be used. FI-GL BBP needs this detail.

Document Splitting' is an SAP specific term. During blueprint phase, we are expected to capture As Is state and define To Be state. Core team should be exposed to the exact technicalities at the time of realization.

Ok Closed





JULY

10 Financial statement consolidation at various level of the business at Planet Retail in under consideration. We have learned that Planet Retail wants to have multi-level consolidation. Consolidation requirement gathering needs to be complete with customer in detail. There are multiple solutions available in SAP solution portfolio to meet the requirement on Business and Legal consolidation

SAP IS Retail provides functionalities for consolidation. But for extensive and full-fledged consolidation, SEM component is required.

Discussed above in Point no.1, OK

Closed

11 FBT process requirement has not been defined in the BBP document, We have learned that for each FBT liable expenses additional GL account will be created for identification of FBT. In case of FBT, instead of creating additional GL account we propose to use tax code to map FBT requirement. Since the category of the exp is already identified for FBT at transaction level, what can be done that a tax code can be created (output tax), which can be used at the time of the voucher entry of the expenses on which FBT is applicable, thus in such a way you can create different tax codes for the different FBT rates and built a validation (OB28) in the system that the FBT tax rate matches the exp category.

SAP has suggested a different approach to manage FBT. We agree with the suggested approach, and cor team will be provided both the options.

Ok Closed

12 Gift Coupon process is still under discussion. For Gift Coupon, under process discussion needs to be finished on a priority basis. Detail solution needs to be built in BBP document.

It has been captured in reasonable detail both in the relevant blueprint chapter as well as the 'Open Issue List'.

Discussed in open issue list. The complete process will be included in BBP.

Closed





JULY

13 In case of FI-Asset management, Budget availability check for asset purchase is not envisaged. In case of asset purchase, we strongly recommend that budget availability should be done at the time of purchase. This will ensure sanity of budget. We also recommend using statistical internal order functionality, Asset reconciliation accounts may be created as cost element with category 90 so that statistical IO will also do the budget check when mentioned in purchase order.

Asset Management component in conjunction with CO - Internal Order component will address budget tracking for assets.

Ok Closed

14 FI – MM Integration has not been discussed in detail in the blueprint document. In case of FI – MM only valuation class are identified, apart from the valuation class there is no integration consideration in BBP document. We recommend that BBP should provide not only valuation class but GL mapping for the same for the different MM transaction.

The blueprint discusses in detail the accounting impact at various stage of material procurement. Exact accounting schema has also been mentioned.

Return entries etc.are to be incorporated

Closed

15 FI-SD or IS-retail integration is not discussed in BBP at all. FI-SD or FI- IS Retail integration needs to be spelt out in BBP clearly. Account determination of revenue as well as discounts, rebates and other sales deduction etc will ensure that the entire business requirement will be covered in BBP in detail.

The blueprint discusses in detail the accounting impact at various stage of sales cycle (both retail as well as wholesale). Exact accounting schema has also been mentioned.

Triversity presentation is awaited and total integration will be suggested after that. CST entry will also be merged

Closed





JULY

16 Stock valuation across the business unit is not discussed in BBP. Looking at the nature of the business process and product line, it is very much required that stock valuation process and physical inventory process at different sites needs to be discussed in detail. Hence we recommend that separate BBP needs to be created for stock valuation.

MM blueprint has discussed the stock valuation approach.

Necessary inventory Reports /process will be incorporated.

Closed

17 Planning exercise for cost center accounting, internal order accounting or profit center accounting is not been detailed. Forecasting or planning requirement of the Planet Retail needs to be documented in BBP with clear solution as to which component of planning will be used for which portion of Planet Retail‟s business requirement. Document should clearly spelt out planning parameters such as planning versions which will be used

Planning has been part of chapters for cost center accounting as well as profit center accounting. We will incorporate planning for Internal orders in the blueprint.

Variance report will also be made available

Closed

18 Allocation basis for the cost center accounting has not been identified. Allocation basis for assessment and distribution cycles to be used in CCA, PCA should be finalized. Wherever AS-IS is not there or allocation basis are not clear we recommend to use industry best practice.

Creation of allocation cycles is of the nature of creation of master data. We have addressed the allocation process in blueprint. Further details will be handled during realization phase.

Ok Closed





JULY

19 In case of new store opening, internal order will be used. However there is no further detail available in BBP on what level Internal order will be created? Whether Budget availability check will be done or not? Whether Internal order will be real or statistical in nature. In case of new store opening budget tracking, we recommend that line item IO should be created to map budget requirement. Line item IO may be created based on major line item of budget. IO group may be created to have store level budget tracking.

Internal orders will be used to track expenses for any particular category or activity such as opening of new stores. Also, we have discussed the possibility of setting budgets at the level of individual internal orders and dynamic tracking of actuals against budget values.

Ok Closed

20 Goods in transit process(from DC to Stores and vice versa) not included in the BBP document. There is no solution proposed for the same. In case GIT, we recommend to explore user exit EXIT_SAPLMBMB_001 to map the Goods in transit business requirement.

Goods in Transit issue is a part of the overall Stock Transfer process which has been handled in logistics modules. There is a specific requirement about usage of Goods In Transit GL account. It will be met during realization phase. Till that time, it is a part of the Open item List.

User exits would be explored as suggested by SAP. Auto reconciliation will be made available

Closed

21 Investments made in FD and other investments processes are identified as GAP. Investments like FD etc are standard process under corporate finance management.

SAP Consulting recommends use of Corporate Finance Management to address these requirements. Corporate Finance Management is a part of SAP component 'Treasury and Risk Management' which is outside project scope.


Closed





JULY

22 Treasury operation and business requirement not captured in the BBP document. Funds requirement can be met using SAP cash and liquidity management. There are various reports available which gives liquidity analysis, cash position liquidity forecast etc.

SAP component 'Treasury and Risk Management' is outside project scope.


Closed

23 BBP document section such as changes to existing process and the key improvement not discussed in majority of the BBP document. We recommend that BBP document section such as changes to existing process and key improvement needs to be included in BBP document. This will enhance quality of business blueprint document and it will enable better understanding of the impact on current business process.

Key changes have been identified wherever applicable.

All process changes will be incorporated in BBP by PWC

Closed

24 Reporting requirement for all sub-modules of financial accounting and Controlling are not captured in BBP. Kindly include reporting requirement of all sub-modules in BBP document. We also recommend mentioning usage of standard information system wherever applicable. In case of GAP in reporting requirement. BBP document should figure out method to bridge the GAP.

Reports have been identified. PWC will provide list of Standard Reports (with details) and on that basis custom reports would be decided.





JULY

25 Business process flow charts are not prepared for all the business process under discussion. It is very important that major processes needs to have business process flow diagram. Business process flow like credit management etc can be explained with greater simplicity using process flow diagram.

Flow charts have been provided for processes where flow charts may add to understanding.

Flow chart pertaining to each sub module/business process will be incorporated by PWC

Closed

26 No Business process description found in BBP document for the following business process. It is recommended that missing BBP document needs to be discussed with customer and document for the same needs to be prepared.

a. Sharing of expenses like electricity, transport expenses wtc., among group companies

This specific requirement has been part of the 'Open Item list', and has been discussed with the core team

Intra company (inter brands) sharing of expenses will be made by the system on certain parametres.Where expenses are identifiable voucher showing nature of expenses and company will be entered. Inter company sharing on certain parameters will also be made by the system

Closed

b. Set up forecast reporting for General ledger accounting

ok , it will be done as discussed earlier ok Closed

c. Inter Company transactions. PwC and core team have discussed the area. For any company code, other company codes will be managed as a supplier or a customer.

Inter company sharing on certain parameters will also be made by the system

Closed





JULY

d. Payroll accounting with deductions for accounts payable..

Till the time HR is not implemented, payroll will be handled inside GL component. JVs will be the method of managing accounting requirements for Payroll processes.

Ok Closed

27 Credit Management for the customer: BBP has only covered standard SAP process of credit check. Document is silent on how the credit limit will be set for each of the customer. Since BBP on credit management has included only standard credit management process from SAP solution perspective, we recommend, including integrated business process like setting of credit limit for customers to credit check at transaction level. And the periodic review of the credit set for the customers from Planet Retail‟s business point of view.

Core team has been introduced to credit management. Functionalities such as credit management based upon overall credit limit or status of outstanding invoices have been discussed. As far as setting up of credit limit for customers is concerned, it is PR's decision. System is capable of complying with credit limits.

Ok Closed

28 We understand that business place and section code will be created for each of the company code. However BBP document is silent on the number of business place and section code will be created.6. We recommend, BBP should include name each business place and section to be created for all company codes. We also recommend to provide for validation of business place/section code needs to be build so that all business transaction has correct business place and transaction is not supplied with null business place value

Exact codes for Business Place and Section Codes will be part of configuration document, and not the blueprint document.

Ok state wise information will be provided

Closed





JULY

29 BBP document is completely silent on number of cash journals required at Planet retail. Details on number of cash journal to be created for each company codes with their codification should be part of BBP document. Similarly BBP document should also include number of business transaction to be used for each of cash journal.

Cash journals have been discussed. Exact number of cash journals will be determined by core team with the assistance of PwC.

Petty Cash treatment will be decided after review of Triversity (IF not possible will be through SRS)

30 BBP covering cash and bank accounting has not included, number of house bank to be created for each company code, identification of GL accounts for bank accounting, business process such as bank reconciliation statement both manual and automatic, electronic funds transfer. Number of house bank to be created for each of the company code together with GL accounts to be used for house bank should be included in BBP. Business process such as bank reconciliation {Manual and automatic} electronic funds transfer etc should be discussed with customer and document for the same needs to be prepared.

These details are in the nature of master data. They can be finalized only once we move ahead in Realization Phase and are close to ASAP methodology‟s "Go-Live Preparation" phase.

more detailed procedures will be incorporated in BBP by PWC.

Closed

31 Treatments for sample sales are not discussed from FI stand point of view. We recommend discussing the same and details of the same needs to be included in the appropriate BBP document.

Will be incorporated. Procedure for items issue for repairing /free samples/ returnable samples / charging to expenditure will be incorporated by PWC.

Closed





JULY

32 Integration of profit center accounting with other modules is not discussed in BBP document. Design document for integration of profit center accounting with other modules is prepared however same is not part of BBP document. Such design document should be part of BBP document.

It has been discussed in extensive details.

The information sub module wise like SD, MM, SCM will be incorporated in BBP.

Closed

33 Integration of profit centers with segments from solution perspective is not included in BBP in detail. Details on integration of segment with profit centers need to be included in BBP document. How reporting requirement at segment level cutting across different company codes needs to be discussed in greater detail.

It has been discussed in extensive details.

The information sub module wise like SD, MM, SCM will be incorporated in BBP.

Closed

34 Detail on IO Budget process and levels at which warning, error and information is missing in the BBP document. Kindly discuss this process with customer and include it in BBP.

It will be demonstrated during Realization phase.

Ok Closed

35 Settlement process for AUC and final asset is not been discussed in BBP in detail. Creation of Final asset and settlement of internal order to final asset needs to be discussed in detailed.

Settlement from AuC (Assets under Construction) to final asset has been discussed in blueprint with reasonable details.

Detailed procedure will be shown at the time of realization

Closed





JULY

36 Period End process is discussed in isolation in various BBP. Implementation of fast close and schedule manager is not discussed in BBP. However same needs to be discussed with integration of financial accounting, Material management, sales and distribution. Checklist for the same needs to be prepared and should be part of BBP document. We recommend usage of Fast Close functionality for closing procedure across all modules. Fast close functionality will enable Planet Retail to have transparency, efficiency in closing procedure.

Fast close and Schedule Manager are User Convenience tools which will be discussed during realization phase.

ok Closed

37 Master data template needs to be identified. Data template for GL Master, Cost center, profit center, internal order and upload of planning data should be identified and shared with users

Master data /others templates will be defined during Realization Phase.

ok closed

38 Discussions on Data conversion requirements should be completed. Data Migration plan for planning and forecasting needs to be prepared and finalized

These activities will be initiated during Realization phase.

ok closed

39 Development requirements are not compiled and grouped into categories like: critical for Integration testing, critical for Go-live and Post Go-live. Still Core team has some reporting requirements yet to be finalized. All the development requirements including those with the core team should be re-looked and should be identified as critical, non critical etc which will helpful to plan the efforts and time

At this stage, we have identified z-reports. Exact classification will be carried out in realization phase.

ok closed





JULY

40 Too many business processes is identified as GAP and Z development however no roadmap thought off to approach such developments.

Post-discussions with SAP, only those points are now categorized as Gaps where SAP has agreed. For Z developments, exact technical specifications will be developed during Realization phase.

ok, closed

41 Schedule VI requirement for the external reporting requirement should be identified as development.

Agreed. ok closed

42 Validation and substitution requirement for financial accounting and Controlling not identified yet. Requirement for Validation and substitution needs to be identified and documented accordingly. Following may be ta a. If automatic payment program is to be used, validation can be used to ensure that payment method is supplied in the invoice document. b. Section code validation check in TDS posting c. Asset master data for validating different field such as asset number, cost center master assignment depreciation key, asset class etc.

These are details which will be freezed during Realization phase.

ok closed

43 Roles and responsibility details for end users needs to be finalized. This will facilitate the creation of authorization matrix and also enables the manpower planning that may be required at different levels – Master data creation, Transaction processing, Approvals, Release etc. Authorization governance strategy about handling authorization before and after go-live should be chalked out clearly

These will be completed during 'Go-Live Preparation" phase.

ok closed





JULY

44 Core team training is not done. Awareness of SAP concept in core team is very low which may lead to sever misunderstanding of the solution proposed for business processes. Level 1 training should be given to Core team so that core team is aware of the SAP terminology and concepts while signing off the BBP document.

Core team training is being started. ok closed

45 Issues that are identified are not adequately documented. There were no Minutes of the meetings or as separate notes maintained by the core team. Issue list is not updated with these issues and hence the statuses of these issues are not identifiable or not readily available. Issue list should be updated on a regular basis. Issues mentioned should also become part of the BBP document. Formal process of writing MOM should be in place so that issues once resolved doesn‟t come in discussion second time.

Core team can further add to details if desired.

ok Closed

fico bbp for sap is retail implementation

Documents

business processes

sap recommendations

gurgaon page

controlling area

surge business blueprint

sap gl component

ankita pwc

final bbp fico