on 2024 Jun 25 8:50 AM
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."
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.
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
MANUAL ASSIGNING THE RECIPIENT DOCUMENT
Thank you for all your answers.
Best regards,
Michal
Request clarification before answering.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As you can see on the message you are receiving on the payment:
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":
When running F110 and editing propostal the item with PM defined have the aggregate function automatically as you expect:
While the other, because of missing PM shows the same error message you received:
Try to set the payment term in the Customer Open Item and check the aggregation behaviour.
BR,
Gabriel Coleti
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Gabriel,
I checked PM at customer open item in BSEG and REGUP. Have the same values "K".
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
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.
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):
2nd consideration: check your Vendor Master Data Individual Payment Indicator:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
User | Count |
---|---|
10 | |
10 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.