Search Results get_kanban_tol_fs_prod

Overview

APPS.FLM_KANBAN_CONFIG_PARAMS is a PL/SQL configuration access package in the Oracle E-Business Suite Flow Manufacturing (FLM) module, specifically serving the Kanban and electronic Kanban (eKanban) feature set. Its central purpose is to centralize the retrieval of organization-specific Kanban configuration parameters, tolerances, and replenishment preferences so that other Flow Manufacturing programs, forms, and concurrent processes can obtain consistent settings without duplicating preference-lookup logic.

The package is declared AUTHID CURRENT_USER and carries a header version stamp of 120.3 dated 2011, consistent with the 12.1.1 and 12.2.2 code lines. A defining characteristic of the package is that nearly every documented function accepts a p_org_id parameter, which identifies the inventory organization whose Kanban configuration is being queried. This reflects the multi-organization architecture of Oracle EBS, where Kanban tolerances, demand ranges, lead-time ranges, and replenishment rules can be defined differently for each warehouse or manufacturing organization. The package also declares PL/SQL record and table types used to return multi-row results for unmoved-card processing.

Key Procedures and Functions

The documented interface exposes 33 program units. The tolerance-related functions return numeric thresholds governing Kanban card sizing and signaling: GET_KANBAN_TOL_FS_PROD, GET_KANBAN_TOL_FS_INTER, GET_KANBAN_TOL_FS_INTRA, and GET_KANBAN_TOL_FS_SUPPLIER retrieve the Kanban tolerance percentages for production, inter-org, intra-org, and supplier replenishment sources respectively. GET_TOL_KANBAN_TRANSFER returns the transfer tolerance as a varchar value.

Analysis and health functions include GET_DEMAND_RANGE_DAYS, GET_DEMAND_TOLERANCE, GET_LT_RANGE_DAYS, and GET_LT_TOLERANCE, which supply the demand and lead-time windows used by Kanban sizing calculations. GET_GOOD_INV_HEALTH_PER and GET_BAD_INV_HEALTH_PER return the good and bad inventory health percentage thresholds, while GET_DIST_DEPLOYMENT returns the distribution deployment setting. GET_DJ_STATUS_REPLENISH and GET_SOURCE_STAGING_SUBINV return configuration strings controlling replenishment status and the source staging subinventory.

Preference resolution is handled by GET_PREFERENCE_LEVEL_ID, GET_PREFERENCE_VALUE_CODE, GET_PREFERENCE_VALUE, and GET_RESULT_VALUE_CODE. The header comment documents that these functions return an attribute code from the WIP preference values structures based on responsibility key, organization, and department, for both single-value and multiple-value preferences. Finally, GET_UNMOVEDCARD_LEADTIME and GET_UNMOVEDCARD_ENB_STATUS return the FLM_UNMOVECARD_TABLE and FLM_UNMOVECARD_ENB_STATUS_T collections, exposing unmoved-card lead times and enabled statuses defined by the FLM_UNMOVECARD_REC and FLM_UNMOVECARD_ENB_STATUS_R record types.

Tables Accessed

All table access occurs through APPS synonyms. The core storage tables are FLM_EKB_PREFERENCE_VALUES, FLM_EKB_PREFERENCE_DEFINITIONS, FLM_EKB_PREFERENCE_LEVELS, and the sequence tables FLM_EKB_PREF_LEVEL_SEQ and FLM_EKB_PREF_VAL_SEQ. Together these implement the Flow Manufacturing electronic Kanban preference framework: definitions describe the available preference attributes, levels map preferences to organizational hierarchy positions, and values hold the effective settings per level. DUAL is used for scalar evaluations, and PLITBLM serves as the standard PL/SQL integer table type used internally. The package is read-oriented; it resolves configuration values rather than maintaining them.

Usage Notes

FLM_KANBAN_CONFIG_PARAMS is referenced by six other packages within the Flow Manufacturing schema, indicating that it functions as a shared configuration service layer rather than an end-user entry point. It is typically invoked from Kanban calculation and replenishment routines, eKanban concurrent programs, and Oracle Forms-based Kanban setup screens that need effective tolerance or preference values for a given organization. Because every getter requires p_org_id, callers must resolve the correct inventory organization before invocation, and results are organization-dependent. Custom code extending Kanban behavior should call these functions instead of querying the FLM_EKB_PREFERENCE_* tables directly, ensuring that preference-level resolution logic remains consistent across the application.