Search Results interlock_shikyu_worker




Overview
Explore in AI Chat

Overview

JMF_INTERLOCK_SHIKYU_CP is a PL/SQL package owned by the APPS schema within Oracle E-Business Suite. Its naming convention places it squarely in the Oracle Process Manufacturing (OPM) family of objects, as indicated by the JMF prefix shared by the shop floor and manufacturing execution modules. The suffix _CP denotes a concurrent program entry point, signifying that the package is designed to be scheduled or submitted through the Oracle EBS concurrent manager rather than invoked interactively from a form or OAF page.

The package addresses interlock handling and reconciliation for "Shikyu" processing, which in the OPM domain relates to the recording of production completion quantities, consumption backflush, and the reconciliation of transactional balances against expected results. Interlocks in this context act as safeguards that prevent a transaction from proceeding when prerequisite conditions — such as matching input quantities, approved batches, or valid item/lot attributes — have not been satisfied. The package therefore supplies both a reconciliation engine and the orchestration layer that invokes it under controlled conditions. The ETRM metadata records the object as VALID, confirming that it compiles cleanly against the referenced SYS.STANDARD constructs and that no unresolved dependencies block its execution.

Key Procedures and Functions

  • INTERLOCK_SHIKYU_MANAGER — The supervisory routine within the package. It coordinates the overall interlock evaluation and reconciliation cycle, determining which records require processing, sequencing the work, and applying the business rules that govern whether a Shikyu transaction proceeds or is held. This is the entry point typically triggered by the concurrent program definition.
  • INTERLOCK_SHIKYU_WORKER — The parallel worker routine paired with the manager. It performs the per-record processing: evaluating individual transactions for interlock conditions and carrying out the fine-grained updates required for each unit of work. The manager/worker split is a standard OPM pattern that supports scalable, multi-threaded concurrent processing.
  • RUN_SHIKYU_RECONCILIATION — The reconciliation driver. It initiates the comparison of recorded Shikyu completions and consumptions against expected or system-calculated values, identifying and resolving discrepancies. Because the ETRM excerpt does not expose parameter signatures, no argument list is asserted here; the routine is described solely by its documented purpose.

Tables Accessed

The documented ETRM metadata for JMF_INTERLOCK_SHIKYU_CP does not enumerate specific base tables reached through APPS synonyms. Only the compiler-level dependency on SYS.STANDARD is recorded, which is expected for any PL/SQL package and reflects standard language constructs rather than business data access. In practice, an OPM interlock and Shikyu reconciliation package of this type operates against the manufacturing execution and inventory transaction tables that hold production batch, completion, and consumption records, writing status flags or interlock release indicators as reconciliation proceeds. Practitioners should not assume specific table names from this metadata alone; the authoritative list is obtained by querying USER_DEPENDENCIES and USER_SOURCE in the APPS schema of the target instance, since the visible dependencies vary with the site's applied patches and OPM module configuration.

Usage Notes

JMF_INTERLOCK_SHIKYU_CP is invoked primarily as a concurrent program. Administrators schedule RUN_SHIKYU_RECONCILIATION — which invokes the manager and worker routines — through the Concurrent Programs and Requests forms, typically on a periodic or event-driven basis to clear pending interlock conditions arising from shop floor activity. Manual submission from System Administrator responsibilities is common during month-end close or after batch processing anomalies. Because the underlying procedures are public within the APPS schema, customized concurrent programs or triggers may also call them, but such extensions should be treated with caution: the package carries no documented public API classification beyond OTHER, meaning Oracle does not guarantee its interface across releases. Any custom invocation should be validated against the specific ETRM 12.1.1 or 12.2.2 instance, and the package should be re-verified after OPM patching, as interlock logic is subject to change between patch levels.