SHORTCOMINGS IN SAP TEST MANAGEMENT

SAP R/3 TESTING

SAP has thousands of tables, multiple industry specific solutions, thousands of transactions, and connectivity to an unlimited number of legacy systems. Furthermore SAP can be configured differently from one company to another which creates a myriad of permutations for executing an SAP transaction. Installing and customizing SAP is a daunting challenge. Testing SAP R/3 is in and of itself another intractable challenge.

Many projects fail to test SAP correctly and consequently suffer staggering financial loses after deploying SAP into a live environment.Below some lessons learned are offered and identified to help organizations test SAP.

1. Not following methodology or No methodology at all
Some companies implementing SAP adhere to the ASAP methodology. Other companies have ad-hoc or ASAP-like methodologies for implementing SAP.Even companies that are supposedly implementing SAP based on the ASAP methodology are not very strict and stringent in adhering to all the activities, deliverables, and tasks associated with ASAP. Consequently, but not surprisingly these companies have much confusion, obfuscation, befuddlement when they attempt to implement SAP. Compounding this problem is the fact that many large companies implementing SAP hire two or more implementation partners and multiple subcontractors that have incompatible approaches, methodologies, and lessons learned for implementing SAP.The project manager and the steering committee should specify within the project charter how SAP will be implemented and what deliverables will be produced based on either ASAP or some other proprietary methodology. The objective is to have defined, proven, and repeatable processes for implementing SAP and that the project members have the knowledge or know-how for adhering to the methodology. The creation of an audit team or standards team would be helpful in enforcing compliance with the chosen methodology.

2. Inadequate test tools
SAP R/3 comes with an internal recording tool known as CATT (eCATT). One of the advantages of CATT (eCATT) is that since it is part of the standard SAP system it’s free of charge. However CATT does have some limitations which impel many companies to procure other test tools.
Companies purchasing automated test tools expect and erroneously believe that the test tools will be the panacea to their entire SAP recording and testing needs. Unfortunately, this is not the case, since no two SAP implementations are exactly the same across two or more companies or at times even within different divisions of the same company. Consequently, a company implementing SAP might need to procure test tools from more than one vendor in addition to the CATT (eCATT) tool.
An SAP implementation could be implementing SAP add-ons such as BW (Business Warehouse), APO (Advanced Planning Optimization), SEM (Strategic Enterprise Management) or even modules such as PS (Project Systems) that generate graphs and charts that a recording tool does not recognize. Furthermore, a company may move its SAP GUI from the desktop (fat client) to running SAP as web-based (thin client) or through an emulated Citrix session which could render the existing test tools useless. Companies that wish to move to an automated testing strategy should articulate and document what SAP modules and SAP add-ons they are installing in addition to any legacy applications integrating with SAP. This information should be provided to the vendors of automated test tools in order to determine what can actually be recorded and tested with the test tools. The company should further investigate with the vendor what additional benefits over CATT (eCATT) the automated test tools provide. The objective is to get the test tools that will maximize SAP recording.

3. Decentralized test teams
Some projects have a decentralized testing approach where each individual business process team, technical team (ABAP/4), and Basis (security) team conduct their own testing in the absence of a QA/testing team.
The decentralized method suffers from various drawbacks including redundancy, inconsistency, lack of standards, missing testing metrics, unreported test results, limited managerial visibility, limited test coverage, chaotic defect resolution, no independent verification of test results, etc.
A more robust approach for testing an ERP system is centralized testing where there is a QA team for defining the standards and procedures for the various testing cycles and documenting the test plan, lessons learned, UAT plan and the test strategy. The test procedures and test strategy include what test case templates will be used, how and what metrics will be reported, how peer reviews will be conducted, ensuring that all test requirements have been met, etc.

4. Working in Silos: Limited or no access to SMEs, Configuration Team
Since SAP is integrated and a change in one of its components can have a cascading effect on other aspects of the software it is often the case where the various SAP teams need to collaborate with one another. This concept seems mundane and at first hand easy to grasp. But due to internal politics, deadlines, budget constraints, etc this concept is ignored and overlooked. When collaboration falls through the cracks the various SAP teams (configuration, RICE, Basis, testing, infrastructure, data, etc) start working independently in isolation or in a silo.In projects where the testing team members who arrived during the middle of the realization phase have been unable to get support from the SAP configuration team members and SMEs for drafting test cases, peer reviews, and sign offs.. In other projects the QA and testing team are almost considered a “bother”, “nuisance” to the other SAP teams. The test manager and PM need to foster an environment of cooperation among the testing team and the various other SAP teams for the successful completion of testing artifacts and testing cycles.

5. Missing test bed
Within the SAP client landscape a dedicated QA environment should be allocated to the testing team for the various testing phases.
The test manager should insist on a test environment where the testing team has complete control (for instance control over the accounting periods, running payroll, etc) and where the environment is not shared with other entities in particular during the test execution phase.

6. No controls for promoting/transporting objects into production
In many SAP projects there are very little controls for promoting objects into a live production environment.
ERP systems like SAP R/3 offer benefits such as tight integrations across its modules and sub-modules and access to real-time data, but these benefits can backfire or even become otiose when a poorly tested or not even tested object is transported into a production environment. A faulty transported object such as a configuration change or code for an interface can have a deleterious cascading effect on other SAP functionality in the production environment. For instance a change to the HR module within payroll can affect functionality in the FI-CO module.
A project should set priorities for transporting objects based on their criticality, document and approve objects that get transported after having been tested, and establish the frequency in which objects will be transported (i.e. every Friday at 4:00 pm) to avoid impacting end users as much as possible. The company Mercury Interactive offers the tool Kintana which can help companies to move objects into various SAP clients and instances while maintaining a history log for auditing purposes of the objects that were transported and the entities approving the transports.A home grown repository within Lotus Notes that provided managerial visibility for moving and transporting SAP objects which included notifications and approvals.
Whether a commercial tool is purchased or a home grown application is developed the main objective is to place stringent controls for moving objects into production with the necessary approvals while maintaining a history log.

7. Flaws with BPPs
For those projects adhering to the ASAP SAP methodology BPPs (Business Process Procedures) are artifacts or outputs from the realization phase. BPPs are documented based on stand alone or for single SAP transactions. The BPP provides detailed information in the form of instructions with screen shot print outs for how to execute a given SAP transaction (i.e. SAP transaction MM01 – Create Material). Admittedly, BPPs can assist a tester or end user on how to execute a given SAP transaction based on the project’s specific customizations. However, and this is often the case the SAP configuration team will document BPPs in a given environment such as the configuration environment with configuration data and then the SAP configuration team fails to update the BPPs to reflect the changes of the QA environment. The failure to update the BPPs diminishes their value for the testing team. When BPPs are not updated they contain obsolete data, and may lack the necessary information to execute an SAP transaction for an SAP environment that has had customizations since the time the BPPs was initially created. Furthermore, many organizations do not perform any form of version control on BPPs which makes it difficult to discern whether a BPP is finalized, completed, peer-reviewed or still undergoing changes. Poorly documented BPPs or outdated BPPs have a propagating effect on the creation of test cases and test scripts. Since BPPs are documented per stand alone SAP transaction, the testing team will need to link multiple BPPs for end to end SAP test cases (i.e. Hire–to–Fire test case) that involve multiple SAP transactions with pre and post conditions. A single poorly written BPP or outdated BPP can inhibit the creation of a test case containing several SAP transactions.

8. Missing peer reviews
Peer reviews help refine work-products and deliverables. Peer reviews also provide independent verification and give the end customers or SMEs an opportunity to provide feedback during the early stages of the SAP implementation. Peer reviews can occur at many junctures during the implementation of SAP for tasks such as filling out CI (Customer Input) templates, drafting test cases, creating functional design specs, development of business process flow diagrams, documenting BPPs, code walk-through, etc. Inexplicably many SAP projects do not engage in the practice of peer reviews or have any templates or forms for documenting peer review feedback. The end result is that often times the end users have complaints about the quality of test cases during the UAT (User’s Acceptance Test) and about how a particular process was customized in SAP versus how the process was previously executed in the end user’s legacy systems. Test managers should solicit the feedback, input and even the sign-off from the SMEs for the various testing artifacts as soon as possible or as the testing artifacts are produced.

9. Problems obtaining valid test data
Arguably, the most prevalent risk to conducting an SAP test whether it is integration, functional, string, volume, smoke, or security test is obtaining valid SAP test data. When dealing with SAP data invariable one or more of the questions below will arise before a testing cycle ensues:Where will the test data come from? How will one produce new data for transactions that require unique data? How will the data be loaded into a new SAP client and instance? What happens when an interface or conversion needs to send data into core SAP R/3 from a legacy system and the interface or conversion is not executing properly or has yet to be developed? What happens when the transactional data has not been created?Assuming that the testing team has a dedicated test bed or QA box the test manager will need to ensure that all the necessary data (master, transactional, test, etc) is properly loaded as part of the assessment for the test readiness review. Ideally an SAP test will be conducted within a test bed containing data that closely mirrors production data and where the testing environment is production-sized. The test manager should prioritize the test cases that will be executed and determine and document any work-around for test cases that cannot be executed due to missing test data.

10. Missing flow processes, diagrams
Diagramming or modeling how a business scenario will flow within SAP provides invaluable insights to the testing team and the configuration team. Diagrams and flow processes can illustrate the lifecycle, stages, sequences, activities, states and events associated with a particular business process. Unfortunately, many projects undergoing an SAP implementation or SAP upgrade fail to diagram their business processes leaving testers or newly hired resources in a bind to comprehend how legacy processes, or new customizations derived from gap analysis will be executed within SAP. SAP testers and end users participating in the user’s acceptance test should have access to diagrams depicting how business processes flow within SAP. The absence of such diagrams puts undue burden on the testing team and places the end users in a position of disadvantage. The SAP business analysts in conjunction with the SAP configuration team, and possibly the SMEs (Subject Matter Experts) can develop diagrams in tools such as Visio, or the ARIS modeling tool that integrates and links with SAP’s Q&adb (Question and answer database) for those SAP implementations following the ASAP methodology. Alternatively, with Rational’s tools one can develop UML (Unified Modeling Language) diagrams to illustrate processes with interaction diagrams (sequence and activity diagrams).

11. No integration testing with external components
SAP integrates with many legacy systems via interfaces, IDOCs, conversions, BAPIs, connectors, or even middle ware such as Mercator. SAP can even be integrated with other commercial ERP systems, forecasting/planning systems, and CRM applications. Although, the integration of SAP with other systems is critical to the successful implementation and deployment of SAP, many companies merely test during the integration test the interaction of SAP among its various modules and add-ons. Although the aforementioned type of integration testing is necessary it is also critically important to test the integration of SAP with non-SAP systems. Some examples of integration testing that I have conducted between SAP and non-SAP systems are: SAP integrating via IDOCs to bar coding software, SAP properly sending outbound data to legacy system and the legacy system processing the data correctly, end to end financial reconciliations between SAP and data warehouses, integration between SAP and planning systems for MRP runs, etc.

12. Limited security access
I have seen SAP testing efforts come to a halt because the testers did not have the necessary privileges and permissions to execute certain SAP transactions or the necessary roles to submit electronic approvals. This problem is exacerbated when testers are executing test cases at odd hours or during weekend hours and there is no Basis support to augment the tester’s security role. Successful execution of certain test cases in SAP whether manually or with automated test tools will require the test team members to have super user access. This is of utmost importance when conducting positive and negative testing for security roles. The testing team should coordinate and plan with the Basis team the necessary roles and permissions for developing test cases and for executing test cases in the designated QA environment or test bed. Conclusion:
In this article we have covered 12 very important lessons learned when it comes to testing your SAP implementation. I hope you have found it useful.
My strong suggestion is that you document these lessons learned as part of your test plan to mitigate the risk of repeating these blunders in your SAP installations.

NOTES FOR SAP FICO TESTING

Guide for Testing SAP Financial

Unit Testing

Unit Testing When you test every single document is called unit testing.
String Testing One transaction full activity is called string testing. For example Vendor invoice, goods received and vendor payment.

Integration Testing

It is purely with other modules and we have to check whether the FI testing is working with other related modules or not.

Regression Testing

Testing for whole database. Bring all the data into another server and do the testing is called regression.

UAT

When we test any particular document with the user and if it is ok immediately we have to take the signature on the document, which is signed off and can be forwarded to the immediate boss. There are some steps to be followed when we go for user acceptance testing.
Transaction – Script Writing – Expected Results – Compare with Actual Results

TPR (Transaction Problem Reporting)

While doing the user acceptance testing if we get any problems then there are some methodologies to be followed according to the company’s policy and normally as a tester we always need to write on Test Script itself.

Key Features

Understanding the business scenarios Organization Structure to incorporate the tune of the script. Preparation of test scripts Execute and record results to see if it is fine before going to approval. Make changes to your test script if required.

What is Test Script (Scenario Testing)

Header Data

Step in Process

Transaction Code / Program (FB60)

Menu Path

Description

Field Data and actions to complete

Expected Results

Actual Results

TPR Closing Period

F.19 Clearing GR/IR Account

F.13 Adjustments GR/IR Account

Using of these above two accounts will help us in clearing the balances and adjustments to those respective clearing accounts so that the GR/IR account will be zero balance and the balances will appear in respective reconciliation accounts accordingly the balances will be carried forwarded to next fiscal year.

GR/IR Clears the following Documents GL Document

Customer Documents Vendor Documents Assignment Field is important in any document (ZUONR), Amount (DMBTR)

Foreign Currency Valuation

Lowest Value Method, If we are in loss then only we will account for it.

GL Accounts which are important in Testing

Enjoy Transaction - FB50

Normal Transaction - FB01

Document Parking - FV50

Post with Clearing - F-04

Incoming Payment - F-06

Outgoing Payment - F-07


Document Related

Reset Cleared Items - FBRA

Parking Document Posting - FBVO

Reversal Documents - F-14

Company Code Clearing A/C

(Trial Balance purposes) reversal - (FBUB)

Clearing Account

Partial clearing Invoice - 100 - Open Item

Paid - 70 - Open Item

Balance - 30
In Partial Clearing you can see 100 and 70 are cleared line items and 30 as balance and if it is in Residual you can only 30 as balance as it creates new line item and you can’t see the other cleared line items.
As no company will use residual clearing as it affects on ageing reports.
Open Items in Foreign Currency in all Modules GL/AP/AR - F.05-Master Data

Company Code

Currency Only

Balances in local currencies

Reconciliation Account Type

Year End Scripts
Re Grouping Receivables / Payables - (F101)
Bad Debts Provisions – Scripts

We assume that the customer has not paid at the end of the year you doubt whether this receivable will ever be paid. So you make a transfer posting for the receivables to an account for individual value adjustments using special GL Indicator E and Transaction Code F-21

Carry forward Balances

Sub Ledgers and General Ledger balances to be forwarded to next Fiscal Year

Accounts Payables

Vendor Down Payments

Invoice Parking Reversal

Outgoing Payments

Automatic Clearing

Manual Clearing

Advance (Down Payment)

Post with Clearing

Post without Clearing Reset

Clearing Carry forward

Regrouping Foreign Currency Valuations

Accounts Receivables

Customer Down Payments

Invoice Parking Reversal

Incoming Payments

Manual Clearing

Advance (Down Payment)

Post with Clearing

Post without Clearing

Reset Clearing

Carry forward

Regrouping

Foreign Currency Valuations

THE SECRETS TO A SUCCESSFUL SAP IMPLEMENTATION

THE SECRETS TO A SUCCESSFUL SAP IMPLEMENTATION

Many wonder what constitutes a successful SAP Implementation. Everyone wants to have a great success story to talk about, from the top management to the implementation consultant. Success is a relative term.

You will hear: “Successfully went live on the planned date and on budget”
You should ask though whether the initial scope was implemented or did they have to take business processes out of scope in order to make it.

You should also ask how are things now that you went live? Can you ship to your customers without any problems? Is the system performing well? Are the end users fully trained and are they doing their job well? Do you still need consulting support to go through your day-to-day business?

Once you put these questions into perspective you can really define a successful SAP Implementation in many ways and many levels.

Success Factors
Here is a list of factors that determine the relative success of a project as mentioned above.

1.Communication:
For a successful SAP project implementation the number one factor is good communication among the project team members. Everybody claims that they are good communicators and we surely have the technology to maintain constant communication with land-phones and cell-phones and email, but it is true that they are not used to their maximum ability.

For example, when there is an issue, which needs to be communicated to multiple people, usually one will email to a number of people who should really be involved. It is extremely annoying and breaks the communication chain when somebody replies only to the sender of the email without including the rest of the members.

SAP is such integrated software that has constantly touch points among the modules. As such, constant integration among the teams is of paramount importance.

Not only constant communication is important, but GOOD communication is important. People must be very clear about what they are talking about. There is a little phrase: “Mary had a little lamb” – these five short words can create such confusion and result to numerous different meanings;
Mary used to have a lamb but does not anymore
Mary had a little lamb which now has grown into a big one
Mary “had” (i.e. ate) a little lamb
I am sure you can make a lot of other meanings out of this small sentence

Now imagine, if this little sentence can cause such confusion, what mess would be created when dealing with complex business processes, spanning through several departments within an organization and involving anywhere from fifty to thousands of employees, end users, managers, consultants.

So the key is good, accurate, specific and timely communication. Clarify things several times. Explain them as if you were talking to little children.

In order to achieve this type of good communication team members should have their workplaces physically close together. I have seen in many recent cases where the Consulting firm in order to “minimize” costs for the client, they outsource much of the Development ABAP programming work outside the USA and in most cases to other continents.

Based on all the things mentioned above, how can good communication be achieved? It is not possible to simply create a program spec with a description in writing and expect a programmer located on the other side of the planet to figure out what the Business Process is, and what would make the program work according to the client’s requirements.

Some consulting firms that do this practice will argue that “it is possible and they have success stories to tell”. Well, remember at the beginning of this article what we talked about “Success”.
We have witnessed this type of “success” when we went in to resolve the issues of such implementation method. We have witnessed the never-ending consulting hours that the client has to pay because of this implementation method. Often the client is made to sign a contract which says something like “…when the program is complete (but not really working as per the client’s requirements – this is not stated anywhere) any change to it would be considered change of scope…”. Such practice force the client to either abandon the effort of making the program work because of the extra scope-change cost or keep paying more, in order to try make the program work.

These tactics are unfair to the clients and give a bad name to the Consulting industry.

The client needs to take charge of these situations. Make the rules of good communication. Make the rules of the type of consultants you want to have. Provide the physical and technological infrastructure for the basis of good communication. Do not allow “consulting” companies to hide behind a “Big” corporate name.

Clients deserve the best for the huge amounts of money a SAP Implementation cost. Communicate well, take control of your project and do not be sold on “air-talk”.

2.Full Corporate Management Support:
Nothing will happen, nothing will move, unless Management supports it. There must be full and utter commitment and support for the project. If Management does not show both in words and deeds that the SAP Implementation is important than the team members, end users and so on, will not be on-board, will not be dedicated. Without dedication the project is bound to fail.

The ways management provides support for the project is by actively participating in the planning and management of the project. Proactively getting involved not only in the high level plans and decision making, but also in the lower level and just as important activities of the day-to-day activities of the project. Get in touch with the project team members, know and be interested about their job and where they stand. This will motivate and keep people committed.

When management is involved then issues get resolved easier, conflict is overcome faster, because the management know the details of what is going on. How is this achieved? By keeping weekly status and communication meetings (remember communication?) These meetings are not to judge or interrogate anybody. They are done so that all members are informed as to what is happening keep the pulse of the project.

The management should help the project move forward, not hinder it with too many bureaucratic procedures. Keep meetings short and to the point. Maintain one status report, not 15 different reports. Have procedures but do not overdo it to the point where the project becomes inflexible and time consuming to make a decision or take a corrective action. Manage the project and provide people enough freedom to do their work. This will be appreciated.

3.The Project Plan and a Methodology are Guidelines and helping Tools – Not Rulers:
Make a good plan. Make a Realistic plan. Most projects do not have a realistic plan. People think everything can be done really fast. They do not allow enough time for the unforeseen parts of the projects. The vendors delaying to deliver the hardware, running out of disk space, actual training time takes a lot longer that thought, users need more training or they are overloaded with their every day job that cannot attend training and much more. The Master Data are corrupt and we need a new SAP Client. We can make a copy. We plan one day for the copy, but why is it always that a SAP client copy always fails the first time resulting taking two or three days?

Remember, if anything can go wrong, it will go wrong. Allow enough time in your plan for travel time, for public holidays, for vacation. There are so many project managers planning to go-live on January 1 – how foolish, inappropriate and disrespectful to the work and dedication of the people. As soon as Thanksgiving comes around things slow down dramatically and especially the last two weeks of the years are down to a crawl. Take these times of the year into account.

If you cannot go live as per the plan then do NOT go live. It is better, cheaper and safer to delay the go-live and being able to serve your customers. Better than going live just to make a big corporate announcement that we went live as planned but then everybody runs around like headless chickens trying to fix problems, help the users, correct errors, serve your customers.

Allow time for errors. Always have contingency plans. What if the go-live fails. Make sure you have a way to regress to the legacy system to be able to function properly as a business.

One of the most known SAP Implementation Methodology is ASAP or Accelerated SAP. Consultants should be Certified by SAP. Following this methodology can be very helpful and really accelerating your process. It can also be a inhibitor and delaying factor if it gets overused. ASAP contains a huge amount of tools, templates and instructions of how to implement SAP. Use common sense. There is no reason to try to use one hundred percent of the ASAP methodology. Use only the parts that help you. There are excellent templates for documentation, BPP documents, Training and testing documents, which would take a lot of time to create from scratch.

4. Make a proper Scope:
Which parts of SAP will you implement. Often team members get too excited and want to implement a hundred percent of the processes SAP offers. Not possible. SAP should be implemented according to the Business needs and processes. There was a team member once that wanted to use Classification in the Material Master at a time that it did not make sense for their business. There was another team member that wanted to implement Evaluated Receipt Settlement or ERS for Vendor Invoicing at a time when most invoices did not much the Purchase Orders. These members were warned that these processes were not appropriate. They did not listen. The process failed.

Be realistic. Because SAP can do almost everything it does not mean that you should implement almost everything. You must make sure that your users are technologically advanced, computer literate enough and that they understand the business processes, which will allow them to comprehend and manage the change that such an implementation will bring.

5.Motivate, Appreciate, Reward your people:

It may sound a cliché, but it must be done. Do not do it just to be politically correct. Do it because you mean it, put your soul into it, make it personal. This is one of the few things someone should take personally in business!! People will work twice as hard when they are appreciated. In order to be able to know what you are rewarding people for, you must be involved it their day-to-day business – here come back again the Full Corporate Management Support point mentioned above. A “thank you” goes very long way.

6.Manage Change:
One of the most important factors is how the organization handles changes. This is one of the riskiest part of this business. To make your people understand that change is a good thing. To make the embrace change and make it happen.
This challenge is accomplished with all the above points mentioned, i.e.
- Full Corporate Management Support
- Communication
- The Project Plan and the Methodology
- A proper Scope
- Motivate, Appreciate, Reward your people
If these are followed and executed successfully, people will appreciate and embrace the coming changes. Admittedly, very, very hard thing to achieve for many reasons. Human nature is to avoid change. Therefore, going against human nature is starting off the wrong way. People are afraid of business change because often they are afraid of their job security – unfortunately often rightly so.

7.Politics:
Every project has them (politics) to some degree. Make sure politics and hidden agendas do not derail your implementation process. Stay focused and bring out in the open differences sooner than later. Do not allow people with hidden agendas mislead the project to the wrong direction. Stop this soon and stop it hard. Politics should not be tolerated and should be dealt with firmly and tactfully at the same time.

8.Find Excellent Resources:
The client, the management, must be involved in the consulting recruitment process. Do not simply trust the Consulting firm. Make sure the consultants know their stuff. Make sure the consultants do not have “layers” of intermediaries before they reach you – the final client. The more layers, the more the Consultant’s rate is reduced, which in turn it means that the consultant who are willing to work for the lower rate are usually the least knowledgeable. In life you get what you pay for – and even though you as a client might be paying dearly for the consultant, too many layers reduce the consultant’s rate and therefore the quality.

Be wary of using headhunters/recruiters, that do not know the first thing about SAP, to go find you a Consultant. Allow someone with project knowledge from within your organization to look for the Consulting resources, interview them and approve them. There are several web sites on the internet where high quality consultants with many years of experience publish their qualifications. Without wanting to promote any specific service, some of them are SAPGenie.com Monster.com, HotJobs.com, Davatec.net.

Successful SAP Project implementations! Such a relative term considering all the above factors. The next time someone says “we had a successful project”, analyze the facts first to determine the degree of success. Some consulting firms (not to mention names) when their relative success of a project is pretty low, they “declare victory and leave the project”!! They announce to the world of the “success” of the project and then they move on leaving the client to suffer the consequences both in business and cost terms.

INTEGRATION OF SAP MODULES

SAP MM and FI INTEGRATION
Process Flow in MM
Step 1 Generating purchase requisition( PP-MM involved)
Step 2 Making inquiries (MM)
Step 3 Raising purchase order (MM)
Step 4 Release of purchase order ( MM)
Step 5 Goods received from vendor ( MM and FI )
Entry will be Raw Material Inventory a/c Dr.
GR/IR clearing a/c Cr.
Step 6 Invoice verification and quality assurance (FI and MM)
Entry will be GR/IR clearing a/c Dr
Vendor a/c Cr
Step 7 Goods issued for consumption(MM, FI and PP)
Entry will be Raw material consumption a/c Dr
Raw material inventory account Cr
Step 8 Production receipt( FI, MM & PP)
Entry will be Finished
goods inventory a/c Dr
Change in stock Cr
Step 9 Finished goods delivered to customer(MM, SD & FI)
Entry will be Change in stock Dr
Finished goods inventory a/c Cr
Step 10 Raising invoice on customers( SD & FI)
Customers a/c Dr
Sales a/c Cr
Step 11 Receipt of payment from customers( Same as SD-FI integration)
CUSTOMIZATION STEPS
Main screen of FI-MM integration is OBYC Here we have to link the MM movement types to FI G/L accounts.
Assign Following G/L accounts to movement type according to valuation class. BSX- Raw material Inventory account GBB- Raw material consumption account WRX- GR/IR clearing account

1. In SAP you will always get integration with other modules. SD will interact with FI, MM will interact with SD :-
1a. Looking at MM and SD interaction first, take the scenario of a third party order process. This process uses a purchase order (which is sent to your vendor). Also invoice verification is used further along the process to check that the invoice you send to your customer is the same material and quantity as that which the vendor sends to you (but obviously shipped directly to your customer).
1b. Billing is an SD function. But SAP needs to know, when processing a customer's payment, to which GL account the payment has to be processed. For instance payment of a UK based material would be placed in a different GL account to that of a non-UK based material. Furthermore, a UK based customer may have a different GL account to that of an Export customer. This is configured in Account Determination.
2. ABAPers are there to essential do some bespoke development. Your integration, or interaction, with them would be when specifying the tables, fields, input fields, a simple process explanation, data mapping (if doing an interface from one system to another) etc. *-- Shahee
The link between SD and MM :-
1. When you create sales order in SD, all the details of the items are copied from Material master of MM.
2. MRP and availibility check related data is also taken from MM although you control this data in SD also.
3. While you create inbound/outbound delivery with reference to a sales order,the shipping point determination takes place with the help of the loading group, plant data, shipping conditions etc. This also refers to Material Master.
4. The material which you are entering in a sales order must be extended to the sales area of your sales order/customer otherwise you cannot transact with this material.
There are many such links between SD and MM.
Now the link between SD and FI :-
1. Whenever you create a delivery with reference to a sales order, goods movement takes place in the bacgground. eg. In case of standard sales order, you create an outbound goods delivery to the customer. Here movement 601 takes place. This movement is configured in MM. Also, this movement hits some G/L account in FI. Every such movement of good s hits some G/L account.
2. The accounts posting in FI is done with reference to the billing documents (invoice, debit note, credit note etc) created in SD. Thus this is a link between SD and FI
3. Tax determination: In case of a tax determination also, there is a direct link between SD and MM
SD Integration points with other modules
SD module is highly integrated with the other modules in SAP. Sales Order –
Integration Points Module
•Availability Check - MM
•Credit Check - FI
•Costing - CO/ MM
•Tax Determination - FI
•Transfer of Requirements - PP/ MM
Delivery & Goods Issue –
Integration Points Module
•Availability Check - MM
•Credit Check - FI
•Reduces stock - MM
•Reduces Inventory $ - FI/ CO
•Requirement Eliminated - PP/ MM
Billing -
Integration Points Module
•Debit A/R - FI/ CO
•Credit Revenue - FI/ CO
•Updates G/ L - FI/ CO
(Tax, discounts, surcharges, etc.)
•Milestone Billing - PS
Return Delivery & Credit Memo -
Integration Points Module
•Increases Inventory - MM
•Updates G/ L - FI
•Credit Memo - FI
•Adjustment to A/R - FI
•Reduces Revenue - FITips by: Subha
SD Transaction Code Flow:
Inquiry / Document type IN Tcode for creation VA11,VA12,VA13. tables VBAK,VBAP
Quotation / QT Tcode for creation VA21,VA22,VA23. tables VBAK,VBAP
Purchase Order PO Tcode for creation ME21,ME22,ME23. tables EKKO,EKPO.
Sales Order OR Tcode for creation VA01,VA02,VA03. tables VBAK,VBAP
Delivery LF Tcode for creation VL01,VL02,VL03. tables LIKP,LIPS
Billing MN Tcode for creation VF01,VF02,VF03. tables VBRK,VBRP
To create a sales order we need purchase order number and custmer number. Before that, to create a purchase order we need to have material no, vendor no.
To create vendor tcode is xk01(create), xk02(change) , xk03(display) Tables are lfa1.
To create custmer tcode is xd01, xd02, xd03. Table is kna1.
After creating sales order using this no we can create delivery note tcode is vl01.

Asset Management

Agencies must maintain asset master records for items
which are considered assets according to DF&A
accounting regulations.The regulations define capitalized
assets as any item over $2,500. This value includes
taxes, shipping, handling and any other cost associated to
the asset.
Items between $500.00 - $2,499.99 are considered low
value assets and are maintained as such. Controlled
items, such as, weapons, radios, cell phones, etc., that are
under $500.00 may also be maintained as low value
assets.
Assets may be purchased, donated, discovered items,
and/or capital projects (assets under construction).

PURCHASED ASSETS

The following are the processes recommended by
the AASIS Support Center for creation and
purchasing asset.
AS01 - Create Asset Master Record
ME51N - Create Purchase Requisition
ME54N - Requisition Approval
ME21N - Create Purchase Order
ME28 - Purchase Order Approval
MIGO - Goods Receipt
MIRO - Invoice Payment

DONATED ASSETS


Items that are donated (given charitably to a State
agency) and meet the criteria for assets must be
maintained in AASIS.

These items are considered a gift and should not be
posted as an expense to the receiving agency's
budget. Therefore, these assets are assigned to the
appropriate non budget relevant (NBR)* asset class.

DONATED ASSETS (cont.)

The agency will create the asset shell and send
an email to DFA/Office of Accounting requesting
that the value be posted. The request to
DFA/Office of Accounting must include the asset
number, capitalization date, and value.

Values should be determined by one of the
following methods:
1. fair market value
2. catalog price
3. value assigned by the donor
4. appraisal of historical item

DISCOVERED ASSET

An item is discovered and the initial accounting
treatment (for the original purchase or acquisition) is
unknown. The original accounting process was most
likely to expense the cost of the item. This means that
the acquisition has already posted against budget and
recording the item as an asset should not be budget
relevant in the current fiscal year. Therefore, these
assets are assigned to the asset class of non budget
relevant (NBR)*.
An asset must be created, value determined,
capitalization date determined. This information is then
emailed to DFA/Office of Accounting for value posting.

ASSET CLASS

The Asset Class:
is used to classify fixed assets
forms a template for the asset master record
establishes the connection between the asset
master record and the G/L postings.

ASSET CLASS - NBR

Asset classes with NBR after the description are
non budget relevant asset classes. This class is
selected for those items that have been acquired as
a gift or donation or for a discovered asset only.

These assets should not be posted as an expense
to the receiving agency's budget, therefore the
transaction is not budget-relevant.

NOTE: DO NOT USE THE NBR (NON-BUDGET
RELEVANT) ASSET CLASSES FOR ANYTHING
BUT DONATED, CONFISCATED OR
DISCOVERED ASSETS.

DEPRECIATION

There are two depreciation areas in AASIS. Both
depreciation areas are shown in the asset master
record:
• Depreciation area 01 - 100% depreciation in the
month of acquisition and is shown as capital
outlay for all assets
• Depreciation area 20 - Straight line depreciation
Depreciation of capitalized (area 20) items (see
note page) is posted each month based upon the
capitalization date and the recommended useful
life of the asset. The depreciation program is
currently run each month by the ASC.

The following asset classes do not depreciate in
Area 20:
• 1000 - Land
• 2100 - *Equip low value
• 3000 - Works of art
• 2101 - Equip low value collective
• 2300 - DIS DP equip low value
• 3020 - Low value works of art
• 8000 - Assets under Construction
*Equip low value fully depreciates in 01 and 20
during period of acquisition.


CAPITALIZATION DATE

The capitalization date is the value date of an asset.
The system determines the asset value date from
the first posting that results in the capitalization of
the asset.

For items that are discovered or donated this date
must be determined according to when the asset
was put into use. The date is entered when the
values are posted to the asset master record.

RECOMMENDED USEFUL LIFE

The recommended useful life is the reasonably
expected length of time for using the asset and applies
only to Depreciation area 20. Within this time period,
the asset should be completely written off. The actual
technical life of the asset can exceed this time period.

The DF&A Office of Accounting has determined that the
recommended useful life in the asset master record
class code description is the useful life that is to be
used.

ASSET UNDER CONSTRUCTION

An Asset under Construction (AuC) is an asset that is in the
process of being constructed, e.g., building, road, etc. It is a
temporary asset and will not be depreciated in area 20. It will
be distributed and settled when the construction has been
completed. Upon settlement, it will be capitalized and begin
depreciation.
At the beginning of the construction process, a WBS capital
project is set up to capture costs associated with the AuC. At
the end of the fiscal year or the completion of the project,
whichever comes first, the capital project is settled. The costs
associated with the project are then posted to the AuC. The
AuC is then distributed and settled to a capitalized asset
when the project is completed. This process is taught in
another AASIS class.

1. Create Asset Master Record:
Accounting> Financial Accounting> Fixed Assets>
Asset> Create> Asset
2. Change Asset Master Record:
Accounting> Financial Accounting> Fixed Assets>
Asset> Change> Asset
3. Display Asset Master Record:
Accounting> Financial Accounting> Fixed Assets>
Asset> Display> Asset
4. Block Asset:
Accounting> Financial Accounting> Fixed Assets>
Asset> Lock> Asset
5. Create Asset Sub-Number:
Accounting> Financial Accounting> Fixed Assets> Asset>
Create> Sub-Number> Asset
6. Asset Retirement by Scrapping
Accounting> Financial Accounting> Fixed Assets> Postings>
Retirement> Scrapping
7. Asset Explorer:
Accounting> Financial Accounting> Fixed Assets> Asset>
Asset Explorer
8. Asset Balances:
Accounting> Financial Accounting> Fixed Assets>
Environment> Worklist> Generate
9. Fixed Asset List:
Special Transactions and Reports>Financial Accounting>Fixed
Assets>Fixed Asset List