Why not 1) special G/L ID with different reconciliation account?
lg
lg
Reply: 6
Auto translated
BP - various reconciliation accounts for a customer or vendor.
Hello all,
does anyone have an idea or even experience how to map the following (attention, now it's getting extensive):
The BP is created with the normal customer/vendor roles (FI Vendor, FI Customer, etc.). It is part of the daily business that now e.g. a vendor has several reconciliation accounts, e.g. an employee has a payable account for the reimbursement of travel expenses, but also one for "normal" deliveries and services, because he is also managed e.g. as a landlord of living space. Up to now we had created such cases twice with different account groups and also reconciliation accounts. Now we want to avoid duplicates in the customer/vendor master data.
I am currently collecting ideas on how to handle such cases (there are various constellations) in HANA.
1) Special G/L indicator --> I know, works theoretically, in practice rather cumbersome, since in various locations is posted and there is a lack of transparency.
2) alternative reconciliation account --> I have only heard of it, but I don't have any experience with it, it might be difficult to implement it on a daily basis for the same reasons as above --> it should theoretically be possible to have more than 2 different reconciliation accounts per customer/vendor account.
3) The external consultant suggested to create different FI roles, since the reconciliation account is defined per role and BuKr --> was my favorite for a while, but when creating the more detailed concept, I reach the limits of my mental imagination, especially how to define which role to post to in the end. Another suggestion from her was to then assign different customer vendor numbers per role, so that the BP number, continues to be used for the trade payables (BP 10010001, but the travel expenses then the vendor number for the FI role travel expenses Kred.No. 10010001RK) is stored.
Theoretically this made sense, but I have no idea if this will work in practice.
Unfortunately our test system doesn't work yet so I could test anything here. Since the other workstreams are also affected by the BP settings, I would like to know if anyone has dealt with this issue and can give me some tips, including how it works in practice, or how best to test something like this.
Many thanks in advance.
Ulrike
does anyone have an idea or even experience how to map the following (attention, now it's getting extensive):
The BP is created with the normal customer/vendor roles (FI Vendor, FI Customer, etc.). It is part of the daily business that now e.g. a vendor has several reconciliation accounts, e.g. an employee has a payable account for the reimbursement of travel expenses, but also one for "normal" deliveries and services, because he is also managed e.g. as a landlord of living space. Up to now we had created such cases twice with different account groups and also reconciliation accounts. Now we want to avoid duplicates in the customer/vendor master data.
I am currently collecting ideas on how to handle such cases (there are various constellations) in HANA.
1) Special G/L indicator --> I know, works theoretically, in practice rather cumbersome, since in various locations is posted and there is a lack of transparency.
2) alternative reconciliation account --> I have only heard of it, but I don't have any experience with it, it might be difficult to implement it on a daily basis for the same reasons as above --> it should theoretically be possible to have more than 2 different reconciliation accounts per customer/vendor account.
3) The external consultant suggested to create different FI roles, since the reconciliation account is defined per role and BuKr --> was my favorite for a while, but when creating the more detailed concept, I reach the limits of my mental imagination, especially how to define which role to post to in the end. Another suggestion from her was to then assign different customer vendor numbers per role, so that the BP number, continues to be used for the trade payables (BP 10010001, but the travel expenses then the vendor number for the FI role travel expenses Kred.No. 10010001RK) is stored.
Theoretically this made sense, but I have no idea if this will work in practice.
Unfortunately our test system doesn't work yet so I could test anything here. Since the other workstreams are also affected by the BP settings, I would like to know if anyone has dealt with this issue and can give me some tips, including how it works in practice, or how best to test something like this.
Many thanks in advance.
Ulrike
CommercialTRUST.EXCELLENCE.PEOPLEErfahren und agil. Nicht auf dem Sprung, sondern verlässlich an Ihrer Seite.!!
You must be logged in to post a reply.
6 Answers
- Thank you for the answer. That's what it will probably come down to, if I do not find a better alternative. Since that would then be a whole lot of additional SHB license plates, I had been looking for other alternatives.
- Hello,
You can open the reconciliation account and overwrite it when posting. But then you have to insert a validation, because otherwise it will certainly be posted incorrectly.
Kessi - Thank you very much! I haven't heard anything about this yet, but I'll discuss it with IT.
- Hello Ulrike,
what did you do in the end? What was your solution?
Thanks and greetings,
TinaB - Hello Ulrike,
I am a SAP FI consultant and have been dealing with issue for years, as many of my customers have the problem with multiple reconciliation accounts for customers / vendors. Unfortunately, the business partner does not solve the problem, unless you have FI-CA (Contract Accounts Receivable and Payable), because FI-AR/FI-AP still needs the customer/vendor master records, and there, as before, only one reconciliation account can be stored per master record.
SAP already provided the solution with the deviating reconciliation account years ago. Here, it is defined in Customizing which reconciliation account may be changed and which reconciliation accounts may be used instead. In the G/L account master of these reconciliation accounts stored in Customizing, the field "Reconciliation account ready for input" must then be selected. This then allows the user to change the reconciliation account when posting. The disadvantage here is that the user must remember when posting that he may have to change the reconciliation account in the posting. This can of course lead to postings to the wrong reconciliation account, since SAP then uses the reconciliation account from the master record. So you would have to include a message here, which informs the user that he has to check the reconciliation account. The message is not an SAP standard. To be honest, so far I have not been able to get any of my customers excited about it.
Then to your external consultant's ideas. They can't work. Another role does not lead to another customer / vendor master record being created via the CVI. There is always a 1:1 relationship between BP and customer/vendor master record, because the derivation of the FI account group in the CVI is not done via the BP role but via the business partner grouping. The same is true for the number range, this also depends on the business partner grouping in the BP and in the CVI there is again only the 1:1 relationship between BP grouping and account group. In addition, a BP grouping assigned in BP can no longer be changed in the BP master record.
SAP has delivered a new function Multi Assigment with S/4HANA 1709. This makes it possible to create several customers/vendors for one BP. But before I now describe the function further, short note. I have received the information that SAP does not want to/will not continue to support the Multi Assignment. If this is really the case, and if this refers only to SAP MDG, I will find out only in the middle of August. But somehow I can't imagine that SAP will take out a relatively new S/4 development for FI so quickly. If so, I can only hope that there will be an alternative solution, otherwise we really have to create several business partners for customers or vendors with multiple reconciliation accounts and that contradicts the business partner principle.
Now, however, still briefly described the Multi Assigment. With this function, the business partner is first created in its customer/vendor (FLCU00/FLCU01) or vendor/vendor (FLVN00/FLVN01) roller and the corresponding customer or vendor is created via the CVI. Then there are two new FIORI APPs "Create/Change/Display Customer" and "Create/Change/Display Vendor". These two APPs can then be used to create the other customers or vendors with the different reconciliation accounts. This function uses tables from the MDG to link the business partner with the other debtors or creditors. It has been tested and it works.
To use the function the following has to be considered. The customizing for the Multi Assigment must be set up under the customizing of the master data synchronization. The account groups selected via the new FIORI APPs Customer/Supplier must have a different number range than the account group derived via the CVI. Number equality between BP and Customer/Vendor must not be selected, but variable grouping must be selected to open the Account Group field for entry in the Customer/Vendor APPS.
I hope this helps you for now.
Many greetings
Gitti
Matching learning content
Release: Feb 7, 2025
A Practical Guide to Advanced Payment Management with In-House Banking
Mary LoughranPraveen Gupta
- Introduction to SAP advanced payment management
- Advanced payment management and in-house banking supported scenarios
- Confi guration and master data setup in both SAP S/4HANA Cloud Private Edition (PCE) and Public Cloud
- Accounting entries, helpful apps, transaction codes, authorization objects, and security roles
Release: Oct 29, 2020
A Practical Guide to Accounts Payable in SAP S/4HANA Fiori
Oona Flanagan
- Introduction to SAP S/4HANA and Fiori
- Organizational structure and master data
- Purchase-to-pay process, invoice and credit note posting, and the GR/IR reconciliation
- Payments and closing and reporting
Release: Aug 20, 2021
A Practical Guide to the General Ledger in SAP S/4HANA Fiori
Oona Flanagan
- Organizational structure and master data essentials
- General Ledger basics including document splitting and document types
- Key transactions from journal entries to intercompany postings
- Closing tasks and reporting