cancel
Showing results for 
Search instead for 
Did you mean: 

F110 Grouping of open items in proposal

subhadeep_das
Contributor
0 Kudos

Hi

Our customer invoice creation triggers from external system which posts the document through bapi. Problem is for each material, system is posting one open item per invoice. As a result, if in one invoice there are 10 material, then under one FI document, system is posting 10 open items with posting key 01.

The impact is coming in F110 run. It is taking a good 7 hours to process the entire list of customers, I can see for each customer , when I go inside the proposal, 10 items with same fi document numbers are appearing. is there a way to consolidate this ? F110 is by default grouping the customer, but inside the customer, can i also group the invoices which have the same document number /reference number ?

Br....Subha

Accepted Solutions (0)

Answers (1)

Answers (1)

Bohdan
Active Contributor
0 Kudos

Hi suvodip78,

I'd say that you approach this problem from the wrong side. Instead of addressing the cause of the problem, you try to address its symptoms. What I mean: it is not a best practice to post a vendor invoice with multiple line items in this way via BAPI. Vendor items should be aggregated and posted as one line item. You should focus your attention on this cause. Once you resolve it, you will address multiple (performance) problems including:

- performance problem & usability of the line item reports (FBL1N). I guess if you have numerous vendor line items for each invoice, you have too much items in the FBL1N and do not even have a good overview of the amounts associated with each invoice. From my experience a few thousand line items in this report are already slowing it down considerably.

- performance issues in the payment program. Well you described it yourselves.

So instead of trying to fix the symptom, look closer to the cause of the problem and try to fix it. To be honest, I do not see any reason why a business would like to have one vendor item for each material procured. I also think it was not a solution by design, but a solution delivered by someone who does not particularly understand how the BAPI works.

P.S. Otherwise, if you still want to go via F110 enhancement, please check out the OSS note 3273670 - Automatic Payment Program. It has a separate chapter on the grouping of the line items in the payment program. But I'd not expect a big performance improvements, because if you have 100000 items to process, it does not really matter how good you aggregate them. The program still has to analyze all of these 100000 items separately and write the results in the DB-table (i.e. REGUP).

Hope that will help you !

Regards,

Bohdan

subhadeep_das
Contributor
0 Kudos

Hi Bohdan,

You are right, while we are targeting the problem at its source where its generating the item, I am also trying to look at alternatives in terms of how we can efficiently group (or not group it at all) the items at proposal level and see if any reduction in processing time.

Best regds

Subha

Bohdan
Active Contributor
0 Kudos

Hi Subha,

I've simulated some examples in my demo system and posted one vendor invoice with 4 items. See the screenshot below. The first screenshot shows the case without aggregation: in this case, each line of the vendor invoice will be paid separately. The second screenshot shows the aggregation on vendor level i.e. in this case, the program can generate one group payment that includes all vendor invoices (and their line items) which are payable on a payment date. But when you drill down to this item in payment proposal, you will still see each item of the vendor invoice (i.e. invoices) and as I mentioned in my previous mail the program still has to select all those line items, analyze them, write the results to the database etc. All of that represents the huge performance load.

There is no way to aggregate the payments further than on a vendor level. Therefore, if your payments are already aggregated this way, you will not be able to introduce higher aggregation / better performance.

P.S. I was referring all the time to vendors, but it works the same with customers. I assume you use direct debits as a payment procedure.

Bohdan
Active Contributor
0 Kudos

Finally, I'd like to add a few suggestions as to potential solutions.

1) Preferable solution is to introduce the aggregation during posting of the customer invoice via BAPI. This way you solve the root cause.

2) If the previous approach does not work, I'd suggest an alternative solution. Develop a small custom program that would run in background on a daily basis. It will process all customer invoices and will post the equivalent transfer posting with clearing (e.g. as in FB05). What I mean by that: you have a customer invoice with 10 line items. The program will post a clearing document that will clear these 10 items (credit posting) and introduce a new line item (debit posting) for the total amount. As a result: you get rid of 10 items and receive one customer open item which will be processed by the payment program without performance implications.

3) You can check other variations of the custom functionality: e.g. custom program that will analyze the customer invoices & generate payment requests for total amount of each customer invoice and these requests will be processed by F111. But eventually, it is more complicated option, because apart from that, you will need to think about clearing of the resulting payments with original customer invoices.

4) Check out about the performance issue with SAP via OSS-note. Maybe they can suggest some performance tips.

Regards,

Bohdan