krishna tissues private limited1fi

KRISHNA TISSUES PRIVATE LIMITED

My SAP Implementation

BR ERP TECHNOLOGIES PVT LTD

Project: Sankalpa

Financial Accounting & Controlling

BUSINESS BLUEPRINT

Prepared by Checked by Reviewed by Signed Date

Tanmoy Dutta (FICO)

Tamal Kanti Biswas(FICO)

Biswanath Maitra

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

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.

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.

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 Operating 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.

One Controlling 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 Posting 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

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.

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.


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


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

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

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

2.4 Maintain Bank Groupings


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


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

3.0 Staff Advances For Companies Business


The same would be managed through Payroll and Travel Management.

N

3.1 Miscellaneous Expenses


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


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

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


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


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

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


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


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.

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


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


For this, the financial statement version, which groups together the accounts under the appropriate categories, will be maintained.

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


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


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 balances are managed through the Accounts Payable functionality.

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

N

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

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 Partially 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

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


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

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


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

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


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

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


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


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


Solution for LC and revolving LC is not available in SAP. Hence KTPL has decided to explore third-party software for the same.

Y

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


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.


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

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


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


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

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

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


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

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


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

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

6.4.2 Clear Down Payment against Invoice


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

each year.

6.8.1 Analyse Customer Account


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


Dunning functionality would be activated and used for the Customers.

N

6.8.4 Carry Forward Balances


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

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


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

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


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

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

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


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

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

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

Credit

7.7.2 Post Scrapping of Asset


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

7.8.2 Plan Depreciation Run


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

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


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


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


Depreciation key will be maintained for Income Tax calculation Purpose.

N

7.9.9 Insurance Classification


Insurance classification would again be only for information purposes - to take care of any reporting requirements for insurance purposes.

N

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

Partially 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 Business 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

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


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


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

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


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

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


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


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

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


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


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


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.

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


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,

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


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

10.1 Internal Order Definition


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

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

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)


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 also be drawn for the profit centers period wise for analysis.

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

Supported data. There would be one highest node called KTPL under which the profit 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

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

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

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

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

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

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

g Profit Centre: Vendors

h Profit Centre: Assets

i Profit Centre: Materials

F. Process Flow Diagrams

(a) Customer Payment Receipt

(b)Customer Master Maintenance

(c)Accounts Payable – Product Invoice Verification

(d) Accounts Payable – Service Invoice Verification

( e) Vendor Master Maintenance

(f) Period Closing Activities

(g) Material Valuation

(h) Tax Deducted at Source (TDS)

(i) Cash Payments

(j) Asset Accounting

(k) Asset Accounting – Acquisition

(l) Asset Accounting – Retirement

(m) Asset Accounting – Depreciation

(n) Cost Centre Accounting

krishna tissues private limited1fi

Documents