Problem Description
I encountered this problem when AR closed the account. The root cause is that the user entered another credit invoice, did a write-off, and later canceled the write-off, did not create accounting entries, did not transfer the general ledger, and did not want this credit The invoice was issued, but the front desk could not delete it, so it was backed up and deleted in the background, and the following tables were deleted:
--事务头
DELETE FROM ra_customer_trx_all trx
WHERE trx.customer_trx_id = 871860;
--事务行
DELETE FROM ra_customer_trx_lines_all l
WHERE l.customer_trx_id = 871860;
--分配表
DELETE FROM ra_cust_trx_line_gl_dist_all d
WHERE d.customer_trx_id = 871860
AND d.customer_trx_line_id IN (739451, 739452);
--子分类账事件表
DELETE FROM xla.xla_events xe
WHERE xe.event_id = 3129795;
--子分类账事务表
DELETE FROM xla.xla_transaction_entities xte
WHERE xte.entity_id = 2963232;
In fact, there are residual data in the following two tables:
payment plan table AR_PAYMENT_SCHEDULES_ALL
write-off table AR_RECEIVABLE_APPLICATIONS
I think the data in the transaction master table has been cleaned up, and the closing check report should not be checked later. After deleting, run the closing check report , Sure enough, it was not checked out, and the following error was reported when the account was closed:
problem analysis
So I ran the analysis program provided by Oracle: EBS Receivables Period Close Analyzer (Doc ID 2019636.1)
Two main effects were found:
- AR_RECEIVABLE_APPLICATIONS_ALL The write-off table has untransmitted general ledger data
- Missing data in AR_PAYMENT_SCHEDULES_ALL (the transaction master table has it, but the plan table does not)
The first problem is caused by the feeling that the data has not been cleaned up. It seems that the design of Oracle is indeed more rigorous, and no mistakes are allowed.
The second problem is that when making an invoice credit, the selected [transaction type] corresponding to the configuration [unsettled receivables] is not checked, as shown in the figure: after the credit is completed, there is no automatic payment in the AR_PAYMENT_SCHEDULES_ALL table
. The generated data eventually led to an error when the credit note was written off the invoice: FRM40738 Parameter 1 (the user's internal NAME_ID cannot be empty), as shown in the figure below:
problem solving
Question 1:
After backup, delete the data in the write-off table AR_RECEIVABLE_APPLICATIONS_ALL.
Question 2
Update the corresponding field in the ra_cust_trx_types_all table in the background from N to Y
to the payment schedule table AR_PAYMENT_SCHEDULES_ALL to supplement the data corresponding to the credit invoice.
After closing the account again after the above two steps, the account can be closed smoothly. Even if the original credit note cannot write off the invoice, it can also be written off.
Appendix: Related SQL
sql to check data integrity
select distinct ct.customer_trx_id, ct.trx_number, ct.trx_date
from ra_customer_trx_all ct ,
ra_cust_trx_types_all ctt ,
ra_cust_trx_line_gl_dist_all gld
where ct.cust_trx_type_id = ctt.cust_trx_type_id
and ctt.type in ('INV', 'DM', 'CM', 'CB')
AND ctt.org_id = ct.org_id
and ctt.accounting_affect_flag = 'Y'
and gld.customer_trx_id = ct.customer_trx_id
and ct.complete_flag = 'Y'
and gld.customer_trx_id = ct.customer_trx_id
and gld.account_class = 'REC'
and gld.account_set_flag = 'N'
and not exists
(select 'x'
from ar_payment_schedules_all ps
where ps.customer_trx_id = ct.customer_trx_id )
and gld.gl_date between to_date('01-APR-2023','DD-MON-YYYY') and
to_date('30-APR-2023','DD-MON-YYYY')
and gld.org_id = 3867
order by 1
sql to check unposted logic
SELECT ' ' "Unposted Items in AR"
FROM dual
WHERE EXISTS
(SELECT 'Y'
FROM AR_ADJUSTMENTS_ALL
WHERE posting_control_id = -3
AND gl_date BETWEEN to_date('01-APR-2023', 'DD-MON-YYYY') AND to_date('30-APR-2023', 'DD-MON-YYYY')
AND NVL(postable, 'Y') = 'Y'
AND NVL(org_id, -99) = 3867
AND rownum < 2
UNION
SELECT 'Y'
FROM AR_RECEIVABLE_APPLICATIONS_ALL RA
WHERE ra.posting_control_id = -3
AND ra.application_type = 'CM'
AND ra.gl_date BETWEEN to_date('01-APR-2023', 'DD-MON-YYYY') AND to_date('30-APR-2023', 'DD-MON-YYYY')
AND NVL(ra.postable, 'Y') = 'Y'
AND NVL(ra.org_id, -99) = 3867
AND rownum < 2
UNION
SELECT 'Y'
FROM AR_CASH_RECEIPT_HISTORY_ALL a
WHERE a.posting_control_id = -3
AND a.gl_date BETWEEN to_date('01-APR-2023', 'DD-MON-YYYY') AND to_date('30-APR-2023', 'DD-MON-YYYY')
AND a.postable_flag = 'Y'
AND NVL(a.org_id, -99) = 3867
AND rownum < 2
UNION
SELECT 'Y'
FROM RA_CUST_TRX_LINE_GL_DIST_ALL a, RA_CUSTOMER_TRX_ALL b
WHERE a.posting_control_id = -3
AND a.gl_date BETWEEN to_date('01-APR-2023', 'DD-MON-YYYY') AND to_date('30-APR-2023', 'DD-MON-YYYY')
AND b.complete_flag = 'Y'
AND a.account_set_flag = 'N'
AND b.customer_trx_id = a.customer_trx_id
AND NVL(a.org_id, -99) = 3867
AND rownum < 2
UNION
SELECT 'Y'
FROM ar_misc_cash_distributions_all mcd
WHERE mcd.posting_control_id = -3
AND mcd.gl_date BETWEEN to_date('01-APR-2023', 'DD-MON-YYYY') AND to_date('30-APR-2023', 'DD-MON-YYYY')
AND mcd.org_id = 3867
AND rownum < 2
UNION
SELECT 'Y'
FROM AR_RECEIVABLE_APPLICATIONS_ALL RA
WHERE ra.posting_control_id = -3
AND ra.application_type = 'CASH'
AND ra.gl_date BETWEEN to_date('01-APR-2023', 'DD-MON-YYYY') AND to_date('30-APR-2023', 'DD-MON-YYYY')
AND NVL(ra.postable, 'Y') = 'Y'
AND NVL(ra.org_id, -99) = 3867
AND rownum < 2
UNION
SELECT 'Y'
FROM AR_TRANSACTION_HISTORY_ALL a, RA_CUSTOMER_TRX_ALL b
WHERE a.posting_control_id = -3
AND a.gl_date BETWEEN to_date('01-APR-2023', 'DD-MON-YYYY') AND to_date('30-APR-2023', 'DD-MON-YYYY')
AND a.postable_flag = 'Y'
AND b.customer_trx_id = a.customer_trx_id
AND NVL(a.org_id, -99) = 3867
AND rownum < 2)
AND rownum < 2