One of the most common issues that users experience when trying to post a document into the Accounting module of SAP is the issue about Assignment of Controlling Object.

This error may appear in different situations: manual entry of the document in Finance, Goods Receipt or Service Entry Sheet for a Purchase Order, and so on.

Let’s see what it means and how to resolve the issue.

What do you have to do?

To start with, you need to understand that the error itself is not an error in the Finance module of SAP. It comes from Controlling. Even though the error text reads “account”, this is not the GL account that causes the issue. Cost Element does. But since Primary cost elements have exactly the same numbers as their counterpart General Ledger accounts in the Chart of Accounts, the error reads “Account”. So, you will not get this error if your GL account is not created as a Primary Cost Element. Moreover, this Cost Element should have category 1 “Primary costs/cost-reducing revenues”.

When you try to post a document with a GL account that has also been created as a Cost Element of category 1, you must provide additional information for the Controlling module for further analysis of the costs. It means you need to supply at least one of the following:

• Cost Centre
• Internal Order
• WBS Elements
• Sales Order item
• And some more – the full list is available in the long text of the error, if you double-click the error message.

Where should you take the information from?

The finance guys who deal with the posting should have the information. If they don’t have it, then ask for people who deal with Controlling reports for the GL account in question. It well may be that a simple default value would do. You can put a default Cost Centre in transaction code OKB9 in this case.

What if you need to put more than one object?

It well may be that Finance guys will ask you to put more than one object into the posting. For example, they tell you to use Cost Centre and Internal Order. What does it mean? It means that your posting will be visible in Cost Centre and Internal Order reports both.

However, the way how the posting is treated in this case is different between Cost Centre and Internal Order accounting. Only one object can be “real” in every posting. The second (and the third, fourth – in extreme cases) objects are only posted “statistically”.

“Real” postings can be re-posted further, for example using the assessment and distribution cycles. “Statistical” postings cannot be re-posted and are only reported on the object they were posted to.

SAP has a strict rule in determining which object is “real” and which is “statistical”. In the pair of Cost Centre and Internal Order the Order is real, while Cost Centre is statistical, unless the Internal Order itself is defined as statistical in its master record, in which case Cost Centre becomes a real object in the posting. More information on this is available in SAP Help.

What if you want to use the object that is not visible on the posting screen?

The way how SAP screens with account assignments work is set up via Field Status Groups. If you post directly in Finance, then the Field Status Group from the GL account master data tells which fields are mandatory, optional, and hidden. It means that if you need to input an Internal Order, but the field is not on the screen, then you need to ensure that correct Field Status Group is assigned to the GL account. Check it in transaction code FS00.

If you post a document from a different module, for example Goods Receipt, then usually account assignment is taken from a preceding document, or from customizing. In the case of Goods Receipt this is Purchase Order. Each line item in the PO may have an account assignment category. Different categories allow population of different fields. The list of categories is customizable, as well as set of optional and mandatory fields for each of them. For example, in the SAP default configuration Account Assignment Category K demands an entry in the Cost Centre field, while F demands an Internal order with an optional Cost Centre.

So, when you have an issue with CO object during the Goods Receipt entry, first ensure that relevant PO line item has a correct Account Assignment Category, and that correct objects are populated in the Purchase Order fields.

If you have more questions about the assignment of CO objects in Financial postings, why not ask SAP Expert?

The need for utilising data increases and that of course includes operational data from ERPs. To serve this basic demand of companies SAP continuously improves their data analysis and data visualisation tools and offers great solutions like SAP BusinessObjects, Lumira, SAP Analytics Cloud or SAP Design Studio. But despite heavy investments, business intelligence still remains a weaker area for SAP, especially compared to great and widely used new-generation BI platforms on the market like Tableau and Spotfire.

It’s not easy to get around SAP’s closed ecosystem and make SAP data available in other platforms, but not impossible. You can even export data from SAP ERP systems with all existing business logic included (not only table level) using Data Unfolder and create magical visualisations in Tableau.

How about the other way around? Wouldn’t it be great if Tableau’s interactive visual analytics could be embedded into SAP?

Now this is not science fiction anymore, due to the recent efforts from VirtDB a technology spin-off of well-known Big Data Consulting company Starschema Ltd. They just released a product called InstantInsights which provides business decision support for SAP users, by embedding responsive Tableau dashboards right into SAP.

What to embed and where?

First of all, how do we know which dashboards should be displayed in SAP and on which screens? Is it possible to add dashboards to standard SAP screens?

When you launch InstantInsights, it will scan the currently displayed screen and will identify business objects like sales orders, materials, customers, storage locations etc. It will display an assistant bar on the left side, listing everything it has found (for ex. Company code 1000, customer 2503 etc.). For each business object, you can assign any number of Tableau Dashboards and you can display them in SAP by double clicking on it. This can be automated by setting a default dashboard.

Filter the dashboard based on your SAP screen field values

With InstantInsights’s solution, based on SAP field values, your Tableau Dashboard will be filtered automatically. It follows that you can use all the functionalities of Tableau, so you can drill down, filter etc. and you can even edit the dashboard in place.

The solution can utilize your existing BI reports and dashboards in a responsive way: for example when creating a Sales Order in SAP, a contextually filtered credit risk analysis dashboard can be displayed for the particular customer in the SAP Client. This can help the Analyst to assess the related risks before operative decisions taken.

This provides interaction between the systems in one direction. However, we have a bi-directional integration.

Launch SAP transactions from Tableau

If you need some detailed information in a dashboard, you may face a problem that you are not able to display _all_ data that sits in SAP and is related to the item you have just selected. You can only add the required infos to the details section, to a tooltip or as a label instead. But would it not be easier to display SAP instead?
InstantInsights enables you to launch any SAP transaction when you interact with your dashboard. You can practically do anything with that, but we have chosen a simple use case: display the document in a new SAP window.

What is the business value?

Well, this two-way integration can be beneficial for you, because:

• Help your SAP users make better decisions by providing analytical insights in the SAP screens (like credit risk analysis for customers, stock levels in a warehouse, predictive analysis etc.). You imagination is the only limit.
• Using the two-way integration, you can trigger events in SAP by clicking on marks on Tableau Dashboards. For example, you can:
  1. Display objects in SAP
  2. Start a workflow in SAP, so a relevant SAP user will get a notification about a task to be done
  3. Trigger a business transaction (reject sales order, approve invoice, release purchase order etc.)
• Reduce communication between teams (SAP and analytics) by merging them: now your clerks do not have to pass SAP data (in Excel…) to the analytics team and get some insights that they can use next week.
• This tool also allows you to display non-SAP data – in a graphical way – within SAP screens without physically loading data from external systems. If your Tableau Dashboard visualises your Salesforce CRM data, you can make that available for your SAP users by embedding it. You don’t have to develop a new interface, load data and process on the SAP side.
• You can embed SAP BW analytics in the operational ERP system. Since Tableau has a standard SAP BW connector, you can build dashboards on your infocubes etc., and make that available in the source SAP system.t
• You can make an embedded end-to-end solution for SAP HANA: you can use the standard Tableau connector to visualize data that is in a HANA database, and provide it to the users in the same SAP GUI.
• This solution is compliant with SAP’s current licensing policy and does not involve any indirect access of SAP systems.

Get your hands on it and sign up for a demo here.

Tamás Holics is a technology enthusiast with a 10+ year experience with SAP systems and works as the CTO at VirtDB.

Are you in the job search? Do you want some help?

SAP Expert wants to give you a helping hand. There are actually two parts of this help.

First of all, I am offering you an impartial  CV / Resume review. Seeing many of them, writing my own, I have some views on what should and should not be covered in the CVs. You can read some of these thoughts in the article. It is my personal view, and thus may be different from what official “recommendations” from different recruiters may tell you. You may or may not follow my advice. That is completely up to you.

Second, I am offering a CV distribution for the list of recruiting agents I have. This list currently contains about 750 email addresses. Here we have some conditions:

1. The list of recruiters mostly (but not only) contains people who deal with UK and EU job markets. Please be conscious about the visa requirements and don’t assume recruiters would deal with people who require visa sponsorship. Although, there is a workaround available. We’ll discuss it before the CV distribution.
2. Emails will be sent from my email address with my personal endorsement. That’s why I will apply a strong filter.
3. I will decide on whether I want to distribute you CV or not.
4. Only 10 people will receive this service.
5. This is a free service for both you and recruiters. I don’t charge you for this. If as a result of this mailshot you have a job offer, I leave it up to you to decide on the award.

Interested? Send your CV across to email address sapexpert@sapexpert.co.uk.

Just to re-iterate it once again, I am not a recruiter myself, but I am only a person who wants to help his fellow SAP consultants to find a job. You can also look at another way for finding your SAP job, which I wrote about recently.

Wish you all the best in your job search!

Image copyright Wellness GM.

I am not a newbie on the SAP job market. I was looking for job myself, and I was helping my friends to have a job.

I sent my CV to many recruiters, both agencies and in-house.

The feedback I received from them is just priceless. Let me list some of the favourites here…

1. Lack of any feedback

Yes, that is number one. You are lucky if 1 out of 100 recruiters would give you any feedback. The rest 99% emails will get no response at all.
To be honest, about 5 of those recruiters will come back to you by phone or by email with some additional questions and conversations, but after 1-2 contacts they disappear. They don’t even bother responding the chase letters.
You know, they have hundreds of candidates and tens of positions to fill, there’s no point in giving feedback to every person who applied.

2. Other candidates more closely fit the requirements

This is usually the full contents of the email, bar a greeting and a signature. That is a very (very-very) helpful answer, because it clearly shows you your place on Earth. It also tells you exactly where you need to improve your skills to fit that vacancy.

3. You do not have necessary consultancy skills

After many years in SAP world, both on consultancy and end-user sides? Yes, my recent experience (at the time of interview) was on the end-user side. But that was a team who dealt with implementation and roll-out of functionality to new businesses within the company. I was on several consulting roles before that. Of course, the recruiters know better, don’t they?

Thanks for your in-depth looking into my skillset, my recruiter friends.

What are you favourite responses?

Bank account statement is the document that tells the bank account holder the information related to the bank account. If your company runs SAP, once the bank statement received for the company bank accounts, it should be entered into SAP. Like with entering invoices and entering payments, SAP supports several methods for entering bank statement too. The method of entering depends on arrangements with the bank and the format of bank statement delivery.

Manual bank statement

The most classical way of entering the bank statement supports the paper statements or electronic formats not directly uploadable into SAP.

Transaction FF67 is the user interface for entering the bank statement details.

Once user enters or selects the bank account, he needs to enter the initial and closing balance of the statement. The next screen gives the opportunity to enter individual transactions from the statement.

When the statement is entered, it can be posted on-line or via a separate batch input session, depending on user preference.

Electronic bank statement (EBS)

The more advanced way to receive bank statement from the bank is via electronic files. There are multiple file formats. Some of them are worldwide standards (e.g. SWIFT MT940, Multicash), other are country- or bank-specific (e.g. BAI2 or Royal Bank of Scotland).

SAP supports multiple formats, and you can configure transactions FF.5 and FF_5 to call one or several of them with the pre-defined variants.

The layout of the transaction in this case will depend on the assigned program and variant. You can pre-populate certain fields on the screen to allow bank statement import with less manual steps.

Once the file is imported, SAP can do some automatic checks, depending on the file format. For example, SAP automatically checks the incoming and outgoing balances of consecutive MT940 statements and throws an error if they don’t match. This check does not work for BAI2 statements because their numbers are not assigned by the bank.

Like with the manual bank statement, SAP can attempt an automatic posting of EBS at the moment of entry, or create a batch-input for processing later.

IDOC

The most advanced way to import bank statement into SAP is via IDOCs. You can ask your bank to send you IDOCs in FINSTA format. In order to enable that way of communication with the bank you need to configure partner profile for the bank in transaction WE20 and add FINSTA IDOC to the profile.

When IDOC is received into SAP, it will automatically create bank statement records in the system. However, the standard SAP program will not attempt automatic posting of these statements. If you need to post them automatically, you need to schedule program RFEBKA30 to run periodically and pick up any unprocessed items.

What is next?

Depending on the way how the statement is entered in SAP and some user-specific settings, SAP will or will not automatically post the bank statement items. In some cases, you will need to process them separately either via batch input or via program RFEBKA30. However, this will not ensure all bank statement items are fully posted.

There are several configuration steps allowed for the bank statement. They are subject to a separate conversation.

You need to check the statement status and, in some cases, you need to post-process the statement items. You can read about that process in a separate article of SAP Expert.

If you have additional questions about the way to import bank statement into SAP, why not ask SAP Expert?

Bank statement is the document that tells the bank account holder the status of the bank account balance along with the list of incoming and outgoing payment transactions.

When the statement is received, it should be entered into SAP system to reconcile bank accounting and general ledger, mark payments as processed, invoices as paid and so on. There are multiple ways how the bank statement can be entered into SAP system.

Receiving a bank statement is one task, and another one is to monitor that all bank statements for all bank accounts were received and processed in time. Is there a tool from SAP for that?

Enter BCM-BSM functionality. To explain the abbreviations, it is Bank Communication Manager, Bank Statement Monitor functionality. It is a part of Financial Supply Chain Management module (FSCM). You may need to activate this component FIN-FSCM-BNK separately in the list of Business Functions (transaction SFW5). It is also advisable to implement SAP Note 1486308 if it is applicable to your system.

What does BSM allow you?

BCM-BSM functionality allows you to monitor bank statements for bank accounts. The way how you receive the statement and enter it into SAP is not important. The following parameters are checked:

1. Bank statement arrived in time.
2. Bank statement numbers are sequential. Last 5 bank statements for the bank account are checked.
3. A difference between the bank statement and bank General Ledger account balances is within a tolerance.
4. Bank statement is properly reconciled and all items are posted.

To call up Bank Statement Monitor, you need to run transaction FTE_BSM.

How is that configured?

The configuration of Bank Statement Monitor is simple. Of course, it is just an addition to the configuration of bank statement entry and processing, which is much more difficult task. Whole BSM configuration is kept in the IMG transaction FTE_BSM_CUST.

Here you list the bank accounts you need to see in BSM report. You enter Company Code, House Bank ID and House Bank Account ID for each bank account.

For each account you also need to tick checkboxes for the checking parameters available in FTE_BSM transaction. Please see them above. In addition to these checkboxes, you can configure specific parameters for some of the checking options.

First, you need to tell the system how often you receive the statement: daily, monthly, every 2 weeks and so on. If you only receive the statement on certain days, you may assign Factory Calendar here. It will ensure that the indicator responsible for timely bank statement receipt shows the correct information.

Separate field allows you to configure a tolerance between the bank statement and bank GL account balances, if these balances do not match. Usually this tolerance should be zero, but you can put your own value here. Tolerance is entered in the bank account currency.

If you need to see bank accounts in a specific order, you can enter the position in the list too.

Running the transaction

Once you configured the Bank Statement Monitor transaction, you can run transaction FTE_BSM. Selection screen of the report allows you to limit the set of company codes, house banks and house bank accounts. It also gives you the option to run the report for the specific key date. Current date is default.

The results will show you a list of house bank accounts according to selection parameters and configuration. For each bank account you will see bank statement opening and closing balance, debit and credit turnovers, GL account balance, a difference between the GL and closing balance and, of course, four traffic light indicators for each of four possible checking parameters. There is some technical information about the bank account, bank statement and its entry too.

Some of the report fields are underlined. Clicking it, you get details of the most recent statement for the bank account, or list of the bank GL account line items.

Background running of this transaction is not allowed, you so need to consider performance aspects when running the report too.

As you can see, the implementation of the Bank Statement Monitor is simple enough, but it gives users a powerful cockpit to monitor the bank statements process.

Do you have questions about BSM-BSM or any other FSCM-BCM components? Why not ask SAP Expert?

SAP Bank Communication Manager (BCM) is one of the components of SAP Financial Supply Chain Management (FSCM) module. The responsibility of BCM, as it follows from its name, is in the management of relationships with the bank.

Let’s have a look at the processes that BCM supports. We will not look into details of the configuration, because these will be too much for this overview.

This diagram shows you an overview of processes you can manage through Bank Communication Manager on ECC and PI sides. There are three major parts, and we’ll look at each of them individually.

Payment authorization

The classical ERP payment process starts with the Automatic Payment Program (transaction F110). There is no difference for the Bank Communication Manager process. You run Payment Proposal, review it and then finalize your Payment Run. At this moment of time, your payment documents are generated and posted in the ledgers. Normally, you also generate your payment files for the bank and remittances for the vendors.

Here start the differences for the BCM process. You do not generate payment files directly from the payment program. Instead, you initiate the BCM process of payment batching.

Transaction FBPM1 is to create approval batches. Batch may contain payments from several payment runs, and one payment run may be split across several batches. There are various criteria that allows you to Approval batch generates a workflow item, which may also generate an email.

From this moment of time, SAP BCM does not work with individual payments, but only with payment batches.

Each payment batch goes through an approval process. SAP BCM supports from 0 to 4 approval levels for each batch. Users approve batches from the workflow inbox SBWP or from an approval transaction BNK_APP. On the 1st approval level, users can approve or reject the whole batch or each individual payment. On the higher approval levels, only the whole batch can be approved or returned to a lower level.

Once the batch is approved, payment file is generated, and also the remittance advices. The generated file can now be transferred to the bank, for example via the SAP PI mechanism.

Batch monitoring transaction BNK_MONI allows users to check the current status of each batch throughout its life cycle. It also shows you the history of the status changes, the contents of the payment file, the approvers and so on.

Payment acknowledgements

Once the bank receives the payment file, it validates it and sends back notifications, also known as “acknowledgements” or ACKs. There can be up to 3 different levels of acknowledgements, but I practically had only seen two. For example, pain.002.001 (XML) file format specifies ACK1 as file structure validation and ACK2 as payment details’ validation.

Depending on your process, you can pick up ACK files manually or via PI. In either case, SAP standard transaction S_EBJ_98000208 can import the acknowledgement files. If you have different levels of ACK files, then you can have acceptance and rejection statuses on each of them. For example, your payment file may be accepted in general, but one payment in it may be rejected for some reason.

As with the payment batch approvals, users can monitor the status changes in BNK_MONI transaction.

Bank statement monitor

When bank accepts your payments, it will execute it. As a result, the company’s bank statement will show transactions.

You can receive statement in some different ways: enter manually, import a file, process the file via PI or even receive IDOCs. These are all standard, non-BCM specific processes.

It is easy to check the status of the bank statements manually if there is one, two or even half a dozen of bank accounts. But what if you have dozens? The Bank Statement Monitor comes to play!

Transaction FTE_BSM allows users to monitor that all necessary bank statements were received, processed and reconciled.

There is a separate article from SAP Expert that describes the functionality and configuration of Bank Statement Monitor in more details.

SAP BCM is a powerful tool that allows you to effectively process payments, monitor its statuses and have a proper audit trail of payment approvals.

Does your company use SAP BCM? Maybe you want it to be implemented? Then why not ask SAP Expert a question?

One of the most common issues that users experience when trying to post a document into the Accounting module of SAP is the issue about Assignment of Controlling Object.

This error may appear in different situations: manual entry of the document in Finance, Goods Receipt or Service Entry Sheet for a Purchase Order, and so on.

Let’s see what it means and how to resolve the issue.

What do you have to do?

To start with, you need to understand that the error itself is not an error in the Finance module of SAP. It comes from Controlling. Even though the error text reads “account”, this is not the GL account that causes the issue. Cost Element does. But since Primary cost elements have exactly the same numbers as their counterpart General Ledger accounts in the Chart of Accounts, the error reads “Account”. So, you will not get this error if your GL account is not created as a Primary Cost Element. Moreover, this Cost Element should have category 1 “Primary costs/cost-reducing revenues”.

When you try to post a document with a GL account that has also been created as a Cost Element of category 1, you must provide additional information for the Controlling module for further analysis of the costs. It means you need to supply at least one of the following:

• Cost Centre
• Internal Order
• WBS Elements
• Sales Order item
• And some more – the full list is available in the long text of the error, if you double-click the error message.

Where should you take the information from?

The finance guys who deal with the posting should have the information. If they don’t have it, then ask for people who deal with Controlling reports for the GL account in question. It well may be that a simple default value would do. You can put a default Cost Centre in transaction code OKB9 in this case.

What if you need to put more than one object?

It well may be that Finance guys will ask you to put more than one object into the posting. For example, they tell you to use Cost Centre and Internal Order. What does it mean? It means that your posting will be visible in Cost Centre and Internal Order reports both.

However, the way how the posting is treated in this case is different between Cost Centre and Internal Order accounting. Only one object can be “real” in every posting. The second (and the third, fourth – in extreme cases) objects are only posted “statistically”.

“Real” postings can be re-posted further, for example using the assessment and distribution cycles. “Statistical” postings cannot be re-posted and are only reported on the object they were posted to.

SAP has a strict rule in determining which object is “real” and which is “statistical”. In the pair of Cost Centre and Internal Order the Order is real, while Cost Centre is statistical, unless the Internal Order itself is defined as statistical in its master record, in which case Cost Centre becomes a real object in the posting. More information on this is available in SAP Help.

What if you want to use the object that is not visible on the posting screen?

The way how SAP screens with account assignments work is set up via Field Status Groups. If you post directly in Finance, then the Field Status Group from the GL account master data tells which fields are mandatory, optional, and hidden. It means that if you need to input an Internal Order, but the field is not on the screen, then you need to ensure that correct Field Status Group is assigned to the GL account. Check it in transaction code FS00.

If you post a document from a different module, for example Goods Receipt, then usually account assignment is taken from a preceding document, or from customizing. In the case of Goods Receipt this is Purchase Order. Each line item in the PO may have an account assignment category. Different categories allow population of different fields. The list of categories is customizable, as well as set of optional and mandatory fields for each of them. For example, in the SAP default configuration Account Assignment Category K demands an entry in the Cost Centre field, while F demands an Internal order with an optional Cost Centre.

So, when you have an issue with CO object during the Goods Receipt entry, first ensure that relevant PO line item has a correct Account Assignment Category, and that correct objects are populated in the Purchase Order fields.

If you have more questions about the assignment of CO objects in Financial postings, why not ask SAP Expert?

Period closing is a process that involves many steps in different SAP modules.

Even if we take SAP Finance (FI) alone, period closing activities include various steps in GL, AP, AR, Assets and other submodules. To ensure the period closing is complete and reports are finalized, users maintain a table with periods open for postings.

You can see and maintain the table in transaction OB52. Period closing is controlled by Posting Period Variants (PPV) that are assigned to one or several Company Codes. Each Posting Period Variant can be further controlled by different account types:

• + – postings are allowed in general
• A – Assets
• D – Customers
• K – Vendors
• M – Materials
• S – General Ledger

Each account type can have 2 separate period ranges open, one for general users (closer to the right part of the screen) and one for users with special authorisation group (closer to the left part of the screen, and authorisation group itself is the right-most column).

Correct maintenance of this table is an essential requirement for period closing. If you maintain it incorrectly, you either risk having additional postings after all the reports are submitted, or risk disallowing legit postings in the current period.

Complex closing procedures in large companies may lead to OB52 maintenance errors.

Is it possible to automate OB52 maintenance and avoid errors? Yes, SAP provides you with automation tools that allow you to maintain the table “en mass” or even in the background. Let’s look at them.

Formalize closing routine

Even though this is an out-of-system step, it is essential that you formalize your period closing routine before you start any automation. Namely, I would recommend you to highlight in the document:

• Date and time for each account type opening for the next period
• Date and time for each account type closing for regular users
• Date and time for each account type closing for users with special authorisations (“superusers”)

Date can be either calendar day of the month, or n-th working day related to a beginning or end of the month.

If you have several PPVs, you may have different rules for each PPV.

Installation of SAP Notes

Once you are clear with the opening/closing timings, you can start the technical preparatory steps. You need to activate the program RFOB5200 in your system, which is delivered in SAP Note 1483900. There are some additional side-effect notes that I would encourage you to review and implement as you see fit.

SAP systems with higher level of Service Packs may have this program already delivered. However, I would still recommend you to search for update notes and act accordingly.

Prepare the variants

Once the program is implemented in your system, you can create variants for it.

The variant should specify PPV, account types, open periods and authorization groups as you would specify them in manual OB52 maintenance.

If you want to run RFOB5200 in the background, you may need to automatically calculate the current/next period number and year. Unfortunately, RFOB5200 cannot calculate them for you. You have to rely on external variables and then assign them in the program variant. Some of the variables can be calculated by the standard program RVSETDAT. If this program does not give you proper values, you can create your own program and do the necessary calculations there.

It is a good idea to run the program RFOB5200 in test mode before saving the variant without the “Test run” checkbox. The test run output will give you the list of PPVs, account types and open periods that would be set in the system after the program run.

Check the authorisations

Running RFOB5200 requires special authorisations for period openings. You may wish to ensure your regular or background users have these authorisations.

Schedule the job

When the variants are created and tested with necessary authorisations, you can schedule the jobs that would automatically maintain the OB52 table.

When you schedule the job, there is an obvious option to start it on a certain day of the month. However, not everyone is aware of a slightly less obvious option to schedule the job to run on the certain working day rather than on the calendar day.

Using this feature, you can ensure that the period opening and closing happens on specific working day, adjusted to weekends and bank holidays of the current month. Of course, you need to maintain a holiday and logistics calendar for that. SAP Expert has already written about the special rules for transporting the calendar in SAP and about the small tricks in using the calendars. I encourage you to re-read these articles.

So, now you are able to open and close the Financial periods in SAP using the most complex closing procedures and scenarios.

If you have further questions about the period opening or other SAP Finance activities, why not ask SAP Expert?

There is no doubt that SAP accumulated a huge amount of experience in automation of business processes throughout the years. Some of these processes are easy to implement in SAP, others are not so.

Many years ago, at least 20 or maybe more, SAP came up with an idea of “SAP Best Practice”, a set of recommendations for the businesses how to organize the processes better so the automation of these processes goes smoothly. SAP Expert has always been a believer in SAP Best Practices. There is even an article that explains how to deal with cases when business users object the SAP Best Practice recommendations.

SAP IDES, a theoretical company running SAP, was a test and educational system for SAP users who wanted to learn more about SAP. And SAP IDES had many ideas from SAP Best Practice implemented.

Fast forward several years, change the system from SAP R/3 through SAP ECC to the current S/4HANA. What do we see now?

SAP went even further on this route. There is not just “SAP Best Practice” set of recommendations now, but the whole SAP system implementation called “model company”. There are model companies for different industries. These are pre-configured SAP landscapes with pre-configured business processes and even some master data. Model Company is not just an ERP system, but some other relevant systems as well, for example SAP CAR for Retail solution. So-to-speak, SAP IDES taken on another level.

Of course, it is not a free product. If you want to get a SAP Model Company, you need to pay money for software itself, as well as prepare (or prepare to pay for) necessary IT technical components: this is a cloud solution.

And then… SAP customers start to implement Model Companies as their main solution. Just few examples: Arvato and Nostrum.

What does it mean for the market? As usual, there are pros and contras.

Of course, some companies will benefit from speedy SAP implementations. There is no need to repeat the same steps in the system implementation project that have been done by other companies multiple times.

But at the same time you need to look critically at the pre-delivered solution. Starting your new implementation with IDES-delivered processes was not a good idea in the past. Why is Model Company different? Only because it has some industry specifics? But how well does it fit your requirements? Will you keep your main competitive processes intact if you start adaptation of SAP standard processes?

The worse would be if SAP starts pushing be customers into using Model Company as a must, as the only way to use SAP software. This will mean ease of support from SAP side, but lack of business advantages for customers. Tail should not wag the dog. Will it even happen?

How well will SAP and its sales partners balance these factors in their sales pitches? Only time will show.

Do you think that the idea of a Model Company and whole SAP implementation based on Model Company is good or evil?

SAP Expert has a very popular article already about the Bank Statement Process in SAP. That article is based on the “old” SAP transaction for post-processing of bank statements: FEBAN. In fact, FEBAN was already the second generation of such transaction, first of which was the single-screen FEBA. The difference between FEBA and FEBAN is like a difference between FB01 and FB50. Both FEBA and FEBAN had their advocates.

Let’s not go deep into that conversation. SAP introduced a new, third generation of bank statement post-processing transaction few years ago. They did not change the transaction code. It is still FEBAN. But this is a New FEBAN.

Let’s have a look at what is actually new in New FEBAN.

Design

The most obvious change is the design. Instead of tree-structure bank statement layout on the left and line item details on the right, new FEBAN has three horizontal sections.

The top section lists line items selected through the selection criteria, so-called “Worklist”.

The middle section gives you an overview of an individual transaction, its amount, text description and so on.

The bottom section allows you to run cash allocation activities, attach documents and check the logs of the line item processing.

The table sections in the top and bottom part of the transactions are configurable through the standard ALV functionality. Moreover, the bottom part tables can be used for data entry in the corresponding fields.

Cash allocation options

New FEBAN allows you to be flexible in the way how you run the cash allocation for the transaction. It no longer limits you to the use of FB01 or FB05 which are called by the “Save” button. Instead, you can search for invoices to clear, allocate amounts in full or partially, post amounts on customer, vendor or even GL account. All that in any combination and without leaving the single screen, just switching between the tabs. The only limit there is that you can post the document only when the balance is zero. Quite logical it is, isn’t it?

Transaction details editing

Yes, you read this right. You can edit, enhance, amend the transaction details right from the New FEBAN transaction. Of course, you are limited to what you can edit. You cannot edit amount, sign or external transaction code. But you can change the internal posting rule, add some batch-input field information (like in the search strings configuration). And what is the most useful, you can change the Remittance section of the bank statement line item.

Why is it the most useful? Because all your interpretation algorithms and search strings use the Remittance (Note to Payee) section for their work. And nowadays you may have remittance information not only through the bank statement, but also from email, online platform, phone conversation and so on. For example, you can copy-paste invoice numbers related to the customer payment from an email received from that customer financial department, and then “Scan” the Note to Payee section again, asking SAP to automatically find the invoices related to that payment. It will not only run search algorithms for finding the invoice, but also use search strings that may redefine the posting rules, populate extra fields and so on.

That is truly convenient, believe me.

Posting simulation

You have an option to simulate the financial document without actual posting, like you do it in normal FB01, FB05, FB50 and so on transactions. That is just another useful option to validate the document before it hits the accounting books.

Document reversal

Once the document was posted in “old” FEBAN, you had no option to re-process the bank statement item. Of course, you could reverse the document itself and post a new document again. But that new posting would have no link whatsoever to the bank statement. FEBAN would still list an old document against the line item.

Now you have an option to reverse (and reset clearing if necessary) the FI document right from the FEBAN screen. Once reversed, you can reprocess the bank statement line item again using all the same functionality as in original posting.

All the postings and reversals are kept in the FEBAN log, so you can have an audit trail.

Manual change of status

You can now manually change to status of the bank statement line item between Open and Completed. Yes, that is without actual posting.

Relationships browser

The posted document number is shown against the bank statement line item in FEBAN. That existed even in the first re-incarnation of the bank statement post-processing transaction FEBA. But now you have a reverse search functionality. Right from the posted document you launch the Document Relationships Browser, and get back to the statement line item overview.

Well, that is not directly linked to the New FEBAN transaction, but still a worthwhile addition to SAP functionality.

Conclusion

As you can see, SAP worked hard on improvement of the bank statement processing transaction and its usability. It now became really useful and user-friendly

Have you tried that new FEBAN transaction yet? Maybe you can add some more features that SAP Expert forgot to mention here?

Do you have questions about using FEBAN? Why not ask a question to SAP Expert?

When we say “Bank statement”, we most often mean the statement that bank provides to us (person or company) with a list of transactions from the past. These are the transactions that already happened on account. They affect available balance on account. They cannot be changed or back-dated.

When talking about bank statement formats, these are SWIFT MT940, BAI2 and many other country- or bank-specific formats, and even FINSTA IDOCs. SAP provides multiple options to upload these bank statement formats.

But these end-of-day statements are not the only ones that banks may provide, and they do provide. There are also intra-day statements.

These intra-day statements contain the information about transactions happening on the account during the day. They are not necessarily confirmed, as there is a chance that some issues may cause the cancellations or delays. But there’s still a chance that these transactions will make their way to the end-of-day statement, which we will receive tomorrow. There can be multiple intra-day statements covering transactions at different time intervals.

Why are they needed? Mostly for cash position reporting. If your company trade volumes are measured in millions, every single transaction may affect your cash position both in negative and positive direction. Treasury needs to plan cash position and act quickly to avoid unnecessary overdrafts and bank charges.

Another use of intra-day statement is to give the credit control team idea about customer payments. Why would you need to chase the customer payment, if your bank already informs you about the transfer to your account?

What are the formats available for intra-day statements? Just to name the most common: SWIFT MT942 plus the same BAI2, and also FINSTA IDOCs. Of course, BAI2 and FINSTA have special indicators to distinguish end-of-day and intra-day files. SWIFT MT940 and MT942 are very similar, but even they have their unique tags, which only appear in one format, but not in other.

What can you do with intra-day statements in SAP? Of course, you can import the intra-day statement files into SAP. But SAP understands that these transactions can yet be cancelled, and it does not make any postings based on intra-day information. Instead, standard SAP program can create Cash Management Memo Records (Payment advices). These memo records can then be viewed in Treasury reports.

The pre-requisite for Memo Records (Payment advices) creation are checkboxes “CM Payment advice” and “Account balance” on the selection screen of MT942 import. Another important thing to remember is that SAP only accepts SWIFT MT942 statements in “Field 86-structured” format. Is your file coming non-structured? There’s a workaround. SAP Expert will be happy to advise if you ask.

Are you using intra-day statements in your company?

Hello, dear friends. First of all, let me introduce myself. I’m Vitalii and last 15 years have been working in SAP HR/HCM field in global companies with 50k+ employees. I’m a top SAP HR blogger in Russia at https://saphr.ru and have recently started my English version of blog at https://saphcmsolutions.com

Today I want to share with you how to generate SAP Business Partners from Employee records. Finally we’ll have personnel number in SAP HR in PA20 transaction and a business partner with Employee role in BP transaction. SAP Business Partners are core entity in S/4 HANA solution as it allows to look at the same person or company under different angles. The same person could be our employee and vendor providing office supplies in his spare time. If we work with staffing agencies we can have one business partner as an agency with multiple contractors working through this business partner. And all of them will be linked together with relations in SAP Business Partners functionality. Good thing – it’s free of licensing. Setup and use it.

I assume we have a clean green-field installation (a development client was copied right from 000), so many default things could be skipped.

By default we have all switches set in ‘Activation Switch for Functions’. Also default Employee role is predefined by SAP with code BUP003 (see V_TB003).

Under ‘Number Ranges and Groupings’ it’s important to setup correct number ranges. I prefer to use internal number ranges.

Here we can setup HR Employees and Org units integration with SAP BPs. Go to ‘Activate Integration’ and make switches look like this.

For testing purpose let’s activate logging functionality in ‘Activate Logging/Error Analysis for Data Synchronization’. I’ve set HRALX MSGRE switch to 2, so all processing errors will be sent to my SAP Office mailbox in SBWP transaction.

Let’s synchronize our current employees with BPs. Open SE38 and run program HRALXSYNC. Tick ‘Employees’ on the first screen.

All red icons show us the data differences. Click the right-most button in the toolbar to sync the data. After it finished open transaction BP and search for the new business partners. Here what I have.

SAP synchronizes several infotypes by default, like personal data (0002), address (0006), org assignment (0001). If we want to provide some more info or change the behavior, then BADis could help.

If we reran the same program and choose ‘Organizational Units’ on the first screen it would have created org units as business partners and relations between org units and employees.

Tax code in SAP is an object that determines the tax treatment of certain transaction. It also drives the postings generated be the system when the tax code is used.

Generally speaking, there are two types of taxes that are relevant to SAP Finance postings: withholding tax and sales tax. This article is about sales tax codes. To limit out scope even further, let’s concentrate on sales tax how it works in Europe and some other countries like Singapore, Australia etc. The ideas may also be applicable to other countries, but be aware of local requirements that may not be fully covered here. Some other countries like USA and Canada use their own logic for sales taxes. They are not covered here at all. This article will also use term VAT, which is sometimes interchangeable with term GST in certain countries.

We have already covered special cases of tax postings. Today we will talk about more standard business processes.

There are some different types of tax codes in SAP system. Each of them serves its own purposes and has its own setup. Let’s check these types in details.

Regular purchases or sales

This is the most common type of tax code. It usually applies to domestic purchases (or sales) from a VAT-registered company. Tax rate depends on the country and type of product. It is specified in tax condition with account key VST for purchases or MWS for sales.

When the document is posted with such tax code, the VAT amount is posted on a separate GL account waiting for further processing during the tax return process.

Purchase and sales without tax

There are some scenarios where tax is not applicable to the transaction. This can be 0%-rated domestic transaction, or transaction not relevant to tax at all, or transaction with a foreign entity. Generally speaking, all these transaction contain 0% tax rate in VST or MWS account keys. Technically you can do with only one tax code for sales and one for purchases, but it is usually recommended to create several of them, as per requirements of tax reporting.

Of course, no separate line item for tax is generated in FI document from such tax code.

Non-deductible purchases

There are certain cases where purchase of a product or service is done for company’s own needs and VAT on such purchases cannot be fully or partially claimed in the tax return. In this case, tax code should be created with tax rate in condition with account key NVV.

This condition determines necessary amount of tax and distributes it across the GL accounts for costs or products purchased. It may be stock, P&L or GR/IR account depending on the situation.

Intra-EU purchases

European Union (EU) is a political organization that includes several states. The Union has its own policy on inter-EU trade, goods movement, accounting and so on. One of the rules applicable within EU is that sales between companies registered in different EU states usually bear zero VAT. While sales part of that transaction is covered in the section above, the purchases part has its own complexity. It is called “reverse charge of VAT”.

In short, buying company needs to reflect the VAT amount with domestic rate as both sales and purchase transaction. They offset each other, making zero in total, but still need to be shown in GL accounts and in tax reporting. That is why tax codes for such transactions use account keys ESE and ESA with domestic tax rate associated with them. Two additional line items appear in the finance document with such tax code.

Full-revenue sales

Majority of states require posting of customer invoices showing only net amount as revenue, while the tax part of the invoice is posted to VAT account. For a 20%-rated tax code the posting looks like:

However, some countries (e.g. Russia) require different logic for sales-related taxes. Gross amount of sales should be posted to a Revenue account, while special GL account “VAT on sales” is posted with VAT amount only. In theory, the posting should look like this:

While it is not technically possible to post Cr Revenue 120 in this case, the following logic is used in SAP:

It means that, in addition to standard logic of sales transaction, two more line items should be created from tax code treatment:

That is why tax code conditions with account keys ZUD and ZUK are employed to generate these line items in FI document. It means that tax code contains three active account keys: MWS, ZUD and ZUK.

You can understand that one of the GL accounts assigned to tax code posting is actually a revenue P&L account. If you have several P&L accounts for revenue postings in your Chart of Accounts, then you need to create as many tax codes in your system, and teach your users to use a correct tax code in each transaction, or use a correct tax code determination for automatic postings.

When you created necessary tax codes in your development system, please remember that there is a special procedure to transport them across the landscape.

What types of tax codes are used in your SAP system?

SAP Expert published multiple articles about the bank statement process in SAP. We looked at the ways to import the statement, the ways to process the end-of-day and intra-day statements.

Now let’s have a look at some interesting aspects of configuration behind the Electronic Bank Statement process.

You are probably already aware of the four main steps in Electronic Bank Statement configuration:

1. Create and assign Account keys
2. Create and assign Posting rules
3. Create Transaction type and assign posting rules to them
4. Assign bank accounts to Transaction type

You can already read a lot about EBS configuration in the free e-book by SAP Expert.

If your bank statement transactions can be easily classified by external transaction codes only, then all works in a pretty standard way . But what if you need to do something extra? Like find profit centre based on POS terminal code quoted in the text? Or change posting rule based on text description of the transaction?

Here we come to search strings for Electronic Bank Statement in SAP. What are they?

Search strings is a functionality that looks at the description of the bank statement transactions, like tag :86: in SWIFT MT940 format, and searches for the symbol sequences (read: pieces of text) that you configured. Based on the finding, it can do a lot.

So, how does it work?

Search string definition

First of all, you need to define the search string itself in transaction OTPM. It can be a fixed text like “BANK CHARGES” or a more complicated set of characters with wildcards and additional logic. Press F1 on the search string field and you will get a nice help page with plenty of examples.

When you define a search string, you can put the mapping directly there. For example, you can map combination “123123123” (as quoted bank account number) to “999888” (as your vendor number), so that you can directly use this vendor number later. Alternatively, you can leave mapping fields blank. It means that search string will only be a trigger for further actions, which we will discuss in few moments. If you want to leave mapping fields blank, don’t forget to remove the search string auto-mapped characters from the right column of search string definition.

Once the search string is defined, you can put some text in the special window and test if the search string really works. For example, you can copy-paste the text from tag :86: of your MT940 file.

Search string use

The second step is activation of search string, “Search string use”. Here you specify under which conditions your search string should be attempted: Company Code, House Bank, Account ID, External Transaction Code, Interpretation algorithm and so on. As for Interpretation Algorithm, it should either match the one from posting rule assigned to external transaction code, or you can put “999” for any algorithm. Most of the fields in the list above can be left blank, so you don’t need to make multiple records for each combination of Company Code, House Bank, Account ID, if your search string is really universal.

Then you specify the search string to be attempted by the EBS processing program. If your defined search string is found in the text, the rest of the table starts to work. First of all, you define which fields you want to populate or replace when the text is found in description of bank statement line item. These can be Posting rule, Cost Centre, Profit Centre, GL account, [Business] Partner and it’s type (vendor or customer) and some more. You also have an option to populate 3 fields in the posting not directly listed in the drop-down list. This gives you a lot of flexibility indeed, only limited by number 3. If you want to use these fields, you first need to define their names and then their values. You can also optionally restrict the use of the search string by debit or credit side in posting area 1 or 2. If you do not restrict, then field will be populated on both sides in all active posting areas.

And last in the list, but on the top of the importance hierarchy stands the configuration field “Prefix”. This prefix is used to add characters to the values produced by search string mapping. For example, prefix 0000000000 (ten zeroes) with search string mapping 123456 will produce output 0000123456. But what if the search string value itself is empty like we discussed few lines above? Then Prefix becomes the only value passed into the posting. This means that you do not need to populate the mapping value in the search string definition. The search string will only work as a trigger. The Prefix values are what will be really passed into the posting. This way, you can use the same search string for different purposes. Just one example: the same search string can be used to define batch input field and batch input value. Just leave the mapping blank and put field name and value right in the Prefix column of Search String Use configuration.

Finally, tick the checkbox “Active” to activate the search string.

So, we defined search strings with their mappings, and configured their use. What is next?

Next is moving changes from configuration to test client and uploading the test statement file. Did it work? Congratulations!

If you have more questions about the search strings for Electronic Bank Statement in SAP, why not ask SAP Expert?