ASCP Planning Flow

Reference doc for setting up ASCP: Doc ID 552415.1

ASCP Error

1. Failed attempt to lock : LOCK TABLE MSC_BOMS PARTITION (BOMS_21) IN EXCLUSIVE MODE
NOWAIT
ORA-02149: Specified partition does not exist

Solution: (Metalink Doc ID 236017.1)

Cause: Share plan partition was set to no from yes

2. No free partitions available, Contact the DBA to create partitions

Solution: Create APS Partition

3. Create APS Partition Error

Cause: FDPSTP failed due to ORA-02149: Specified partition does not exist
ORA-06512: at "SYSTEM.AD_DDL", line 165
ORA-06512: at "APPS.MSC_MANAGE_PLAN_PARTITIONS", line 371
ORA-14074: partition bound must collate higher than th

Solution: Doc ID 552415.1 (Version 12.0.4 to 12.1 [Release 12 to 12.1])

4. Launch Plan – Loader worker with direct load option

Record 1: Rejected - Error on table MSC.DEMANDS1023, column PROMISE_SHIP_DATE.

ORA-01861: literal does not match format string

Proposed solution: Doc ID 1333183.1, Doc ID 1286320.1

Solution: set profile MSC: 64-bit Planner Platform to null (not permanent solution)

5. Memory based snapshot error

APP-MRP-22075: An internal error has occurred (mrnspia, 2, 85, )

 @ERRORTEXT Cause: The current routine encountered the specified@ERRORTEXT x
Action: Contact your customer supportrepresentative.
APP-MRP-22075: An internal error has occurred (main, 19, MSCNSP, )
@ERRORTEXT Cause: The current routine encountered the specified@ERRORTEXT x
Action: Contact your customer supportrepresentative.

Solution: (Metalink Doc ID 401726.1)

Setup: MSC Hour UOM must be set.

6. Analyze Plan Partition

Cause: FDPSTP failed due to ORA-20000: WO_SUB_COMP_999999 invalid partition name

ORA-06512: at "APPS.FND_STATS", line 2025
ORA-06512: at "APPS.MSC_MANAGE_PLAN_PARTITIONS", line 1504
ORA-06512: at line 1

Solution:(Metalink Doc ID 1347087.1)

The Plan partition has become corrupt. Perform the following:

1. In this example the plan partition which has become corrupt has plan_id = 999999 as the
error showed the partitioned table having the issue was WO_SUB_COMP_999999

2. Purge the ASCP Plan Name having the error message

3. Drop the plan partition having the issue with the Drop Partition concurrent request

4. Create a new plan partition with the Create Partition concurrent request

5. Create a new plan name/options

6. Run the new ASCP plan

7. Archive plan summary error

msc_phub_pkg.populate_details_fn: User-Defined Exception

Solution:(Metalink Doc ID 1513478.1)

Set the profile option MSC: APCC Category Set 1 to a valid category

a. System Administrator > Profile > System

b. Query the profile option at the Site level
c. Change the value accordingly
d. Save your changes

8. No organization defined for this organization

Solution:
 Go to inv super user-> setup-> organization-> organization access, define organization that
use ASCP responsibility.
Go to advanced planning administrator -> admin -> instances, define instances (must be set
before run collection or refresh snapshot), run concurrent refresh snapshot, run standard
collection oracle.

9. Planning Data Collection (Request Set Planning Data Collection) :

(Running planning data pull from collection -> oracle -> standard collection)

MSCPDX module: Request Set Planning Data Collection

Planning Data Pull :

(Running planning data pull from collection -> oracle -> standard collection)

Staging tables' data is not collected. Please submit the request - Planning ODS LOAD.

Solution:(Metalink Doc ID 1531482.1)

The most likely cause is that a previous run of collections has failed before completing. To
resolve this:

1) Access Advanced Planning Administrator responsibility and run the concurrent program
Planning Data Pull Purge Staging Tables and run for the instance and set Validation to No.

2) Once this has completed please run the ASCP Standard Collection again and you will see
that it will no longer fail for this error.

10. Planning Data Load, Planning Data Worker:

(Running planning data pull from collection -> oracle -> standard collection)
Timeout error. There is an Unknown Error in the Worker. Planning ODS Load process failed.
Solution:
Expand time in timeout parameter or add more workers in workers parameter.

Cause: Planning data collection has run more than defined timeout parameter.

11. Set up Profile for ASCP, MSC: Hour UOM

 Solution: Running collection first to get UOM

12. Set up Profile for ASCP, MSC: Hour UOM

APP-MRP-22100: Request 1902427 failed

Cause: The specified concurrent request exited with an error.

Action: Examine the concurrent request log file for details.

APP-MRP-22075: An internal error has occurred (mrnspgmsg, 1, 1902427, )

@ERRORTEXT Cause: The current routine encountered the specified@ERRORTEXT x
Action: Contact your customer supportrepresentative.
APP-MRP-22075: An internal error has occurred (main, 11, , )
@ERRORTEXT Cause: The current routine encountered the specified@ERRORTEXT x
Action: Contact your customer supportrepresentative.
13. Launch supply chain planning process: Memory-Based Planner 64-Bit Sun

APP-FND-01564: ORACLE error 1830 in mrfgrq_flush_demands

Cause: mrfgrq_flush_demands failed due to ORA-01830: date format picture ends before
converting entire input string

14. Launch supply chain planning process: Loader Worker With Direct Load Option

value used for ROWS parameter changed from 1000 to 40

Record 1: Rejected - Error on table MSC.MSC_DEMANDS, column REQUEST_DATE.
ORA-01861: literal does not match format string
References:
Doc ID 1286320.1
Doc ID 1349708.1
Bug: BUG:13547783, Bug 12866593
15. Launch supply chain planning process: Loader Worker With Direct Load Option value used
for ROWS parameter changed from 1000 to 31

Record 3015: Rejected - Error on table MSC.MSC_SUPPLIES, column

SCHEDULE_DESIGNATOR_ID.
ORA-01722: invalid number
References: Doc ID 1460247.1
Keyword for issue no. 10 & 11 in metalink: MSCPLD

16. Create instance in APS destination with decentralized implementation failed with message:
Currently installed/licensed options of Advanced Supply Chain Planning product do not
 allow Distributed Instances. Please consult the implementation guide and upgrade notes for
detail
Solution:
On the APS destination, you should set profile GMP: APS Installation Level = 3
IF the EBS Source is R12.0 or 12.1 or higher, then you also need to set this profile on the EBS
source instance as well.
IF the EBS source is 11.5.10, then this profile should not be required.
Reference: Currently Installed/Licensed Options Of Ascp Product Do Not Allow Distributed
Instances (Doc ID 1188082.1)

17. Cannot gather schema statistic:

FDFGVD failed due to ORA-01406: fetched column value was truncated.
The SQL statement being executed at the time of the error was: SELECT
A.ORACLE_USERNAME,A.ORACLE_USERNAME VALUE, A.DESCRIPTION DESCRIPTION, NVL('N',
'N'), NVL(TO_NUMBER(NULL), -1), NULL, NVL('Y', 'Y'), NVL(TO_CHAR(TO_DATE(NULL), 'J'), 0),
NVL(TO_CHAR(TO_DATE(NULL), 'J'), 0) FROM (SELECT 'ALL' ORACLE_USERNAME,'All Schemas'
DESCRIPTION,1 SEQ FROM DUAL UNION SELECT ORACLE_USERNAME,DESCRIPTION,2 SEQ
FROM FND_ORACLE_USERID ) A WHERE 1=1
AND A.ORACLE_USERNAME = :X and was executed from the file &ERRFILE.
Solution: Please change to the value set to define the description column as 240 in
FND_STATS_OWNER_ALL
1. Application Developer > Application > Validation > Set
2. Query for FND_STATS_OWNER_ALL
3. Press on Edit Information button
4. Put the size of the 2 columns 240
5. Come back and put Maximum Size also 240.
6. Save
7. Retest the issue.

18. Collection Error: Planning Data Pull

MSDPDP: Demand Planning Setup Data Collect Fails with NO_USER_DEFINED, Error in Refresh
Snapshot Process. (Doc ID 333558.1)
Cause: The exact same responsibility that is used to launch the collection process must exist
on the source instance
Solution:
1. You launched collection from an id using a responsibility.
2. Go to the source instance and ensure that the exact same responsibility exists on the
source instance.
19. Constrained plan did not work out (still act like unconstrained plan)
Steps to reproduce:
1. Create plan with MDS
2. Launch plan
3. Open planner workbench
Result: Recommendation did not consider resource capacity but only give exceptions
material/resource capacity overload
Solution:
1. Set profile: MSC: Enable Advanced Constraints to Yes

20. Resource availability did not regenerate in planner workbench

Cause:
When run standard collection, planning data pull, resource availability was not set to
Regenerate and Collect.
Solution:
Run planning data collections, and set resource availability set to Regenerate and Collect
21. Refresh collection snapshot error (from EBS source, decentralized environment)
Petunjuk :
 Collections Triggers (Complete error  error setting up triggers)
 Collections Views (Complete error  error setting up views)
 Setelah kedua concurrent di atas error, semua concurrent ‘Create Collections XXX
View  complete error) dan muncul banyak invalid object (select distinct OWNER,
OBJECT_NAME,OBJECT_TYPE,LAST_DDL_TIME from dba_objects where status='INVALID'
order by owner;)
 Refresh collection snapshot (complete error)  Error Setting Up Source Objects
Cause:
Terdapat user yang sama antara dua destination (planning) instance dengan EBS source,
contoh:

ASCP 1

EBS User: MII.ASCP

User: MII.ASCP us

ASCP 2

User: MII.ASCP

us
 Solusi:

Recompile invalid object dan buat user khusus untuk destination (planning) instance ke
source instance (user antara destination dengan source harus sama). Refresh collection
snapshot dilakukan menggunakan user tersebut

ASCP 1

EBS User: MII.ASCP

User1: MII.ASCP us

User2: MII.ASCP2 ASCP 2

User: MII.ASCP2
22. Launch Plan (production plan) (from EBS source, decentralized environment)
us
APP-FND-01564: ORACLE error 1854 in mrfgrq_flush_demands
Cause: mrfgrq_flush_demands failed due to ORA-01854: julian date must be between 1 and
5373484
*kasus: Production plan dan baru ada perubahan dblink
Diketahui terdapat 3 invalid object di MSC_DEMAND
Cause:
The issue is caused by the following setup: executable MSONEW was not relinked.
This issue is described in: Bug 2174505 MEMORY BASED PLANNER: APP-FND-1564: ORACLE
ERROR 1854 IN MRFGRQ_FLUSH_DEMANDS
Solution:
 Please recompile all MSC/MSO invalid objects if there are any.
 Please do the followings successfully to relink the executable again and retest:
adrelink.sh force=y "mso MSONEW"
Important: Users should also relink all MSC/MSO/MSR executables with Adadmin to
make sure all executables are relinked properly.
 Re-run the plan

23. Resource usage displayed as 0.0 in ASCP Plan workbench

Root cause: Resource usage is 0.00xx or 0.000xx
Decimal places in preferences, capacity plan tab is 1 but resource usage has decimal place
more than 1
 Solution:
Open Plan/Collection workbench, tools, preferences, capacity plan tab, set decimal places
to 6
MSO: Floating Point Precision for Usage in Routings -> 100

24. Refresh collection snapshot in source instance is end with error neither standard collection is
destination instance
Error:
21-FEB 15:57:53 : ORA-12537: TNS:connection closed
21-FEB 15:57:53 : Error_Stack...
21-FEB 15:57:53 : ORA-12537: TNS:connection closed
Root cause: New destination instance created and have same instance name

ASCP 1

EBS Instance: ADF

User: MII.ASCP us

ASCP 2

Instance: ADF

us
Solution:
Drop ASCP 2 instance which have same name with ASCP 1 instance and create new
instance in ASCP 2 with different name
 ASCP 1

EBS Instance: ADF

User1: MII.ASCP us

User2: MII.ASCP2 ASCP 2

Instance: ADI

us

25. Refresh collection snapshot error:

CREATE INV SNAPSHOT error:

CREATE MRP SNAPSHOT error: sama dengan di atas table WIP.WIP_DISCRETE_JOBS

CREATE WIP SNAPSHOT error: sama dengan di atas table MRP.MRP_SCHEDULE_DATES
Solution: Dropped the corrupted snapshot based on the view log and run refresh collection
snapshot in Fast mode
Reference: Doc ID 415135.1
26. Unable to create plan:
App-Fnd-01206 This Record Already Exists When Entering APS Plan Name
Solution: Purge the corrupted plan
Query for checking corrupted plan:
select a.plan_id, a.compile_designator, partition_number, free_flag
from msc_plans a, msc_plan_partitions b
where a.plan_id=b.plan_id
and b.plan_id in (select plan_id
from msc_plan_partitions where free_flag=1);
Reference: Doc ID 184984.1 or Doc ID 1193053.1
You need to purge the last TWO plans that were defined.
Then drop those plan partitions as well.
What happens is that there was a problem with saving the plan options for the last plan that was
successfully defined.
1. Check MSC_PLAN_PARTITIONS for the last plan defined.
select * from MSC_PLAN_PARTITIONS
order by last_update_date desc;
 2. For with FREE_FLAG = 1
Run Drop Partition with Partition number and plan = Yes
3. Then for the first plan in the list that shows free_flag = 2 (yes), purge that plan.
If this errors, do not be concerned.
4. Then run again
select * from MSC_PLAN_PARTITIONS
order by last_update_date desc;
5. This partition_number for the plan you just purged should have free_flag = 1
6. Then run drop partition request for this partition.
7. Then run Create APS Partitions with parameters
Plan partition = 1 (or more)
instance partition = 0
8. Then create your plan and save the plan options.

27. Refresh Collection Snapshot (in source instance, MSC: Source Setup Required : Y)
Error: User defined exception
Solution: Set Profile option Concurrent: Sequential Requests to No
Reference: Doc ID 1297393.1
28. Gather Schema Statistic Error
Error:
Error #1: ERROR: While GATHER_TABLE_STATS:
object_name=MSC.OPERATION_RESOURCES_ADF***ORA-20000: Unable to analyze TABLE
"MSC"."OPERATION_RESOURCES_ADF", insufficient privileges or does not exist***
Error #2: ERROR: While GATHER_TABLE_STATS:
object_name=MSC.OPERATION_RESOURCE_SEQS_ADF***ORA-20000: Unable to analyze
TABLE "MSC"."OPERATION_RESOURCE_SEQS_ADF", insufficient privileges or does not exist***
dan tabel2 yang lain

Solution: Do not do Gather Schema Statistic when ASCP Collection

Reference: 1395008.1

29. MSCSNR_SNP_ROUTINGS failed due to ORA-01652:unable to extend temp segment by 128 in

tablespace TEMP1 when launching ASCP Plan
Solution: Gather Schema Statistic weekly or monthly with higher percentage (30-40%) (It
depends on how fast the data grows). If the error is on routings, then gather schema statistic
for routings. if it in BOM, then gather schema statistic for BOM.
30. Launch Plan runs very slowly
Solution: Gather Schema Statistic weekly or monthly with higher percentage (30-40%)
Or execute this query:
exec fnd_stats.gather_table_stats('MSC','MSC_ITEM_ID_LID',PERCENT=>30);
exec fnd_stats.gather_table_stats('MSC','MSC_ST_BOM_COMPONENTS',PERCENT=>30);
exec fnd_stats.gather_table_stats('MSC','MSC_ST_ROUTING_OPERATIONS',PERCENT=>30);
exec fnd_stats.gather_table_stats('MSC','MSC_ST_ROUTINGS',PERCENT=>30);

31. Launch Plan error in Memory Based Planner

APP-MRP-22066: mrivoff_interval_offset: Invalid value of '-23453' for the

argument 'the_date'

32. Launch Plan error Loader Worker With Direct Load Option
value used for ROWS parameter changed from 1000 to 22
Record 1: Rejected - Error on table "MSC"."MSC_SYSTEM_ITEMS#".
ORA-14400: inserted partition key does not map to any partition

MAXIMUM ERROR COUNT EXCEEDED - Above statistics reflect partial run.

Solution : If the setup of the profile MSC:Share Plan Partitions to Yes is required for business
reason then ensure that the partitions are correctly created.Basically for this setup we need to have
the _999999 partition exist.So if the partition does not exist just create partition using the request
"Create APS Partition" with Plan = 1 with the profile MSC:Share Plan Partitions set to Yes so that it
creates the necessary _999999 partitions.
Doc. ID : MSCPLD Loader Worker Fails With ORA-14400 (Doc ID 960022.1)
33. FORMULA, RECIPES NOT COLLECTED TO ASCP 12.24 IN STANDARD COLLECTION

Solution : Apply Patch 19603840

Reference : Doc ID 1951906.1

34. Recipe information not collected with not updating formula_header_tab.

Symptom : Some recipes are collected

Solution : Run this query to define which recipes are still un-collected
select *
from GMD_RECIPE_ROUTING_STEPS
 where recipe_id in
(select recipe_id
from gmd_recipe_validity_rules
where recipe_validity_rule_id = < recipe_validity_rule_id from 2) above>)
Try to create production batch with one of those above items. If any error appears as screen below :

Then you must set up conversion UOM for the item.

Reference : Doc ID 814483.1

35. Launch Plan Error Snapshot Delete Worker

ORA-06512: at "SYSTEM.AD_DDL", line 165
ORA-06512: at "APPS.MSC_MANAGE_PLAN_PARTITIONS", line 355
ORA-14074: partition bound must collate higher than the last partition
j := 1
table := MSC_ATP_SUMMARY_SO
partition_name : ATP_SUMMARY_SO__1
l_count := 1
Partition for instance 1 already exists
table := MSC_ATP_SUMMARY_SD
partition_name : ATP_SUMMARY_SD__1
l_count := 1
Partition for instance 1 already exists
l_share_partition := N
plan count := 0
 After Create Partitions

Solution :
Doc ID 552415.1
Then, create APS Partition:
- Plan partition count = 5
- Instance partition count = 1
36. Running Collection Error in Planning ODS Load Error
ORA-14098: index mismatch for tables in ALTER TABLE EXCHANGE PARTITION.
Fatal Error in Exchange Partition

Solution :
Diagnostics Steps R.12.x :
A> LOOKUP VALUE ISSUE - This must be checked and if any corrections are required, then fix the
lookup, then find all the problem indexes in one SQL
1. The lookup MSC_ODS_TABLE may have bad records with meaning and description having an
appended value of (1)
NAV: Advanced Planning Administrator / Admin / Lookups and query on MSC_ODS_TABLE
Easiest way to check the lookup values is to export the lookup values using /file/export and
open the .tsv file in Excel and review the results
2. For this lookup there should be only one row for each table and none of them should have
(1) appended to the name.

Example seen internally :

Code Lookup Code Meaning Lookup Code Description
640 MSC_CALENDAR_MONTHS MSC_CALENDAR_MONTHS
630 MSC_CALENDAR_MONTHS(1) MSC_CALENDAR_MONTHS(1) << this rows should be
disabled (uncheck Enabled flag)

3. When table lookup is corrected, then we can see which tables have missing indexes and fix
these tables

B> FINDING MISSING INDEXES

Run SQL to determine the tables in need of fix.
select
ods.table_name
, ai.index_name
, substr(ods.table_name,5) || '__' || to_char(mip.instance_id) partition_name
from msc_ods_table_v ods
, msc_inst_partitions mip
, all_indexes ai
where ods.partition_type = 'R'
and ods.table_name = ai.table_name
MINUS
select
 ods.table_name
, aip.index_name
, aip.partition_name
from all_ind_partitions aip
, all_indexes ai
, msc_ods_table_v ods
where ods.partition_type = 'R'
and ods.table_name = ai.table_name
and ai.index_name = aip.index_name
and ai.owner = aip.index_owner;

1. To drop the index(es), use the following command :

drop index <schema>.<index name>
2. After this, run Data Collections and it should now complete successfully
3. Recreate the index using the following info
adjava -ms128m -mx256m -nojit oracle.apps.fnd.odf2.FndXdfCmp \
MSC MSC APPS APPS \
thin erpdev.campina.co.id:1527:TEST index \
$MSC_TOP/patch/115/xdf/MSC_DEMANDS.xdf \
$FND_TOP/patch/115/xdf/xsl \
logfile=$HOME/adjava_XDF.log

4. After the object is recreated, please run the Data Collections process again to verify that the
object(s) were created successfully

Reference : DocID = 340118.1

37. Purchase Order cannot be collected and calculated by ASCP Plan

Cause :
The Planning Manager wasn't running, thereby causing the purchase orders not to get collected.

In the view MRP_AP_PO_PO_SUPPLY_V the missing PO is seen. This is the view on the source that is
selected from to populate the MSC_ST_SUPPLIES and subsequently the MSC_SUPPLIES table.

The query used to insert data into MSC_ST_SUPPLIES from MRP_AP_PO_PO_SUPPLY_V has the
following
WHERE clause:

from PJM_PROJECT_PARAMETERS mpp,

MRP_AP_PO_PO_SUPPLY_V x
where x.TO_ORGANIZATION_ID in (&ORG_ID)
AND mpp.project_id (+)= x.project_id
 and mpp.organization_id (+)= DECODE( :v_mps_consume_profile_value,1,
x.MRP_TO_Organization_ID,x.Organization_ID)
and DECODE( :v_mps_consume_profile_value,1,
x.MRP_DESTINATION_TYPE_CODE,x.DESTINATION_TYPE_CODE)= 'INVENTORY'

The value :v_mps_consume_profile_value refers to the profile MRP: Consume MPS. If this value is
set to Yes, then the data collection is concerned with the columns MRP_TO_ORGANIZATION_ID and
MRP_DESTINATION_TYPE_CODE in
MRP_AP_PO_PO_SUPPLY_V. These columns should be populated by the Planning Manager.

Solution :
To implement the solution, please execute the following steps:

Start the Planning Manager.

This will populate the MRP_ columns in the PO tables and allow for the POs to be included in the
MRP_AP_PO_PO_SUPPLY_V and subsequently get collected.

From there, the POs will be included as supply in the ATP check.

Also on the source instance, if you set profile MRP:Consume MPS from Yes to No, the Planning
Manager does not need to be running and the purchasing data will be collected by data collections
and thus will be picked up by ATP and ASCP plan. Note 790125.1 has a discussion on when the
planning manager should be running when using VCP/ASCP products

38. Error when Collection : Planning Data Pull Worker

Cause : GMP_BOM_ROUTING_PKG.get_profile_value called for profile
BOM:HOUR_UOM_CODE with dblink
Profile "BOM: UOM for Hour" is Invalid
Effectivity extraction failed
21-MAY 11:21:00 : Error in Routine GMP_BOM_ROUTING_PKG.EXTRACT_EFFECTIVITIES.
21-MAY 11:21:00 : User-Defined Exception
21-MAY 11:21:00 : User-Defined Exception
21-MAY 11:21:00 : Error_Stack...
21-MAY 11:21:00 : ORA-06510: PL/SQL: unhandled user-defined exception

21-MAY 11:21:00 : Error_Backtrace...

21-MAY 11:21:00 : ORA-06512: at "APPS.MSC_CL_PULL", line 7028
ORA-06512: at "APPS.MSC_CL_PULL", line 1815

Solution :

1. Go into the responsibility: OPM Supply Chain Planning-->then go to edit menu-->Preference-

->Profile
2. First check whether you have selected the correct UOM in profile i.e. "BOM: UOM for Hour,
if not setup the correct UOM in Profile i.e. "BOM: UOM for Hour.

3. Setup Profile Options MSC: Setup Source Required to Yes.

4. Run the Request "Planning data pull- purge staging table" to purge the staging table data.
5. Re-run the Standard Data collections..
6. Migrate the solution as appropriate to other environments

INSTALL ALERT - Setting Up The APS Partitions and To

Data Collections Instance in R12 (Doc ID 552415.1) Bottom

For a Fresh Installation:

The table MSC_NET_RES_INST_AVAIL will be created and is created with partitions
The partitions created are not correct and cause errors when trying to perform basic setup steps for
Advanced Planning Administrator OR Advanced Supply Chain Planning:

Update 04-APR-2014 - New Report

Found corruption of table - MSC_RESOURCE_INSTANCE_REQS
has bad instance partitions
RESOURCE_INSTANCE_REQS__21
RESOURCE_INSTANCE_REQS__3062
RESOURCE_INSTANCE_REQS__5061
RESOURCE_INSTANCE_REQS__5062

and bad plan partition

RESOURCE_INSTANCE_REQS_999999

For an Customer upgrading from 11.5.x to R12.0.4 or 12.0.6 or 12.1.1 or

higher

IF the table MSC_NET_RES_INST_AVAIL does not already exist on the system

THEN as part of the R12.0.4 or 12.1.x installation and upgrade, the partitions created for this table will
not be correct.

This can result in a number of ORA errors in the MSCCRPAR - Create APS Partitions and Data Collection
process ORA-02149 and ORA-14074 have been observed

Symptomps

Due to the different order that setup steps that can be run by the customer, this issue can
encountered at many different times and cause different failures.

Failure Conditions:

1. The most common failure is in Data Collections ODS Load Worker

ALTER TABLE MSC_NET_RES_INST_AVAIL TRUNCATE PARTITION
NET_RES_INST_AVAIL__1
ORA-02149: Specified partition does not exist
2. Create APS Partitions fails with
ORA-14074 Create APS Partitions Fails with Error ORA-14074
3. ORA-06512: at "SYSTEM.AD_DDL", line 165
ORA-06512: at "APPS.MSC_MANAGE_PLAN_PARTITIONS", line 355
ORA-14074: partition bound must collate higher than the last partition
4. ERR_GET_INSTANCES (ERROR_MSG=No Free partitions available. contact DBA to
create partitions.)
This can happen on a fresh install in the Instances form when users try to create the
Instance setup

Workaround

Table MSC_NET_RES_INST_AVAIL and MSC_RESOURCE_INSTANCE_REQS should have the same

NUMBERS in the PARTITION_NAME column as the other Planning Tables of the same type
We use MSC_SYSTEM_ITEMS to compare and check the NUMBERS of the PARTITION_NAME column

SQL #1
select table_name,
partition_name
from all_tab_partitions
where table_name like 'MSC_NET_RES_INST%'
OR table_name like 'MSC_SYSTEM_ITEMS%'
order by substr(partition_name,instr(partition_name,'_',-1,1)+1);

SQL #2
select table_name,
partition_name
from all_tab_partitions
where table_name like 'MSC_RESOURCE_INSTANCE_REQS%'
OR table_name like 'MSC_SYSTEM_ITEMS%'
order by substr(partition_name,instr(partition_name,'_',-1,1)+1);

EXAMPLE OF BAD RESULTS USING SQL #1

The only pair that exists in _0 pair, and NET_RES_INST_AVAIL does not have matching partition numbers
for the other partitions of SYSTEM_ITEMS

You will see that we have some partitions with __n <double underscore_number> AND some partitions
with _n <single underscore_number> This is normal.
Double__Underscore partitions will store data collected from other applications, while
Single_Underscore partitions store data created by the Planning Applications. See Note 137293.1 for
more information

MSC_SYSTEM_ITEMS

TABLE_NAME PARTITION_NAME

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_0

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL_0

MSC_SYSTEM_ITEMS SYSTEM_ITEMS__1

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_1

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_2
MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL__21

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_3

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_4

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_5

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL_999999

EXAMPLE OF GOOD RESULTS

Each table partition has a pair and the numbers match. The actual numbers for the partition_name
shown here are for the default installation of a fresh installation that has no problems. If you upgraded
and were using Advanced Supply Chain Planning before the upgrade, then your number could be
different, but the important point is that the number match between the tables and each exists as a
pair.

You will see that we have some partitions with __n <double underscore_number> AND some partitions
with _n <single underscore_number> This is normal.
Double__Underscore partitions will store data collected from other applications, while
Single_Underscore partitions store data created by the Planning Applications. See Note 137293.1 for
more information

TABLE_NAME PARTITION_NAME

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_0

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL_0

MSC_SYSTEM_ITEMS SYSTEM_ITEMS__1

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL__1

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_1

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL_1

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_2

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL_2
MSC_SYSTEM_ITEMS SYSTEM_ITEMS_3

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL_3

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_4

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL_4

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_5

MSC_NET_RES_INST_AVAIL NET_RES_INST_AVAIL_5

How to Resolve and Fix the Partitions

1. Set profile MSC: Share Plan Partitions = No

2. You need to remove the bad partitions - By running Drop Partition - we will remove the bad
partitions.
STEPS FOR MSC_NET_RES_INST_AVAIL
We need to remove NET_RES_INST_AVAIL_999999 and NET_RES_INST_AVAIL__21
From Advanced Planning Administrator - use /view /requests - submit a new request
A> Run Drop Partition with parameters
-- Partition = 999999
-- Plan = Yes
B> Then run again with parameters
-- Partition = 21
-- Plan = No
Note: If this request is not available, then see
System Administrator /Security / Responsibility /Request - query on %MSC% to bring up 'All MSC
Reports'
and add Drop Partition to the request group and save, then execute the steps above

STEPS FOR MSC_RESOURCE_INSTANCE_REQS

We need to remove Plan partition RESOURCE_INSTANCE_REQS_999999
We also have 4 Instance partitions RESOURCE_INSTANCE_REQS__21,
RESOURCE_INSTANCE_REQS__3062, RESOURCE_INSTANCE_REQS__5061,
RESOURCE_INSTANCE_REQS__5062
A> Run Drop Partition with parameters
-- Partition = 999999
-- Plan = Yes
B> Then run again with parameters
-- Partition = 21
-- Plan = No
 B> Then run again with parameters
-- Partition = 3062
-- Plan = No
B> Then run again with parameters
-- Partition = 5061
-- Plan = No
B> Then run again with parameters
-- Partition = 5062
-- Plan = No

3. From SQL*Plus as APPS user, run file $MSC_TOP/patch/115/sql/MSCCLPAR.sql

4. Run Create ATP Partitions request (this is NOT Create APS partitions). This request has no
parameters.

5. Run Cleanup Instance Partitions request with Parameter Mode = Repair

6. Run the following SQL to check that the corruption to table MSC_NET_RES_INST_AVAIL is not
present

SQL #1
select table_name,
partition_name
from all_tab_partitions
where table_name like 'MSC_NET_RES_INST%'
OR table_name like 'MSC_SYSTEM_ITEMS%'
order by substr(partition_name,instr(partition_name,'_',-1,1)+1);

SQL #2
select table_name,
partition_name
from all_tab_partitions
where table_name like 'MSC_RESOURCE_INSTANCE_REQS%'
OR table_name like 'MSC_SYSTEM_ITEMS%'
order by substr(partition_name,instr(partition_name,'_',-1,1)+1);

7. The SQL Results should show that the each PARTITION_NAME has a pair for each partition
number like shown in EXAMPLE OF GOOD RESULTS table above.
39. ASCP Plan fails in MSCNSP with the following error message occurs:
APP-MRP-22052: 11-JAN-08 is outside the range of valid calendar dates

Cause: The specified date is outside the range of valid workdays (04-FEB-08 to 01-JAN-12).
The date is either before the start of the workday calendar or after the end of the workday calendar.
(Routine: xxxx_xxxxx_xxxxx)

Action: Extend the boundaries of your workday calendar.

(JULIAN_DATE=2454477) (LOW_JULIAN_DATE=2454501) (HIGH_JULIAN_DATE=2455928)

Cause :
Here is a common and quick cause to check. Bear in mind that this is not cause of all cases when
this error occurs, but here is first common check to perform :
Typically, Profile: "MRP:Retain Dates Within Calendar Boundary" not set, and there is a record with a
date that is outside of the calendar range

Solution :
Check setting of the profile option: MRP:Retain Dates Within Calendar Boundary
This can prevent this type of issue as the profile determines whether to pull dates outside the
calendar boundary into calendar horizon.
If not set to Yes, please set profile to this value at site level
Run the plan again to see if it completes

Resource requirement cannot calculate in ASCP Workbench after launching Plan.

From the apscheck please see section:

17.1 Product Pro*C Files Spot Check Version Comparison

and in particular:

17.1.2 Comparing file msocnew.ppc in MSO_TOP/bin/MSONEW and $MSO_TOP/lib/libmso.a ...

-------------------------------------------------------------------------------------

$Header: msocnew.ppc 120.178 2012/04/24 17:23:47 jdirks ship $

$Header: msocnew.ppc 120.178.12020000.34 2014/10/02 21:47:45 wexuxu ship $
 1) Please see the instructions under 17.1 and relink this executable where these versions are seen as
being out of synch.

2) Once completed please re-run and upload the apscheck.

It is possible that there will be something in addition to this issue identified above but for sure this is
a mandatory first step and might well resolve the issue in total.

40. On Hand can not be collected in ASCP

Complete Warning on Planning ODS Load Worker

**Starts**04-NOV-2015 01:28:10
**Ends**04-NOV-2015 01:31:02
Planning ODS Load process succeeded.
+---------------------------------------------------------------------------+
Start of log messages from FND_FILE
+---------------------------------------------------------------------------+
04-NOV 01:27:51 : Purge Batch Size is set to : .
04-NOV 01:27:51 : Procedure MSC_CL_SUPPLY_ODS_LOAD.LOAD_SUPPLY started.
04-NOV 01:27:51 : load_supply
04-NOV 01:27:51 : Load supply: not found:
04-NOV 01:27:51 : OTHER========================================
04-NOV 01:27:51 : Error in PROCEDURE=LOAD_SUPPLY, TABLE=MSC_SUPPLIES
04-NOV 01:27:51 : COLUMN=MSC_CL_ITEM_ODS_LOAD.ITEM_NAME, VALUE=PM-TP-00305
04-NOV 01:27:51 : COLUMN=ORGANIZATION_CODE, VALUE=UJA:UHT
04-NOV 01:27:51 : COLUMN=ORDER_TYPE, VALUE=On Hand

04-NOV 01:27:51 : ORA-00904: "ALTERNATE_ROUTING_DESIGNATOR": invalid identifier

04-NOV 01:27:51 : OTHER========================================
04-NOV 01:27:51 : Error in PROCEDURE=LOAD_SUPPLY, TABLE=MSC_SUPPLIES
04-NOV 01:27:51 : COLUMN=MSC_CL_ITEM_ODS_LOAD.ITEM_NAME, VALUE=RM-ST-00121
04-NOV 01:27:51 : COLUMN=ORGANIZATION_CODE, VALUE=UJA:UHT
04-NOV 01:27:51 : COLUMN=ORDER_TYPE, VALUE=On Hand
04-NOV 01:27:51 : ORA-00904: "ALTERNATE_ROUTING_DESIGNATOR": invalid identifier
04-NOV 01:27:51 : Load supply: not found:
04-NOV 01:27:51 : OTHER========================================

Solution :
1. Make sure profile is set to MRP: Consume MDS = No
2. Confirm the following file versions :
$MSC_TOP/patch/115/sql/MSCCLJAB.pls 120.34.12020000.17
You can use the commands like the following:
strings -a $MSC_TOP/patch/115/sql/MSCCLJAB.pls |grep '$Header'

If the version is lower than it, such as :

MSCCLJAB.pls 120.34.12020000.12
 Then you should apply patch :
21680334:R12.MSC.C

DOC.ID = 1970718.1

41. Memory Based Planner completed error

value used for ROWS parameter changed from 1000 to 40
Record 1989: Rejected - Error on table MSC.MSC_DEMANDS, column OLD_DEMAND_DATE.
ORA-01861: literal does not match format string

MAXIMUM ERROR COUNT EXCEEDED - Above statistics reflect partial run.

Table MSC.MSC_DEMANDS:
1988 Rows successfully loaded.
1 Row not loaded due to data errors.
0 Rows not loaded because all WHEN clauses were failed.
0 Rows not loaded because all fields were null.

Space allocated for bind array: 984720 bytes(40 rows)

Read buffer bytes: 1048576

Total logical records skipped: 0

Total logical records read: 1994
Total logical records rejected: 1
Total logical records discarded: 0

Loader_Worker_With_Direct_Load_170815_2.txt
=======================================
value used for ROWS parameter changed from 1000 to 147
Record 323: Rejected - Error on table MSC.MSC_EXCEPTION_DETAILS, column DATE1.
ORA-01861: literal does not match format string

MAXIMUM ERROR COUNT EXCEEDED - Above statistics reflect partial run.

Table MSC.MSC_EXCEPTION_DETAILS:
322 Rows successfully loaded.
1 Row not loaded due to data errors.
0 Rows not loaded because all WHEN clauses were failed.
0 Rows not loaded because all fields were null.

Space allocated for bind array: 999306 bytes(147 rows)

Read buffer bytes: 1048576
 Total logical records skipped: 0
Total logical records read: 441
Total logical records rejected: 1
Total logical records discarded: 0

Run began on Mon Aug 17 12:58:55 2015

Run ended on Mon Aug 17 12:58:55 2015

Elapsed time was: 00:00:00.05

CPU time was: 00:00:00.00

Solution :

For 64 bit environment, the below profiles drivers the plan to use 64 bit exe.

MSC: 64-bit Planner Platform

MSC: Enable 64 bit snapshot

For 32 bit environment, these profiles should not be set so that plan will use 32 bit exe

42. Copy Plan Options Failed

Solution :
Query to check free flag in Partition Number :

select plan_id,
plan_name,
free_flag,
partition_number
from msc_plan_partitions;

Create Plan Partitions for the plan to get created

43. Launch ASCP Plan took a long time, running almost about 1.5 hours
The log :

prs: Capacity>0
activity 41982-100-/ [29837..29837] [29838..29838] totalCapacity = [1], capUsedByTask = [1], npt =
[1], tpt = [1] alt index value = 0
Saving solution for operation 41982, start time: 29249 becomes 29837 and end time: 29250
becomes 29838 - saving
saveSolution for op 41982 : [29837,29838]
committing HLS time table for operation 41982
recalling solution for operation 41982
committing HLS time table for operation 41982
After RIGHT JUSTIFY justification, YES afterSched noHLK operation scheduled 41982 29837 - 29838
operation: 41983 is selected for 'RightJustify' is SDS 0
justifying Operation 41983, Justify Type = RIGHT JUSTIFY
 Scheduling operation back 2X or fail 41983
operation 41983 [29248..29836] - [29249..29837], JIT -137
activity 41983-100-/ [29248..29836] [29249..29837] totalCapacity = [1], capUsedByTask = [1], npt =
[1], tpt = [1] alt index value = 0
Operation 41983no choice point created
in setOperationAlternatesAndCapacitiesForPropagationIfRequired
Scheduling operation backward 41983 29248..29836 29249..29837
scheduling activity 41983-100-/ backward
scheduling activity 41983-100-/
Total processing time more than needed
Activity 41983-100-/ => select alternate backward
there is no choice
scheduling activity backward
prs: Capacity>0
/oracle/DEV/data/UUAT/apps/fs1/EBSapps/appl/mso/12.0.0/bin/MSONWL64.exe
Program was terminated by signal 9

Solution :
1. Please check Fixed Order Quantity in Organization Item
2. If it has found Fixed Order Quantity in small size one, please remove unwanted Fixed Order
Quantity in Org Item Level

44. Memory Based Planner 64-bit Linux completed error

The Log File :

PROBLEM
-------------
MSONWL64 module: Memory Based Planner 64-bit Linux
+---------------------------------------------------------------------------+

TIMER: in phase 2, non firmed ops computeexceptions for demand 6 time = 0

TIMER: slice 1 phase 2 time = 0
TIMER: slice 1 phase 2 time = 0
HLSHeuristic2: --------- START OF PHASE 3 -------------
Fatal error, aborting
HLSMathModel::schedule
### Error: RightJustify Phase failed
/u01/oracle/UPROD/fs1/EBSapps/appl/mso/12.0.0/bin/MSONWL64.exe
Program exited with status 113

Solution :
Your plan shows Org UJA:SCM. The calendar attached is far too short and ends before the end of the
planning horizon.

29-DEC-14 31-DEC-15 UJA:UJ_SCM_CAL

1. Please extend calendar UJA:UJ_SCM_CAL out to 31-DEC-25

 2. Tools-> Rebuild
3. Run collections to pick up change.
4. Launch plan again.

45. Refresh APCC Materialized Views Completed Error

msc_phub_pkg.refresh_mvs.exception: ORA-00942: table or view does not exis

Cause :
They were not using Demantra, and the profile value for "MSD_DEM: Schema" was set (on the VCP
instance)

Solution :
1) Set the "MSD_DEM: Schema" profile value to NULL on the VCP instance.

2) Re-run the 'Refresh APCC Materialized Views' concurrent program. Make sure it completes
without warning.

46. ORA-20001: MSCDROPS: Error in Dropping Snapshots Process : ORA-20001:

Error while executing:-DROP MATERIALIZED VIEW AHL.AHL_VISITS_SN(1): ORA-
00933: SQL command not properly ended
ORA-06512: at line 2108
When Planning Data Pull  Drop Changed Snapshots

Solution :
Apply Patch

47. Error in PROCEDURE=LOAD_STAGING_SUPPLY, TABLE=MSC_SUPPLIES

COLUMN=MSC_CL_ITEM_ODS_LOAD.ITEM_NAME, VALUE=AG-AC0-001
COLUMN=ORGANIZATION_CODE, VALUE=TST:SPB
COLUMN=ORDER_TYPE, VALUE=Purchase order
ORA-01400: cannot insert NULL into
("MSC"."SUPPLIES_TST"."NEW_SCHEDULE_DATE")

Cause :
This issue occurred because for the problem Purchase Order both Need by Date as well as Promised
Date were NULL. Since both the two date columns have NULL value the dock date and eventually
the due date gets calculated as NULL. Consequently the collection process tries to insert NULL in the
date column of MSC_SUPPLIES. Since this column is not NULLable, insertion fails, this particular PO
gets rejected and Planning ODS Load Worker completes in warning
 Solution :
The problem Purchase Order needs to be manually corrected for the issue to be resolved

1. In order to find out the list of such Purchase Orders that can have impact on Data Collections,
please run the following query on the source instance.
SELECT PO_NUMBER,
PO_LINE_LOCATION_ID
FROM MRP_AP_PO_PO_SUPPLY_V
WHERE PROMISED_DATE IS NULL
AND NEED_BY_DATE IS NULL;

2. To verify that the columns are indeed NULL for these Purchase Orders, run the following query,
again on the source instance.

SELECT PO_HEADER_ID,
PO_LINE_ID,
LINE_LOCATION_ID,
NEED_BY_DATE,
PROMISED_DATE
FROM PO_LINE_LOCATIONS_ALL
WHERE LINE_LOCATION_ID IN
(SELECT PO_LINE_LOCATION_ID
FROM MRP_AP_PO_PO_SUPPLY_V
WHERE PROMISED_DATE IS NULL
AND NEED_BY_DATE IS NULL);

3. Go into the responsibility: Purchasing Super User (or any other responsibility through
which the returned Purchase Orders can be modified).

4. Navigate to Purchase Orders > Purchase Orders.

5. Query for the Purchase Order

6. For the appropriate line enter Need-By and/or Promised dates

7. Repeat steps 5 and 6 for each Purchase Order returned by the above queries.

8. Run the query below to verify that no rows are returned.

SELECT PO_NUMBER,
PO_LINE_LOCATION_ID
FROM MRP_AP_PO_PO_SUPPLY_V
WHERE PROMISED_DATE IS NULL
AND NEED_BY_DATE IS NULL;

9. Launch Data Collection to retest the issue.

10. Migrate the solution as appropriate to other environments.

48. Load Worker Completed Error

Record 292: Rejected - Error on table "MSC"."MSC_RESOURCE_REQUIREMENTS#",
column DAILY_RESOURCE_HOURS.
ORA-01722: invalid number

MAXIMUM ERROR COUNT EXCEEDED - Above statistics reflect partial run.

Table "MSC"."MSC_RESOURCE_REQUIREMENTS#":
274 Rows successfully loaded.
1 Row not loaded due to data errors.
19 Rows not loaded because all WHEN clauses were failed.
0 Rows not loaded because all fields were null.

Cause :
If you review the .bad file shown in the log file you will notice the column daily_resource_hours = inf
which means infinite and thus the failure. The plan is failing because WIP jobs have completion
dates BEFORE the start dates. Example data:

SUPPLY_ID WIP_ENTITY_ID START_DATE END_DATE

16777723 423656 10-Aug-10 9-Aug-10
16777723 423656 10-Aug-10 9-Aug-10
16777724 423646 11-Aug-10 10-Aug-10

Solution :

To implement the solution, please execute the following steps:

1. Run on Destination(Planning) instance.

select supply_id , WIP_ENTITY_ID ,daily_resource_hours, start_date, end_date

from msc_resource_requirements
where plan_id=-1 and trunc(start_date)> trunc(end_date)

This will give you all wip entity id's that have END_DATE<START_DATE in
MSC_RESOURCE_REQUIREMENTS.

SUPPLY_I WIP_ENTITY_I DAILY_RESOURCE_HOU START_DAT END_DAT

D D RS E E
16777723 423656 10-Aug-10 9-Aug-10
16777723 423656 10-Aug-10 9-Aug-10
16777724 423646 11-Aug-10 10-Aug-10

2. Then on Source:

You will enter the id's returned from above script and add a /2.

select WIP_ENTITY_ID,ORGANIZATION_ID,WIP_ENTITY_NAME
from WIP_ENTITIES
where WIP_ENTITY_ID in (423656/2,423646/2);

You will enter the id's returned from above script and add a /2. This will give you the discrete
jobs that need fixed on source.

2. Run collections again.

3. Re-run the plan and it should go through successfully.

49. When attempting to run collections for the first time MSCTRIGS fails with the message
below. Subrequests all finish successfully.

ERROR
-----------------------

MSCTRIGS module: Collections Triggers

+---------------------------------------------------------------------------+

**Starts**08-MAY-2012 09:35:09
**Ends**08-MAY-2012 09:46:39
Error in creating Source Triggers

08-MAY 09:35:09 : Request : 421162 :Creates Item Triggers used by Collections Process
08-MAY 09:35:09 : Request : 421163 :Creates BOM Triggers used by Collections Process
08-MAY 09:35:09 : Request : 421164 :Creates Routing Triggers used by Collections Process
08-MAY 09:35:09 : Request : 421165 :Creates WIP Triggers used by Collections Process
08-MAY 09:35:09 : Request : 421166 :Creates Demand Triggers used by Collections Process
08-MAY 09:35:09 : Request : 421167 :Creates Supply Triggers used by Collections Process
08-MAY 09:35:09 : Request : 421168 :Creates Other Triggers used by Collections Process
08-MAY 09:35:09 : Request : 421169 :Creates Repair Order Triggers used by Collections
Process
08-MAY 09:35:09 : select
NVL(FND_PROFILE.VALUE('MSC_ASCP_IGNORE_CMRO_EAM_WO'),1) from dual
08-MAY 09:35:09 : select
NVL(FND_PROFILE.VALUE('MSC_ASCP_IGNORE_CMRO_EAM_WO'),1) from dual

To implement the solution, please execute the following steps:

1. Go into the responsibility: system administrator

2. Navigate to concurrent - manager - define

3. query for standard manager, click on workshifts and increase processes to 15

4. Retest the issue.

5. Migrate the solution as appropriate to other environments