SAP - FI AR BK: Electronic Bank Reconciliation

The EBS is used to automatically assign incoming and outgoing payments to house bank accounts when they relate to items already posted in the system to customer/vendor/clearing accounts and, where appropriate, the clearing of them.
Each uploaded electronic bank statement will be assigned with a unique no. in SAP and can be printed retrospectively.
 
Steps in Electronic Bank Reconciliation:

1. Electronic Bank Statement file (in SWIFT MT940 format) is extracted from BANK
2. Data (SWIFT MT940 for BANK) is imported into a temporary dataset in SAP
3. Batch input sessions are generated (per bank statement: one session for G/L Accounting and one for Subledgers- AR/ AP).  Bank accounting and subledger accounting batch session can be executed separately or jointly
4. Posting rules and account determination are defined in TR-CM customization
5. As an electronic bank statement is being imported, the system identifies the transactions in it and determines how they are posted. 
6. The note-to-payee fields in the electronic bank statement contain various information relevant to open item clearing.  Note to payee fields can be interpreted by document number or reference document number for the clearing transaction (example: standard algorithm).  If the algorithms we deliver are not sufficient, it is possible to program a user exit tailored to your business (e.g. change the posting rule; influence account determination by means of account modification).
7. Post-processing for posting proposals(line items) which cannot be cleared

Note:
Electronic Bank Statement format SWIFT MT940 is compactable with SAP TR-CM.  Standard algorithm for clearing documents is available in the predefined form in SAP.  Customisation, as stated in point 6 above, will be needed to cope with AAA specific requirements on Bank Reconciliation.  The review task will be performed on the Detail Design Phase, detail of which will be incorporated into the respective customisation functional specifications.

Reasons for adopting Costing-Based COPA

SAP CO-PA was intended for use with a cost-based approach that stores different currencies, quantities and values from SD, FI, MM and PP as PA value fields to manipulate for a variety of reports.  This is the recommended path as it allows more variability in collecting data for PA reports (related to details of cost components for variances, etc.)

In case of High-Tech industry companies using SAP CO-PA, the majority of them utilitise Costing-Based COPA to enable more detail level of Cost of Sales analysis. 
 
Costing-Based CO-PA sometimes does not match with legal book values.  Such discrepancies can be explained mainly by 3 big factors:

Timing differences: When the Delivery step is performed in SAP SD, but Billing is not, nothing gets booked into COPA, but COGS is already booked in the FI legal book.  During the SD Prototype, since Billing Due List (a batch program) will be executed each day, which perform the billing step for Sales Order with Delivery but not yet billed, the COGS and Revenue will be in syn in both FI and COPA for AAA.
 
Accruals: It is possible that accrued values are posted in COPA (might be triggered by program in Sales Order conditions), without any posting in FI legal book
 
Rounding differences from Foreign Currency Translations

Note:
Management using/ viewing these COPA reports need to be acknowledged the fact that due to the intended design of the Costing-Base COPA, values not necessarily always tie to FI legal book. Discrepancies to FI might occur, but explainable.s

SAP- CO : Some of the Product Cost Approaches

§ Finished Goods Inventory in Production Plant AAAA

  • Valuation at moving average price per batch (FIFO batch valuation) 
  • A new batch number will be generated for each production order (work order) producing the finished product
  • Each batch will have a unique material cost
  • The material cost of a batch is calculated from semi-finished goods and raw materials that are directly constituting to the finished product according to the BOM

§ Semi-finished Goods Inventory in Production Plant AAAA

  • Valuation at standard price updated from standard cost estimates
  • All inventory of each semi-finished product will be valuated the same (at the defined standard cost)
  • The standard cost can be updated either: 1) manually, or 2) automatically from the cost roll-up (can be using weighted average) of the lower levels of the BOM and can be selectively updated only for certain semi-finished products.
  • Re-valuation of existing inventories for semi-finished product will happen whenever the standard cost is updated.  The gain or loss will post to the P/L accounts

§ Raw Materials Inventory in Production Plant AAAA

  • Raw materials will be valuated for each batch of the receipts of purchase using the purchase order price.
  • The batches of raw materials will be issued to production orders at FIFO.
  • No re-valuation of raw materials will be required.


§ All Inventory in Branches

  • Inventory will be valuated for each batch of the receipts of STO using the STO price (transfer prices plus the landed costs).
  • The batches of goods will be delivered to customers at FIFO.
  • No re-valuation of inventory will happen.

SAP - CO : Period End Closing Process

Period end closing process is a monthly activity in CO and it refers to the following areas:

  1. Execution of allocation cycles to apportion cost from common or shared cost centers to final cost centers
  2. Generation of monthly reports


The following tasks have to be executed at every period end closing:

  • Ensure postings are completed from sub modules and sub modules have closed
  • Execute all the active allocation cycles
  • Check key figures to sub modules (i.e. total Cost Center Accounting figures to agree to total G/L expense accounts etc)
  • Generate monthly reports
  • Lock current posting period for controlling

SAP - CO : Statistical Key Figures

Statistical key figures serve as a basis for internal allocations and as references in the key figure analysis framework. Statistical key figures can be used for internal cost allocations, and can be defined as either fixed values or totals values.  There are two major types of allocation in SAP:

  1. Distribution
  2. Assessment

Distribution is the process of cost allocation used to allocate primary costs of cost center using the original primary cost elements.  In this method, the costs being allocated will be retained into the original cost elements.  On the other hand allocation by assessment could be applied to both primary and secondary costs using a secondary assessment cost element which is different from the original cost elements.  In this case, the costs being allocated will be posted to a secondary assessment cost element.

Statistical key figures are defined for assessment purpose:

The statistical key figures used are:
  • Employees
  • Man-hours
  • Floor space
  • Quantity by Finish Goods

Points for ECC 6.0 FI Certification - NEW GL

1.       Possibilities with New GL:

·          Legal and Management Reporting

·          Extensibility                                  (extended data structure by default - with customer fields)

·          Account Balancing with Any characteristics

·          Simple Mapping of Parallel Valuation              (possible to manage multiple "books" (->ledgers)

·          Reduction of TCO

·          Transparency and Uniformity

·          Segment Reporting                              (with online document split in real time)

·          Real-Time Integration        CO=>FI                        (time consuming recon activities omitted)

2.       Above possibilities not available in Classic GL

3.       Do I have to use the new GL

·          Optional: for existing SAP customers – during upgrade Classic GL (GLT0) remains active at first

·          For initial installations New GL Ledger is active by default in mySAP ERP

4.       Activating the NGL Accounting:

·          Automatic in initial installation

·          It is at client level – applicable across all CC'

·          TCODE: FAGL_ACTIVATION

·          Result in system-wide changes to the easy access menu and screen and customizing paths

·          Conventional Financial Accounting paths will initially remain available – can hide with program RFAGL_SWAP_IMG_OLD

5.       Ledger Definition:

·          SAP provides leading ledger "0L" and summary table – FAGLFLEXT with the standard system

·          Leading ledger gets many of its control parameters from the CC – automatically comes to LL

·          LL manages additional local currencies & FYV  & PPV which are assigned to CC

·          There is exactly only one leading ledger

·          Only the values from LL are posted on to CO in standard system

·          Addition to LL, you can define other non-leading ledger

·          You can assign different alternate currencies &/ FYV, PPV to NLL

6.       Summary / Total Table:  

·          Every reporting is from this table only

·          It has extended database

·          New GL Total Table (FAGLFLEXT) updates more char/data than the Classic GL Total Table (GLT0)

·          New standard fields included:

                                                   i.      CC

                                                  ii.      PC

                                                iii.      Segment

·          It can extended with additional fields – both predefine SAP fields and entirely new fields

·          To add this – have to add to account assignment block

·          Extending the block will lock out all other transactions

7.       Scenarios – Definition and Assignment:

·          Scenario defines which fields are updated in the ledgers (in GL view) during a posting (from other application component)

·          Scenario provided by SAP:

                                                   i.      Cost center update                 -        FIN_CCA        - sender & receiver CC

                                                  ii.      Preparation for consolidation         -        FIN_CONS        - consolidation transaction type & trading partner

                                                iii.      Business area                -        FIN_GSBER        - sender & receiver BA

                                                 iv.      Profit center update                -        FIN_PCA        - PC & Partner PC

                                                  v.      Segmentation                -        FIN_SEGM        - segment, partner segment & PC fields

                                                 vi.      COS accounting                 -        FIN_UKV        - sender & receiver FA

·          Scenarios should be associated with the types of Ledgers (LL, NLL (N1), NLL (N2))

·          Scenarios available in customizing         -        provided scenarios assigned to ledgers in customizing

·          A ledger (LL) can be assigned one or more scenarios, or even all six at once

·          Can not define your own scenarios

·          Scenarios do not have to be assigned to non-leading ledgers

·          You do not need one ledger for each scenario

·          Multiple/non-leading ledgers are useful for modeling different accounting rules

·          Values recorded in non-leading ledgers not record in CO module

·          If you don't assign scenarios to a ledger (or to multiple ledgers) - segment B/S will not be possible

8.       Entry View and GL View:

·          When NGL active Financial accounting document always has two views

·          You can also see the document in NLL in GL view

·          Entry:        view of how a document also appears in the sub ledger views / sub ledgers (AR/AP/AA/Taxes)

·          General:        view of how a document only appears in GL        -        only for GL and not for sub ledgers

9.       S – A & F' I:

·          In general, nothing has changed regarding the entry of the documents

·          Dependencies have also remained:

                                                   i.      Expense account is defined as primary cost element in CO and therefore requires a CO relevant account assignment during entry

                                                  ii.      CO object is used to derive PC and FA

                                                iii.      Now new with ERP: A segment can now be derived from PC

10.    S – A & F' II:

·          If corresponding scenario not assigned – no entities are inherited to GL (neither LL / NLL)

·          Effects of missing scenario will be like – if you call up B/S you can see the amount in exp account – but the same not allocated to scenarios – so segment B/S not possible

11.    S – A & F' II:

·          Scenario assignment is not capable of creating a "zero balance position" for any given entity – because all the terms not passed to all the line items so segment B/S not possible – this function can be possible using the document splitting with active inheritance

12.    Use of segment entity:

·          Segment field is one of the standard account assignment objects available in mySAP ERP to run analyses for "objects" below CC Level.

·          Objective is to give a detail look at the various business activities- segment reporting        -        IAS14

·          BA / PC can be used as alternatives – segment is in addition to BA & PC

13.    Deriving a segment:

·          Segment assigned in the PC Master record

·          Segment posted automatically when PC posted

·          There is no "dummy segment posting"

·          If the PC does not have a segment, there is no segment account assignment either

·          Default is derive segment from profit center – using BAdI , customer can develop their own derivation solutions

·          BAdI : FAGL_DERIVE_SEGMENT

14.    To post, analyze, and display document segments in NGL you have to perform below activities:

·          Definition of the segment

·          Derivation of the segment                             -        from PC

·          Maintain the FSV & FSG of corresponding FI doc         -        make 'segment' field to 'optional entry'

·          Maintain the field status of the posting key          -               "   "

·          Display the segment field using layout in the document display

·          Define the scenarios : scenarios has to be defined for LL         - if not segment will only be visible in entry view

15.    Document Splitting:

·          Motivation: to create segment financial statements

·          Assumption:

                                                   i.      Operative process (of document entry) must not be disturbed (changed) by the online split

                                                  ii.      When a vendor line item list is called, of course, there should still be only one open item for the invoice.

·          Splitting doesn't happen in sub ledgers – happens only in GL account level

16.    Steps involved in DS:

·          Passive split

·          Active (rule-based) split

·          Clearing line/zero balance formation by document

17.    Passive split:

·          During clearing the account assignments of the items to clear are inherited to clearing line items

·          Cannot be customized

18.    Active split:            (rule – based)

·          System splits document due to splitting rules         (provided or custom define)

·          Can be configured

19.    Clearing lines / zero balance formation by document:

·          System creates new clearing line automatically to achieve a split

·          Can control this process with the "zero balance flag"

20.    Splitting procedure:

·          Is the total of all splitting rules of all business transactions.

·          Defines how and under which circumstances split will be performed

·          Means, each procedure defines how each item category will be handled in the individual business transactions

                                                   i.      Business transaction: is a general breakdown of actual business process that SAP provides and that is assigned a wide variety of item categories

                                                  ii.      Business transaction variant: is a specific version of the predefined business transaction provided by SAP and (technical) modeling of a real business process for document splitting.

                                                iii.      Item category:  is (technical) map of the posted line items – describes the items that appear within a document – derived from among other things, GL account categories – semantic description of document split.

                                                 iv.      An individual splitting rule defines which item categories can be split and at the same time defines which foundation can be used

·          Every GL has to be categorized into one of the item category

·          GL account is associated with the item category

21.    Splitting rule TCODE: GSP_RD

22.    Splitting rules are not for CC – it is defined at client level

23.    Document splitting characteristics:

·          After defining how you want to split – now define which characteristics to use for splitting in GL accounting

·          System proposes logical document splitting characteristics based on the assigned scenarios

·          If you elect to use additional splitting chars, you should manage these chars in at least one Ledger

·          Activate:

                                                   i.      Zero balance flag – if you plan to use char to create FS. Balance of the involved entities is then always 0 for every posting, ensuring  "entity balancing"

                                                  ii.      Mandatory flag – has the two meanings:

1.       It is an extension of the field status for accounts in which the char can not be entered during doc entry and for accounts that cannot be controlled through the field status.

2.       It is a check as to whether a business process-equivalent business transaction variant was selected (which determines whether a splitting rule can be found)

24.    Activating document splitting and inheritance:

·          Splitting is first activated client-wide in customizing

·          In a further step you can activate/deactivate splitting in each CC

·          Inheritance: means when you create customer invoice from a revenue line – entities (such as BA / segment) are projected to the customer and tax lines in the GL View

·          Default account assignment can be used to replace all account assignments that could not be derived from the posting with a constant "value"

25.    Splitting procedure 0000000012 is the defaulted procedure provided by SAP

26.    There is no reason why you shouldn't activate inheritance when splitting is active.

·          If you didn't use inheritance, you'd have to define "rules" for the business processes to ensure that the account assignment are inherited – to achieve a zero balance in order to post the item

·          Activation of inheritance is a first practical step to enable documents with active splitting, without any other customizing activities.

·          Inheritance is performed online and at the line item level.

Need to stop depreciation posting on some assets

Our client want to stop depreciation posting on some particualr assetsbecause these assets are not in use & need to be disposed in future.

 
What to do to stop depreciation posting on some assets ?
 
Set the shutdown indicator for these assets and assure that shutdown is considered by the assigned depreciation key.
 
I have tried this option already but the result is that it is reversing all the depreciation posted in previous month of current year.
My issue resolved. I used shut down option.

Calculation of Depreciation for Tax for India

In India, there is a requirement that the Depreciation for Income Tax should be calculated based on the date of Acquisition. If an asset has been acquired before or on completion of 180 days of a Financial Year, than the calculation of Depreciation is allowed for full year. If the asset has been acquired after 180 days , depreciation is allowed only for 180 days. Hence for an asset acquired on 25/09/2009, system should allow calculation of depreciation from 01/04/2009, assuming that the fiscal year starts from 01/04/2009 and ends on 31/03/2009. However, if the asset is acquired on 07/10/2009, the system should allow depreciation from 01/10/2009. Sap has delivered standard depreciation keys for the same in reference chart of depreciation for India 0IN.

But if the asset has been acquired on 01/10/2009, still the asset has to be depreciated from 01/04/2009, since the asset has been acquired for less than 180 days into the fiscal year. The system is working fine for asset capitalized on 25/09/2009 and 07/10/2009. But we are not able to map the same if asset is capitalized on 01/10/2009 and 02/10/2009. For these two dates, the depreciation should start from 01/04/2009.

I have checked the period control setting and calender assignments and everything seems to be in place. How can we tackle the issue?
 
The same has been resolved.I Created a new assignment in Period Control IT for my fiscal year variant. For month 10, i added a new line item with no of days as 2 in addition to no of days as 31 for month 10.