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
Project: Surge
Business Blueprint
For
SAP IS-Retail Implementation
Planet Retail
Gurgaon
ST
FINAL BBP – FICO ISSUED TO ANKITA (PWC) FOR SOLMAN UPLOAD PURPOSE DATED -31 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.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.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
ST
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
ST
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.
ST
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.
ST
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.
Posting Period Name Company code

Variant
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.
ST
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 -
Group
Nature Account 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
ST
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.
ST
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.
ST
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)-
ST
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
ST
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
ST
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.
ST
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.
ST
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
ST
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 -
ST
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 -
ST
HR
TBS
TBS -
Common
Store 8
Store 9
DC-TBS
QRPL –
FashionCube
Store 5 –
Body Shop
Store 5 –
Sole Effect
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.
ST
XX XX XXXX XX
______ ___
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
ST
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.
ST
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.
ST
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.
ST
The processes and its integration can be summarized in a diagram as follows:-
ST
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.
ST
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.
ST
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,
ST
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.
ST
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:
ST
Start
Assign appropriate account codes and other information
Determine document type
No
Is approval Post the document
required?
Yes
Park the document
Verify the parked document
No
Approved?
Yes
Post the document

ST
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.
ST
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.
ST
Start
Post outstanding general ledger entries
Execute recurring entry program
Execute foreign currency line item revaluation program
Close past posting periods and open new opening period
Execute GRIR clearing
End
ST
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.
ST
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
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 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
ST
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.
ST
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:
ST
Customer GL Account System

Type description
Customer – Domestic Sundry Debtors – IS - Retail
- Institutional Domestic- Institutional
Customers – Domestic Sundry Debtors – IS – Retail
- Others Domestic- Others
Customers – Domestic Sundry Debtors – IS – Retail
- Consignment Domestic- Consignment
Customer - One time Sundry Debtors – One IS – Retail
Time
Customer - Group Sundry Debtors – IS – Retail
Companies Group Companies
Customer - Export Sundry Debtors - Export IS – Retail
Customer – POS One POS
Time -
ST
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

GL Account description
Description
Sundry Creditors – Trade -
Vendor - Trade Domestic Domestic
Sundry Creditors - Trade –
Vendor - Trade Import Import
Sundry Creditors - Trade -
Group Company – Trade Group Companies
Sundry Creditors - Non-
Vendor - Non-trade Domestic Trade-Domestic
Sundry Creditors - Non Trade
Vendor - Non-trade Import – Import
Sundry Creditors –
Group Company - Non Trade Non Trade - Group Co
ST
Sundry Creditors – Capital

Vendor - CAPEX Domestic Goods - Domestic
Vendor - CAPEX Import Goods - Import
Vendor – Service Sundry Creditors – Services
Vendor - Rental Sundry Creditors - Rental

Vendor - Employee 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.
ST

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 Will be demonstrated Closed - can be done. Core
checked. team has to develop
expertise for such changes
in the basic system design.
PwC will provide training
towards that.
Current balance should be shown Standard SAP doesn't show balances Closed by PRHPL
while entering the voucher on document entry screen.
ST
Vehicle wise costing - Fuel Solution proposed - Usage of internal Closed – It would be done
expenses, repairing (in case of orders. through internal orders
different cost elements.), employees
cost with more than one cost
element, details of telephone
expenses location wise and
employee-wise.
Activity Analysis of Cost elements. Solution proposed - Usage of internal Closed –it will be done
i.e. advertisement expenditure may orders. through internal orders
be bifurcated into PR, Direct
Marketing, Newspaper, Radio, SMS
etc.. Likewise legal & professional
fee and others.
Insurance tracking-Open Insurance/ No development is required at this Closed
tracking of inventory/cash in chest stage. It will be routed through service
etc. and expiry. entry sheet. However reports should
be available.
A Separate Trial Balance showing GAP Closed
un approved entries in separate
column
Drilldown reporting required up to Standard reports are available Closed
lowest level
Consolidated Balance Sheet of SAP component SEM (Strategic Closed
holding company and subsidiaries 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
ST
elimination of common transaction

balances will be done manually.
Allocation of common Corporate / Possible. Details will be handled Closed
divisional expenditure to different during realization phase.
brands/companies may be made on
the basis of certain parameters
given to system.
Trial balance and financials (for GAP. (SAP provides functionality for SAP suggests usage of
internal reporting purpose) should Noted Items. But noted items will not Parked document facility.
have provision of memorandum appear in Structured Financial PwC is not certain about the
entries (off line) which have not to Statements (transaction F.01). applicability of park
be passed instantly in the books of documents for the purpose.
accounts. There may be two PwC is of the opinion that z-
columns extra as additional amt. for development is required. In
adjustment in financials in trial any case, core team should
balance offline the books. take decision only during
realization phase.
Reports-CF/ fund position on daily SAP provides cash flow for existing Closed
basis, CMA data, Inventory reports / data. Standard SAP system doesn't
other reports 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.
BBP doesn‟t contain anything on Functionalities such as down payment Closed
travel management. Complete for travel and subsequent actual
ST
information on employee wise travel expense bookings are available in

cost with fields such as place of standard system. However, z-
travel, period, mode of travel, fare, development is needed to capture
conveyance, hotel and other details such as place of travel, period,
expenses are required. mode of travel, fare etc.
FBT process requirement has not SAP has suggested a different Closed
been defined in the BBP document; approach to manage FBT using tax
We have learned that for each FBT codes. We agree with the suggested
liable expenses additional GL approach, and core team will be
account will be created for provided both the options.
identification of FBT.
Custom Reports – PwC will Custom reports will be
provide a list of standard report decided during realization.
(with details) and on that basis,
custom reports will be decided.
We understand that business place Exact codes for Business Place and Ok. State wise information will be
and section code will be created for Section Codes will be part of provided
each of the company code. configuration document, and not the
However BBP document is silent on blueprint document.
the number of business place and
section code will be created.
Period End process is discussed in Fast close and Schedule Manager are Ok
isolation in various BBP. User Convenience tools which will be
Implementation of fast close and discussed during realization phase.
schedule manager is not discussed
in BBP.
ST
Master data template needs to be Master data templates will be defined Ok

identified. during Realization Phase.
Schedule VI requirement for the Agreed. Ok

external reporting requirement
should be identified as
development.
Roles and responsibility details for These will be completed during 'Go- Ok
end users needs to be finalized. Live Preparation" phase.
Consolidated reporting required for Will be provided by using Profit Center Closed
multi-brand concepts like Accounting component
FashionCube i.e. consolidation of all
brands of one store irrespective of
company code
Business Plan at Group Level, Business plan would require budget Closed - Budget preparation
Company wise Brand wise store processing in SAP. Budget planning should be outside SAP system on
wise. Allocation of expenditure and cannot be fully automated on SAP as Excel. Prepared revenue and
consolidation. budget planning requires human expense budgets can be entered
judgement and intervention. Budget into SAP system at the level of
functionality will be demonstrated on individual profit center and cost
SAP to core team. For allocation of center. SAP can track actual
expenditure, it is possible. revenue and expenses, and
provide variance reporting.
Calculation Deferred Tax/ Income Not possible with standard SAP. Z Closed
tax etc. development required
Reporting of expenditure and Standard reports are available Closed
ST
earnings in foreign currency

Cost accounting for manufacturing As per standard SAP Closed
activities
Interest Calculation on ICDs/ Standard interest calculation Closed
Unsecured Loans / FDs/ functionality will be used
Investments/Debtors & creditors/
Buyers Credit/business deposits
Financials –Monthly basis in Will be made available by using Profit Closed
prescribed format at Group level, Center Accounting
company level, Brand level, Store
level, Concept level, Zone level,
Division level like retail/wholesale.
TDS entry should be after making Vendor account will be credited by net Closed
gross amount or a separate report of TDS amount as per standard SAP.
should be there to reconcile vendor For reconciliation purposes, a z report
account. can be developed specifying gross
amount, TDS and net amount.
There should be advance expenses Ok Closed
and prepaid expenditure module
separately for running to pass
necessary entries regarding
adjustment of advance of prepaid
expenses in respective month.
Advertisement exp – PO will be Service entry sheets along with Closed
raised and invoices will be booked Internal Orders will be used to address
as per IV. System will provide the requirements.
tracking of PO, activity analysis and
event tracking
ST
Trial balance may have column s for Standard reports will be studied. If Closed
opening balance, MTD, YTD. It deemed unsatisfactory, z-report may
should also have facility for multiple be developed if needed.
MTDs.
Day books and reports containing Standard reports will be studied. If Closed
voucher numbers, amount etc deemed unsatisfactory, z-report may
be developed if needed.
System should support extraction of Standard reports will be studied. If Closed
reports/ information / account for deemed unsatisfactory, z-report may
more than one year in one shot be developed if needed.
Filtering system on date or Standard reports will be studied. If Closed
transaction or amount wise. Access deemed unsatisfactory, z-report may
of voucher directly through ledger. be developed if needed.
Depiction of check no, date, invoice Standard reports will be studied. If Closed
no, date etc along with offset deemed unsatisfactory, z-report may
account in ledger/reports be developed if needed.
Report on unapproved vouchers Ok Closed
Query module to know entries Ok Closed
pertaining to certain amount,
document no etc
System should not allow any invoice Ok Closed
no or check no twice
Reports like GL, sub-ledger, trial Ok Closed
balance main a/c, sub-ledger trail
balance, complete trial balance sub-
ledge wise, trial balance site wise,
division wise, cash position etc
ST
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
ST
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:

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
ST
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:

GL Account description GL Code
Description
Sundry Creditors – Trade -
Vendor - Trade Domestic Domestic
Sundry Creditors - Trade –
Vendor - Trade Import Import
Sundry Creditors - Trade -
Group Company – Trade Group Companies
Sundry Creditors - Non-
Vendor - Non-trade Domestic Trade-Domestic
ST
Sundry Creditors - Non Trade

Vendor - Non-trade Import – Import
Group Company - Non Trade Non Trade - Group Co
Vendor - CAPEX Domestic Goods - Domestic
Vendor - CAPEX Import Goods - Import
Vendor – Service Sundry Creditors – Services
Vendor - Rental Sundry Creditors - Rental

Vendor - Employee 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.
ST
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)
ST
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
ST
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.)
ST
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
ST
Start
Determine the bank account and check lot
Identify the vendors and invoices to be paid
Identify whether to use complete payment, partial payment

or residual payment method for each invoice
No
Approval Post the document
required?
Yes
Park the payment document
No
Approved?
Yes
Post the document
ST
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.
ST
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.
ST
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.
ST
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.
ST
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
ST
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.
ST
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.
Ste Procedures Responsibility

p
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:
ST
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 Description Number range

type
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.
ST
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/Cre Account

dit 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 Credit Vendor
memo
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
ST
Posting Key Description Debit/Cre Account

dit 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 User has to be aware of the House Bank Closed - follow standard
approval process which is to be used prior to specifying which practice.
invoices are being cleared. SAP doesn't
provide facility to change house Bank later.
Auto reco of supplier accounts It is not recommended to upload statements Closed - Take data from
ST
received from your business partners into SAP, and do reconciliation

SAP system. However, if you want to do this, on Excel.
we need to identify a format in which your
business partners will provide the account
statements.
The system should give GAP Closed - Non
indication in case of major differ merchandise will be
in costing and existing weighted through purchase info.
average rate.
Purchase returns with If reference to purchase return is not Closed
information of invoice number available, system will show a list of purchase
and actual rates/scheme made of that particular article for last 12
effected in last 12 months months. User will take further action based
upon the displayed list.
In case of electricity payments It will be done through Statistical Key Figures Closed
the report may also give (SKF)
information about meter reading
if possible
PDC Management in case of Standard SAP doesn‟t have any dedicated Very limited use of future
PDC issued as well as PDC functionality for PDC as PDC are a form of dated PDC is
received and accounting guarantee (and not an actual accounting recommended (two
treatment and Reports showing transaction). As a workaround, a separate months max.) and testing
PDC Received, Banked, PDC in payment method can be created for PDC to be done when system
hand and due for banked for a which will allow entries into account such as becomes ready. Or
particular date PDC Issued and PDC Received. though recurring entry
system.
Report – related to filing Return HR-Payroll component. (in second phase) Closed
of TDS on Salary – Form 24 &
ST
other TDS Returns

Statement of outstanding/dues Will start with standard report and if need, will Closed
invoice wise and also showing go for z development later.
PDC cheques received or paid
TDS processing in case of Standard process OK
advance payments and invoicing
– whichever is earlier
Issue of money receipt Reports to be developed Closed
Payment Advice Possible Closed
BOE should be prepared by the Third party application. To be discussed with Closed
system for tallying with actual GCI
BOE or E filing.
Reports pertaining to Bank Basic SAP demonstration will be done if not Closed
Guarantee/LC-Issue date expiry suitable then z development will be thought, if
date, Margin money with bank needed.
etc. likewise buyers‟ credit etc.
FD tracking with LC.
A facility to generate advice of Standard report will be demonstrated. If not Closed
outstanding to employees / debit suitable, Z- Development, if needed.
note/ credit note to parties.
A report of vendors showing SSI/ Ok Closed
MSI for balance sheet purpose
INR account of supplier should Standard report will be demonstrated. If not Closed
have foreign exchange rates suitable, Z- Development, if needed.
ST
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
ST
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 – ZCIN IS -Retail
Institutional
Customers – Domestic - ZCOT IS –Retail
Others
Customers – Domestic – ZCCO IS –Retail
Consignment
Customer - One time ZCON IS –Retail
Customer - Group ZCGC IS –Retail
Companies
ST
Customer - Export ZCEX IS –Retail

Customer – POS One - POS
Time
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 GL Account GL
Type description Account
Customer – Domestic Sundry Debtors –
- Institutional Domestic- Institutional
Customers – Domestic Sundry Debtors –
- Others Domestic- Others
Customers – Domestic Sundry Debtors –
- Consignment Domestic- Consignment
Customer - One time Sundry Debtors – One
ST
Time
Customer - Group Sundry Debtors –
Companies Group Companies
Customer - Export Sundry Debtors - Export
Customer – POS One
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.
ST
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:
ST
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)
ST
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:
ST
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.
ST
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.
ST
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
ST
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
ST
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.
ST
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:
ST
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.
ST
Start
Determine
customer account
No
Identify invoice
being paid?
Yes
Post incoming Post incoming

payment – without payment – with
clearing clearing
Manually match
the payment with End
invoices once can
be identified
ST
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
ST
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
ST
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
ST
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.
ST
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:
ST
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.
ST
ST
Process Overview
Start
T o po st/delete
parked do cume nts
E xecute recurring
pro gram
C lo se AR po sting
per io d and o pen
new per io d
Generate mo nth
end repo rts
E nd
ST
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
ST
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 End of day “I Doc” will be generated and accounted the
Site referring to site code aggregated data to “Cash at Store account” crediting Sales
Transaction date will be clearing a/c (site as customer)
capture as Posting date 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 At the end of the day the information of credit card sales is
be created and each service available in the POS – Triversity.
provider to a site will be MID. 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.
ST
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 Condition type for Advance from customs for stock
customs for stock reservation is maintained.
reservation 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.
ST
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: -
Documen Description Number range Reversal document type

t 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:
ST
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
ST
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.
ST

Auto reconciliation of debtors account It is not recommended to upload statements Closed - Take data from
received from your business partners into SAP SAP, and do
system. However, if you want to do this, we reconciliation on Excel.
need to identify a format in which your
business partners will provide the account
statements.
Export sales invoice including exp. and Possible Closed
involving multi currency
Merchandise/Non-merchandise items Non returnable - direct debited to cost centre Closed
issued for repairs / free and returnable - through internal order or sub
samples/returnable samples / for contracting.
charging to expenditure
Manual billing in case of retail sales- Not possible Closed - Whenever
bills should be raised by PC off line. system will up store
There should be a Report containing manager will punch in
manual bills raised with reasons and manual bill into the
entered into POS later on their against system and reported in
with details of outstanding manuals bills DSR.
to be punched in.
Sales return limit as % of sales/ fixed Standard process will be used and standard Closed
amt. The system should allow sales reports will be used.
return note in case of excess only after
authorisation.
Employees coupons accounting Through loyalty cards Closed
ST
Sales returns with information of rates In case of Retail Sales Return -Sales return will Closed
/scheme effected in last 12 months with have reference of invoice. In Wholesale -
respective debtor Reports would be available for past sales
prices.
Taxation- C/F forms ,waybill tracking A reports should be available for all C form Closed
Sales. To be discussed with GCI. In case of
unavailability in GCI, Z report can be
developed if required.
Statement of outstanding/dues invoice Will start with standard report and if need, will Closed
wise and also showing PDC cheques go for development later.
received or paid
The system should give report indicating Possible in BIW - Phase II Closed
impact of Mark Down to analyse the
impact of mark down at the level of
inventory
There is no tracking system of Gift As discussed in blueprint, GVs will be created Closed
Vouchers (sale/uses in voucher scheme as articles. These articles will be batch
and redemption). The system should managed to carry data such as GV serial no,
give this report having GV issued, issue date etc. This will assist in reporting
redeemed and unredeemed with expiry about GVs and enable auto-reconciliation.
date Accounting of GVs.
Drilldown reporting required up to lowest Standard reports are available
level
Debit / Credit note book / day book. Use standard functionalities Closed
Issue of Debit / Credit note
There should be a system of taking Under progress Final decision will be
credit card number (compete digits) with taken during realization
card holder name and invoice number in phase.
ST
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 System creates a credit note document which Closed
expired and unredeemed credit notes will carry data such as expiry date at the time
with expiry date. 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
Freight outward tracking –docket no., Could be done through standard routines and Closed
weight, no. of cartons etc.(LTO/SI etc. user exit or pricing Procedures. PR will give
wise), Octroi Tracking, waybill tracking. size of cartons, and formulae of volumetric
weight calculation with rate. If not possible, z
development will be done if required.
Promotional/discount schemes- Promotions will be created in the system. Sales Closed
complete analysis in terms of profitability data along with promotional details will flow
and comparison. 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
ST
Taxation-Auto Calculation of VAT, CST, Auto-calculation is possible. To be discussed Closed

WCT, FBT, service Tax etc and reports with GCI for reports. And will also analyse
related thereto. standard reports available in SAP
Report- for E filing of State wise Monthly To be discussed with GCI for reports. And will Closed
VAT Return also analyse standard reports available in SAP
Goods In Transit – complete auto reco User exits would be explored as suggested by Closed
(site wise) WH- store transfers SAP. Auto reconciliation will be made available
Cash Management System/ Posting Posting of retail sales is automatic. Triversity Demo is
of entries should be user friendly so required.
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.
ST
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
ST
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
Activities Source document
Transaction
 Transaction charges such as DD Commission,

Cash/Cheque pick-up charges, Cheque printing charges,
additional statement issuing charges, Min. Balance
Bank
maintenance charge, roaming current account charge, stop
charges - Payment Advice sent by
advice payment charges, cheque bouncing charge etc. will be bank / Bank Statement
booking captured from the bank statement.
 Import L/C opening charges, document negotiation

charges, remittance charges, etc & Export bill discounting
ST
Business
Transaction
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 wrongly deducted e.g. free Pay Order issue
Bank Letter for Reversal / Bank
charges - up to certain limit is agreed but may still be debited by Statement
advice Bank wrongly, may be reversed upon request.
booking
 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
Sales Cash
deposit/Colle for collection from the acquiring bank.
ction from  For SD billing, payment received from customers against All Payment Methods
customer
open invoice items in full or in partial settlement will be
with clearing
credited to the customer account through open item
management using full /partial settlement. In this
adjustment mode, the open invoice amount will be
ST
Business
Transaction
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.
 Payment received from customer not assignable to open
Collection
from invoice items will be credited using this mode. This mode
customer will be used only in case of lump-sum/on account/advance All Payment Methods
without
payments received. The cheque deposit will be routed
clearing
through the „Bank – Receipt a/c‟ as explained above.
 Cheques will be issued to vendors based on due dates of
open invoice amounts. For mass transaction processing,
Cheque the APP process as per SAP standard application may be
issue to used. Cheques, payment advice etc. will be printed using
vendor
the SAP standard process.
 The „Bank – Payment a/c‟ will be cleared on the basis of
Bank statement upload by matching cheque numbers.
ST
Business
Transaction
 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
Manual
cheque treasury/GoI payments e.g. TDS Payment, Sales Tax /
issued VAT payment.
against GL
 Upon issue of manual cheques, liability A/c will be debited
payables
& „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.
 When cash is deposited into bank, the contra/transfer
account will be debited and cash account will be credited.
Cash deposit
„Bank – Receipt a/c‟ will be debited & „Contra/transfer a/c‟
will be credited.
Interest
 Interest charged by bank will be debited to „Interest a/c‟
debited by Bank Statement
bank and credited to „Bank – Main a/c‟.
ST
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
ST
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 Standard SAP functionality for interest Closed
loans, FDs, CDs, Buyers‟ Credit etc. calculation
Daily Fund Position report Standard reports can be used. Closed
Bounced Cheques Report Standard SAP method will be demonstrated. Closed
Treasury operation and business SAP component 'Treasury and Risk Basic SAP demonstration
requirement not captured in the BBP Management' is outside project scope. will be done and work
document. around will be made
available
Investment - FD Reports with Basic SAP demonstration will be done if not Closed
ST
maturity date , rate of interest etc. suitable then z development will be thought
Investment- Others with rate or Basic SAP demonstration will be done and Dropped by PR
maturity date workaround suggested. If not suitable, then
z development will be thought
ST
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 --
ST
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
ST
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)
ST
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.
ST
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.
ST
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.
ST
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.
ST
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:
ST
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 “depreciation
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
ST
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.
ST
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
ST
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.
ST
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.
ST
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
ST
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.
ST
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.
ST
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.
ST
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
ST
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
ST
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 -
Accessorize
STPL
STPL – IT
STPL –
ST
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
ST
Store 9
DC-TBS
QRPL –
FashionCube
Store 5 –
Body Shop
Store 5 –
Sole Effect
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.
ST
XX XX XXXX XX
______ ___
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.
ST
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.
ST
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
ST
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.
ST
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.
ST
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 – Reposting (Actual)
0199999999 Transactions
3 0200000000 – Allocation (Plan and
0299999999 Actual) transactions
The number ranges will be revisited during realization phase, and finalized at that time.
ST

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.
ST
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.
ST
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.
ST
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
ST
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
Creation of
Internal order ORDER STATUS -
CREATED
Release internal order

ORDER STATUS -
RELEASED
Determine planned costs

on internal order ORDER STATUS -
PLANNED
Post-actual costs on the

internal order A/C POSTING –
FICO DOC & ORDER
STATUS - COSTED
ST
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
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.
ST
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.
ST
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.
ST
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.
ST
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 -
ST
Common
Store 3
Store 4
DC - Next
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
ST
STPL-
FashionCube
Store 5 –
M&S
QRPL
QRPL -
Common
TBS
TBS -
Common
Store 8
Store 9
DC-TBS
QRPL –
FashionCube
Store 5 –
Body Shop
Store 5 –
Sole Effect
ST
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.
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.
ST
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.
ST
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
ST
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
ST
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.
ST
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
ST
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
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
ST
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.
ST
Annexure
ANX 1 SAP Observations / Recommendations / PwC’s response
S. SAP - Observations/Recommendations PWC Response Remarks after discussions Status

No.
1 Since Consolidation requirement process not SAP IS Retail provides functionalities for Summation of financials would be Closed
finalized yet, different approach to consolidation will consolidation. But for extensive and full- available at GL Level in standard
trigger creation of additional organization element fledged consolidation, SEM component SAP but elimination of common
for consolidation. is required. transaction balances will be done
manually.
2 The level of reporting – whether P&L or Balance Reporting Levels - Comprehensive BS and P & L a/c will be made Closed
Sheet or both for each of the organizational Balance Sheet and Income Statement at available at Group Level,
elements defined should be agreed and the level of Company Code. Income Company wise, Profit Centre
documented. Documentation of these integration statement will be generated at the level wise. Net Profit at Division level
points gives clarity on the reporting and process of individual profit center. like at Retail and wholesale
definitions division.
3 Segment identification and its design needs to be We do not see any need for 'Segment Presently we are dealing with in Closed
discussed with customer and to be documented in Mapping' as defined in SAP product. We only one segment as per statutory
BBP document. are leveraging profit center accounting to requirement.
address our needs.
ST
4 Cost Center Categories not identified yet. Cost It‟s a low-level detail which should be Ok Closed
center categories can be used for the locking or addressed at the time of Realization
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.
5 Internal Order types, number range and its usage It‟s a low-level detail which should be Ok Closed
not documented adequately. Number of internal addressed at the time of Realization
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.
6 Field status variant has not been discussed with the It‟s a low-level detail which should be Ok Closed
core team member. The field status group addressed at the time of Realization
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
ST
7 Core team is in the process of vetting the BBP Ok it will be done on deadlines Closed
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.
8 Not all the business processes of planet retail are The 'Open Issue List' is conceptualized The issues mentioned in the Closed
included in BBP document. There are no of as an annexure to blueprint itself. The annexure will be put in
business processes in open issue list which has not purpose of 'Open Issue List' was to appropriate place in respective
been discussed in BBP at all. All the applicable capture and document requirements sub modules by PWC
business process for Planet Retail needs to be which are very specific in nature.
discussed in BBP. Detail solution for the same also Additionally, the list is not just a
needs to be documented adequately in BBP doc. 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.
9 New GL functionality with document splitting not Document Splitting' is an SAP specific Ok Closed
discussed with core team in detail. Document term. During blueprint phase, we are
splitting is proposed. New GL concepts and expected to capture As Is state and
implication of document splitting needs to be define To Be state. Core team should be
discussed with business and finalized document exposed to the exact technicalities at the
splitting criterion and business scenarios to be used. time of realization.
FI-GL BBP needs this detail.
ST
10 Financial statement consolidation at various level of SAP IS Retail provides functionalities for Discussed above in Point no.1, Closed
the business at Planet Retail in under consideration. consolidation. But for extensive and full- OK
We have learned that Planet Retail wants to have fledged consolidation, SEM component
multi-level consolidation. Consolidation requirement is required.
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
11 FBT process requirement has not been defined in SAP has suggested a different approach Ok Closed
the BBP document, We have learned that for each to manage FBT. We agree with the
FBT liable expenses additional GL account will be suggested approach, and cor team will
created for identification of FBT. In case of FBT, be provided both the options.
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.
12 Gift Coupon process is still under discussion. For It has been captured in reasonable detail Discussed in open issue list. The Closed
Gift Coupon, under process discussion needs to be both in the relevant blueprint chapter as complete process will be included
finished on a priority basis. Detail solution needs to well as the 'Open Issue List'. in BBP.
be built in BBP document.
ST
13 In case of FI-Asset management, Budget availability Asset Management component in Ok Closed

check for asset purchase is not envisaged. In case conjunction with CO - Internal Order
of asset purchase, we strongly recommend that component will address budget tracking
budget availability should be done at the time of for assets.
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.
14 FI – MM Integration has not been discussed in detail The blueprint discusses in detail the Return entries etc.are to be Closed
in the blueprint document. In case of FI – MM only accounting impact at various stage of incorporated
valuation class are identified, apart from the material procurement. Exact accounting
valuation class there is no integration consideration schema has also been mentioned.
in BBP document. We recommend that BBP should
provide not only valuation class but GL mapping for
the same for the different MM transaction.
15 FI-SD or IS-retail integration is not discussed in BBP The blueprint discusses in detail the Triversity presentation is awaited Closed
at all. FI-SD or FI- IS Retail integration needs to be accounting impact at various stage of and total integration will be
spelt out in BBP clearly. Account determination of sales cycle (both retail as well as suggested after that. CST entry
revenue as well as discounts, rebates and other wholesale). Exact accounting schema will also be merged
sales deduction etc will ensure that the entire has also been mentioned.
business requirement will be covered in BBP in
detail.
ST
16 Stock valuation across the business unit is not MM blueprint has discussed the stock Necessary inventory Reports Closed
discussed in BBP. Looking at the nature of the valuation approach. /process will be incorporated.
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.
17 Planning exercise for cost center accounting, Planning has been part of chapters for Variance report will also be made Closed
internal order accounting or profit center accounting cost center accounting as well as profit available
is not been detailed. Forecasting or planning center accounting. We will incorporate
requirement of the Planet Retail needs to be planning for Internal orders in the
documented in BBP with clear solution as to which blueprint.
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
18 Allocation basis for the cost center accounting has Creation of allocation cycles is of the Ok Closed
not been identified. Allocation basis for assessment nature of creation of master data. We
and distribution cycles to be used in CCA, PCA have addressed the allocation process in
should be finalized. Wherever AS-IS is not there or blueprint. Further details will be handled
allocation basis are not clear we recommend to use during realization phase.
industry best practice.
ST
19 In case of new store opening, internal order will be Internal orders will be used to track Ok Closed
used. However there is no further detail available in expenses for any particular category or
BBP on what level Internal order will be created? activity such as opening of new stores.
Whether Budget availability check will be done or Also, we have discussed the possibility
not? Whether Internal order will be real or statistical of setting budgets at the level of
in nature. In case of new store opening budget individual internal orders and dynamic
tracking, we recommend that line item IO should be tracking of actuals against budget
created to map budget requirement. Line item IO values.
may be created based on major line item of budget.
IO group may be created to have store level budget
tracking.
20 Goods in transit process(from DC to Stores and vice Goods in Transit issue is a part of the User exits would be explored as Closed
versa) not included in the BBP document. There is overall Stock Transfer process which has suggested by SAP. Auto
no solution proposed for the same. In case GIT, we been handled in logistics modules. There reconciliation will be made
recommend to explore user exit is a specific requirement about usage of available
EXIT_SAPLMBMB_001 to map the Goods in transit Goods In Transit GL account. It will be
business requirement. met during realization phase. Till that
time, it is a part of the Open item List.
21 Investments made in FD and other investments SAP Consulting recommends use of Basic SAP demonstration will be Closed
processes are identified as GAP. Investments like Corporate Finance Management to done and work around will be
FD etc are standard process under corporate address these requirements. Corporate made available
finance management. Finance Management is a part of SAP
component 'Treasury and Risk
Management' which is outside project
scope.
ST
22 Treasury operation and business requirement not SAP component 'Treasury and Risk Basic SAP demonstration will be Closed
captured in the BBP document. Funds requirement Management' is outside project scope. done and work around will be
can be met using SAP cash and liquidity made available
management. There are various reports available
which gives liquidity analysis, cash position liquidity
forecast etc.
23 BBP document section such as changes to existing Key changes have been identified All process changes will be Closed
process and the key improvement not discussed in wherever applicable. incorporated in BBP by PWC
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.
24 Reporting requirement for all sub-modules of Reports have been identified. PWC will provide list of Standard
financial accounting and Controlling are not Reports (with details) and on that
captured in BBP. Kindly include reporting basis custom reports would be
requirement of all sub-modules in BBP document. decided.
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.
ST
25 Business process flow charts are not prepared for Flow charts have been provided for Flow chart pertaining to each sub Closed
all the business process under discussion. It is very processes where flow charts may add to module/business process will be
important that major processes needs to have understanding. incorporated by PWC
business process flow diagram. Business process
flow like credit management etc can be explained
with greater simplicity using process flow diagram.
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 This specific requirement has been part Intra company (inter brands) Closed
expenses wtc., among group companies of the 'Open Item list', and has been sharing of expenses will be made
discussed with the core team 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
b. Set up forecast reporting for General ledger ok , it will be done as discussed earlier ok Closed
accounting
c. Inter Company transactions. PwC and core team have discussed the Inter company sharing on certain Closed
area. For any company code, other parameters will also be made by
company codes will be managed as a the system
supplier or a customer.
ST
d. Payroll accounting with deductions for accounts Till the time HR is not implemented, Ok Closed
payable.. payroll will be handled inside GL
component. JVs will be the method of
managing accounting requirements for
Payroll processes.
27 Credit Management for the customer: BBP has only Core team has been introduced to credit Ok Closed
covered standard SAP process of credit check. management. Functionalities such as
Document is silent on how the credit limit will be set credit management based upon overall
for each of the customer. Since BBP on credit credit limit or status of outstanding
management has included only standard credit invoices have been discussed. As far as
management process from SAP solution setting up of credit limit for customers is
perspective, we recommend, including integrated concerned, it is PR's decision. System is
business process like setting of credit limit for capable of complying with credit limits.
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.
28 We understand that business place and section Exact codes for Business Place and Ok state wise information will be Closed
code will be created for each of the company code. Section Codes will be part of provided
However BBP document is silent on the number of configuration document, and not the
business place and section code will be created.6. blueprint document.
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
ST
29 BBP document is completely silent on number of Cash journals have been discussed. Petty Cash treatment will be
cash journals required at Planet retail. Details on Exact number of cash journals will be decided after review of Triversity
number of cash journal to be created for each determined by core team with the (IF not possible will be through
company codes with their codification should be part assistance of PwC. SRS)
of BBP document. Similarly BBP document should
also include number of business transaction to be
used for each of cash journal.
30 BBP covering cash and bank accounting has not These details are in the nature of master more detailed procedures will be Closed
included, number of house bank to be created for data. They can be finalized only once we incorporated in BBP by PWC.
each company code, identification of GL accounts move ahead in Realization Phase and
for bank accounting, business process such as bank are close to ASAP methodology‟s "Go-
reconciliation statement both manual and automatic, Live Preparation" phase.
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.
31 Treatments for sample sales are not discussed from Will be incorporated. Procedure for items issue for Closed
FI stand point of view. We recommend discussing repairing /free samples/
the same and details of the same needs to be returnable samples / charging to
included in the appropriate BBP document. expenditure will be incorporated
by PWC.
ST
32 Integration of profit center accounting with other It has been discussed in extensive The information sub module wise Closed
modules is not discussed in BBP document. Design details. like SD, MM, SCM will be
document for integration of profit center accounting incorporated in BBP.
with other modules is prepared however same is not
part of BBP document. Such design document
should be part of BBP document.
33 Integration of profit centers with segments from It has been discussed in extensive The information sub module wise Closed
solution perspective is not included in BBP in detail. details. like SD, MM, SCM will be
Details on integration of segment with profit centers incorporated in BBP.
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.
34 Detail on IO Budget process and levels at which It will be demonstrated during Ok Closed
warning, error and information is missing in the BBP Realization phase.
document. Kindly discuss this process with
customer and include it in BBP.
35 Settlement process for AUC and final asset is not Settlement from AuC (Assets under Detailed procedure will be shown Closed
been discussed in BBP in detail. Creation of Final Construction) to final asset has been at the time of realization
asset and settlement of internal order to final asset discussed in blueprint with reasonable
needs to be discussed in detailed. details.
ST
36 Period End process is discussed in isolation in Fast close and Schedule Manager are ok Closed
various BBP. Implementation of fast close and User Convenience tools which will be
schedule manager is not discussed in BBP. discussed during realization phase.
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.
37 Master data template needs to be identified. Data Master data /others templates will be ok closed
template for GL Master, Cost center, profit center, defined during Realization Phase.
internal order and upload of planning data should be
identified and shared with users
38 Discussions on Data conversion requirements These activities will be initiated during ok closed
should be completed. Data Migration plan for Realization phase.
planning and forecasting needs to be prepared and
finalized
39 Development requirements are not compiled and At this stage, we have identified z- ok closed
grouped into categories like: critical for Integration reports. Exact classification will be
testing, critical for Go-live and Post Go-live. Still carried out in realization phase.
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
ST
40 Too many business processes is identified as GAP Post-discussions with SAP, only those ok, closed
and Z development however no roadmap thought points are now categorized as Gaps
off to approach such developments. where SAP has agreed. For Z
developments, exact technical
specifications will be developed during
Realization phase.
41 Schedule VI requirement for the external reporting Agreed. ok closed
requirement should be identified as development.
42 Validation and substitution requirement for financial These are details which will be freezed ok closed
accounting and Controlling not identified yet. during Realization phase.
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.
43 Roles and responsibility details for end users needs These will be completed during 'Go-Live ok closed
to be finalized. This will facilitate the creation of Preparation" phase.
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
ST
44 Core team training is not done. Awareness of SAP Core team training is being started. ok closed
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.
45 Issues that are identified are not adequately Core team can further add to details if ok Closed
documented. There were no Minutes of the desired.
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.
ST

Fico BBP For Sap Is Retail Implementation

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Fico BBP For Sap Is Retail Implementation

Hochgeladen von

Copyright:

Verfügbare Formate

FINANCE & CONTROLLING

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

LOCATION : GURGAON PAGE 1

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

LOCATION : GURGAON PAGE 2

Planet Retail Organization structure .............................................................................................................................................................................................. 4

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

LOCATION : GURGAON PAGE 3

6.3 Account Determination ........................................................................................................................................................................................................ 112

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

LOCATION : GURGAON PAGE 4

Planet Retail Organization structure

1.1 Company Code

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

LOCATION : GURGAON PAGE 5

Company Code Description Company Code

Supreme Tradelinks Private Limited 1100

Quest Retail Private Limited 2000

Fiscal Year and Accounting Posting Period

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

LOCATION : GURGAON PAGE 6

Posting Period Variant

Posting Period Name Company code

1000 Planet Retail Holdings Private Ltd. 1000

1100 Supreme Tradelinks Private Ltd. 1100

2000 Quest Retail Private Ltd. 2000

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

LOCATION : GURGAON PAGE 7

GL Account Creation Process

Step 2 – Extend GL account to individual company codes

Chart of Accounts Description Chart of Accounts

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

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

LOCATION : GURGAON PAGE 8

Inventories INVE 220000 229999

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

LOCATION : GURGAON PAGE 9

1.2 Controlling Area

Controlling Area Description Controlling Area

1.3 Credit Control Area

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

LOCATION : GURGAON PAGE 10

Credit Control Area Description Credit Control Area

PR Credit Control Area PR00

1.4 Profit Center

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

LOCATION : GURGAON PAGE 11

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

LOCATION : GURGAON PAGE 12

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

LOCATION : GURGAON PAGE 13

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

LOCATION : GURGAON PAGE 14

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

LOCATION : GURGAON PAGE 15

1.5 Cost Center

The Cost Center Hierarchy is structured as follows:

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

LOCATION : GURGAON PAGE 16

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

LOCATION : GURGAON PAGE 17

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

LOCATION : GURGAON PAGE 18