PS_PAYMENT， the data sits in tables PS_DEPOSIT_CONTROL， the worksheet data gets into table PS_PAYMENT_ITEM. When you are applying the payment， you would see the activity on the PS_ITEM table and the PAYMENT_STATUS changes to C (Complete). Now what could have gone wrong in your case is that the PAYMENT_STATUS was changed to C but the payment was not posted to PS_ITEM table. I am not sure how this could have happened!! The best way to debug the problem would be to look into the following tables for more information on this payment: Check if there are any rows for this payment in PS_PAYMENT_ITEM table. This might help us understand how payment was applied. There should a field called GROUP_ID on the PS_PAYMENT table. Take this group ID and check the status of this group from PS_GROUP_CONTROL table. For the above group， PS_PAYMENT_ID_ITEM and PS_PAYMENT_ID_CUST. The status of the payment would be I (Identified) or U (Unidentified) based on whether you have the reference information or not. The data from this table should be available always for reference. Payment Predictor proess uses this data to create worksheets. When you create a worksheet， the PAYMENT_STATUS would be W (Worksheet) and once you have balanced the worksheet the status changes to A (Applied). RU picks up all payments with status A and transfers data from PS_PAYMENT_ITEM into PS_PENDING_ITEM table. Once the payment is posted， The main tables involved in the Payment processing are as follows: When you enter the payments，。
check the status of the Items in the PS_PENDING_ITEM table. The flag that you can look into is ERROR_FLAG. You can get the translate values of this flag from App Designer. Check if this payment had any activity associated with it. You can check this from PS_ITEM_ACTIVITY table. You can also check this from the “Item Activity from Payment” page. Let me know how these checks go and it might help is understand the problem better. 。