Payments in SAP is a very important topic. Most often these are payments made to vendors. There are multiple ways how you can pay vendors in SAP using invoices or down payment requests.
Some special cases require you to make payments without an invoice, and Payment Requests become handy in these cases. If these are one-off payments, you can create and approve payment request, like discussed in this article.
There are also some types of payments that need to be done the same way from time to time. Say, money transfers between the banks. Of course, you can still create individual payment requests for each of them, but there is another tool that simplifies the business process and reduces the possibility of making an error, for example a typo. This tool is called Repetitive Codes. Let’s see how these are set up in SAP.
Setting up payment methods
Of course, you need to start with setting up payment methods in the country and in the Company Code – same way as for regular vendor payments. Just to mention that if you are going to use BCM (Bank Communication Manager) for the approval process, you still need to assign a PMW (Payment medium workbench) file generation tool to the payment method in question.
You may wish to set
up separate payment methods for repetitive payments and for regular
vendor payments, but that is just an option, not a requirement.
Setting up GL account determination for outgoing part
There is a special
place in SAP IMG (Implementation Guide) where you need to set up GL
account assignment for your payment methods that will be used for
Repetitive Payments with Payment requests. This is done in IMG node
Financial Accounting (New)
Bank Clearing Account Determination
Define Account Determination
You also need to check that configuration of the GL account assignment is consistent for Payment Requests and for vendor payments. There is an IMG node located just next to the IMG node mentioned above. Report RFFMB001 does the same check too.
There are some other
configuration transaction located near the node above. Check if they
are relevant to your case, for example you may need to define number
Setting up GL account determination for incoming part
When you do a bank
to bank transfer you need to set up offsetting GL account for the
accounting posting, for example clearing account for incoming
payments on recipient bank. This is done in IMG node
Financial Accounting (New)
Define Clearing Accts for Receiving Bank for Acct. Transfer
Setting up Repetitive codes
The final part of
setting up the process is a definition of Repetitive Codes for
payments. This is done in transaction OT81.
Here you set up
payer and payee parts of the bank to bank transfer, assign payment
currency and payment method, and even assign the bank chain if
If you populate Reference Text field there, you remember that asterisk in the first position will allow you to copy the text to the accounting document and also to the payment file. You can read more about automatic field copying in a separate article by SAP Expert.
You can set up
groups of repetitive codes too, if you want to use this feature.
Repetitive Codes should be created in each client individually, they are not a part of SAP transport system.
Do not forget to
release the Repetitive Code, otherwise you will not be able to use it
in the process.
Optional BCM configuration
If you are going to use the approval cycle in Bank Communication Management for your repetitive payments, you need to define payment run IDs as relevant to BCM. Run transaction OBPM5, and use the FI-BL button there to create a list of relevant run IDs.
Creation of payment requests
When all the configuration is done, you need to test your scenarios. Start from creation of payment requests in transaction FRFT_B. Put your filtering criteria in the Selection Condition part of the screen, for example Company Code or grouping parameter. You can leave filter empty to see the full list of existing repetitive codes.
Populate posting date for payment request and for payment run (if you are going to run it directly from FRFT_B), and then put the amount of your bank to bank transfer payment request in the corresponding field.
Pressing the Create
Payment Request button will do exactly the same: payment request will
be saved in the system. It will appear in the lower part of the
screen. You still need to release it for payment using the buttons
If you want to create payment straight from FRFT_B, you can still do so using the Pay button. But remember that payment run ID generated by automatic process may not be the same as assigned to BCM approval configuration. It may also be a good idea to separate steps for the segregation of duties purposes. Otherwise you can define your own Payment Run ID in the following step.
Payment program F111.
If you run payment program separately, you need to use transaction F111 (not F110) to process payment requests.
The general idea of F110 and F111 use is very similar, although the screens and buttons may look slightly different. I will not discuss the functionality of F111 here, but I’ll only mention that if you want to limit the selection of data by certain payment request ID, you can do so in Dynamic Selections. There is a special field Key Number in the section Payment Requests.
Once you finish with
payment run and BCM approval cycle, your payment file will be created
ready to transfer to the bank.
Now you want to test that the payment process will work as
expected and that integration with the bank is reliable. There are several
steps of testing you should undertake.
1. Unit testing
Unit testing is usually done in the special Testing client of
Development system. You extract the payment medium file to your local computer
and validate it against specifications received from the bank or payment
bureau. If you find errors, you fix them straight away and validate again.
Once you are happy with the results of your own validation,
you can send the file to your bank and ask them to run their own validation. They
often have a special tool to test payment files without making actual payments.
This may lead to other changes in the file and more test iterations.
If you plan to deliver the files to the bank using some
automatic solutions, for example SAP PI, you need to configure and test the
connection too. You may run these tests on dummy files, or you can start exchanging
SAP-generated payment files already.
2. System integration testing
System integration testing is done in Quality Assurance
In this test, your main topic is to validate the full flow of information from invoice to the bank and back. This is the first time when you need to test the fully automated process as intended to be in Production. No manual workarounds for file generation, for file delivery and so on.
If you plan to use Bank Communication Manager (BCM) in your solution, here you need to validate that bank sends you proper Acknowledgement files for your test payments. Of course, subject to the bank’s ability to provide you test environment with necessary functionality.
3. User acceptance testing
User acceptance testing is done in Quality Assurance system,
same as SIT that we discussed above. The difference between SIT and UAT is in
testers. SIT is done by consultants preparing the solution. UAT is done by a team
of users from customer side. Quiet often this is the first time when users see
the developed solution, so prepare yourself for additional questions,
challenges and work. Training, training and once again training – that is what
UAT is about.
4. Penny value testing
Penny value testing is done in Production system. It can
have other names: Smoke testing, Small value testing and so on. This time you
make real payments with real money from real bank account paying real invoices.
To minimize the risk, usually two approaches are used:
Payments are done between your own accounts or at least within your group of companies (intercompany). If not, choose a vendor with good relationships so you can avoid long arguments if something goes wrong.
Select small invoices to pay. You do not want to risk big money if something goes wrong.
It is very likely that PVT will be the first time when you see the Bank Statement reflecting your payments made the new way. This means that some changes in the EBS configuration can be required.
Of course, you need to move all your transports into Production system before you start PVT. But you may wish to postpone mass master data change until after the PVT – just a handful of vendors / banks would suffice the PVT purposes. Once you have a confirmation of successful PVT, you may start mass changes of your master data. This is already a part of Cutover activities, which we will discuss separately.
Successful result of PVT is a mandatory requirement before
the system go-live.
Remember that badly tested solution is always a big headache for consultants and for the customer. But badly tested payment solution is worse: it may lead to loss of money and spoiled reputation.
SAP HANA is a database that is not only a technology behind S/4 HANA, C/4 HANA and other SAP systems. The database may be a powerhouse for many other applications.
When you have multiple databases for different applications, sooner rather than later you will face a requirement to replicate data between them. SAP already has a tool for that called SDI, short for Smart Data Integration.
SAP Expert will not write a lot about that tool today, but rather pass the mic to a specialist in the area who already prepared separate blog on this topic.
We live in the era of data, digital data to be precise. That’s why old and outdated approaches are going, and new approaches are leading their way to the top of the hype.
Many may see SAP as
an old company, which has 40+ years of experience in ERP market. But
still, SAP changes. You can see it in the product range. You can see
it in the pricing policies.
Nobody is surprised now when SAP builds its pricing policy on data consumed, processed and stored in the system, rather than by an outdated “user” or “time consumption” methodology. SAP users are paying their license fees by number of sales order line items, by turnover gone through Treasury module, and so on.
It comes to no surprise that SAP is also changing the way how consulting works are charged. Are you a consultant working for a customer? How are you charging your customer? By hour or by day? That is yesterday’s methodology. Do you have a fix-price deal? That is last century! Forget about that!
New recommendations by SAP is to charge the customers by volume of work the consultant does, and it can be measured by strict system tools. Let’s have a look at some of these recommendations:
Charge by the line of ABAP code produced. Every single line counts, except for comments starting with an asterisk (*) sign. Yes, if you comment by the old statement trick “IF 1=2.” your work still counts as chargeable. But any comments with * should be dropped as a waste of time and money. At the end of the day, who does need comments in ABAP?
Charge by the table entry you put in the transport. Every record counts, except for table T001, because creation of Company Codes is a too rare process anyway. It does not matter if you deleted the record afterwards, and they are not going to be transported anywhere. As long as it is in the transport, it is chargeable.
Same as above for FICO consultants, you should be charging by records in the transport. The only exception here are condition records. They are charged as double price. The condition records with user-exits in them are charged as triple price. You can see that having these conditions not only allow you to charge customers more for yourself, but also creates work for ABAPers. No matter if a standard condition can be used instead. Create a new one and earn money!
Once you charged the customer and got the payment, it will be a time to relax and have some well-deserved rest. SAP Expert already gave you an idea.
It is an interesting concept, isn’t it? Do you want to learn more – read here.
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
SAP Business Partners configuration in IMG
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
Ranges and Groupings’ it’s important to setup correct number
ranges. I prefer to use internal number ranges.
BP and HR integration
Here we can setup
HR Employees and Org units integration with SAP BPs. Go to ‘Activate
Integration’ and make switches look like this.
BP number ranges
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.
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.
Employee Business Partner
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.
There has also been a long and interesting interview with Tanya, where she speaks about SAP, career and travel.
Today I am happy to introduce you to yet another book, where Tanya is now a co-author. This book should be a best-seller among SAP Finance consultants, because this is an introduction to SAP Finance in S/4HANA, the next generation of ERP systems from SAP SE.
The year 2018 is now over. We celebrated and congratulated each other.
Let’s now see what it meant to SAP Expert.
There were 15 new articles published in 2018 altogether. Is it interesting to see which of them was the most interesting, which one was the best, which one attracted the most readers? Let me open that secret to you!
The year 2018 comes to the end. Clocks are ticking, and Christmas and New Year are just around the corner. Time to concentrate on closing all important projects and tasks for this year. Time to build plans for the new year 2019. Time to relax, reflect and revisit what has been achieved.
It was a nice and busy year for myself. A year of changes, a year of travel, a year of success. And let’s not remember the dark clouds, let them go!
2019 will bring us even more fun, even more interesting challenges, even more love! I promise!
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.
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?
Everyone knows that simple rule of the market: the price is determined by the balance of supply and demand.
When there’s too much supply, the prices fall until there’s not enough incentive for sellers to provide the resources.
And on the opposite, if there’s unmatched demand, the supply is growing to balance it off, because more sellers find the prices profitable enough. Of course, it only happens when there are enough resources. But what happens if resources are limited, either naturally or artificially? Then it will be either a growth in the prices, or demand will not meet any supply at all.
The same rule applies to the market of SAP consultants labour.
The big markets for SAP consulting are known: United Kingdom, Germany, The Netherlands, Belgium, Australia, USA, Canada, UAE, Saudi, India etc. They all have very steady demand for SAP resources, and the supply there is also very strong, supported by both local and borrowed resources. The latter includes people coming from other countries either on-site or on remote off-shore and near-shore basis.
But what happens with smaller countries like New Zealand, Cyprus, Dominican Republic and so on? They also have some footprint in the SAP world, but much smaller than giants. It also means that the supply of the SAP resources in these countries is much weaker. Once the limits are reached, companies in these countries need to ask for external resources to come. And here we hit another problem linked to the size of the countries: not many people want to relocate there simply because they are too small. Not only cultural life in these countries is different to the bigger ones, but also career development is different. There are too many chances that once you arrive there for a permanent position, you’ll be limited in the options to change the employer in the future.
This makes the hiring of resources in these smaller countries much more difficult compared to the bigger ones.
Just an example, a friend of mine was looking for a BW / BO consultant for a permanent role in Cyprus for about 6 months. There was even a post about this on job.sapexpert.co.uk. And he is still looking! Would that be thinkable in the United Kingdom or Germany? Unlikely, me thinks.
What do you think about perspectives of working in a small country?
By the way, if you are interested in the details of that job, pleas contact SAP Expert at firstname.lastname@example.org.