I’ve found that background jobs can hide a lot of errors whenever TRANSACTION_SYS shows up in the error stack, so my first thought here is usually to run it live. However, this particular procedure detects whether it’s being run as a background job and will spawn itself as a job if it isn’t. This makes troubleshooting annoying because you can’t run it live from the GUI. If you have access to the app owner, you might try this hacky workaround in Oracle. The idea is to make it think it’s running as a background job so it runs live, selecting a negative background job ID that will never exist.

(Using a raw DELETE query like this is not considered a best practice, so if you can, it would be best if you could refresh a nonproduction environment and try it there.)

BEGIN
   DELETE FROM transaction_sys_local_tab WHERE id = -1;
   DELETE FROM transaction_sys_status_tab WHERE id = -1;
   transaction_sys.set_current_job_id(-1);
   mpccom_accounting_api.transfer_to_finance (
      contract_         => 'YOUR_SITE_HERE',
      date_applied_     => NULL,
      execution_offset_ => 0,
      booking_source_   => 'INVENTORY');
END;
/

In my 9 environment, line 6437 doesn’t look like it could cause such a catastrophe, so I don’t have the source code to help you in that way. I suspect you’re on a different update level.

Durette, 

Thanks for the quick reply. This is a tricky one. :-)

Kind regards,

Sheri