Inconsistent MRP results

Dear Sir / Madam
Our users are continuously complaining that the MRP results are inconsistent. We are using MD61 transaction for entering Planned Independant Requirements. Planning run is executed using 1 3 1 3 1 parameters in md01. We are using multi level BOMs. Backflush indicator 1. Strategy group for BOM components is 40. Strategy group 11 is used for FG.
KIndly suggest how to get consistent MRP results.
Thanks in advance.

Dear Sagar ,
I would like to comment on the same issue that MRP  is one of the most  high level functionality in SAP specially in supply chain  , which is intregarted with core module like MM-SD-PP-PS-FICO etc .
There are two different aspect which one should be very much aware about MRP : Excution of MRP  based on business requirement based on Demand situation  and Analysing the MRP result for decision making  as a planner ( Why did it happen -What needs to be done ) .There are bvarious exception messages MRP generates in MD04-Dyanamic result which indicates the reason and needs farther investigation to conclude on the result .
Now in your case , as you have mentioned some of the activity . I would suggest the following :
1.Re-check the MRP excution parameters selection  in MD01/MD02/MD03  ( Processing Key -NETCH , Create PR-2 OR 1 , MRP List -3 , Scheudle Line -3 , Planning Mode -1 for frist time , 3-Delete and re-create  )
2.Check all the MRP1-MRP4 parameters .Specially for depedent compoenets , you must have BOM explosion and selection methods  is important and OPPQ-Carry all over all plant parameters -BOM explosion is very important .
3.If you delete planned order , then open demand or current demand will be treated in MRP  and it will generate planned order based on the planning horzon or Process key seletion .
4.Finally , it needs extensive training and understanding for user level to have clarity on MRP concept .
Hope its helps
Reagrds
JH

Similar Messages

  • Send the MRP results through mail to the user.

    Dear SAP Gurus,
      My client have a requirement where in they want that the MRP results as displayed in MRP list should be sent through mail to the user after the MRP run. Is it possible through the standard functionality ?
    Regards'
    Ankush

    Dear ,
    In MD04/MD05 -Check there is an option called Sending e-mail at the header ( Envelope sysmbol ) .From here you can send e-mail to MRP Controller if your user is identified  as MRP Controller .
    In Customizing for MRP, you can maintain a mail link to inform an MRP controller by using the mail connection function you can do it.In Customizing for MRP, you have entered a mail recipient (individual recipient or recipient group) for the MRP controller in the IMG activity Define MRP controller. You can also integrate the sending of the mail into a workflow .
    If you want to send the mail directly to just one MRP controller and include the MRP list or stock/requirements list automatically, you can use the function for variable printing. When using variable printing, the data is displayed in the form of a list that can be processed and printed. A separate mail function also appears, which you can use to send this print list.
    MRP controller will get mail in that case you are planned to use Workflow to trigger mails for a given condition of MRP evaluation.
    SPROMRP- -EvalutionActivate workflow  mail to mrp controller .Also check SAP Note 426648
    Explore this above functionality with this information and try to check the same
    Regards
    JH

  • New report to analyze MRP result.

    Hi all,
    Is there any report other than MD04 to analyze MRP result in order to get details for a given material or multiple materials. The details like SO, Forecast (from MD63), PO arrival, PR with respect to the material or materials?
    Regards,
    Brijesh

    Hi ,
    You Can check MD4C and CO46 where multilevel order details can be seen and for each line item if double click will display MD04 screen at the bottom.
    Hope these are the reports you are looking for .

  • MRP RESULT TABLE

    Hi I am developing a report to display the MRP results collectively.
    what is the table from which i can get the MRP results like current stock, Purchase requisition and purchsae orders for various time periods.
    Solai
    [email protected]

    Hi ,
    U can also look into table MDKP - Header Data for MRP Document alongwith MDTB .
    Hope this helps.

  • MRP Results

    Hi All,
    I've managed to come out with the MPR results using Crystal Report 2010 using crosstab.
    My question is,
    How can i get the date and workweek as shown in B1 MRP results?
    Refer to screenshot below.
    The columns is basically MSN2.PeriodID
    But if i were to output it directly from B1 using the MRP.
    I will get output like this.
    How can i get that kind of value to show in Crystal report?
    Which table should i get it from?
    What condition should i use?
    Thank you very much for your help.

    Hi Adrian,
    To get the table info, joins etc, please repost to the SAP Business One Application space.
    -Abhilash

  • MRP result analysis report

    Dear friends
    i am trying to go back to old MRP results to see how a certain material was handeled, i am looking
    for a reports where i can see the result acoording to date and material , at the moment i have only
    Tcode - MDLD  which print out all results page by page for each single part.
    are you familiar with some helpful report.
    thank you in advance.
    david

    Dear David,
    In my understanding the reports MDLD or MD06 ,MD45,MD46 can help you.
    Regards
    Mangalraj.S

  • MRP result differences for PD, HB setting materials

    Hi all,
    I have two materials which were set with PD and HB.  But the MRP results were calculated differently.
    Material A - planned order with correct quantity was generated.  The quantity was calculated as ' maximum stock level minus availability stock'
    Material B - planned order with the quantity to replenish only shortage was generated.  Maximum stock level was not used for calculating the planned order quantity.
    Could you please provide me the answer why two different result were generated?
    Thanks for your support!!!

    Thank you for all the response.
    However, MRP type, checking rule, lot size key setting are both same.
    Detailes results are as follows;
    Material A   Max. stock level  45,000g (Round value 1000g)
    Date           MRP element     Required Qty      Available Qty
    2009/6/12   Stock                 24,849.56           24,849.56
    2009/6/12   Safety Stock          -15,000             9,849.56
    2009/6/18   Ord Res                   -4,957             4,892.56
    2009/6/26   Planned Ord            26,000            30,892.56
    2009/6/26   Ord Res                  -4,957             25,935.56
    Material B   Max. stock level   14,550g (Rounding value 100g)
    2009/6/12   Stock                 14,527.90           14,527.90
    2009/6/12   Safety Stock            -4,850             9,677.90
    2009/6/15   Ord Res             -10,086.87              -408.97
    2009/6/15   Ord Res              -1,048.74            -1,457.71
    2009/6/19   Planned Ord             1,500                  42.29
    For the material B, only the shortage quantity is proposed by SAP irrespective of the max. stock level.

  • SAP MRP Results

    Hoping to find some help here from some knowledgeable experts:
    Situation: Trying to create an program to extract MRP results out of SAP(basically what you see in MD04).
    Question 1: Does anyone know a way using the ABAP interface to determine if a part has "activity" (has supply or demand or onhand) prior to performing a bunch of expensive queries? I really only want to extract the parts that have this but I can't figure out how to do this efficently.
    Question 2: Trying to find an easy way to understand what SAP considers the a) Total active demand for a part is, b) Total active supply for a part is and c) Ending inventory balance based on MRP results. Does anyone know of a way to efficently determine this on a part by part basis?
    Thanks in advance for any help anyone can provide me!
    Regards,
    Kris

    Kris,
    MD04 does not extract MRP results, MRP results are extracted and displayed in MD05.  MD04 only shows you the 'current' situation.
    Question 1: Does anyone know a way using the ABAP interface to determine if a part has "activity" (has supply or demand or onhand) prior to performing a bunch of expensive queries? I really only want to extract the parts that have this but I can't figure out how to do this efficently.
    I am not aware of a single and easy comprehensive way to determine whether a material has supply or demand elements.  FYI even SAP's MRP does not attempt to make this determination.  Instead, it either reviews ALL materials (regenerative MRP) or it uses the Planning file (Net Change MRP) to determine which materials have had activity since the previous MRP run.
    Question 2: Trying to find an easy way to understand what SAP considers the a) Total active demand for a part is, b) Total active supply for a part is and c) Ending inventory balance based on MRP results. Does anyone know of a way to efficently determine this on a part by part
    MRP uses different methods to determine supply and demand, depending on the type of planning being used. Planning is dependent on MRP type and Planning Strategy.  MD04 uses different but related methods from those used by MRP. Check out some basic online help about
    MRP Planning Process
    http://help.sap.com/saphelp_erp60_sp/helpdata/EN/5c/33b8371a2c9912e10000009b38f889/frameset.htm
    Overview of MD04 (Stock Requirements list)
    http://help.sap.com/saphelp_erp60_sp/helpdata/EN/f4/7d2f3844af11d182b40000e829fbfe/frameset.htm
    I don't know what your business requirements are, but MRP Calculations and MD04 calculations are some of the more involved within SAP MM and PP.  Exactly duplicating the results of either of these tools IN ALL SITUATIONS is a daunting task.  You should consider cloning MD04 or MD05 and then modding the result to meet your business requirements.  Another possibility is to make use of the userexits within MD04/MD05 to alter the display to meet your requirements.
    Rgds,
    DB49

  • MRP result Exception No., 61  "Scheduling: Customizing inconsistent"

    Dear All hi,
    After running MRP iam getting the exception message 61 as "Scheduling: Customizing inconsistent" in MD04 screen for FERT
    Please help

    Hi Shaiz,
    The Reason for getting Exceptiom message is "The scheduling data Maintained in the Customizing settings are not consistent for the material".
    May be Routing selction Id u have defined at OPPQ is  not matched with ur routing u have cerated at ca01(Like type,usage,status, valid date.).
    I hope u have "acitavated scheduling"   check Box and all other  at "para detailed schedu" and OPU5
    Please do scheduling for Planned order or convert to production order  & see the routing selection
    Regards
    Pradeep

  • Inconsistent SDO_RELATE results when querying 2.5D data

    Oracle 11.1.0.7 with Patch 8343061 on Windows Server 2003 32bit.
    I'm getting inconsistent results from SDO_RELATE results when querying 2.5D data. Some geometries I expect to be OVERLAPBDYDISJOINT, are not always being returned by SDO_RELATE when using the OVERLAPBDYDISJOINT mask. It seems that the order of the tables makes a difference to the result.
    Here's a table with one 2.5D geometry and a 2D index:
    CREATE TABLE TEST1 (
    ID                NUMBER PRIMARY KEY,
    GEOMETRY     SDO_GEOMETRY);
    INSERT INTO TEST1 (id, geometry) VALUES (
    1,
    SDO_GEOMETRY(3002, 2157, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(561695.935, 834005.726, 25.865,
    561696.229, 834005.955, 25.867, 561686.278, 834015.727, 26.088, 561685.179, 834019.771, 26.226, 561680.716, 834022.389, 26.226,
    561674.434, 834025.125, 26.171, 561671.963, 834032.137, 25.667, 561670.832, 834037.185, 25.619, 561667.946, 834042.976, 25.84,
    561666.717, 834047.218, 26.171, 561664.229, 834051.781, 26.778, 561660.041, 834055.935, 26.64, 561657.514, 834061.742, 26.53,
    561658.59, 834067.116, 27.882, 561657.67, 834070.739, 28.821, 561653.028, 834073.777, 29.042, 561653.234, 834078.769, 28.379,
    561658.336, 834080.105, 29.511, 561664.582, 834079.468, 31.94, 561669.257, 834075.821, 33.707, 561672.716, 834074.456, 33.707,
    561676.875, 834077.262, 33.735, 561675.868, 834081.55, 33.707, 561673.131, 834087.641, 33.679, 561672.208, 834093.502, 33.238,
    561668.578, 834100.894, 33.735, 561666.013, 834106.399, 33.679, 561661.408, 834111.23, 33.514, 561654.854, 834117.181, 33.486,
    561651.695, 834122.292, 33.569, 561649.112, 834128.847, 33.431, 561645.982, 834134.786, 33.293, 561642.485, 834141.235, 33.072,
    561642.138, 834150.085, 33.293, 561646.072, 834159.721, 36.578, 561647.274, 834165.532, 37.02, 561646.359, 834170.867, 37.02,
    561645.42, 834175.485, 36.799, 561642.44, 834180.977, 36.826, 561638.677, 834185.419, 36.771, 561636.693, 834194.824, 37.158,
    561635.462, 834202.105, 37.241, 561631.998, 834208.745, 37.268, 561628.871, 834213.994, 37.241, 561627.554, 834220.393, 37.82,
    561625.79, 834226.697, 39.532, 561620.561, 834236.494, 39.891, 561619.265, 834249.687, 39.697, 561619.883, 834260.02, 41.326,
    561620.977, 834264.399, 43.093, 561622.557, 834270.723, 43.452, 561622.172, 834276.978, 43.452, 561621.347, 834285.541, 43.479,
    561622.214, 834292.055, 43.645, 561619.718, 834302.583, 43.755, 561616.762, 834316.47, 43.755, 561608.842, 834328.241, 43.7,
    561606.346, 834334.93, 43.7, 561605.27, 834341.929, 43.7, 561603.925, 834350.648, 43.728, 561602.462, 834358.405, 43.838,
    561599.552, 834366.629, 44.031, 561594.551, 834374.291, 43.396, 561590.644, 834383.986, 43.065, 561588.48, 834392.21, 44.942,
    561586.923, 834397.32, 46.737, 561584.608, 834402.898, 49.299, 561581.389, 834410.194, 50.077, 561580.437, 834419.49, 51.907,
    561580.438, 834427.63, 53.127, 561582.245, 834433.389, 55.791, 561586.664, 834433.397, 57.503, 561593.88, 834433.608, 57.475,
    561596.305,834439.653, 57.42, 561591.804, 834445.862, 57.309, 561589.097, 834447.689, 57.014)));
    SELECT sdo_geom.validate_geometry_with_context(geometry, 0.0005) FROM TEST1;
    DELETE FROM user_sdo_geom_metadata WHERE table_name = 'TEST1' AND column_name = 'GEOMETRY';
    INSERT INTO user_sdo_geom_metadata VALUES ('TEST1','GEOMETRY', 
         MDSYS.SDO_DIM_ARRAY(
         MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
         MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005),      
         MDSYS.SDO_DIM_ELEMENT('Z',-10000,10000,0.0005)     
    ), 2157);
    DROP INDEX TEST1_SPIND;
    CREATE INDEX TEST1_SPIND ON TEST1(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=line sdo_indx_dims=2');And here's another table with a 2D geometry and a 2D index:
    CREATE TABLE TEST2 (
    ID                NUMBER PRIMARY KEY,
    GEOMETRY     SDO_GEOMETRY);
    INSERT INTO TEST2 (id, geometry) VALUES (
    1,
    SDO_GEOMETRY(2002, 2157, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(561816.516, 834055.581, 561819.504, 834057.173,
    561817.942, 834060.818, 561810.044, 834078.997, 561805.576, 834087.634, 561801.572, 834094.299, 561798.558, 834100.467,
    561796.254, 834107.637, 561793.754, 834115.605, 561794.049, 834123.694, 561793.698, 834130.518, 561792.905, 834138.883,
    561787.867, 834145.772, 561782.544, 834150.548, 561777.707, 834156.53, 561773.945, 834161.32, 561771.061, 834166.957,
    561768.155, 834173.131, 561764.735, 834178.744, 561759.603, 834187.782, 561756.146, 834195.493, 561753.416, 834198.821,
    561754.141, 834205.691, 561756.768, 834209.681, 561757.217, 834216.701, 561753.086, 834232.46, 561744.371, 834254.589,
    561740.936, 834263.001, 561737.198, 834272.208, 561732.231, 834284.915, 561730.52, 834297.01, 561728.339, 834310.053,
    561727.825, 834328.069, 561730.461, 834342.992, 561729.808, 834367.948, 561730.216, 834396.988, 561732.273, 834419.047,
    561732.783, 834424.668, 561731.647, 834432.212, 561731.872, 834439.436, 561731.39, 834449.269, 561732.041, 834462.813,
    561733.583, 834471.926, 561733.229, 834485.049, 561730.868, 834498.462, 561726.379, 834512.59, 561725.776, 834528.932,
    561727.488, 834555.23, 561729.357, 834577.873, 561731.05, 834595.931, 561731.163, 834611.928, 561734.057, 834637.031,
    561732.67, 834636.4, 561725.401, 834633.796, 561721.039, 834632.493, 561718.777, 834632.167, 561710.437, 834632.888,
    561647.929, 834636.658, 561644.963, 834630.085, 561632.796, 834629.813, 561625.553, 834627.647, 561620.473, 834626.711,
    561608.718, 834624.94, 561599.935, 834619.684, 561596.67, 834613.843, 561594.27, 834607.774, 561592.513, 834601.752,
    561591.349, 834593.899, 561597.265, 834584.888, 561595.956, 834571.479, 561595.075, 834556.196, 561593.997, 834539.68,
    561594.316, 834528.071, 561595.261, 834516.44, 561595.538, 834504.804, 561597.227, 834497.417, 561599.3, 834490.416,
    561601.265, 834482.61, 561605.126, 834475.502, 561599.232, 834473.683, 561593.076, 834471.379, 561599.154, 834451.112,
    561589.097, 834447.689, 561591.804, 834445.862, 561596.305, 834439.653, 561593.88, 834433.608, 561582.245, 834433.389,
    561580.438, 834427.63, 561580.437, 834419.49, 561581.389, 834410.194, 561584.608, 834402.898, 561586.923, 834397.32,
    561588.48, 834392.21, 561590.644, 834383.986, 561594.551, 834374.291, 561599.552, 834366.629, 561602.462, 834358.405,
    561603.925, 834350.648, 561605.27, 834341.929, 561606.346, 834334.93, 561608.842, 834328.241, 561616.762, 834316.47,
    561619.718, 834302.583, 561622.214, 834292.055, 561621.347, 834285.541, 561622.172, 834276.978, 561622.557, 834270.723,
    561620.977, 834264.399, 561619.883, 834260.02, 561619.265, 834249.687, 561620.561, 834236.494, 561625.79, 834226.697,
    561627.554, 834220.393, 561628.871, 834213.994, 561631.998, 834208.745, 561635.462, 834202.105, 561636.693, 834194.824,
    561638.677, 834185.419, 561642.44, 834180.977, 561645.42, 834175.485, 561646.359, 834170.867, 561647.274, 834165.532,
    561646.072, 834159.721, 561642.138, 834150.085, 561642.485, 834141.235, 561645.982, 834134.786, 561649.112, 834128.847,
    561651.695, 834122.292, 561654.854, 834117.181, 561661.408, 834111.23, 561666.013, 834106.399, 561668.578, 834100.894,
    561672.208, 834093.502,561673.131, 834087.641, 561675.868, 834081.55, 561676.875, 834077.262, 561672.716, 834074.456,
    561669.257, 834075.821, 561664.582, 834079.468, 561658.336, 834080.105, 561653.234, 834078.769, 561653.028, 834073.777,
    561657.67, 834070.739, 561658.59, 834067.116, 561657.514, 834061.742, 561660.041, 834055.935, 561664.229, 834051.781,
    561666.717, 834047.218, 561667.946, 834042.976, 561670.832, 834037.185, 561671.963, 834032.137, 561674.434, 834025.125,
    561680.716, 834022.389, 561685.179, 834019.771, 561686.278, 834015.727, 561696.229, 834005.955, 561695.935, 834005.726,
    561677.805, 833994.91, 561683.163, 833985.817, 561703.01, 833949.434, 561725.891, 833961.856, 561744.35, 833971.197,
    561768.396, 833983.86, 561777.842, 833988.883, 561798.333, 833999.743, 561797.243, 834005.725, 561783.574, 834040.515,
    561798.127, 834046.391, 561807.001, 834050.509, 561816.516, 834055.581)));
    SELECT sdo_geom.validate_geometry_with_context(geometry, 0.0005) FROM TEST2;
    DELETE FROM user_sdo_geom_metadata WHERE table_name = 'TEST2' AND column_name = 'GEOMETRY';
    INSERT INTO user_sdo_geom_metadata VALUES ('TEST2','GEOMETRY', 
         MDSYS.SDO_DIM_ARRAY(
         MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
         MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005)
    ), 2157);
    DROP INDEX TEST2_SPIND;
    CREATE INDEX TEST2_SPIND ON TEST2(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=line sdo_indx_dims=2');Now if I check how these two geometries relate to each other, the answer is OVERLAPBDYDISJOINT, which makes sense when inspecting the geometries.
    SQL> SELECT
      2  sdo_geom.relate(t1.geometry, 'determine', t2.geometry,  0.0005) relate_1_to_2,
      3  sdo_geom.relate(t2.geometry, 'determine', t1.geometry,  0.0005) relate_2_to_1
      4  FROM test2 t2, test1 t1
      5  WHERE t1.id = t2.id;
    RELATE_1_TO_2        RELATE_2_TO_1
    OVERLAPBDYDISJOINT   OVERLAPBDYDISJOINT
    1 row selected.So, I'd expect this query to return something...
    SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry,  0.0005) relate
    FROM test2 t2, test1 t1
    WHERE sdo_relate(t1.geometry, t2.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
    AND t1.id = 1
    AND t2.id = 1;Nada. And this...
    SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry,  0.0005) relate
    FROM test1 t1, test2 t2
    WHERE sdo_relate(t2.geometry, t1.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
    AND t1.id = 1
    AND t2.id = 1;Nada.
    And this...
    SQL> SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry,  0.0005) relate
      2  FROM test2 t2, test1 t1
      3  WHERE sdo_relate(t2.geometry, t1.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
      4  AND t1.id = 1
      5  AND t2.id = 1;
            ID         ID RELATE
             1          1 OVERLAPBDYDISJOINT
    1 row selected.This version gives the right answer.
    Can anyone explain this?

    Hi,-
    I think you are running into these bugs 7158518 and 7710726.
    Could you please request the patch for the bugs so that they are published on Metalink
    if they dont exist there?
    Please let us know if these fix your problem.
    Best regards
    baris

  • Inconsistent Query Result in SEM-BCS using Virtual Info Provider

    We have just upgraded to BW 7.0 and SEM-BCS 6.0. When we run an existing 3.5 BW query for BCS through the Virtual Info Provider against the basic consolidation cube, we are getting inconsistent results. Sometimes we get the correct result, and other times our results are not rolling up correctly causing an out of balance on our balance sheet query. We did not make any hierarchy changes between the query executions. Has anyone else experienced this? We cannot see the cause of the inconsistency. Everything looks good when running through RSRT DEBUG. Any help on pushing us in the right direction to solve this would be appreciated. 
    Thanks,
    Rob

    Hi Rob,
    Could you please let me know how you have resolved this issue? Thanks.
    Regards,
    Ashok

  • LTP MRP results doesn't show not firmed receipt elements like PRs, Plan Ord

    Hi,
    I have ran the LTP MRP using a particular planning scenario, but the results doesn't show any Purchase requisitions, Planned Orders, etc in the long-term window. It shows only firm receipt elements like Purchase Orders, Production Orders only. Any reasons behind this? Thanks
    Raj

    Dear,
    Check: Re: Long Term Planning
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PPMPLTP/PPMPLTP.pdf
    LTP -MRP Problem
    Regards,
    Syed Hussain.

  • Table for MRP results

    Dear all,
    Is there any table in which the results of MRP run are stored?
    I want to pick up some of the data for a report.
    Thank you,
    Shrenik

    Dear Shrenik,
    check in these tables,
    MDKP                           Header Data for MRP Document                           
    MDTB                           MRP Table                                              
    MDVL                           Planning file entry for long-term planning             
    MDVM                           Entry in MRP File                                      
    PBVPV                          Material index for consumption of planning             
    PLAF                           Planned order                                          
    REUL                           Material stock transfer reservation index              
    SAFK                           Run Schedule Master Data                               
    T024D                          MRP controllers                                        
    T436A                          Floats for scheduling                                  
    T437V                          Distribution key in MRP                                
    T437W                          MRP distribution key (texts)                           
    T438A                          MRP Type                                               
    T438S                          Text describing the range of coverage profile          
    T438T                          MRP description                                        
    T438X                          MRP group text                                         
    T439F                          Handling of planning flag at abnormal termination      
    T439L                          Warehouse costs for MRP lot size                       
    T439T                          Texts for lot-sizing procedures                        
    T440A                          Change fields for MRP                                  
    T440B                          Control table for creating MRP record                  
    T440F                          Exception messages for the forecast                    
    T440Z                          Allocate error -> error class in the forecast          
    T449A                          Period split                                           
    T449B                          Period split: language-dependent description           
    T450                           MRP transaction control                                
    T457A                          Processing key for planning run                        
    T457C                          Transaction calls control                              
    T457S                          Block table for MRP and forecast run                   
    T457T                          Description of MRP elements                            
    T458B                          Description of exception messages                      
    T460A                          Special procurement key                                
    T460B                          Special Procurement Key Conversion                     
    T460C                          Order/Purchase order types for planned order           
    T460D                          Order/Purchase order types for planned order           
    T460T                          Texts for special procurement keys                     
    T461P                          Planning strategy group                                
    T461S                          Planning strategies                                    
    T461T                          Planning strategy text                                 
    T461X                          Planning strategy group text                                                                               
    Regards
    Mangalraj.S

  • Getting Inconsistent Query Results

    I am getting inconsistent results when trying to filter data based on the DATETIME stamp. Any help will be appreciated.
    Here is my table information.
    TableA:
    SR DATE
    15     8/30/2007 9:34:41 AM
    16     9/4/2007 1:03:38 PM
    17     9/4/2007 2:50:48 PM
    18     9/4/2007 3:04:03 PM
    19     9/5/2007 11:47:58 AM
    20     9/5/2007 12:16:23 PM
    21     9/6/2007 3:34:38 PM
    22     9/6/2007 3:43:27 PM
    23     9/6/2007 3:46:27 PM
    24     9/7/2007 10:14:26 AM
    25     9/7/2007 10:16:11 AM
    26     9/18/2007 1:03:47 PM
    27     9/19/2007 9:31:14 AM
    28     9/19/2007 9:44:36 AM
    29     9/19/2007 4:18:05 PM
    30     9/21/2007 10:44:52 AM
    Now if I execute this query,
    SELECT * FROM TableA WHERE DATE >= '9/3/2007 9:34:41 AM'
    Result (Missing all 2 digit dates:
    16     9/4/2007 1:03:38 PM
    17     9/4/2007 2:50:48 PM
    18     9/4/2007 3:04:03 PM
    19     9/5/2007 11:47:58 AM
    20     9/5/2007 12:16:23 PM
    21     9/6/2007 3:34:38 PM
    22     9/6/2007 3:43:27 PM
    23     9/6/2007 3:46:27 PM
    24     9/7/2007 10:14:26 AM
    25     9/7/2007 10:16:11 AM
    If I change the day in query to 2 digit then I am getting correct results.
    SELECT * FROM TableA WHERE DATE >= '9/03/2007 9:34:41 AM'
    But If I run this query:
    SELECT * FROM TableA WHERE DATE >= '9/05/2007 9:34:41 AM'
    Results (Getting all the dates even less than '9/5/2007':
    16     9/4/2007 1:03:38 PM
    17     9/4/2007 2:50:48 PM
    18     9/4/2007 3:04:03 PM
    19     9/5/2007 11:47:58 AM
    20     9/5/2007 12:16:23 PM
    21     9/6/2007 3:34:38 PM
    22     9/6/2007 3:43:27 PM
    23     9/6/2007 3:46:27 PM
    24     9/7/2007 10:14:26 AM
    25     9/7/2007 10:16:11 AM
    26     9/18/2007 1:03:47 PM
    27     9/19/2007 9:31:14 AM
    28     9/19/2007 9:44:36 AM
    29     9/19/2007 4:18:05 PM
    30     9/21/2007 10:44:52 AM
    The results are so inconsistent with different combination, I could not figure out the main reason behind this.
    The datatype for this field in database is "VARCHAR2(250)" and because of some restrictions, I could not change datatype of this field in the table.

    SQL> DESC t;
    Name                                      Null?    Type
    COL                                                VARCHAR2(50)
    SQL> SELECT col FROM t ORDER BY col;
    COL
    8/30/2007 9:34:41 AM
    9/03/2007 9:34:41 AM
    9/05/2007 9:34:41 AM
    9/18/2007 1:03:47 PM
    9/19/2007 4:18:05 PM
    9/19/2007 9:31:14 AM
    9/19/2007 9:44:36 AM
    9/21/2007 10:44:52 AM
    9/3/2007 9:34:41 AM
    9/4/2007 1:03:38 PM
    9/4/2007 2:50:48 PM
    9/4/2007 3:04:03 PM
    9/5/2007 11:47:58 AM
    9/5/2007 12:16:23 PM
    9/6/2007 3:34:38 PM
    9/6/2007 3:43:27 PM
    9/6/2007 3:46:27 PM
    9/7/2007 10:14:26 AM
    9/7/2007 10:16:11 AMThe ones in bold are your predicate "dates". Do you see why it doesn't work as you expect?
    John

  • Inconsistent SELECT results in PL/SQL package

    Inside an Oracle package, I populate variables with "SELECT ... INTO ... FROM <table name> WHERE ...;"
    Should be straightforward, but I have found it inconsistent. Sometimes the variables are not populated, sometimes they are (using the same WHERE). Any possible reasons for this behavior?
    Edited by: user12236430 on Jan 31, 2012 5:46 AM

    user12236430 wrote:
    I'll bring a snippet home from the office with me. It doesn't throw the NO_DATA_FOUND exception, because one of the variables it (sometimes) populates is used in an INSERT later, and when it's not set I get a "Precision Error occurred" exception. It's straightforward PL/SQL as best I can tell, but I'll update with actual code later today.Could the select be reading NULL values?

Maybe you are looking for