The SAP functional specification, affectionately referred to as

functional spec, is critical to the development of RICEF objects. RICEF

stands for Reports, Interfaces, Conversions, Enhancements, Forms —
in other words, anything that requires programming in SAP. This post
will delve into the purpose and content of a functional specification.

Purpose of an SAP Functional Specification

A functional consultant writes an SAP functional specification any
time there is a gap between standard SAP functionality vs desired
functionality. Functional specs may be necessary during an end-to-end
SAP implementation to address gaps identified in the business
blueprint. They may also be required when an SAP add-on is
purchased, an enhancement is approved, or even when a bug-fix is
raised. Basically any time you need a technical consultant to do
something, write a functional spec!

The document should paint a clear picture of the required outcome in

the system. The goal of the document is to:

 Enable the developer to create a technical design document and,

ultimately, to develop the solution correctly
 Identify the test scenarios so testers know what to execute

 Convey the end result to stakeholders so they know what they

are getting

 Act as a historical reference (along with the technical design

document) to identify what was built in the system and why

There may be several revisions to the document as it is discussed

between functional, technical, test and business teams. Ultimately, the
functional spec is finalized, approved by the stakeholders and saved
for posterity.

Content of an SAP Functional Specification

As a functional consultant, I have written many functional
specifications that followed many different formats. In my last role as
a project manager, I created a simple template that worked perfectly
for the company’s needs. It is available for free download here:

SAP Functional Spec Template

Team and Timing

This section defines the administrative needs and resources leveraged

in the project. It answers the following questions: Who? Where? When?
If physical signatures are required for approval of the spec, they may
be included here as well.

Requirement Details

The meat of the document lies in the requirement details. It answers

the following questions: Why? What? How? There is no perfect formula
for filling these details in a functional spec, as the style varies by
RICEF object type. The requirement details should tell a logical story
about the need, the current process, the desired outcome and the
proposed solution. DO include process flow diagrams, existing sample
programs, performance considerations, layout mock-ups and reporting
expectations. DO NOT write lazy, vague descriptions of the
requirements or presumptions about the desired results. Remember,
the developer needs to use this document to build the object. For a
great read on the technical consultant’s advice on writing functional
specs, click here.

As an example, if the RICEF object is a custom report, the diligent

consultant might append an external document of output field
specifications and add some bullet points to express the output type,
toolbars and export methods like so:

 Report output in ALV grid format

 Standard ALV toolbar options activated:

 Details, Sort, Search, Filter, Total, Subtotal, Print, Export,

Layout Maintenance
  Ability to export report to Spreadsheet, Local File, or SAP
Business Workplace

Test Cases

Similarly, the test cases should include all individual test execution
steps of the TO BE requirement. Again, the test team needs to use this
document to develop the scripts and execute the testing once the
object is developed. Be as detailed as possible!

Summary
At the end of the day, the SAP functional specification is the blueprint
used to build development objects in the system. Spend some time and
effort writing the document. Ensure that the requirements are
understood, the expected result is clearly defined, and that all of the
above is agreed upon by all stakeholders.

2).

The Art of Writing an SAP Functional

Specification
 APRIL 20, 2010
 MICHAEL SALVO
 15 COMMENTS
 SAP ABAP, SAP CONSULTANTS BLOG, SAP FUNCTIONAL, SAP TECHNICAL
 ABAP, DATAXSTREAM, FUNCTIONAL SPECIFICATION DOCUMENT, MIKE
SALVO, PROJECT MANAGEMENT, RICEF, SAP, UPGRADES
Overview
I am currently working on an SAP implementation project that is just starting
its realization phase. One of my first tasks, as a member of the technical
implementation team, is to review completed functional specification
documents for RICEF objects. These documents, written by functional
subject matter experts, are supposed to detail business requirements that
address gaps, and which need to be incorporated into the system being
implemented. The purpose of the review is to make sure that the functional
specification documents are complete, accurate, and contain the approval
signatures required to move on to the technical design phase.

In my career, I have had the pleasure of working with some first-rate

functional analysts who know how to draft an excellent functional
specification document in a timely manner. It is this type of performance
that helps to move a project along in the right direction, on schedule, and
within budget. Likewise, I have had the not-so-pleasant task of working with
not-so-first-rate functional analysts, who draft functional specification
documents that are not clear, inaccurate, and incomplete. The risks here are
ultimately manifest as project delays and cost overruns.
The Good…
A really good functional specification document contains enough detailed
information about the business process to enable a technical designer to use
it as the foundation for drafting a complete and accurate technical design
document. The functional specification document should not only highlight
the presence of a gap, but should demonstrate how the business process,
accompanied by automation, will close the gap. This document must also
indicate the abnormal processing requirements – what should happen when
that report or interface does not run, what are the recovery steps, how are
key employees notified of the problem, etc. The content of a functional
specification document must be tuned to the flavor of the RICEF object that it
is describing. Since they perform very different tasks, a report specification
document should be very much different from an interface, conversion,
enhancement, or form functional specification document. Using functional
specification templates helps to insure the appropriate content for each type
of RICEF object.

… and the Not-So-Good.

I am sometimes astonished by the sparse content that is actually offered up
for review. “We need a report” really does not tell me a whole lot about the
business process that I am supposed to automate. Nor does it even hint at
the report purpose, content, layout, user interface, execution mode,
authorization requirements, or error handling. And likewise, “Build me an
interface” does not even begin to describe the direction, payload content,
mapping, frequency, error handling and recovery steps. It would be so
wrong for me to attempt to build a technical design on such meager
functional definitions. One of my favorite cartoons shows a development
manager standing in front of rows of programmers saying “You guys start
coding. I’ll go and find out what they want”.

I am further astonished by:

a) the project managers who apply pressure to accept inaccurate and

incomplete functional specification documents, to give the impression that
the project is actually moving forward and making meaningful progress.

b) the functional analysts who whine incessantly when their paltry

functional specification document is not accepted.

A functional specification document that does not meet expectations must

be upgraded until it does. But bouncing a functional specification document
back and forth like a ping pong ball between the functional team and a
technical reviewer is inefficient and wasteful. I find that the best way to
quickly firm up a weak functional specification document is to thoroughly
research all of the issues that I found in the document, formulate proposed
solutions where possible, and then schedule a face to face collaborative
meeting with the functional analyst and the business process owner(s). This
type of collaboration can save hours, days, or even weeks of wasted ping-
pong posturing, and that is always best outcome for the project.

Off-Shore Technical Resources

This face-to-face quick resolution scenario typically cannot happen if you
have an off-shore technical contingent in play. In this case, it is absolutely
imperative that the functional specification document be most accurate and
complete to mitigate the risk of excessive time loss. Why is that?

Off-shore resources are sometimes time zone shifted eight or more hours
ahead of where the project is located. If a functional specification document
is released for review, it will not be analyzed until we have left for the day. If
the off-shore reviewer has questions or raises issues, we will not see these
questions or issues until the next day when we arrive at the project site.
When we respond to the questions or issues, the off-shore team will not see
our response until we have left for the day. And so on.

Under these conditions, a poorly written functional specification document

with issues takes days instead of hours to resolve. This leads to unnecessary
project delays and cost overruns.

When One is Really Many

That 3PL interface, which was scoped and planned by the business process
owners as a single RICEF object named “The 3PL Interface”; and for which
only one interface functional specification document is written, is actually
many RICEF objects. We need to move purchase orders, inventory receipts,
advance ship notices, inventory picks, and cycle counts between the two
interfacing partners. Each of these represents a different payload, different
mapping, is triggered by a different point in the business process, has
separate error handling and recovery procedures, and requires a separate
RICEF development object.

That single enhancement functional specification document, which addresses

all of SD pricing, has the potential to extend into many different user exits. I
just finished coding an ABAP proxy that was functionally specified as one
interface. In fact it was four. The requirement was to search the database
for sales and invoice data starting with either an invoice number, sales order
number, customer name, or company name. Each of these search
techniques required the development of a separate method. The only pieces
of code that were shared among the four search techniques were the input
parameters and the output return table.

The point here is to make sure that the project planners understand the real
complexity and effort required on the development side, and to make sure
that the project plan and budget reflects these more realistic metrics. This
really goes a long way to stop everyone from wondering, “It’s only one
interface! What is taking development so long?”

Great Expectations
So what is a reasonable set of expectations for a really good functional
specification document? What is it that we are asking the business analyst
to do?

First, let me describe what I do not expect. I do not expect a business

analyst to write code, build tables, design efficient database retrievals, or to
decide that one BAPI, function module, class, or IDOC is better than another.

Here is what I do expect:

A clear definition of a business process that is repeatable, and which actually

works. As a pre-automation test for data conversions, I always require the
functional analyst to manually enter one of whatever, using the standard SAP
transaction for which a conversion program is to be built. Many times, they
can’t because the system is not configured correctly, the supporting data is
not present, or any number of other reasons which cause the transaction to
fail. An interesting observation is that there is much indignant huffing and
puffing during this manual entry “test” process. But when the manual test
fails, I simply remind them that I cannot automate a broken or non-existent
business process.

A clear definition of what should happen under abnormal or failure

circumstances. This must include error handling, notification, recovery and
reprocessing steps.

A business process that can efficiently be automated. Requiring a search of

sales order header text for the phrase “This is a red order” is a very bad
design for automation purposes. While such a design is technically possible
to build, it will certainly be inefficient at run time, and may not always
produce all of the red orders. This is because the key value is a free-form
phrase that can and will be misspelled, and abbreviated, along with
countless other mutilations of the key phrase “This is a red order”. There are
much better business processes and technical implementations that will
more efficiently and more accurately find all of the red orders in your system.

An explanation of the need for development. Exactly what is the gap, and
how will automating the business process close the gap?

Screen shots from SAP transactions depicting data that is to be retrieved or

stored. From the screen shot in the transaction, I can usually determine the
exact table and field in the SAP database. Note that some business analysts
are very adept at identifying the actual underlying table and field name.

Clear and concise details with respect to data mappings, formulae, data
transformations, conditional processing, etc. If I come to an intersection and
it is unclear whether I should continue to go straight, turn left, or turn right,
then the functional specification document needs a bit more detail behind it.

How to insure Consistency in Functional Specification Document

Review
Design a separate functional specification document review checklist for
each flavor of RICEF object. Distribute these checklists to the functional
specification writers so that they know what the expectations are. Using a
checklist will help to make sure that your review process is consistent and
accurate. Improve these checklists over time. My Form functional
specification checklist document now includes the following check:

Is it physically possible to print the specified content on the specified form

using the specified font style and size? Was an actual printed mock-up
provided as proof?
 – but only after I had received a functional spec for a form that required four
inches of print content on a one inch label. And somehow, the business
analyst who wrote this particular request erroneously thought that it was my
problem to solve. After all, writing code is magic! Isn’t it? In this case, I
pushed back and insisted that an actual printed mock-up be produced – one
that I would then agree to automate.

Summary
A good functional specification document will help tremendously in moving a
project forward in the right direction with minimal cost and risk. A poor
functional specification document has serious potential to cause project
delays, and schedule and cost overruns. The best goal for the project is to
achieve a good functional specification document, using whatever means
required.

Skip to content

ERProof
Blog about all things SAP
 SAP Modules
o SAP ABAP

o SAP APO

o SAP BASIS

o SAP BI

o SAP CO

o SAP BPC

o SAP FI

o SAP HANA

o SAP HR

o SAP MM
o SAP PM

o SAP PP

o SAP SD

 SAP Training

o SAP ABAP

o SAP BASIS

o SAP BPC

o SAP BW

o SAP CO

o SAP FI

o SAP HR

o SAP MM

o SAP PM

o SAP PP

o SAP SD

 SAP Questions

o SAP BI Questions

o SAP FI Questions

o SAP HR Questions

o SAP MM Questions

o SAP PM Questions

o SAP SD Questions

 SAP Books

o SAP ABAP Books

o SAP APO Books

o SAP BASIS Books

o SAP BI Books
o SAP BPC Books

o SAP FI Books

o SAP HANA Books

o SAP HR Books

o SAP MM Books

o SAP PM Books

o SAP PP Books

o SAP S/4HANA Books

o SAP SolMan Books

o SAP SD Books

 SAP Jobs

o SAP ABAP Jobs

o SAP APO Jobs

o SAP BASIS Jobs

o SAP BI Jobs

o SAP BPC Jobs

o SAP CO Jobs

o SAP FI Jobs

o SAP HR Jobs

o SAP MM Jobs

o SAP PP Jobs

o SAP SD Jobs

 SAP Forum

Home » SAP ABAP

SAP ABAP

LinkedIn 0 Facebook 0 EmailShare 0

Advertisement

What is SAP ABAP?

Here we provided a brief description of SAP ABAP, which is a
programming language for developing business applications with SAP,
and also some useful information about SAP ABAP Certification. ABAP
stands for Advanced Business Application Programming and is
primarily used for enhancements of the standard SAP modules, such
as Business Intelligence, Financial Accounting, Controlling, Human
Capital Management, Materials Management, Production
Planning, Sales and Distribution, etc. ABAP is a programming language
of a high-level and it provides an abstraction of the basic database
level.

ABAP Workbench is a special development environment that enables

creation, modification and testing of programs. ABAP programs run on
application servers and power work processes that execute individual
dialog steps of SAP program. ABAP was developed by SAP and for SAP.
It is not used anywhere else. Therefore, people who learn this
programming language and think about undertaking SAP ABAP
certification will be tying their future careers with SAP. Each ABAP
program consists of the following parts:

 Program name (it can be between 1 to 30 characters long and some

special symbols are not allowed)
 Program attributes (they determine what this program is for in SAP
system). Examples of ABAP program attributes are ‘Type’, ‘Status’, and
‘Package’

 Program source code (these are the instructions that determine

processing logic for SAP)
The following picture illustrates the place of ABAP programs in the
overall SAP architecture.

Advertisement

For beginners, SAP architecture might look confusing at first and it is

necessary to spend some time with SAP Help Documentation for
understanding why there are so many components and how SAP ABAP
links them. We wrote an article with simple explanation about how
does SAP work and this could be a good start before diving into the
official documentation from SAP.

The simplest ABAP program (also known as “Hello World” program)

looks like this:

REPORT EXAMPLE.
WRITE ‘Hello World’.

SAP ABAP Certification

Similarly to other modules SAP came up with a certification program
for people who do ABAP programming. Unlike functional SAP modules
(e.g., SAP FI or SAP SD), SAP ABAP certification is considered to be
“technical”. Therefore, SAP calls people who passed this certification
“Certified SAP Development Associate”.

Advertisement

The official name of this certification is SAP Certified Development

Associate – ABAP with SAP NetWeaver X.XX where X.XX stands for the
version of SAP NetWeaver and periodically changes with introduction
of new version of the NetWeaver. The certification code for this exam
is C_TAW12_731. By the way, SAP NetWeaver is a platform hosts ABAP
Workbench and other SAP components (like ERP or BW). The main
purpose of SAP ABAP certification is to verify knowledge of developing
programs for SAP using ABAP. So, theoretically everybody who passed
this exam should be able to write programs that extend or modify the
standard functionality of SAP systems.

Usually, people who go for SAP ABAP certification (or just for ABAP
developer profession) have highly technical background. For example,
they could have Bachelor degree in computer science and know how to
write programs in Java or other programming languages. If one knows
how to write programs, usually it is relatively easy to learn basics of
SAP ABAP because all you need to learn is a new syntax and rules for
organising your programs. However, it is could be very challenging to
master SAP ABAP at the advanced or expert levels due to a large
amount of technical nuances of SAP.

Exactly like other SAP certifications of the Associate level, SAP ABAP
certification offers you to answer 80 questions. Each question is
multiple-choice (so, it is necessary to just tick all the correct options).
There is no negative marking for wrong answers. Therefore, if you don’t
know the correct answer for sure, it makes sense to try and guess it.
Even if your guess turns out to be wrong, you will not be given
negative points for providing the incorrect answer.

The duration of the certification is 180 minutes (3 hours) and it is

generally sufficient amount of time for answering all the certification
questions.
SAP ABAP certification score is calculated in percent. So, if you
answer all the questions correctly, you will get 100% score. In the real
world, it is difficult to achieve 100% score not only because you might
not know some ABAP topics but also because the questions are often
formulated in confusing way. But don’t worry too much about it
because the passing score for SAP ABAP certification is around 60%.
So, SAP leaves you some room for making mistakes.

Advertisement

How to Pass SAP ABAP Certification?

You will not be able to pass SAP ABAP certification if you don’t know
ABAP and programming. These are the essential prerequisites of
taking this exam. Unfortunately, it is not sufficient to just know how to
develop programs with SAP ABAP for passing the certification. There
are many questions that are difficult to answer if you did not read the
official training materials from SAP.

Based on our experience, we can recommend the following books for

study:

 TAW10 ABAP Workbench Fundamentals

 TAW12 ABAP Workbench Concepts

 BC400 ABAP Workbench Foundations

 BC401 ABAP Objects

 BC402 Advanced ABAP

 BC405 Programming ABAP Reports

 BC410 Developing Screen-Based User Dialogs

 BC414 Programming Database Changes

 BC425 Enhancements and Modifications

 BC427 Enhancement Framework

 BC430 ABAP Dictionary

 NET310 Fundamentals of Web Dynpro for ABAP

 NW001 SAP NetWeaver – Overview

As far as we know, it is not possible to buy these books from retailers.

SAP prefers to distribute these books only to those people who
purchased their official training courses. If you go to their SAP ABAP
course, they will give you these books for free.

If you do not want to pay a hefty amount of money for the official
training course, it could be a good idea to ask your colleagues of
friends who previously attended the official training to borrow these
books for several weeks. Another alternative is to use SAP
books (available to purchase) because they generally explain the same
concepts. In this case, you should make sure that you closely follow
SAP ABAP certification syllabus in your preparation. It will help to
focus on the important topics and allocate less attention to questions
that do not have big weight in SAP ABAP certification.

One more approach is to take ABAP training from third-party institute.

If you decide to take third-party training, it is a good idea to look for
the best institute in our catalog of SAP ABAP training. Make sure to
read reviews and do research about a training provider before buying
SAP training from them.

Advertisement

If you decide to study yourself, you may need access to SAP system for
doing practical exercises. Again, there are different options. One
opportunity is to purchase access to an SAP system that was set up
and is maintained by somebody. Learn more about it here: SAP IDES
Sandbox. The benefits is that the system is ready to use and it is a full
SAP ERP system. The downside is that you need to pay for it. Another
opportunity is download developer and/or trial editions of SAP
NetWeaver from SAP website and install them on your own computer.
More information about this option can be found here: SAP Developer
and Trial Editions. The benefit of this option is that it is FREE. The
downside is that you will need to figure out how to install and
configure it.
 Finally, we would like to wish you good luck with passing SAP ABAP
certification and success in your SAP career. Let’s hope that your
achievements will keep you motivated to continue professional growth.

Skip to content

ERProof
Blog about all things SAP
 SAP Modules
o SAP ABAP

o SAP APO

o SAP BASIS

o SAP BI

o SAP CO

o SAP BPC

o SAP FI

o SAP HANA

o SAP HR

o SAP MM

o SAP PM

o SAP PP

o SAP SD

 SAP Training

o SAP ABAP

o SAP BASIS

o SAP BPC

o SAP BW
o SAP CO

o SAP FI

o SAP HR

o SAP MM

o SAP PM

o SAP PP

o SAP SD

 SAP Questions

o SAP BI Questions

o SAP FI Questions

o SAP HR Questions

o SAP MM Questions

o SAP PM Questions

o SAP SD Questions

 SAP Books

o SAP ABAP Books

o SAP APO Books

o SAP BASIS Books

o SAP BI Books

o SAP BPC Books

o SAP FI Books

o SAP HANA Books

o SAP HR Books

o SAP MM Books

o SAP PM Books

o SAP PP Books

o SAP S/4HANA Books

o SAP SolMan Books

o SAP SD Books

 SAP Jobs

o SAP ABAP Jobs

o SAP APO Jobs

o SAP BASIS Jobs

o SAP BI Jobs

o SAP BPC Jobs

o SAP CO Jobs

o SAP FI Jobs

o SAP HR Jobs

o SAP MM Jobs

o SAP PP Jobs

o SAP SD Jobs

 SAP Forum

Home » What is SAP Reconciliation Account?

What is SAP Reconciliation Account?

Author Written by Janelle Swanson and last updated on Posted onJune 8,

2017. Posted in CategoriesSAP Interview Questions.

LinkedIn 0 Facebook 0 EmailShare 0

Advertisement
 SAP financial accounting has several sub
ledgers, including accounts receivable, accounts payable and asset
accounting. An account is maintained for each customer, vendor or
asset in the sub ledger. When preparing financial statements the
details of these individual accounts are not necessary. Instead, every
asset, customer or vendor account is linked to a certain SAP
reconciliation account, also known as a control account. Each SAP
reconciliation account is used to reconcile the sub ledgers with the
general ledger. SAP reconciliation accounts are reported on the
financial statements, while the individual sub ledger accounts are not.

The SAP general ledger is linked to the sub ledgers. For every
transaction posted in the sub ledger, the same value will be updated to
the corresponding reconciliation account.

Advertisement

For example, reconciliation account 160000 is used for trade vendors.

Let’s assume we have vendor A with account 36. If we post an invoice
of $2000 to vendor A, account 36 will be debited for $2000 and the
reconciliation account 160000 will also be debited automatically for
$2000.

Creating SAP Reconciliation Account

SAP reconciliation accounts are created very similar to all other
general ledger accounts. There are just a few attributes that need to
be set correctly. Transaction code FS00 is used to create
reconciliation accounts centrally.
In this tutorial, we will not walk through the entire account creation
process, as a reconciliation account is created in much the same way
as any other general ledger account. Instead, let’s examine account
160000 for AP (Accounts Payable) reconciliation. We will walk through
the three main areas where a reconciliation account differs from other
accounts.

To display a reconciliation account use transaction code FS00 or you

can use the following menu path:

Menu path for creating a reconciliation account

You will be taken to the screen below:

Displaying a reconciliation account

The first area that denotes that this is a reconciliation account is the
control data in the “Type/Description” tab. Here, you should note that
the account group “Recon.account ready for input” is selected. Also,
all reconciliation accounts should be identified as balance sheet
accounts:
Displaying a reconciliation account

Click on “Control Data” tab and check the second area that has to be
maintained when creating a reconciliation account. In the field
“Recon.account for acct type” you select between assets, customers
and vendors to specify which sub ledger the account reconciles:
Displaying a reconciliation account

Finally, click on “Create/bank/interest” tab and check the field status

group. The field status group for all reconciliation accounts is G067:
Displaying SAP reconciliation account

Assigning SAP Reconciliation Account to Sub

Ledger Account
Now that we have seen how to set up a reconciliation account,
complete the process by learning how to assign it to a sub ledger
account. Each sub ledger account has to be linked to a certain
reconciliation account for its postings to be recognized in the financial
statements. Let’s see how it’s done by looking at an already created
vendor.

Advertisement
Use transaction code FK03 to display a vendor or use the the following
menu path:

Menu path for displaying a vendor

You will be taken to the screen below:

Displaying a vendor

Enter a valid company code and vendor number, select the “Accounting
info” tick box and press enter. The reconciliation account 160000
examined earlier is assigned in the “Recon. account” field for this
vendor:
Displaying a vendor

The result is that for every posting recorded under vendor 36, the
general ledger updates with the same amount via reconciliation
account 160000.

Posting a Vendor Invoice

Finally, let’s see how a reconciliation account is updated when you
post an invoice for a vendor.

Advertisement

To post a vendor invoice use transaction code FB60 or you can use the
following menu path:

Menu path for posting a vendor invoice

Fill in the vendor number examined above (vendor 36 in our case) and
all details necessary for posting an invoice:
Posting a vendor invoice

Now post the invoice and click “Document > Display” on the top far left
of the toolbar to display the created document:
Displaying invoice document

You will see the following screen. Here you see that vendor 36 has
been credited with 2000 BWP. Click on general ledger view:
Displaying invoice document in entry view

You can see the reconciliation account 160000 assigned to the vendor
account is updated by the transaction above:
Displaying invoice document in general ledger view

The end result is that reconciliation account 160000 was also credited
with 2000 BWP. Therefore, every time you post a transaction to a sub
ledger account the reconciliation account will be updated with the
same amount in real time. In order to maintain a clean reconciliation
with the sub ledger, SAP reconciliation account can only be updated by
the system through the sub ledger. Direct posting to SAP reconciliation
account is prohibited by the system.