Deploying Digital Supplier Network Series – best practices part 2
Troubleshooting issues related to Payment Proposal outbound message:
Payment proposal is a message sent from backend system of a customer to Ariba Network.
It serves a purpose of notifying vendor about the date of his invoice to be paid.
It shows up for the vendor as scheduled payment date, it is usually based on payment run scheduled date. What payment run invoice should go to is based usually on baseline date and payment terms calculation outcome.
Thank to this functionality, Vendor knows when the money will appear on his bank account. Supplier can plan better, and by staying informed about their cashflow, vendor does not trouble accounts payables with inquiries about the status of the invoice.
While configuring this functionality in Cloud Integration Gateway add-on. The issue we faced in our project occurred during the execution of program: ARBCIG_PAYMENTPROPOSAL_EXPORT.
Program executed without errors – but no records got picked up. This caused invoices to get updated with scheduled dates.
Upon closer inspection, we noticed that when a supplier submits an invoice and that very invoice gets Parked in the SAP system. The value “bktxt” is populated as ARIBA_ASN
And while posting the invoice and accounting (MM) documents are created value does not get pushed
Because of the missing value, supplier is not notified about scheduled payments:
When program ARBCIG_PAYMENTPROPOSAL_EXPORT runs it picks no records because it has a filter set to retrieve only records only with ARIBA_ASN value.
To address this problem, a small program is needed to fetch the value and get it populated (Ex : Attached below bapi written to populate the value).
F sy-tcode EQ 'J_1IG_INV' OR sy-tcode EQ 'MIRO' OR sy-tcode EQ 'MIR4' OR sy-tcode EQ 'MIR7' OR sy-cprog = 'ZFI_FB01_BAPI' OR sy-cprog = 'ZFI_VCGLBAL'. ex_document-header-bktxt = im_document-header-bktxt. ENDIF.
Thanks to that, invoice shows scheduled payment date correctly:
Sometimes even if unit tests and all procedures finish successfully and without errors, the output may be incorrect.
Therefore, best practice when running such unit tests is to write down expected number of records to be processed and expected outcome.
After execution of unit tests, expectation needs to be compared with actual output.