Surviving a successful SAP GO-LIVE

I still remember the first time that I was a part of a SAP project that went live. We had toiled for seven months to get the Netherlands operation of a gas manufacturing company from an outdated HP legacy on to SAP. The day before the go-live saw us toil till 04:30 in the morning only to miss the opening address of the general manager over some cakes and beer. Yes the Dutch can drink beer at all hours of the day. The go-live was a rocking success but still we missed out on the free cans of beer that morning. So here is my list of things that enable companies to have a rocking go-live and not miss the beer party:

==>  Proper Governance: A lot of resource and money is spent on a SAP implementation. Without a proper governance model there is no accountability and the project would fall apart. Lots of time, the upper management is way too busy in running the business at hand and the implementation takes a backseat. A proper governance ensures that the vision of the management is percolated down to the lower levels and conflict resolutions are easier. Weekly meetings with status reports go a long way in making a success story of any implementation.

==>  Scoping: Most SAP projects have time and cost overruns because of improper scoping. A proper blueprinting of the business at hand and mapping the same to the solution available results in knowing the gaps that have to be bridged. Sometimes very little time is given to this whole process resulting in improper estimates and subsequent gaps being found that are critical for the business. As a result the scope keeps on creeping up and leads to an overall delay in the program. Proper documentation should be maintained about the scope and a process should be set up by the governance team about scope creeps. Best managed projects have minimum scope changes.

==>  Stakeholder communicaton: Many project disasters can be avoided by setting up proper communication channels. Often there are no clear cut communications from the project management team about the expectations from the business. In turn the business has no clues about what to expect out of SAP. Communication of weekly progress and targets for the next week play a pivotal role  Most SAP implementation service providers follow a global-delivery model where custom development (ABAP coding) is done at a different location. As a result there are a lot of bottlenecks in communication. Efforts should be made to ensure that there is proper communication of requirements resulting in near zero errors. During the stage of cutover and go-live effort must be made to have status meetings everyday which go a long way in giving confidence to the stakeholders.

==>  Involvement of business at all steps of the project: An SAP implementation is not only an IT software change. It involves a change in the approach of business and lots of processes need to be aligned to this new way of working. As a result, there should be involvement of the business at all steps straight from blueprinting till the go-live. Teams working in silos often face a problem because of unwillingness of the business to look for alternative ways of working at the last moment before the go-live. The involvement of business results in healthy discussions and subsequent realignment of business process becomes easier.

==> Not the onus of IT: Similar to the previous point, there should be a firm communication from the top management that the onus of implementing SAP is not only for the IT team but the whole business. This results in different ideas coming to the table and reduces conflicts during go-live.Business approvals at every stage: No SAP project can be achevied without custom developments. There are local business processes that need ABAP codes to be written for certain add on functionalities. Often the developments related to such gaps go completely untested till the point of user acceptance testing resulting in major defects that can be avoided by taking the business approval from a very early stage of development. The best way is to share unit testing and integration testing results with the business and seek their approvals before hand.

==> Ease of usage tools creation: A lot of SAP processes/ transactions are time consuming and hence business users are unwilling to let go of old processes. In one of our projects, rebate processing was being done through excel sheets. It was very difficult to convince the business users to use the standard SAP functionality to create rebates because of the sheer time required to create one rebate in SAP. Similar was the requirement for having a tool for faster upload of contracts into SAP. We managed to create such tools that have gone a long way towards the acceptance of the solution by the business users. Such tools are easy to create and give the users a confidence and saves their time.

==> Exhaustive training and hand holding pre and post go-live: Usually during any implementation, user trainings are completed in tight schedules. For a novice, learning all the transactions and nuances of SAP is not easy. This can only be acheived through exhaustive trainings and hand holding sessions pre and post go-live. Most of the issues that are encountered during any implementation is caused because of a lack of knowledge. After the go-live there should be a validation of the data going into the system by the implementation team to check for errors in transactions before they become disruptive.

==> Controlling data issues during user acceptance testing: During any user acceptance testing the majority of issues are related to wrong master data. Most of these issues can be avoided by putting in place checks and controls to make the master data proper for the testing. A lot of time and effort can be saved by this step. If this step seems to be very tedious, then a subset of the data should be analsyed for errors and this should be provided to the users for user acceptance testing.

==> Managing changes: Change management is very important to any organisation and especially so when taking a giant step like a SAP implementation. A lot of processes are bound to change and reactions to change are not always positive. To ease changes there should be proper hand holding for the users and giving them the broader picture of why such changes are necessary. Human nature avoids changes and in case of a SAP implementation people are also afraid of their job security. To get the best results the governing body should address change management issues with positive reasons.

==> Motivating and rewarding people: A SAP implementation is a very complex project and people need motivation to go ahead with the work at hand. Rewarding people who have worked towards change, arranging open forums and appreciating people for their committment towards the project goes a long way in making an SAP implementation successful.

==> Managing politics: Politics is one thing that can derail an implementation and hence the governing committee should take every possible action to eliminate the politics. Hidden agendas should be brought out in open through transparent communication.

Author: ainindra
Source: sdn. sap. com

SAP FICO: SPL - Variable field movements in FI

Sometimes we need to modify standard SAP transactions in FI for field movements . This blog is intended to provide a step by procedure of user exit creation for this field movement to occur instead of modifying standard SAP programs with an example scenario.

Example Business Scenario Company A has created a special purpose ledger (ZZHYP say) would like to populate 4 digit trading partner(VBUND) in the special purpose ledger  .The field will only be used for reporting and is only needed in the Special Purpose Ledger. But the available data or the current values are present in 3 digits only. So Company A would like to change the entire 4 digit trading partner populated from FI to 3 digit trading partner in the special purpose ledger.  

For this purpose, a standard sap modification has to be done, but SAP allows you to enhance FI/CO features without modifying the standard code which are often collectively referred to as "user exits," SAP Enhancements are used to expand the standard functionality within SAP. Enhancements use function modules and are called from the standard SAP code. Each module in the system has a set of delivered enhancements that help companies expand the standard functionality where they need it. So here we create a Z program to insert our code for changes that has to be done and customize it. Hence when the data flows from FI to SPL, it will pass through the user exit that we have created to get the required result.

To accomplish this requirement, Company A will use the Variable Field Movement User Exit.
 
Read full story here
 
Author: Ramya
Source: sdn. sap. com

IFRS Adoption In Consolidated Statements

This first series of four blogs is dedicated to handling IFRS adoption for consolidated statements. They provide an overview of a new SAP "How-to guide" called "IFRS adoption in consolidated statements using SAP® BusinessObjectsTM Financial Consolidation, starter kit for IFRS". The objective is to bring practical guidance to end-users in order to manage successfully all the issues raised by the adoption of IFRSs and to get the maximum benefit from SAP® BusinessObjectsTM Financial Consolidation.
 
The blogs will cover: 
  • Blog #1: Approaches in IFRS adoption
  • Blog #2: Operating issues to deal with in financial reporting systems.
  • Blog #3: How to face the challenge - The starter kit for IFRS as a starting point - this blog
  • Blog #4: How to face the challenge - Key implementation templates
In the previous blogs (1 and 2), the retrospective method was described, along with the main issues to handle in financial reporting systems. We will now focus on the solutions proposed by SAP.
 
Continue here for full story
 
Author: Jean-Francois Bouillon
Source: sdn.sap.com

Non-Deductible Tax in Procurement

The detailed explanations regarding Taxes in purchasing are recorded in below SAP notes:

501054     FAQ: Taxes in purchasing
214151     Tax processing in purchasing

Let us review the customizings and have an example of non-deductible tax in procurement process. The simple example is procurement of non-stock material.
 
Click here for full story
 
Author: Jimmy Zhnag
Source: sdn.sap.com

TCodes F110 and FBZ0 - Segregation of Duty Fix

Generally Tcode F110 is a potential SoD risk. F110 combined with FBZ0 creates numerous SoD violations. Let's discuss what is exactly the risks are and how to avoid it.

F110 - Automatic Payment Transactions : Status
FBZ0 - Payment Proposal

Through F110, we can do two activities i.e. Payment Run and Payment Proposals.
(While running payment proposal it asks for FBZ0 access at the background, that is why I have combined both of the transactions while describing it)

Now the risk is that payment run and payment proposals should not be given to the same person who will access F110 because of SoD violation.

To remove this SoD risk, we need to play around some authorization objects i.e. F_REGU_BUK and F_REGU_KOA.

These authorization objects contain some activities which are given as numbers inside the role.

The meaning of those numbers are provided below.

02 Edit parameters
03 Display parameters
11 Execute proposal
12 Edit proposal
13 Display proposal
14 Delete proposal
15 Create payment medium proposal
21 Execute payment run
23 Display payment run
24 Delete payment run payment data
25 Create payment media of payment run
26 Delete payment orders of payment run
31 Print payment medium manually

To make payment run and payment proposal mutually exclusive, we need to restrict the activities accordingly.

So one role should not contain 11, 12, 13, 14 and 15 and the other role should not contain 21, 23, 24, 25, 26 and 31.

Restricting the authorization objects with above activities we can remove the potential SoD risk easily.
 
Author: Sambit
Source: sdn.sap.com

How to configure valuated project stock?

Introduction: 

Today many industries want to manage project stock in quantity and value basis.In this blog we are going to discuss the attibutes of valuated project stock and the configuration steps

valuated Project stock:

Project stock for which each material in the stock is always managed quantity-based and value-based.Each material quantity is valuated with monetary valuation.All goods movements for the project stock lead to corresponding postings to G/L accounts in Accounting.
 
Click here for full story
 
Author: Raja Ramaswamy
Source: sdn.sap.com

Restriction of Maximum 999 FI Document Items During MM transactions

I guess you might have this experience. While entering a goods receipt (MM-IM) through transaction MIGO, there is the error message: F5727 "Maximum number of items in FI reached".
 
There is a limit of (999) line items which can be posted per FI document.  This is because the line item number (BSEG-BUZEI) field length is defined as (3) numeric positions, i.e., (999) line items.
 
Click here for full story
 
Author: Jimmy Zhang
Source: sdn.sap.com
 

No Subsequent document found in Accounting

An  invoice has been cancelled using MR8M.

While the material document has been generated no accounting has been generated.
 
The error message is : No Subsequent document found in Accounting (Message No. RW 017)
Solution :
 
If the invoice is via MIRO, then below notes should be helpful to you.
 
 
OSS Note : 382797 - MIRO: Analysis and repair for missing follow-up documents

OSS Note : 781498 - MIR4: Missing follow-on documents
 
 

Accounting entries not involving GR/IR directly

MATERIAL PRICE CHANGE
In SAP, material price can be changed by using the TCODE: MR21. The accounting entries are similar for both V and S price control. Price can either be increased or decreased which is directly affecting the stock account and therefor hitting BSX. The balancing act is done by the account Gain/Loss revaluation which is UMB.
Accounting entry:
 Description

 Posting Key
 Transaction Key
 Account Type
 Raw material consumptin a/c
 DR
99
BSX
M
 Revenue Expens a/c.
 CR
83
UMB
S
PIPELINE MATERIAL WITHDRAWL

Pipeline material assumed to be availabel all the time. This type of material is not planned, purchased. The material is never stored. The material is withdrawable at any time. Info record should be maintained for the material for Pipeline category.
Accounting entry:


 Description

 Posting Key
 Transaction Key
 Account Type
 Consump.for internal goods a/c
 DR
91
KON
S
 Cost Price Differ a/c
 CR
81
GBB
S

MATERIAL TO MATERIAL TRANSFER

Inventory from one material can be transferred to another material. The only condition for this is, both the materails should have the same base unit of measure.

Movement type used is 309.

There are four possible cases with this scenario depending on the Price Control of the Material.

From  - To
V       -  V
V       -   S
S       -   S
S       -   V
As long as the receiving material is maintained at V, there won't be any difference entries. The receiving material with V will always accept the incoming price. If the receiving material is at S, and if the incoming price is different from its Standard price, then there will be price difference entries.

Case 1: S to V

Material-MATS (Price control-S) to Material-MATV (Price contrl-V)

 Description

 Posting Key
 Transaction Key
 Account Type
Material
 Raw material consumptin a/c
 DR
99
BSX
M
MATS
 Raw material consumptin a/c
 CR
89
BSX
M
MATV


Case 2: V to S

Material-MATV (Price control-V) to Material-MATS (Price contrl-S)


 Description

 Posting Key
 Transaction Key
 Account Type
Material
 Raw material consumptin a/c
 DR
99
BSX
M
MATV
 Raw material consumptin a/c
 CR
89
BSX
M
MATS
 Exp.from St. Transfer a/c
 DR
93
AUM
S
MATS

Here the receiving material is at S, and hence the difference amount is posted to a Exp/Rev account with AUM.

PLANT TO PLANT TRANSFER

This is similar to the previous scenario, only difference is different valuation areas, material being the same. Again the same four case (S<->V) are possible.

The entries will also be of the same naterua BSX, BSX and AUM.

Note in case of STO, the accounting entries happen when the material issued from the shipping plant. At the receiving plant when the GR is done, there won't be any accounting entries.

VALIDATION & SUBSTITUTION : Boolean logic

1. Boolean logic refers to the system of mathematical logic
2. It is used to create logical rules or statements
3. These logical statements are used to analyze, select, and process data
4. Logical statements can be linked using operators
5. An operator links logical statements and defines how the statements should be processed
6. A combined statement is two or more logical statements linked together.

Boolean logic is used in:

Report Writer
Validation
Substitution
 
TRUE / FALSE : is a logical proposition that is either true or false

AND (conjunction)

Both statements must be true for the combined statement to be true.

(Condition A) AND (Condition B) = In this case if Codition A & Condition B are true then only total statement becomes true to move further on posting.

Example : (GL = 900000) AND (cOST CENTER = A001CD1000)

while posting system check whether GL = 900000 AND cOST CENTER = A001CD1000

(10 > 6) AND (2 + 2 = 4) (TRUE)
 
(2 + 2 = 4) AND (10 < 6) (FALSE)
 
(10 < 6) AND (2 + 2 = 4) (FALSE)
 
(2 + 3 = 4) AND (10 < 6) (FALSE)

OR (disjunction)

At least one of the statements must be true for the combined statement to be true.

(Condition A) OR (Condition B) = In this case if Codition A or Condition B are true then only total combined statement becomes true to move further on posting.

Example : (GL = 900000) OR (cOST CENTER = A001CD1000)

while posting system check whether GL = 900000 OR cOST CENTER = A001CD1000

(10 > 6) OR (2 + 2 = 4) (TRUE)
 
(2 + 2 = 4) AND (10 < 6) (TRUE)
 
(10 < 6) AND (2 + 2 = 4) (TRUE)
 
(2 + 3 = 4) AND (10 < 6) (FALSE)

NOT (negation)

Statement that follows the NOT operator must be false for the statement to be true.

NOT (2 + 2 = 4) (FALSE)
 
NOT (10 < 6) (TRUE)
 

NAND (NOT AND)

At least one statement must be false for the combined statement to be true.

Example :
 
(2 + 2 = 4) NAND (10 > 6)  (FALSE)
 
(2 + 2 = 4) NAND (10 < 6) (TRUE)
 
(10 < 6) NAND (2 + 2 = 4) (TRUE)
 
(2 + 3 = 4) NAND (10 < 6) (TRUE)
 

NOR (NOT OR)

Both statements must be false for the combined statement to be true.
 
Example :

(2 + 2 = 4) NOR (10 > 6) (FALSE)
 
(2 + 2 = 4) NOR (1 = 2) (FALSE)
 
(2 + 1 = 4) NOR (2 + 2 = 4) (FALSE)
 
(2 + 1 = 4) NOR (10 < 6) (TRUE)
 

--> (implication)

The two statements depend on each other to determine the truth value of the statement, if the second statement is true or the first statement is false, the combined truth value is true.
 
Example :

(1 = 1) --> (2 + 4 = 6) (TRUE)
 
(2 + 2 = 4) --> (10 < 6) (FALSE)
 
(10 < 6) --> (2 + 2 = 4) (TRUE)
 
(10 < 6) --> (2 + 3 = 4) (TRUE)
 

<-> (equivalence)

Both statements must be true or both statements must be false for the combined statement to be true.
 
Example :
 
(1 = 1) <-> (2 + 2 = 4) (TRUE)
 
(1 = 1) <-> (10 < 6) (FALSE)
 
(10 < 6) <-> (1 = 1) (FALSE)
 
(2 + 3 = 4) <-> (10 < 6) (TRUE)

source: help.sap.com

Useful VIEW TABLES from different modules :

Sometimes we face difficult to pull the data from one table, put the data in different table to fetch required data. In most of the cases SAP has provided some view table which are the combination of the 2 or more tables. This makes easy for us to fetch the data without much effort. I did some workaround and got some info. Appreciate if you also share the view table information in this relation.

View Table Tables joined Description
EKBI EKKO, EKPO, EKBE Join via EKKO / EKPO / EKBE for MR11
MARAV MARA, MAKT View Table for Logical DB MGM
MARCP MARA  EC-PCA: View of Table MARC
MARDP MARA  EC-PCA: Projection View of Table MARD
SWIVOBJECT SWW_CONTOB, SWWWIHEAD Join SWW_CONTOB with SWWWIHEAD
SWWVHEARET SWWWIHEAD, SWWWIRET Joint view of SWWWIHEAD and SWWWIRET (types B,F,P,W)
TXW_J_WITH BSAK, WITH_ITEM Join of BSAK and WITH_ITEM for DART
V_ACEDSASSGMT ACEDSASSGMT, ACEOBJ Join ACEDSASSGMT and ACEOBJ
V_ACEDSOH ACEDSOH, ACEOBJ Join ACEDSOH and ACEOBJ
V_ACEDSOI ACEDSOI, ACEOBJ Join von ACEDSOI und ACEOBJ
V_ACEDSOI_ACCNTS ACEDSOI_ACCOUNTS, ACEOBJ Join of ACEDSOI_ACCOUNT and ACEOBJ
V_ACEDSOP ACEDSOP, ACEOBJ Join ACEDSOP and ACEOBJ
V_ACEPSOH ACEOBJ, ACEPSOH Join ACEOBJ and ACEPSOH
V_ACEPSOI ACEOBJ, ACEPSOH, ACEPSOI Join ACEOBJ and ACEPSOI
V_ACEPSOIT ACEOBJ, ACEPSOIT, ACEPSOH Join ACEOBJ and ACEPSOIT
V_ADRCADRV ADRC, ADRV View of ADRC and ADRV
V_AFAB_1 ANLA, ANLZ and ANLC View of ANLA, ANLZ and ANLC for dep. posting
V_AFVC_AFKO AFVC und AFKO View-Tabelle mit Kombination AFVC und AFKO
V_ANI_AB ANIA & ANIB Joint View of ANIA & ANIB
V_ANI_AB ANIA & ANIB Joint View of ANIA & ANIB
V_ANLBAZ ANLB, ANLZ, and ANLA View of ANLB, ANLZ, and ANLA
V_ANLC_CURR ANLC Value Fields of ANLC
V_ANLP_ACC ANLP View for Table ANLP with Doc. Number and Accounting Objects
V_ANLSUM_1 ANLA, ANLZ, ANLB and ANLC View of ANLA, ANLZ, ANLB and ANLC
V_ANLSUM_2 ANLA, ANLZ, ANLB and ANEP View of ANLA, ANLZ, ANLB and ANEP
V_ANLSUM_3 ANLA, ANLZ, ANLB and ANEP with ANEA View of ANLA, ANLZ, ANLB and ANEP with ANEA
V_ANLV_UPD ANLV View of ANLV for Update of Insurance Values
V_E070TC E070TC, E070 and E07T View of E070TC, E070 and E07T
V_EINA EINA + EINE Joinview zum Lesen der EINA + EINE
V_EWU_KEKO  KEKO and KEPH Generated Table for View V_EWU_KEKO
V_KBED  KBED and KBEZ Database View Using KBED and KBEZV_KEKO_ENQ
V_KEKO_ENQ KEKO & T001K View for locking KEKO using company code
V_KNA1ADR3 KNA1-ADRNR, KNA1-LAND1 Projection View for checking KNA1-ADRNR, KNA1-LAND1
V_KNA1ADRC KNA1 and ADRC View of KNA1 and ADRC
V_LFA1ADR3  LFA1-ADRNR, LFA1-LAND1 Projection View for Checking LFA1-ADRNR, LFA1-LAND1
V_MARM_T006A MARM and T006A View of MARM and T006A
V_MKPF MSEG and MKPF View of MSEG and MKPF
V_MMIM_BEW MBEW View of Table MBEW
V_MMIM_BS EKKO & EKPO View of Purchase Orders
V_PACKIN PACKKP, PACKPO, PACKKPS View of tables PACKKP, PACKPO, PACKKPS
V_PACKIN2 PACKKP, PACKPO, PACKKPS View of tables PACKKP, PACKPO, PACKKPS
V_PTRV_APPR  PTRV_HEAD & PTRV_PERIO Join to Tables PTRV_HEAD & PTRV_PERIO
V_PTRV_HEAD  PTRV_HEAD & PTRV_SHDR & PTRV_PERIO Join to Tables PTRV_HEAD & PTRV_SHDR & PTRV_PERIO
V_PTRV_SREC PTRV_SREC & PTRV_SADD Join to PTRV_SREC & PTRV_SADD
V_QDQLQEM QALS, AVFC; QAMV, QASV View of QALS, AVFC; QAMV, QASV for dyn. mod. hist. (characs)
V_RESBRSADD RESB and RSADD View Between RESB and RSADD
V_RPBANF RESB, RSADD and RSDB View for RESB, RSADD and RSDB
V_RPBANF_STOCK RESB, RSADD and RSDBS View for RESB, RSADD and RSDBS
V_S_FCODE SE18/19/20 View for internal tables in SE18/19/20
V_TXW_AFRU COEP/COBK/AFRU Join COEP/COBK/AFRU