Page1

KRISHNA TISSUES PRIVATE LIMITED
My SAP Implementation
BR ERP TECHNOLOGIES PVT LTD
Project: Sankalpa
Financial Accounting & Control ling

BUSINESS BLUEPRINT














Prepared by Checked by Revi ewed by Signed Date
Tanmoy Dutta
(FICO)
Tamal Kanti
Biswas(FICO)

Biswanath
Maitra




Page2

CONTENTS

A. INTRODUCTION – OBJECTIVE OF BUSINESS BLUEPRINT PHASE ....................................................................................... 3
B. SCOPE OF THE BLUEPRINT DOCUMENT .................................................................................................................................. 4
C. ORGANIZATION STRUCTURES ........................................................................................................................................................................................... 4
D. FINANCIAL ACCOUNTING PROCESSES ........................................................................................................................................................................ 6
GLOBAL SETTINGS................................................................................................................................................................................................................................. 6
MANAGE GENERAL LEDGER ACCOUNTING ............................................................................................................................................................................ 7
MANAGE ACCOUNTS PAYABLE................................................................................................................................................................................................... 16
MANAGE ACCOUNTS RECEIVABLE ........................................................................................................................................................................................... 25
MANAGE ASSET ACCOUNTING .................................................................................................................................................................................................... 29
BUSINESS AREA .................................................................................................................................................................................. 39
MANAGE COSTING .............................................................................................................................................................................. 41
INTERNAL ORDER ............................................................................................................................................................................... 46
PROFIT CENTER ACCOUNTING ......................................................................................................................................................... 49
E. STANDARD SAP REPORTS ...................................................................................................................................................... 53
F. PROCESS FLOW DIAGRAMS ................................................................................................................................................... 57




Page3


A. Introduction – Objective of Business Blueprint Phase

This document is the outcome of discussions during training, As-Is and To-Be process, AT KTPL report and business process requirement
analysis for the KTPL.

Based on these inputs from the core team members during To-Be discussion, we arrived at the Business Processes, which are
incorporated in the Business Blue Print. The aim of this document is to map the best business processes related to the Financial &
Management Accounting (FI/CO) module in SAP ECC 6.0. This document is to be studied by core team members & process owners
from KTPL. The preparation of this document is an essential precursor to prototyping and testing. The development work will start
once process owner’s approval for this Blue Print is obtained followed by a corporate presentation to the senior management team of
KTPL.
This document will be used for configuring the FI/CO module in SAP implementation. Document is based on
discussions/presentations between representatives of KTPL & BR ERP. In other words it contains

1. SAP Organization Model in context of existing business scenario and future requirements/issues as envisaged by KTPL.

2. Mapping of business processes/issues brought forward by BR ERP, AT KTPL, with SAP functionality.

3. Gaps & issues emerged during the discussion between KTPL & BR ERP.



Page4

4. Business Process Flows mapped in SAP as per the scope defined.

5. Closure of Mapping Phase and start of Piloting Phase of implementation.


B. Scope of the Blueprint Document
The objective of this Blueprint presented to the Project Sponsor is to document the following:

1. Business Requirements of KTPL that need to be translated into SAP.
2. This has been prepared by SAP consultant team members on the basis of inputs, factory visits, AT KTPL & discussions
between BR ERP TPL SAP consultants and KTPL core team members.
3. SAP gaps as identified by BR ERP TPL team . the present scope of implementation as well as technical & functional feasibility
and business requirements of KTPL.
4. Details of SAP new business process description supported by process flow diagrams w.r.t. different SAP processes indicating
the desired “To be Processes”.

In order to bring the clarity and better understanding, the document has been divided in three sections:
(a) Organization structure
(b) Master Data Management, To-Be Business processes, and Gaps identified for business processes as per SAP
(c) Appendix - Process Flow Diagrams

C.Organization Structures
In an SAP system every organisation needs to be defined in terms of a structure from the point of view of statutory and management
reporting requirements.
As per discussions the following Organisation Structure has been drawn up for KTPL.


Page5



A Company Code is an entity for which a complete set of accounts can be maintained. It is the minimum unit of organization in
Financial Accounting. A balance sheet and P/L account can be prepared for a company code. A Company Code is identified by a four
character key.
KTPL shall have one company code as mentioned below: KRISHNA TISSUES PRIVATE LIMITED ( KTPL).

Business Areas are primarily used to distinguish and facilitate segment reporting covering the company’s main areas of operations (plant,
product lines, and branches). While externally reported and legally required financial statements are obtained at the company code level,
financial statements derived at business area level are only suitable for internal reporting. Similar to company code, business area is also
identified by a four character key. As per discussions, KTPL shall have one business areas, as mentioned below:


(KTPL) KRISHNA TISSUES PRIVATE LIMITED.

An Operating Concern is the highest level in the CO organisation structure. An Operating Concern is identified by a four character
key.

KTPL shall have one Operati ng Concern called Krishna Group. It shall be identified by a four character code KTPL.
A Controlling Area is an Organisation Unit which defines the scope of Cost Objects (Cost Centres, Production Orders, Internal Orders,
etc). Controlling Areas are defined for internal controlling purposes.


Page6

One Controll ing Area called KTPL will be created. It will be denoted by a four character code KTPL.
The Controlling Area needs to be assigned to the Operating Concern. The Company Code needs to be assigned to the Controlling
Area.
Hence Controlling Area KTPL shall come under the Operating Concern KTPL, while the company code shall be under the Controlling
Area KTPL.

Sl No Process Name Mode Process Description Gap(Y/N) Remarks
1.0 GLOBAL SETTINGS

1.1 Fiscal Year Variant Fully
system
supported
The company code will maintain a
Backward Year Shift. which means that
the year 2006-07 will be shown in the
system as 2006 for reporting purposes. The
Fiscal Year Variant has been named KL.
The Fiscal Year Variant will have 12
Normal Posting Periods and 4 Special
Posti ng Periods and the Fiscal Year will be
from April – March.

N
1.2 Posting Period
Variant
Fully
system
supported
The Posting Period Variant used has been
named KTPL.

It is used for controlling the postings by the
user during the specified period. After a
specific period is over, it will be closed for
making any further entries. If such a dire
need arises for opening the previously
closed period, approval should be received
from the authorised person.

N
1.3 Chart of Accounts Chart of Accounts KTPL would be used for N


Page7

Company Code KTPL. The length of the
G/L Accounts to be used in the Chart of
Accounts KTPL would be 6.

1.4 Document Number
Range
All the document number ranges will be
Year Dependant. That means every year
new number ranges has to be maintained in
the system. Different number ranges for
different document types will be maintained.
However since it is not possible to maintain
different documents types for all kinds of
transaction, KTPL has agreed to go ahead
with those which are possible.


2.0 Manage General
Ledger Accounting


2.1 Master Data
Maintenance
All the master data that has to be
maintained in SAP for the G/L function is
captured here.

N
2.1.1 Account Group The company has to maintain different
account group for their reporting
requirement. Number ranges will be
assigned to the account group and the
same will be external. The Accounts Groups
shall be as per company’s reporting
requirements.

N
2.1.2 GL Master Fully
system
supported
The General Ledger master applicable to
the entire company needs to be maintained
here. This would be a central function. The
GL Masters have two segments. The Chart
of Account segment will be maintained
centrally.



Page8


2.1.3 Bank Masters Fully
system
supported
Bank Masters creation would be a central
function. All the details relevant to the bank
(account number, branch etc) are
maintained in this transaction. Also the
linking of the bank master to the GL account
is made here.

N
2.1.4 Interest Indicators Fully
system
supported
For loan and bank accounts, the interest
payable thereon is to be periodically
calculated and posted by the system. For
this purpose, interest indicators for the
different interest terms needs to be created.
This interest indicator is assigned to the
respective GL accounts of the loans and
Banks.

2.2 Loan Repayment Fully
system
supported

2.2.1 Maintain Interest ID In
GL Master
Fully
System
Supported
Depending upon the terms of the
agreement entered into, separate interest
ID will be created. This interest ID will be
maintained in the GL Master record.


2.2.2 Run Interest
Calculation on
Balances Program.
Fully
system
supported
Interest on balances would be periodically
calculated and posted by the system
automatically. For storing the calculation
details and break-up, the report available at
the time of the execution of the program,
would be stored using a separate
customized development.

N
2.3 Bank Reconciliation
Statement
Fully
system
supported
For the purpose of BRS in SAP each of the
existing bank accounts (as represented by
GL accounts) would be needed to be split
N


Page9

into bank sub-accounts – each sub account
representing a GL account.

Typically, the bank accounts would be
maintained as follows:

Main Bank A/c ( GL Account)
Checks Payable A/c (all payments made
through this sub-account)

Checks Receivable A/c (all receipts made
through this sub-account)
The transaction would be like:

While making any payment:

Vendor A/c / GL A/c Dr
To Cheques payable A/c

While receiving any money:

Cheques Receivable A/c Dr
To Customer / GL A/c

At no point of time during transactions will
the main bank account be affected. The
only time any posting to the main bank
account will be made is when the bank
statement received from bank is entered
into SAP.

Each bank statement received from the


Page 10

bank has to be entered into SAP.

Depending on the debits received in the
bank account the following entry is passed
automatically:

Cheques Payable A/c Dr
To Main Bank A/c

Depending on the credits received in the
bank account the following entry is passed
automatically
Main Bank A/c Dr.
To Cheques Receivable A/c.

Implications

At the end of any period (after the bank
statement is entered in SAP) the balances
in the various bank accounts would
represent:
Cheques Payable A/c – Cheques issued not
presented;
Cheques Receivable A/c - Cheques
deposited not cleared.
Main bank -The balance in the bank
statement



Page 11

2.4 Maintain Bank
Groupings
Fully
System
Supported
Separate groupings of the bank accounts
are possible for the purpose of reporting
e.g. grouping all branch banks, all factory
banks, all company banks etc.




2.5 Cash and Petty cash
Transactions
Fully
System
Supported
Two General Ledger Account will be
maintained one for normal cash and other
for petty cash.

N
2.6 Cash Journal For petty cash transaction, they will use
cash journal functionality of SAP. They will
identify business transactions for different
cash journal.


2.7 Receipt and Payment
Cash Voucher.
Individual Cash Receipt and Payment
Voucher is to be generated from the SAP.

N
2.8 Other Payments Other cash / bank related transactions are
covered in this section. All statutory
payments like TDS, Excise duty, sales tax
etc have to be made with the GL outgoing
payments functionality.
Except TDS payments, vendors shall be
created for all other outgoing statutory
payments.


2.9 Cash Withdrawal
From Bank
Fully
system
supported
For cash withdrawals from bank, a bank
outgoing payment transaction would be
entered into the system.
The cheque preparation for such
withdrawals would be manual.

N


Page 12

3.0 Staff Advances For
Companies Business
Fully
system
supported
The same would be managed through
Payroll and Travel Management.
N
3.1 Miscellaneous
Expenses
Fully
system
supported
Other Expenses would be captured
individually with every voucher posted in the
system. For expenses, proper invoices must
be raised in the system, against which all
payments to the respective parties will be
made. No direct entries should be made.
N
3.2 Foreign Currency
Payments
Fully
system
supported
The payment in this case is made manually.
During matching the outgoing payment, one
can enter the rate of exchange manually. At
the time of the payment, the system posts
the exchange rate difference to an expense
/ gain account.
automatically.
The entry passed:
Vendor Dr.
Forex Loss – Realised Dr.
To Bank – Outgoing


3.3 Incoming Payments Fully
System
Supported
Apart from collection from customers other
incoming payments would be on account of
Sale of Assets, interest income, etc.


3.4 Journal Vouchers Fully
System
Supported
This relates to rectification entries made as
and when it is detected that errors have
occurred during previous postings. These
necessitate reversing the incorrect entries,
resetting them, if they are already cleared,
and posting the new entries.

N
3.5 GL Closing Activities The closing activities that need to be
undertaken in the GL module are covered in
N


Page 13

this section.

3.5.1 Account Clearing Account Clearing is a periodic activity – in
the system, G/L accounts will be cleared
automatically as well as manually.

Accounts which are managed on an Open
Item (OI) Basis needs to be cleared e.g.
withholding tax accounts, sales tax payable
accounts etc.

N
3.5.2 Manual Account
Clearing
Fully
system
supported
In manual clearing of accounts, the system
by default selects all the open items for the
clearing process.The user then manually
chooses the debit and credit items to be set
off and cleared.


3.5.3 Automatic Account
Clearing
Fully
system
supported
In automatic clearing, the system chooses
the line items to be set off, based on pre-
defined criteria specified by the user. A
program needs to be run, giving the details
of the clearing. The program can first be run
in the test mode.


3.5.3.1 GR/IR Clearing Fully
system
supported
GRN clearing is the process of matching
debits and credits in the GRN liability
account. The process is similar to account
clearing.
All GR/IR accounts would be automatically
cleared on the basis of the material and the
purchase order combination.

N
3.5.4 Forex Revaluation Foreign exchange revaluation occurs on
account of the outstanding loans in foreign
currencies, which have to be revalued at the



Page 14

period-end based on the exchange rates
prevalent on that day.

Unrealised Gain / Loss A/c Dr.
To Loan A/c

3.5.5 Revaluation and
Posting without
Reversal
Fully
system
supported
Outstanding liabilities in foreign currency
need to be revaluated periodically for MIS
purpose. The system calculates the
exchange rate difference and posts the
same to unrealised loss/ gain accounts. In
the case of year-end revaluation, such
postings do not need to be reversed.
Separate exchange gain/loss accounts
could be opened for foreign exchange
gain/loss arising from different factors viz.
exports, import
s and miscellaneous transactions. A report
on foreign exchange gain/loss segregated
on the basis of different currencies may also
be required.

N
3.5.6 Revaluation and
Posting with Reversal
Fully
system
supported
This relates to period-end foreign currency
revaluation other than those at the year-
end. In this case, the entries passed by the
system automatically need to be reversed in
the subsequent posting period. Here, the
user needs to mention the reversal posting
date while running the revaluation program.

N
3.5.7 GR/IR Adjustment Fully
system
supported
In GRN adjustment, at the month-end, one
identifies, for Balance Sheet purposes, the
goods received and not invoiced and the
goods invoiced but not received.




Page 15

For all instances, where the goods have
been received but invoice not received the
system passes the following entry:

GR/IR Adjustment A/c Dr.
To Goods Received Not Invoiced

For all instances, where the invoices have
been received but goods not received the
system passes the following entry:

Goods Invoiced Not Received A/c Dr
To GR/IR Adjustment A/c




FOR PRESENTATION PURPOSES THE
GR/IR ADJUSTMENT A/c IS DISPLAYED
ALONGSIDE THE GR/IR LIABILITY A/c -
SO THAT ONLY THE NET BALANCE IS
DISPLAYED IN THE OUTER COLUMN.

3.6 Balance Sheet/ Profit
& Loss A/c
Fully
system
supported
For this, the financial statement version,
which groups together the accounts under
the appropriate categories, will be
maintained.

Different financial statement versions would
be created for IFRS and Indian GAAP
reporting.
N
3.7 Financial Statement
Version
Fully
system
supported
For this, the financial statement version,
which groups together the accounts under
the appropriate categories, will be
maintained.



Page 16


3.8 Open / Close Posting
Period
Fully
system
supported
Once the accounts for a period are
accepted, to ensure the validity of such
accounts, the period for which the accounts
are completed, needs to be closed.

Once closed, no one can post to that
period. NOTE: Closing for material
accounting is separate in MM.

The closing of the periods can be done for a
group of GL / Vendor / Customer accounts,
or all such accounts in one go.

N
3.9 Create Posting Period
For Next Fiscal Year
Fully
system
supported
At the end of the fiscal year, the posting
periods for the new fiscal year are to be
created to ensure posting to the fiscal year.

N
3.10 Carry Forward
Balances
Fully
system
supported
The balances at the end of a fiscal year will
be carried forward by this transaction. All
balance sheet account balances are carried
forward to the next fiscal year, while the
Expense / Revenue accounts are
transferred to the Profit & Loss account.
NO ACCOUNTING DOCUMENTS ARE
CREATED WHILE TRANSFERRING THE
BALANCES


4.0 Manage Accounts
Payable
The vendor accounts and bal ances are
managed through the Accounts Payable
functional ity.



4.1 Vendor Master Data Several reconciliation accounts will be
maintained for different kinds of vendors.
N


Page 17

Sometimes Vendors may also be
Customers and vice-versa. Same should be
maintained in the master data for proper
payment.
The Payment Terms will be maintained in
the Vendor Master and will be maintained
by KTPL MM Core Team.
All the Vendors for which Withholding Taxes
are applicable are to be maintained in the
Vendor Master Data with reference to
exemption certificate details (if any).
If cheque payment has to be made in a
name different than that of the Vendors’, the
same has to be maintained in the Vendor
Master Data.
For regular expenses like electricity bill,
telephone bill, Vendors would be created for
automatic cheque printing. First invoice has
to be posted in the system then payment
would be made.

4.2 Employee The same would be managed through
Payroll and Travel Management.

N
4.2.1 Employee Advance The same would be managed through
Payroll and Travel Management.

N
4.2.2 Salary and Others The same would be managed through
Payroll and Travel Management.

N
4.2.3 Deductions on Salary The same would be managed through
Payroll and Travel Management.

N
4.2.4 Allowances and other
Cash Payments to
The same would be managed through
Payroll and Travel Management.
N


Page 18

Employee
4.3 Vendor Invoices Fully
system
supported
This relates to the entire invoicing
procedure in FI, including the deduction of
TDS and Work Contract Tax and the
printing of TDS Certificates.

TDS and WCT certificates and returns shall
be produced from the system.
Customization needs to be done for the
same.

If the vendor revises the invoice amount,
supplementary invoicing for the same would
be done. The following would be the entry
generated:
Inventory A/c / Price Difference A/c Dr
Vendor A/c Cr


N
4.4 Credit Memo Fully
system
supported
The Quantity based credit memos would be
passed by MM. The non-quantity based
Credit Memos would be passed by Finance
Department where Invoice Reference would
be Optional.

N
4.5 Payments Fully
system
supported
Payment transaction relates to payments
made to the vendor through different
payment methods.

N
4.6 Excise Duty Partiall y
system
supported
Excise invoice will be generated in the MM
module. The accounting entry for cenvat
receivable shall happen automatically upon
up gradation of RG 23 A part II register.

N
4.7 Make Payments Fully This relates to the option of making N


Page 19

system
supported
payments either through the automatic
payment program or manually. In the latter
case, one can automatically print checks
from the payment document or manually
create the cheque and assign the payment
document to it.

4.8 Automatic Account
Assignment for
Discount
Fully
system
supported
If discount is maintained in the payment
terms the system will prompt the discount
and if approved the same can be posted
automatically. However the user can always
override the proposal made by the system
and change the same.

N
4.9 Clear Invoice Fully
system
supported
In SAP, the open item concept requires that
the payments be made against specific
outstanding invoices and thus linking up of
the two.
Whenever the automatic payment
programme is used, this linking is
automatic. However, when manual
payments are resorted to, this link has to be
created at the time of making the payment.

On the other hand, the manual payment
clears the invoice that had remained as an
open item – a new payment document is
simultaneously created by the system.
The Payment Terms will be maintained in
the Vendor Master but they can be
overwritten at the time of creation of
Purchase Order.

Y
5.10 Account Clearing Fully
system
Account Clearing to be done automatically
as well as manually
N


Page 20

supported
5.11 Print Cheque Fully
system
supported
In the procedure for manual payment with
automatic cheque printing, the system
generates and prints a cheque. Before
entering the payment document enter the
bank from which the payment is to be
made.

N
5.11 Prepare Manual
Cheque
Fully
system
supported
There might be instances, in which the
cheques might be manually prepared. In
this step, a manual payment is made but
the system does not automatically print a
cheque. Instead, the user needs to create a
manual cheque by assigning the
subsequent cheque number in the cheque
lot currently being processed for a particular
house bank account.

N
5.12 Make Down Payment Manual Advances to vendors would be made in
SAP using the Special G/L down payment
functionality.

Advances for material procurement and
related costs would be initiated through a
request made by the purchase department,
with a date by which the payment is to be
made. For other advances, the finance
department will be the authorising authority.

The system would automatically block all
requests, to ensure that it is properly
authorised by accounts before payment.

Down payment to be made manually.

N


Page 21

The TDS on the down payments (where
applicable) would be made in this
transaction.
Advance payment requests can be
generated from the system. These request
can be generated with reference to a
Purchase Order. Correspondingly, payment
can be made with reference to these
requests.

5.13 Clear Down Payment Fully
system
supported
It needs to be ensured that the down
payments are adjusted before running the
payment program. The system will pay the
net amount due after the payment run.

KTPL desires automatic clearing of vendor
accounts. The same is been worked upon.
N
5.14
TDS
Fully
system
supported
KTPL will use Extended Withholding Tax
Functionality. Since TDS is maintained at a
Company Code Level so all the checks,
controls & entries regarding TDS will be
take place at the Company Code Level.

N
5.15 TDS Deduction Fully
system
supported
The Withholding Tax Codes will be
maintained in the Vendor Master Data for
which TDS is applicable. Different Sections
and Different Tax Rates have to be
maintained.
At the time of Payment or Invoice which
ever is earlier, system will deduct the TDS
by referring the Tax Code maintained in the
Vendor Master. If TDS has to be deducted
at a different rate or the Base Amount will
be different, then the same has to be
modified at the time of entry.
N


Page 22

The Accounting Entry will be generated as
follows:

Vendor A/c Dr
To Bank A/c
To TDS Liability A/c

5.16 Remittance Challan Fully
system
supported
At the period end Remittance Challan
should be entered in the system against the
TDS Liability.

N
5.17 Bank Challan Fully
system
supported
On the basis of remittance challan, Bank
Challan would be entered in the system.
N
5.18 Generating TDS
Challan
Fully
system
supported
A vendor specific TDS certificate for a
period can be printed after entering the
Bank Challan.

N
5.19 Return Partially
system
supported
The Return can be generated from the
system at a Company Code Level.

N
5.20 Deduction of ESI and
PF from Contractors
Payment
Partially
system
supported
The same should be calculated and
deducted manually from contractors invoice
and FI entry has to be passed.

Y
5.21 Work Contracts Tax
Deduction
Partially
system
supported
Similar to TDS, Extended Withholding Tax
functionality would be used for Work
Contracts Tax. Tax codes would be
maintained in the Vendor master. WCT
certificates and returns shall be available
from the system.

Y
5.22 Letter of Credit and
Revolving LC
Partially
system
supported
Solution for LC and revolving LC is not
available in SAP. Hence KTPL has decided
to explore third-party software for the same.
Y


Page 23

5.23 Bills Of Exchange Fully
System
Supported
All Bills of exchange payment would be
made through the bill of exchange
functionality.

N
5.23.1 Receive Bills of
Exchange
Partially
System
Supported
The bill would be received from the vendor
at periodic intervals that would be entered in
the system as Noted Items.

N
5.23.2 Clear Vendor Invoice Fully
System
Supported
On the basis of the bills received, the
invoices of the vendor would be cleared.

N
5.23.3 Create Bills of
Exchange
Fully
System
Supported
The creation of the bills of exchange and
clearing of the outstanding vendors would
be manual. On clearing the vendor invoice,
the following entry is passed automatically.

Vendor A/c Dr
To Bills Of Exchange Payable

After creating the Bills of Exchange, the
Noted Item should be cleared.

N
5.23.4 Receive Bank
Statement
Manual The payment to the vendor through the
bank would be identified through the bank
statement.

N
5.23.5 Clear Bills of
Exchange Liability.
Fully
System
Supported
On the basis of the clearing instruction from
the bank statement the bills of exchange
liability for the vendor would be cleared.

N
5.24 Period End Activities The following closing activities would be
performed every month.

N
5.24.1 Account Clearing Fully
system
Account Clearing is a period-end activity –
in the system, accounts can be cleared
N


Page 24

supported either manually or automatically according
to pre-defined criteria
This activity is to adjust the unadjusted
debits in the vendor balance.

5.24.1 Manual Account
Clearing
Fully
system
supported
In the option of manually clearing an
account, the system by default selects all
the open items, which can be set off – the
user would then selectively choose the line
items to be cleared.
The special GL items in the vendor sub-
ledger will be cleared during this process.

N
5.24.2 Automatic Account
Clearing
Fully
system
supported
In the automatic account clearing
functionality, the system chooses the line
items to be set off and cleared together,
based on certain pre-defined criteria. The
program can be run first in the test and then
in the actual mode.
For this the common fields on the basis of
which the clearing is to be done has to be
identified and maintained at each
transaction.


5.24.3 GR/IR Clearing Fully
system
supported
GRN clearing is the process of matching
debits and credits in the GRN liability
account. The process is similar to account
clearing.
All GR/IR accounts would be automatically
cleared on the basis of the material and the
purchase order combination.

N
5.24.4 GR/IR Adjustment Fully
system
supported
In GRN adjustment, at the month-end, one
identifies, for Balance Sheet purposes, the
goods received and not invoiced and the
N


Page 25

goods invoiced but not received.

For all instances, where the goods have
been received but invoice not received the
system passes the following entry:

GR/IR Adjustment A/c Dr
To Goods Received Not Invoiced

For all instances, where the invoices have
been received but goods not received the
system passes the following entry:

Goods Invoiced Not Received A/c Dr
To GR/IR Adjustment A/c

5.24.5 Correspondence Fully
system
supported
Dunning shall be activated for Vendors. N

6.0 Manage Accounts
Receivable
The customer balance management is
covered in this section


6.1 Customer Master Different reconciliation accounts will be
maintained as per requirement.

N
6.2 Incoming Payments The following processes relate to customer
collection.

N
6.2.1 Collection Fully
system
supported
Receive the Incoming Payment through
Cheque/DD/Direct Credit in the bank. All
down payments made by a customer should
be received with reference to a sales order.

N
6.2.2 On account Collection Fully Each Incoming Payment is to be cleared N


Page 26

system
supported
against an invoice.
If any payment is received, which is not
linked to the invoice, then that will be posted
in the system as on account payment.

6.2.3 Post Partial Payment Fully
system
supported
Where the entire amount is not collected,
the same would be entered as Partial
payments. Subsequently, when the final
payment is received, the original invoice
and the partial payment received will be
cleared.
There will be a different G/L Account for
Automatic Rounding Off.

N
6.2.4 Post Incoming
Payment
Fully
system
supported
If the relevant invoice is known and
payment in full, post the incoming payment
with reference to the invoice.

N
6.2.5 Clear Invoice Fully
system
supported
While entering the incoming payment if it is
equal to the invoice value, the invoice is
cleared against the payment, generating a
clearing document number.

N
6.2.6 Print Receipt Voucher Fully
system
supported
Receipt voucher will be printed from the
system
N
6.2.7 Customer TDS Partially
system
supported
TDS deducted by customer will be
maintained in the SAP but all the tax rates
have to be maintained in the customer
master record.

N
6.2.8 Customer Invoice Fully
system
supported
Customer Invoices will be raised in the SD
Module upon billing. The accounting entry
will be generated automatically.

N


Page 27

Entries for Excise duty, Sales Tax, VAT, etc
shall be posted on
the basis of Tax code selected at the time of
SO/Invoice. The Tax Code shall contain tax
rates and G/L Accounts used for posting the
tax.

Customer Account….. Dr
To Sales a/c
To Excise duty recovered a/c
To VAT Payable a/c
etc…..

6.2.9 Excise Invoice Partially
system
supported
The excise invoice shall be generated in the
SD module. An accounting entry shall be
generated in the background for adjusting
excise payable against modvat receivable
(RG 23 A, RG 23C etc) and the difference
amount if any shall be adjusted in the PLA
account.
The utilisation of modvat can also be done
periodically in the SD module.

N
6.3 Special GL
Transactions
Special GL transactions relating to
transactions like customer advances, bills of
exchange, bank guarantees are covered in
this section.

N
6.4 Down Payment Advances received from customers are to
be maintained here.

N
6.4.1 Post Down Payment
from Customer
Fully
system
supported
Post the down payment received from the
customer as a special GL transaction. Two
special G/L indicators will be created for
advance to customers.
N


Page 28

The sales order reference will be optional at
the time of giving advance.

6.4.2 Clear Down Payment
against Invoice
Partially
system
supported
Once the customer is billed, the invoice
needs to be cleared against the down
payment received from the customer.
The credit item in the customer balance
needs to be cleared manually.

N
6.5 Letter of Credit The LC functionality is missing in SAP.
KTPL may also decided to explore third-
party software for the same.
Y
6.7 Bills of Exchange Bills of Exchange would be handled through
the standard SAP Bills Of Exchange
Functionality.

N
6.7.1 Receive Bank
Statement
Manual The receipt against a Bills of Exchange is
evidenced by the entry in the bank
statement.


N
6.7.2 Reverse Bill liability Fully
system
supported
After the bill has been collected (as
evidenced by the BRC and the bank
statement) you reverse the bill receivable in
the special G/L account and your own bill
liability.

N
6.7.3 Bank Charges Separate G/L will be created for bank
charges and the posting will be done
manually.


6.8 Period End Activities The following would be the period end
activities that would need to be undertaken
at the end of every period and at the end of
N


Page 29

each year.

6.8.1 Analyse Customer
Account
Fully
system
supported
Manually one needs to check each of the
customer account as to analyse the open
items waiting to be cleared against each
other

N
6.8.2 Account Clearing Fully
system
supported
Unadjusted credits in the system need to be
cleared. The tagging of the debit and credit
entries can be done manually or
automatically.

N
6.8.3 Other
Correspondence
Fully
system
supported
Dunning functionality would be activated
and used for the Customers.
N
6.8.4 Carry Forward
Balances
Fully
system
supported
Here, the balances of the customers are
carried forward from one fiscal year to the
next.

N
7.0
Manage Asset
Accounting

Asset accounting would involve
the following processes.


7.1 Chart of Depreciation Fully
system
supported
KTPL will use only one Chart of
Depreciation. The name of the same will be
KTPL.

N
7.2 Depreciation Areas Fully
system
supported
Depreciation areas will be maintained for
the system. One for Companies Act
Depreciation that will be posted in G/L
directly, other is Income Tax depreciation
that will be used for reporting purpose only.

N
7.3 Budgeting Partially
system
supported
The Asset Accounting module does not
support the functionality of the current
system of budgeting through Capex. As a
N


Page 30

workaround, Internal Orders are used for
this purpose.

7.3.1 Create Capex Fully
system
supported
Each Internal Order is planned and
budgeted. In the first step, the Internal
Order is created, approved and cleared.
This gives the details of expenses at the
G/L account level.
This detailing is done while planning for the
internal order.

Separate internal order types shall be
created for different budget types. Release
strategy for the orders would be determined
based on these budget types

N
7.3.2 Budget Capex Fully
system
supported
In the next step, the capex is budgeted.
Here, a higher authority puts a cap on the
Internal Order. Budgeting can however be
performed only for the Internal Order as a
whole and not for each G/L account.

N
7.3.3 Release Capex Fully
system
supported
The release of the capex makes it available
for posting. Till such time as the internal
order is not released, no costs can be
booked into it.
This is largely for authorisation control.

N
7.4 Create Asset Under
Construction
Fully
system
supported
The costs that are accumulated in the
capex are settled periodically to the assets
under construction.

At the time of creation of the capex itself,
the AUC can be created and assigned to
the internal order. However, this can be
N


Page 31

delayed till the point of time of the first
settlement of the capex.

However, alternatively, all the expenses or
material procurement with respect to a
project or capital expenditure can be directly
booked against a CWIP asset with line
items. On completion, for captialization
purpose, the CWIP assets can be settled to
another asset, line item wise. These CWIP
assets would be attached to statistical
internal orders which would enable budget
management during Purchase Order
creation as well as expense booking stages.

7.5 Create Settlement
Rule
Fully
system
supported
Every internal order has a settlement rule.
The settlement rule defines how and how
much of the costs collected in the internal
order are to be settled. Also, the settlement
rule contains who the valid receivers of
such cost are. Valid receivers would include
Assets, GL account, cost centres, other
internal orders etc.
Also, through the settlement rule one can
control how much of the costs are to be
settled.
Settlement will be configured to provide for
both - force a full settlement or partial
settlements. Settlements from one capex
can be made to multiple receivers. In such
case, one can split up the amount on the
basis of a fixed percentage or a ratio or
fixed amounts.
The settlement rule can be created at the
time of creation of the capex or latest by the
N


Page 32

first settlement.
When the AuC is ready for capitalisation, it
is settled to an asset. For this purpose, one
needs to create a separate settlement rule,
which will determine the assets that will be
posted to. In the system, defining
distribution rules performs line item
settlement.

7.6 Acquisition Fully
system
supported
For asset acquisition there are multiple
methods supported by the system including
methods of integrating with MM, FI.

1. Acquisition through PO.

2. Capex related asset purchase with
Internal Order - The internal order
(capex) would have been created
and the same specified in the PO.
On creation of the GR, the system
would automatically debit the internal
order with the PO cost.

Acquisition without PO - In such cases, the
asset account would be posted to through a
simple vendor invoice without reference to
any PO.

N
7.6.1 Update Internal Order Fully
system
supported
In the instances where the assets are being
acquired against a capex, the initial posting
has to be made through an internal order.
Where the PO is raised in MM, the PO
would be assigned to the Capex. When the
asset is received and a GR made, the
posting would be made to an expense
N


Page 33

account:

Project Purchase A/c….Dr
To GRN Liability ……Cr

Subsequently during settlement the cost is
capitalised.
Similarly for expenses booked from FI, if
these can be directly attributed to the
capex, then they are first expensed before
being capitalised during a settlement at the
month end.
With every posting (and with every PO
commitment) the capex budget is adjusted.
Where the assets are not being procured
against an internal order, one can post the
cost directly to the asset (final asset) or to
an AUC and from there to the final asset
through a settlement. (Described later)

7.6.2 Settle Internal Order
Periodically
Fully
system
supported
The expense incurred for the acquisition of
an asset is first charged off to the Internal
Order. Periodically, this order is settled to
the AuC.
Before running the settlement programme,
one needs to ensure that the settlement
rules have been created and the receivers
defined.
Each asset to which the cost is to be settled
has to be created and maintained in the
settlement rule for the internal order.
Internal orders can be settled individually or
cumulatively.
Depending on the settlement rule, the entry
made during settlement is :
N


Page 34


Asset A/c Dr
To Expense A/c (if settlement is
through the original expense head)
OR
Asset a/c Dr
To Settlement Cost Element (if
settlement is not through original expense
head )

7.6.3 Update AuC Fully
system
supported
On a periodic basis capex is to be settled to
the AUCs. The AUCs are updated with the
total values. The details of the transfer can
be viewed through a proof of origin report.

N
7.6.4 Asset Class Fully
system
supported
The Companies will create the asset class
as per the reporting requirement. A number
range will be assigned to an asset class. All
the number ranges will be internal number
ranges.

N
7.6.5 Create Asset Fully
system
supported
Each asset is created with reference to an
asset class. The asset class would control
(among other things) the field status of the
asset master and the numbering of the
assets being created.
The asset master has multiple data
screens. The field maintenance for each of
asset classes needs to be ascertained and
the field entry screen created accordingly.
Every asset master would have
depreciation keys – control parameters for
depreciation. Separate depreciation keys
would need to be maintained for different
depreciation areas.
N


Page 35

On saving the asset master the asset
number would be created by the system
automatically.
7.6.6 Evaluation Key Fully
system
supported
The companies will use all the valuation
Key for their different reporting purpose. But
all the fields will be Optional.

N
7.6.7 Settle AuC to Asset Fully
system
supported
Once the final asset is operational, the
AUCs are to be settled to the final asset.
In a process similar to the settlement of the
internal orders, a settlement rule can be
defined and the value of the AUC
transferred to the final asset.
N
7.7 Post Retirement Fully
system
supported
This would retire (removal / disposal) of an
asset or part of an asset from the asset
portfolio.

N
7.7.1 Post Sale of Asset Fully
system
supported
The asset would be retired with revenue
recognition. The entries would as follows:

Asset a/c
Credit
Accumulated Depreciation a/c
Debit
Asset Retirement a/c
Debit
Loss/Gain on Retirement a/c
Debit/Credit

The retired asset would be then uploaded to
the asset material.

Inventory – Asset to be sold a/c
Debit
Asset Retirement a/c
N


Page 36

Credit

7.7.2 Post Scrapping of
Asset
Fully
system
supported
In this scenario, an asset has to be
scrapped, with no revenue earned. The net
value of the asset is charged off to an
expense account.
The gain loss on sale / disposal of the asset
are automatically posted to the accounts
maintained for the purpose.

N
7.7.3 Asset Gain/ Loss Fully
system
supported
The gain loss on sale / disposal of the asset
are automatically posted to the accounts
maintained for the purpose.

N
7.7.4 Update FI/CO/AA Fully
system
supported
On passing the entry for the retirement of
the asset, the corresponding impacts on the
other modules are made.

N
7.8 Depreciation Depreciation takes place automatically in
the system, depending upon the
depreciation controls specified in the asset
master. The depreciation key contains all
control amounts for the calculation of
planned annual depreciation. A depreciation
key can be entered in the asset master
record in each depreciation area.

N





7.8.1 Depreciation Key Fully
system
supported
Straight Line Depreciation will be followed
for Companies Act depreciation area.
Different rates of depreciation will be made
for different type of asset class. The assets,
which have similar depreciation rate as per
the Companies Act, should be in same
asset class.

N


Page 37

7.8.2 Plan Depreciation
Run
Fully
system
supported
The depreciation calculation programme is
to be run monthly.
Such depreciation runs are planned
depreciation runs. One cannot skip a
planned depreciation run – i.e. until
depreciation for the month of April is run
depreciation for the other periods of the
year cannot be executed.
The planned depreciation run creates a
batch programme, which has to be run to
give effect to the depreciation and make the
postings for the same.

N
7.8.3 Repeat Run Fully
system
supported
If any problems occur in a planned
depreciation run, a repeat run has to be
made.

N
7.8.4 Update FI/CO Fully
system
supported
The batch programme created during the
depreciation would update both FI and CO.
Posting to the cost centres would be on the
basis of the cost centre maintained in the
asset master. The posting to the profit
centre is through this cost centre.

N
7.8.5 Post revaluation on
depreciation
Not
Supported
In the depreciation run posting for the
depreciation on the revaluation is also taken
care of.

N
7.9 Maintain Masters The following master data are relevant for
asset accounting.

N
7.9.1 Asset Master Fully
System
Supported
An asset master having a unique number
will identify every physical asset. An asset
will be created with reference to an asset
class and the asset numbering would be
N


Page 38

internal.

7.9.2 Calculation Key Fully
System
Supported
Calculation keys would define the method
and the rates of depreciation.

N
7.9.3 Depreciation Key Fully
System
Supported
Depreciation key contains the calculation
key and other items that control
depreciation like scrap value.

N
7.9.4 Asset Super asset Fully
System
Supported
Asset super- asset would be maintained for
reporting purpose only.

N
7.9.5 Evaluation Key Fully
System
Supported
The company may use all four-evaluation
keys for the reporting purpose. All the fields
will be optional.

N
7.9.6 Group Asset for IT
Depreciation
Fully
System
Supported
Group Asset will be maintained for Income
Tax Depreciation purpose and the same will
be maintained in the individual asset level.

N
7.9.7 IT Depreciation
Calculation
Fully
System
Supported
IT Depreciation will be calculated in Group
asset level. No depreciation will be
calculated for IT ACT to individual asset
level. This depreciation calculation is only
for Informative purpose. No Accounting
document will be generated from
depreciation calculation.

N
7.9.8 Depreciation Key for
IT Act
Fully
System
Supported
Depreciation key will be maintained for
Income Tax calculation Purpose.
N
7.9.9 Insurance
Classification
Fully
System
Supported
Insurance classification would again be only
for information purposes - to take care of
any reporting requirements for insurance
purposes.
N


Page 39


7.9.10 Lease Assets Fully
System
Supported
If assets are taken as Financial Lease then
the same should be maintained in the
master data to take care of any reporting
requirements for Financial Lease purpose.


7.9.11 Interest on Loan
Taken for the
Acquisition of Asset
Partiall y
System
Supported
If it is identifiable the assets against which
loan has been taken then the same can be
maintain in the asset master to take care of
any reporting requirements for the asset
against which loan has been taken. But
Interest on loan will be posted to the
individual asset manually.

N
8.0
Busi ness Area

8.1 Defining Business
Area
Fully
System
Supported
Business Area is primarily and essentially
used for internal reporting purposes. It is not
used, nor is it possible, to extract statutorily
required financial statements and other tax
reports at business area level.

While most balance sheet and P&L items
can be automatically and directly assigned
to business areas, certain items cannot be.
Business area wise Balance Sheet, Profit &
Loss A/c and Cash Flow shall be generated
from the system.

N
8.1 General Postings Fully
System
Supported
Business areas cannot be directly assigned
to GL Accounts. Hence during entries either
they have to derived from CO objects or
have to be inputted manually. Posting with
single business areas are automatically
balanced and adjusted. However certain
automatic transactions do not populate
N


Page 40

business areas. Similarly, single
transactions with multiple business areas
cannot be automatically balanced in real
time, unless balanced separate business
area line items for separate accounts are
posted.

8.2 Accounts Receivables
and Payables
Fully
System
Supported
Vendors and customer accounts
automatically derive business area from the
simultaneously posted single business area
sales/ revenue or expense accounts.

Materials, posted to, populate business
area based on the plant/ valuation area and
division combination for purchase cycle and
plant and division combination for sales
cycle. Balancing simultaneous line item
automatically derives the business area
from the supplementary line item. However
with base line items have multiple business
areas the leading vendor or customer line
items do not populate any corresponding
business area.

N
8.3 Assets Fully
System
Supported

Single business area is assigned in asset
master. Therefore any transactions related
to a asset, automatically posts to the
mentioned business area.


8.4 Business Area
Financial Statement
Adjustments
Fully
System
Supported
In order to balance business area books,
certain balance sheet and profit & loss
adjustments are required periodically.

N
8.4.1 Balance Sheet
Adjustments
Fully
System
Customer & vendor reconciliation accounts,
exchange rate differences in open items
N


Page 41

Supported and taxes need to be allocated to proper
business areas to balance the financial
statements.

The calculation for business area posting is
done using transaction F.5d and the posting
for the same is done through F.5e.

Vendors/ Customers – Since reconciliation
accounts cannot be posted directly to, these
accounts are updated using a adjustment
account.

Whereas for other adjustments, required
entries can either be posted to a separate
adjustment account or directly to the
respective account in absence of a
adjustment account.
Clearings accounts are maintained for
posting which cannot be allocated to either
of the mentioned categories.

8.4.2 P&L Adjustments Fully
System
Supported
Realized and valuated exchange rate
difference and cash discounts are
distributed to respective business areas.
This program unlike BS Adjustment can
only be run once in a period.

N

9.0
Manage Costing

9.1 Defining Cost Center
Hierarchy
Fully
System
Supported
The cost center is an organizational unit in a
controlling area representing a clearly
delimited location where costs occur.

N Remarks


Page

One type of hierarchy needs to be created
for Cost Center Accounting.
1. Standard Hierarchy

The Cost Centers will be as decided by the
KTPL team.

9.2 Defining Standard
Hierarchy
Ful ly
System
Supported
Here is the structure of the standard
hierarchy for KTPL
(Note that we are detailing to the level of
cost center groups only; the cost centers
are master data that will be created based
on requirements. Also the naming is to be
changed as per KTPL’s requirement)

KTPL KTPL main hierarchy

100000

Group

SD



Admin




Manufacturing




N


Page 43





9.3 Create cost center Fully
System
Supported
Cost centers are to be created from the
application side. Information required for
creating the cost centers should be
governed by two basic principles- need for
reporting, maintenance purpose and for
product costing information.
Each cost center contains a cost center
category – i.e. the nature of the cost center
– production, overhead etc. We are
proposing that the cost center categories be
divided into these basic categories-
production, Sales & Distribution, and
Administration.
N The cost centers will
be created business
area
specific, i.e. we
would be using the
business area field
compulsory in the
cost center creation
time. This would
assist in keeping
control check for
business area wise
bifurcation as well as
reconciliation
between FI and CO.
9.4 Determine validity
Period
Manual It decides the period for which cost center
will be valid. Cost center cannot be deleted
within that period. The period can also be
extended.

N
9.5 Grouping Cost
Centers
Fully
System
Supported
Cost centers need to be logically grouped
on certain criteria (reporting, location,
function). Each group is to be attached to
standard hierarchy.

N
9.6 Assign Cost Centers
to Standard Hierarchy
Fully
System
Supported
While creating cost center, it is to be
attached to a Node of standard hierarchy.

N Very Important step
as once this
assignment of CC is
done and
transactions are
entered, the


Page 44

changing of the CC
from the node to
another node is not
possible. Also,
deletion of CC is not
possible.
9.7 Defining Cost
elements & elements
groups
Fully
System
Supported
All types of cost elements i.e. primary and
secondary cost elements will be created in
controlling. Primary cost elements will be
taken from revenue and expense GL
accounts. Secondary cost elements will be
created based on activity types & settlement
rules calculations.
The number of such accounts is being
decided upon along with the finalization of
the chart of accounts – reporting needs
would largely drive this.

N
9.7.1 Create primary cost
elements
Fully
System
Supported
Accounts in the Chart of Accounts, which
are Profit and Loss Account type, would be
primary cost elements.

N
9.7.2 Logical grouping
primary cost elements
Fully
System
Supported
Cost elements would be grouped together
for reporting purposes.

N Grouping also
created for collating
expenses for the
activity types, making
overhead pools
9.8 Create Activity types Fully
System
Supported
Activity types represent the functions or
services performed by the cost centers.
Activity types are defined to value the job
done by a cost center. For production cost
centers we would be using two activity
types-machine hours and labour hours.

Each activity type would have a Unit of
N As of now, KTPL is
not using activity
types; we would have
the provision of using
splitting and then
automatic price
calculation procedure
for activity types.


Page 45

measure, control parameters as to whether
the activity prices are to be manually
determined or to be calculated by the
system automatically based on planned
values and the secondary cost element that
is to be used to allocate the activity prices to
the other cost objects.

9.10 Create secondary
cost element
Fully
System
Supported
Secondary cost elements will be used to
transfer costs within controlling without any
impact on FI.

We would be needing secondary cost
elements for overhead rates allocation to
the production/process order and product
cost collector, to allocate costs from one
cost center to the other, for internal and
external settlement and also to derive
conversion costs and load it on to the
product.

N Following secondary
cost element
categories in CO
would be used-
internal activity,
assessment,
overhead rates,
settlement
9.11 Actual costs Fully
System
Supported
In CO-CCA actual cost collection is done
from FI, MM, PP, PM & SD modules.

N For each P&L
expense G/L, we
would be making CO
account assignment
mandatory so that
during the booking of
expense, the relevant
cost center/internal
order is entered.
9.12 Other expenses Fully
System
Supported
All other expenses booked in finance would
flow into cost center accounting through the
mandatory cost center assignments.

N
9.13 Direct Materials Fully Material planning will be done in Bill of N For cases like power,


Page 46

System
Supported
Material (BOM). All the materials that have
been maintained in the BOM will be issued
to the production order.
The production order will be settled to the
finished stock valuation. So material
consumption will not be posted to the cost
center.

The only two ways in which material cost
can be directly loaded in the product is by
BOM and activity type (routing route).

if the specific
consumption cannot
be determined then
the other alternative
is to put it as the
activity type.
9.14 Indirect Material Fully
System
Supported
All material not maintained in the BOM –
fuel, consumables, stores spares, and
others - the GI is to be done to the cost
center. These costs will be treated as
overhead or as the activity type and will be
included in the Finished Stock valuation
through costing sheet.
N The rates of the O/H
by means of % or the
unit price is to be
maintained properly
and changed every
month based on the
under/over
absorption
9.15 Material for
Maintenance
Fully
System
Supported
The maintenance material will be issued to
the Maintenance order and the cost of it will
be settled to the maintenance cost center
periodically.
N The maintenance
material will be
issued to the
Maintenance order
and the cost of it will
be settled to the
maintenance cost
center periodically.
9.16 Depreciation Fully
System
Supported
Monthly entry of depreciation will be passed
in FI through the Asset Accounting sub-
module. The same data will be captured in
CO-CCA cost center wise based on the cost
centers specified in the asset masters.

N
10.0
Internal Order



Page 47

10.1 Internal Order
Definition
Fully
System
Supported
Internal Order is a cost object, which is
used to monitor cost as well as well for
CAPEX process mapping.

The use of a cost center depends upon the
users requirements. It is not time dependent
rather it depends upon the users choice.
Internal orders are two types: Real Order
and Statistical Order.

Real order collects the actual cost but
statistical order is used only for reporting
purpose.

N
10.2 Create Capex Fully
System
Supported
For the existing system of capexes, a
separate internal order type is to be
created.

N Different numbers
range for different
types of orders,
different budget
profiles and
settlement receivers
will be maintained
10.3 Plan Capex Fully
System
Supported
The internal orders to be used for capexes
first need to be planned. The planning is at
a micro level – at the GL/expense account
level. Typically this would be prepared by
the individual/department raising the capex.

N Internal order
planning possible by
creating layouts for
periodic levels.
10.4 Budget Capex Fully
System
Supported
Subsequently a budget would be fixed on
the capex. The budget is at a macro level,
at which point of time, the overall cap on the
expense (at the capex level) is frozen.
Budget for capexes could span fiscal years.
N Budgeting for internal
order possible yearly.
A budget manager
should be assigned
under customizing for
each budget. It is an
overall value
10.5 Release Capex Fully Until the asset is finally released, no posting N By means of a


Page 48

System
Supported
to the capex can take place.

release strategy, for
the capex order
types, release would
not be immediately
activated during
creation. It has to be
released separately
by means of
authorization control
10.6 Posting to Capex Fully
System
Supported
Any expense incurred for a capex can be
assigned to it at the transaction level.

For all purchase and service related
activities for a capex, the posting would be
made from the MM module directly, during
GRN and invoice verification.

For all asset purchases under a capex a PO
will be prepared by account assigned giving
the capex internal order number.

Commitment account is proposed to be
activated. Hence, as soon as a PO is raised
against a capex, the budget of the capex is
accordingly reduced.

While creating a GRN, the following entry
would be made:

Project Purchase A/c Dr
To GRN Liability

For services (for which PO is raised) the
capex needs to be assigned at the PO level
itself.
N


Page 49


Again, all expenses that can be related to
the capex for which expenses are booked
from FI, the internal order would be
assigned to each expense line item during
the transaction.

As budget management is also activated
(possible only for internal orders) the
system would give warnings / errors (as
configured) when the budgetary limit is
being reached.

10.7 Settle Capex
Periodically to Asset
Under Construction
(AuC)
Fully
System
Supported
All posting to the capex is initially made
under an expense head. Subsequently at
the end of every month, a settlement
program would be run to settle the costs
from the internal order to the AuC.

Before this, the AuC first needs to be
created in the Asset module.

N
10.8 Monitor Budgets Fully
System
Supported
Multiple reports are available for budget
monitoring in addition to the online budget
availability checks.

N
11.0
Profit Center
Accounting
New functionality being used in KTPL to
derive the profitability of the different
product lines.
Selected balance sheet items can al so
be drawn for the profit centers period
wise for analysi s.

N
11.1 Standard hierarchy of
profit centers
Fully
System
The first step is to enter the name of the
standard hierarchy for profit center master



Page 50

Supported data.

There would be one highest node call ed
KTPL under whi ch the profi t center
groups will be maintained.

You can then maintain it to create the lower
level nodes required to complete your
hierarchy.
11.2 profit center Fully
System
Supported
The following will be the profit centers that
would be designed for BALCO for capturing
the profitability information:

Profit Center: KTPL
A dummy profit
center (9999) will be
automatically created
that will have
unlimited validity
period. This profit
center will contain
statistical postings
made to any object
which had no profit
center assigned to it.

11.3 Assignment of profit
centers
By assigning all the objects which incur
costs or revenues in your system to profit
centers, you
determine how your company is to be
divided into profit centers.
These assignments also make it possible to
display selected balance sheet items. All
relevant account assignment objects are
assigned to the respective profit centers
using Customizing functions.

a) By assigning unique profit
center to material+plant
combination, all the costs



Page 51

incurred in the production
order can be attributed to the
profit center for that material
b) By assigning cost
centers/internal orders to the
profit center, the expenses
incurred for the cost
center/internal orders will get
statistically posted to the profit
center automatically
For the sales order, the order item would
get related to the profit center based on the
material for which the order item is made
and hence revenue items would start
flowing.

11.4 Monitoring
assignments of profit
centers
The assignment monitor provides you with
an overview of all the assignments you
have made to
profit centers and supports you when you
make or change assignments.
For example, you can call up a list of cost
centers that have not been assigned to a
profit center or those cost centers which are
assigned to a particular profit center or profit
center group.
Incorrect
assignments lead to
incorrect transaction
data in Profit Center
Accounting, which
usually can only be
corrected with great
difficulty. You should
therefore check your
assignments very
carefully.


11.5 Transfer from CO
objects to the profit
centers
All primary postings to account assignment
objects in Controlling are posted to profit
centers using
the same cost element.

The profit center of the crediting account



Page 52

assignment object is “credited” using the
same cost
element, and the profit center of the object
to be debited is used as the partner profit
center.

In addition, the profit center of the “receiver”
is debited using the same cost element, and
the profit
center of the sender is used as the partner
profit center.

11.6 Allocations of profit
center expenses and
revenu
Allocation (assessment and distribution) of
overhead costs is usually performed at
period closing.
This is usually done directly in CO and
reflected in the data in Profit Center
Accounting.


11.8 Derivation of profit
centers
SD-Sales order/Billing Document: Line
items of the
sales order. For line items default is from
material and plant

MM Goods movement- Goods receipt for
purchase order from the plant/material of
the purchase order

FI-AA Asset Accounting: From internal
order or cost center of asset master

FI – Posting: Additional P & L accounts
Profit center
remains blank. Default Profit Center (3KEH)
to be assigned and if possible validation



Page 53

rules will be defined.



E. Standard SAP Reports

Serial
No
Sub-Module Report

1. General Ledger a Financial Statements – Balance Sheet/ Profit & Loss A/c
b Financial Statements – Plan/ Actual Comparison
c Cash Flow
d G/L Account Balance
e G/L Account Line Items
f Chart of Accounts
g G/L Accounts List

2. Customer
a Customer Sales
b Customer Balances
c Customer Account Balance


Page 54

d Due Date Analysis
e Customer Line Items
f Customer Due Date Forecast
g Customer Payment History
h Analysis of Overdue Items
i Open Down Payments
j Customer List


3. Vendor
a Vendor Balances
b Vendor Account Balance
c Due Date Analysis
d Vendor Line Items
e Open Down Payments
f Vendor List
g Check Register

4.Fixed Assets


Page 55

a Asset Explorer – Single Asset
b Asset Balance – Various Variants
c Inventory List
d Depreciation


5. Cost Center Accounting
a Cost Centre: Actual/Plan/Variance
b Cost Centre: Current Period/Cumulative
c Cost Centre: Actual/Plan/Commitments
d Activity Types
e Cost Centre: Quarterly Comparison
f Cost Centre: Fiscal Comparison

6. Internal Order
a Orders: Actual/Plan/Variance
b Orders: Current Period/Cumulative
c Orders by Cost Element


Page 56

d Cost Elements by Orders
e Orders: Actual/Plan/Commitments
f Orders: Periodic Comparison
g Orders: Quarterly Comparison
h Orders: Annual Comparison
i Orders: Actual Line Items
j Plan Line Items
k Budget Line Items



7. Profit Center Accounting
a Profit Centre: Plan/Actual/Variance
b Profit Centre Group: Plan/Actual/Variance
c Profit Centre Group: Compare Quarters over 2 Years
d Profit Centre Group: Balance Sheet Plan/Actual/Variance
e Profit Centre List: Plan/Actual
f Profit Centre: Customers


Page 57

g Profit Centre: Vendors
h Profit Centre: Assets
i Profit Centre: Materials











F. Process Flow Diagrams

(a) Customer Payment Receipt



Page 58









Page 59


(b)Customer Master Maintenance







Page 60





(c)Accounts Payable – Product Invoice Verification




Page 61


(d) Accounts Payable – Service Invoice Verification





Page 62


( e) Vendor Master Maintenance











Page 63


(f) Period Closing Activities




Page 64





(g) Material Valuation



Page 65








Page 66

(h) Tax Deducted at Source (TDS)







Page 67


(i) Cash Payments





Page 68



(j) Asset Accounting








Page 69




(k) Asset Accounting – Acquisition




Page 70





(l) Asset Accounting – Retirement





Page 71






(m) Asset Accounting – Depreciation




Page 72







(n) Cost Centre Accounting



Page 73










Page 74