Best Of
Re: GL reconciliation process in Oracle R12
Hello User,
You haven't mentioned for which module to GL process,
Refer this document: Its for journal line reconciliation
Journal Line Reconciliation in R12: A Technical Brief (Doc ID 1673357.1)
Regards,
Srinivas
Re: GL reconciliation process in Oracle R12
Hi @User_GE3VU,
If you are reconciling between GL and AP
please refer
R12 : Initial Steps to Troubleshoot Accounts Payable Trial Balance and General Ledger Reconciliation Issues (Doc ID 758531.1)
Thank You,
Anees
Re: How to Modify the Column Length in a Standard Report - Account Analysis report?
Hi there,
First of all, it is not advisable to modify the standard reprot instead you can make a copy of same report and then with the help of your internal Technical team can perform the changes.
Thanks,
Neeraj
Re: The RUN_SQL action has been disabled for DataLoader.
Hi,
To enable support for RUN_SQL in an download mnt add the following to the environment's system.properties.
dtv.dataloader.enableRunSql=true
Re: Auto Create NCR Below a Certain Threshold to a PO
Thanks
I love the Spot Buying functionality; works as per the notes you cited
Thanks again David
David T
Re: After April 2025 PSU materialized view refresh failing which connects to SQL Server using dg4odbc.
Setting this to AL32UTF8 resolved the issue. Thank you. When the setting had <remote database>, I had it set to the SQL Server character set and it should be the Oracle database character set.
Thank you for the quick resolution.
Re: There are blocks in v$nonlogged_block, but NONLOGGED_START_TIME is empty
Your analysis of the situation regarding v$nonlogged_block is correct. The reason NONLOGGED_START_TIME is null and your SCN_TO_TIMESTAMP conversion is failing is that the NOLOGGING operations that affected these blocks occurred further in the past than the database's SCN-to-timestamp mapping retention period allows. Oracle maintains this mapping for a limited time, so any SCN older than this cannot be resolved to a specific timestamp. It is crucial to understand that these blocks are not "corrupt" on the primary database; they contain valid data. However, they represent a potential recovery issue because the changes were not captured in the redo logs, which would cause them to appear as genuinely corrupt blocks on a physical standby database or if you needed to perform media recovery over that time period. The next step is to join v$nonlogged_block with dba_extents to identify the specific objects (tables or indexes) affected, which will allow us to take corrective action, such as rebuilding an index or reloading a table, to ensure full recoverability and clear these entries.
Re: Oracle Retail Customer Engagement
Hi,
Unfortunately this Community is for the Xstore POS. Please create a service request under the Oracle Retail Customer Engagement so this question can be assigned to an engineer.
Thank you
Re: Is the following patch is ready to download and apply??
Thanks Rahul and Somashekar for quick reply and guidiance…..🙂