Search Results conc_log

Overview

MSC_ATP_24X7 is an Oracle Advanced Supply Chain Planning (ASCP) package body in the APPS schema that supports the 24x7 Available-to-Promise (ATP) synchronization process. Its purpose is to synchronize ATP data between a currently active plan and a newly collected plan so that ATP checks executed against a live, continuously available plan reflect current supply and demand without requiring the plan to be taken offline. The package coordinates the transition between an old plan identifier and a new plan identifier, updating ATP scheduling records, flagging synchronized rows, and calculating the impact of planned downtime on sales order records.

The header indicates a last revision of version 120.7 dated 2011/10/27, which places it within the 12.1.1 and 12.2.2 release lineage. The package is classified as API type OTHER in the ETRM metadata, and it is referenced by three other packages, indicating it is a dependent utility rather than a top-level entry point.

Key Procedures and Functions

The documented metadata lists four callable units: CALL_SYNCHRONIZE, CONC_LOG, CONC_DEBUG, and PARSE_SALES_ORDER_NUMBER. The source excerpt also declares the core synchronization procedures that give the package its purpose:

• ATP_SYNCHRONIZE — the primary driver procedure, accepting an old and new plan identifier and returning status information. It coordinates the overall ATP synchronization cycle.
• Synchronize_Call_To_ATP — invokes the ATP synchronization logic for a specific ATP record type and session, returning total elapsed time and status.
• Get_Records_Pre_Collections — retrieves pre-collection records. Per the embedded comment, this procedure is no longer used because 24x7 does not support MDS-based ATP plans.
• Get_Records_Post_Collections — retrieves post-collection records for a given session, returning an ATP record collection and record count.
• Update_Sync_flag — updates the synchronization indicator on ATP records associated with the old plan.
• ATP_Downtime_Init and ATP_Downtime_Complete — bracket a planned downtime window for ATP synchronization with start and completion markers.
• ATP_Sync_Error — records error conditions encountered during synchronization.
• Calculate_Downtime_SO_Records — quantifies the effect of downtime on sales order records based on record count and total time.
• CALL_SYNCHRONIZE, CONC_LOG, CONC_DEBUG, and PARSE_SALES_ORDER_NUMBER — the four procedures confirmed in the 12.2.2 ETRM metadata. These provide the concurrent-program entry point, logging and debug output for concurrent runs, and parsing of sales order numbers during synchronization.

Tables Accessed

The package reads and writes a range of ASCP and application foundation tables through APPS synonyms:

• MSC_PLANS, MSC_PLAN_ORGANIZATIONS, MSC_PLAN_REFRESHES — plan definition, organization, and refresh status data used to identify the active and incoming plans.
• MSC_DEMANDS, MSC_SALES_ORDERS, MSC_SYSTEM_ITEMS — demand, sales order, and item records that participate in ATP checking.
• MSC_CTO_BOM, MSC_CTO_SOURCES — configure-to-order bill of material and sourcing data used when ATP records involve configured items.
• MSC_TP_ID_LID, MSC_TP_SITE_ID_LID — trading partner and trading partner site identifier mappings.
• MRP_ATP_SCHEDULE_TEMP_S and the MRP_ATP_PUB.ATP_Rec_Typ record type — the ATP schedule and record structures passed between procedures.
• FND_ORACLE_USERID, FND_PRODUCT_INSTALLATIONS, ALL_OBJECTS — application user identity, product installation verification, and object metadata lookups.
• DBMS_LOCK — serialization of synchronization activity to prevent concurrent ATP sync runs.

Usage Notes

MSC_ATP_24X7 is invoked from ASCP ATP processing rather than directly by end users. Its CALL_SYNCHRONIZE entry point is designed to be driven by the concurrent manager, with CONC_LOG and CONC_DEBUG providing standard concurrent program logging and diagnostic output. It is also called by the three referencing packages. Because the package performs plan synchronization across old and new plan identifiers, it is typically executed after a plan collection completes and before ATP checks are routed to the new plan. Given the "chennai one data centre bangalore" search context, note that this package is data-centre agnostic: it operates purely on database objects and makes no assumptions about physical data centre location, so its behavior is identical whether the EBS database is hosted in Chennai, Bangalore, or elsewhere.