Inside SAP F110: Exploring Payment Proposal Tables
When you run the automatic payment run in SAP, the system builds a payment proposal before anything actually moves money. Behind that proposal lies a set of database tables that hold everything from vendor balances to selected payment methods. Understanding SAP F110 Payment Proposal Tables is essential for anyone who needs to troubleshoot, customize, or simply trust the output of the payment run.
Why the Tables Matter in an F110 Run
The F110 transaction gathers open items, applies selection criteria, and finally writes the proposal to a few core tables. If one of those tables contains unexpected data, you might see duplicate payments, missing invoices, or an outright run‑time error. By knowing where the system stores each piece of information, you can trace problems without digging through endless logs.
Core Tables Behind the Proposal
- PAYR – Holds the header data for each payment proposal, such as the run ID, posting date, and total amount.
- PAYR_ITEM – Contains the line‑level details: vendor/customer account, invoice number, amount, and payment method code.
- PAYR_TAX – Stores tax‑related data that the proposal calculates, useful when you need to verify tax codes before posting.
- PAYR_DOC – Temporary storage for the generated accounting documents before they are posted to the GL.
- PAYR_LOG – A log table that records warnings and errors encountered during the run, giving you a quick audit trail.
These tables are populated in a specific order, and each depends on configuration settings in the payment program (transaction OBPM1) and the master data of the business partners involved.
Step‑by‑Step: How F110 Fills the Tables
1. Selection Phase – The system reads open items from BSID (customer) or BSEG (vendor) and places the qualifying rows into a work buffer.
2. Proposal Creation – Using the criteria defined in the payment run (payment methods, bank selection, due date, etc.), F110 writes a header record to PAYR and corresponding line items to PAYR_ITEM.
3. Tax Calculation – If tax codes are relevant, the engine calculates tax amounts and stores them in PAYR_TAX. This step is optional and controlled by the tax procedure assigned to the vendor/customer.
4. Document Generation – Before the actual posting, tentative accounting entries are written to PAYR_DOC. This gives you a chance to preview the impact on the GL.
5. Logging – Any inconsistencies—such as missing bank details or blocked accounts—are recorded in PAYR_LOG. The run can still finish, but you’ll see warnings that need attention.
Customizing the Tables for Your Business Needs
Out of the box, the tables carry only the fields SAP deems essential. However, you can add custom fields via Append Structures (using transaction SE11) without breaking the standard flow. A common enhancement is to append a “Cost Center” field to PAYR_ITEM so that each payment can be traced back to a department for internal reporting.
When you add a field, remember to adjust the corresponding screen layout (transaction SE51) and, if you need it in the payment proposal printout, modify the SmartForm or Adobe Form that renders the proposal.
Typical Issues and How to Diagnose Them
Duplicate Payments – Often stem from stale entries in PAYR_ITEM. Check the run ID in PAYR and delete any orphaned rows before re‑executing the run.
Missing Vendor Bank Details – The log entry in PAYR_LOG will mention “Bank data not found.” Verify the vendor master record (transaction XK02) and ensure the bank key matches the bank master (transaction FI12).
Tax Mismatches – If the tax amount in PAYR_TAX differs from expectations, review the tax code assignment and the tax procedure configuration in transaction FTXP.
Best Practices for Maintaining Clean Proposal Data
- Archive old payment runs regularly; tables can grow large and affect performance.
- Use transaction SE14 to check table size and set up a periodic job that deletes entries older than a defined threshold.
- Implement a simple ABAP report that flags items in PAYR_ITEM without a matching header in PAYR. This catches orphaned records early.
- Document any custom Append Structures in a change request, so future upgrades don’t overwrite them.
FAQ
What is the difference between PAYR and PAYR_ITEM?
PAYR stores one row per payment run (the header), while PAYR_ITEM holds every individual invoice or credit memo that the run proposes to pay.
Can I run F110 without generating entries in PAYR_DOC?
Yes. If you stop the process after the proposal phase (using the “Display Proposal” option), the system never creates the temporary accounting documents in PAYR_DOC. This is useful for a dry‑run check.
How do I delete a failed payment run?
Identify the run ID in PAYR, then issue a DELETE statement against PAYR, PAYR_ITEM, PAYR_TAX, and PAYR_LOG for that ID. Always back up the tables first.
Is it safe to modify the structure of PAYR_TAX?
Modifying standard tables is discouraged. Instead, add an Append Structure to keep SAP‑supported upgrades intact.