cancel
Showing results for 
Search instead for 
Did you mean: 

F110 Aggregation of open items after editing proposal

mmklodz
Explorer
0 Kudos
217

Hi all,

I have set up recipient settlement with the supplier. The functionality is generally working correctly. When I generate a payment proposal, all documents are aggregated and included in one payment - this is functioning correctly.

If a document is blocked for payment, the position will not be paid.
We can see that the recipient and supplier positions have been properly offset.
344.69 - 54,339.00 - 2,208.34 = -56,202.65."

mmklodz_2-1719301220178.png

mmklodz_3-1719301242090.png

In such a situation, the user who is processing the payment enters the payment proposal editing mode and has the ability to remove the block.

mmklodz_4-1719301321031.png

HERE MY PROBLEM ARISES

Edited supplier positions from which the block has been removed automatically enter the payment. Unfortunately, the recipient document, which was not blocked, needs to be manually assigned to the payment.

Since we have implemented more precise control and block more positions during the proposal generation, the work takes longer, and there are often multiple recipient invoices that require assignment. Only after the assignment is done, the positions are linked together.

Is it possible to automatically aggregate these positions after removing the block, in order to avoid manual assignment?

AFTER REMOVING THE BLOCK

mmklodz_5-1719301469313.png

MANUAL ASSIGNING THE RECIPIENT DOCUMENT

mmklodz_6-1719301531412.png

mmklodz_7-1719301545944.png

Thank you for all your answers.

Best regards,

Michal

 





Accepted Solutions (0)

Answers (3)

Answers (3)

coleti
Active Contributor
0 Kudos

Now, try to remove the Grouping Key in the Vendor Master. The grouping key is used in cases where you do not want all the open items of a customer or a vendor to be paid together but rather you want only those items which belong together to be grouped into a single payment. A maximum of three fields from the open items are defined for every grouping key; the contents of these fields must correspond in order that the open items can be paid together.

 

coleti_0-1719486940164.png

 

mmklodz
Explorer
0 Kudos

Dear Gabriel,

I can call it semi success. Thank you.

When I cleared grouping field then after proposal run the vendor and customer documents were compensated. But if all vendor documents are blocked and I unblock one of them then I still need to manually assign customer invoice. 

BR, 

Michal

coleti
Active Contributor
0 Kudos
Wow... nice... in my case, if I change the Pmnt Block in the proposal, it´s automatically aggregated. It's related to the Payment Method Determination, you should consider that. The aggregation will be done automatically with items sharing same Payment Method. Grouping Key 01 was one of the issues that prevent automatically aggregation from different document types. Vendor and Customer Open Item Payment Method should be determined to make that work. Actually, the users I have, they don´t use proposal changing functions... they prefer to use FBL1N and FBL5N because of the massive change document option. So, they usually prepare the open items first using these two transactions removing payment block and defining payment terms... then they run F110. If any inconsistence, they back to FBL1N or FBL5N, adjust and delete the proposal running again.... this is their routine.
coleti
Active Contributor
0 Kudos

As you can see on the message you are receiving on the payment:

coleti_0-1719413135723.png

I could simulate same behavior in my system and the main reason is because the Customer Open Item don´t have the Payment Term defined... because of that, the F110 does know where to aggregate that open. Check below, I replicate your issue having 1 customer open item with PM "U" defined and other without PM "U":

coleti_2-1719421481996.png

When running F110 and editing propostal the item with PM defined have the aggregate function automatically as you expect:

 

coleti_3-1719422121422.png

 

While the other, because of missing PM shows the same error message you received:

 

coleti_4-1719422188483.png

Try to set the payment term in the Customer Open Item and check the aggregation behaviour.

 

BR,

 

Gabriel Coleti

 

 

 

 

 

 

mmklodz
Explorer
0 Kudos

Hello Gabriel,

I checked PM at customer open item in BSEG and REGUP. Have the same values "K". 

mmklodz_0-1719468598220.png

Again after change of the block for vendor open item I have same situation.
I think it is problem with this debit balance like you said. 

"No pymt possible because items with a debit
bal.still exist; see job log"x

mmklodz_1-1719468654753.png
I did a little bit different test.
Now I have one unblocked document for vendor in the amount 2 208,34-
one blocked document for vendor in the amount 54 339,00-
one for customer 344,69.

I dont know why he connect customer invoice with blocked document when in the payment is vendor open item with higher amount. 

mmklodz_2-1719469008772.png

mmklodz_4-1719469080763.png

 

 

coleti
Active Contributor
0 Kudos

Dear Michal, 

There are some consideration that you should took into account. Actually, the configuration that will perform the automatic aggregation depends on the Payment Methods and the Vendor Master Data.

I could see on your print screens that your open items don´t have Payment Methods defined, so maybe it will automatically defined by the Vendor Master Data during your payment proposal.

 

1st consideration: make sure the payment method choosen in the proposal for your open item is well configured to avoid single payment(FBZP - Payment Methods in Company Code):

coleti_0-1719315744954.png

 

2nd consideration: check your Vendor Master Data Individual Payment Indicator:

coleti_1-1719315946664.png

If this indicator is set, every customer/vendor open item is paid separately during automatic payment transactions. This means that open items are not grouped together for payment.

 

I hope this could help you on that. Anyway the aggregation will automatically set if these considerations allow grouping items and not individual payment.

 

BR,

 

Gabriel Coleti

 

 

 

 

 

 

 

mmklodz
Explorer
0 Kudos

Thank you for your tips.

I checked configuration and vendor md. It looks ok. 
Proposal works the same. 

mmklodz_0-1719321309487.png

mmklodz_1-1719321418731.png

The more I read about it, the more I have a strong feeling that this is the correct behavior of SAP and cannot be changed with standard configuration.

Michal

coleti
Active Contributor
0 Kudos
On your Vendor Master Data we have defined only Payment Method "C" and in the configuration FBZP you are sharing payment method "K". As I could see, you open item also don´t have payment method defined... so it´s a problem. You should have specfied in the Open Item, the Payment Method or in the Vendor Master because the aggregation logic is done as per payment method. In this case, during the proposal run, neither Vendor nor Open Item is setting the proper payment method "K". That will generating a manual task from your users to reallocate this in the proposal.
mmklodz
Explorer
0 Kudos

I dont believe that this is the issue but lets try, this is the SAP. 

Like you can see before all changes in the first run of proposal SAP aggregate document correctly. 
It looks like SAP don't repeat aggregation on edit mode.

I changed payment method on customer and vendor MD also for documents.
first run of proposal is correct, after edit payment block behavior of the system is the same. 

mmklodz_1-1719387230306.png

mmklodz_2-1719387429274.png