Delta load -  request status is partially activated

Hi to All,
From one Info package data is loading to 1 CUBE, 1 ODS simaltaneously through PSA, but data is not updated to PSA. Then I have activated the ODS and then I changed the ODS request status to GREEN but here transfered records are 2000 but added records are 0, after few minuets data packets came into PSA then I am trying to CHANGE THE REQUEST ODS STATUS TO RED, IT IS SAYING "REQUEST IS PARTIALLY ACTIVATED".
In both ODS and CUBE manual updation terminating.
LOAD IS : DELTA
Pls can anyody give suggestions/inputs to come out from the problem.
Thanks In Adv,
MSM.

Hi Akash,
Here ODS request status is changed to(from RED ->GREEN) GREEN forcebly b'z red request is not activating the ODS, after ODS activation when I am trying to change the request status to RED, its saying " REQUEST IS PARTIALLY ACTIVATED NOT POSSIBLE TO CHANGE THE QM STATUS"
If we want to delete the request the REQUEST SHOULD BE IN RED, its allowing to change to RED
pls help me on this what can we do now
Thanks in Adv
MSM.

Similar Messages

  • Sales Document Delta Load Error - Status procedure could not be set

    Hello,
    I am getting the following error message during the sales document delta loads. It errors out in SMQ2 with this message - "Error in Validation (Details: transaction SMW01)"
    In SMW01, I get this message:
    <b>The status procedure CRMORD_I could not be set from item category XXX</b>.
    Message no. CRM_ORDERADM_I503
    Diagnosis
    Possible causes are:
    1. The system administrator has not assigned the status profile CRMORD_I to the object type.
    2. Initial statuses that should be set in the status profile CRMORD_I cannot be set at present.
    3. The current user RFCUSER does not have the authorization to set application statuses.
    Detailed error messages can be found in the following error log for status management.
    System response
    The status profile is not set in the document.
    Procedure
    Set the status profile in Customizing so that these cases do not occur.
    This status profile has been assigned to the item category mentioned and the RFCUSER has full authorization (SAP_ALL)
    Do any of you know what else could be the problem here?
    Thanks,
    MAX

    Dear All,
    I met similar error before, it happens when you change the item category in ECC but there is a status profile assigned to the item
    category in CRM with an active status set.
    In CRM, when the item category is changed, the system can only change (or delete) the status profile if there is no user status set for this item. So for example, if there is already a status set for an item (Say, E0001 'Open' is active) in CRM, so a change of the user status profile is impossible. If you need to change the item type, then you have to make sure that there is no active user status in the item.
    Please see note [1113116] point 2. This is a restriction in CRM. If you try to make the same changes directly in CRM you will also get the same error.
    It is not allowed to change the item category if the document has been saved and the status profile of the new item category is different from the old one.
    That is the reason why the error occurs when the data reaches CRM frm ECC.
    In order to prevent that there are sysfails in the inbound queue you can implement note [1438966] - after this is implemented you will not have the queues failing but you will get the error message in the sales order in CRM.
    You should ensure that the configuration for alternative item categories is R/3 is the same as in CRM and in this case all the alternative item categories should have no status profile or all the same status profile configured.
    I hope this could be helpful.
    Best regards,
    Maggie

  • Earlier loaded request status

    Hi Experts,
       In my validation program i am checking the source file format and triggering the respective process chain events to load data into BW(FILE->ODS1->ODS2->CUBE) . Now i would like to trigger process chain if the previous request status of ODS1,ODS2& CUBE are green only. I would lke to notify my support team if previous request in any of the above targets is Red.
    Please shed some light on this.
    Regards,
    Ramesh

    Hello Ramesh,
    I think you will have to include ABAP Program in your process chain which will check the status of previous load from the table RSREQICODS and RSREQDONE and if this is successful then trigger further processes.
    There is How to guide for how to integrate ABAP in process Chain.
    Hope it helps.
    San.
    Message was edited by: SAN

  • Request is already (partially) activated; no further QM action possible

    HI
    iam unable to delete the top request in DSO which is loaded through flat file.
    in monitor screen it is green but in manage screen it is red..
    Tried this not worked...
    Use SE37, to execute the function module RSBM_GUI_CHANGE_USTATE
    From the next screen, for I_REQUID enter the request ID (yellow or green) and execute.
    From the next screen, select 'Status Erroneous' radiobutton and continue.
    pls help.
    Thanks
    Mahi

    Hi Mahi,
    i think U didnot select option  Set Quality Status to 'OK'
    ,when you created ODS/DSO  ....
    Change QM status GREEN in ODS manage screen.Now activate particular request.
    or else
    if you want to delete that Requested data
    problem to delete DSO data
    Hope this will help you....
    Thanks
    chandra sekhar

  • How to change the status of a Partially Activated Red request?

    Hi
          I am unable to delete a Request which is partially activated and which is in Red.
    This was due to
    We were trying to manually update a data packet which was struck for a long time in the above request. While we changed the status of the requests to red and were about to perform the manual update, the struck data packet processed automatically and the activation too  started automatically before the request was set to green.
    To recover , we need to delete the request which we are unable to do.
    Please provide help
    Regards,
    Rezwan Asraf Ali

    Dear,
    When you create a production order, an operation created by the system is generated automatically if no routing is used for the creation. As a result the order header receives the status HOGAN; the operation created automatically also has this status.
    If you delete the operation created automatically and then do not have the status HOGAN.
    To avoid this maintain the Routing for the material or delete the setting of default operation from OPJG.
    Regards,
    R.Brahmankar

  • ODS Delta Load --- Activation problem

    Hi
    I had an ODS, newly transported in to procuction. I did Initialization for that with out having any problem. But i am facing problem in the delta load. I can see that delta data load is successfull. But couldnot able to Activate the delta load request.
    I can able to see following comments in  cancelled job log.
    Key value exists in duplicate (Not allowed by the ODS object type)       
    System error occurred (RFC
    call)                                         
    Errors occured when carrying out activation         
    Can you please help me out why activation of delta request cancelling?
    Thanks & Best Regards,
    Venkata

    hi..
    for ur ODS..right click..go to change..in the settings..the checkbox for 'unique data records' must be ticked.
    in dev..remove this checkbox and then save/activate the ODS.
    transport this change to prod and then reload the data to the ODS in prod.
    the delta request will surely load(and also activate) without any problem.
    cheers,
    Vishvesh
    Message was edited by: Vishvesh

  • DSO Partially Activated

    Hi All
    I have searched before posting this and although there are some threads re: the above they are not entirley like mine.
    I have run an initialisation on a DSO but it will not let me activate it.  On monitor everything is showing as green.  When I go into the DSO to activate it the QM status turns red.  If I hover over it the message "Error occurred during the activation process".  If I click it a pop up appears saying "Request is already (partially) activated; no further QM action possible".
    The same load is also loading into another DSO and everything is fine with that one.
    Do any of you have any idea of what can be causing it. 
    I've tried initialising without data
    I've tried loading into the psa first
    I've even tried running the load and activation via a process chain
    but each time the activaiton fails, maybe there is a setting somewhere or somthing I have to delete before I can go any further.
    I've read a thread which mentions RSMONICDP, RSICCONT, RSODSACTREQ and RSODSACTUPDTYPE but these were mentioned in the respect of deleting the request.  I can delete it but I want to beable to activate it.
    thanks in advance
    Sandra

    Hi All
    Thanks for getting back so promptly.
    Dennis,
    I don't think it's anything to do with volume of data as I have also tried initialising without data and it still won't let me activate.
    Ansel,
    I've looked on SM37 and it says "Overlapping check with archived data areas fro InfoProvider ZSD_O01. Data to be activated successfully checked against archiving objects. ABAP/4 SYNTAX ERROR"
    I have now searched on the above error and although I found the exact same error the person solved it but didn't say how he solved it
    I've looked on ST22 and there is a dump it is saying something about " /BIC/B0000343000 is unknown"
    Subray,
    I haven't checked the differences between the two DSO yet but will do soon
    thanks again for your comments, I will carry on looking
    sandra

  • Init. Delta load in BI 7.0?

    Hi, Experts:
    I just changed to a new BI application team. We have a delta load from ECC into an ODS then into a cube. I thought that there must be an initial delta load before the daily delta load. But I don't see init delta load request when right click the ODS/cube then select "Manage". The application started to load from January 2008. I have put the request display date to sometime 2007 then click the refresh button. But still could not see init delta load. From the very 1st load till date, I only see all are delta loads. Is this some thing new in BI7.0 that init delta is not needed any more? Or something is wrong?
    Thanks,
    Jenny

    Hi,
    that's right, there is no special request for Delta/Init.
    The DTP can do it itself at the first time.
    If you want to check which DTP is the Initialization, you can go on the DTP log, and in the header you will see "Extraction Mode" -> Delta.
    If the corresponding DTP request is the init, the flag "Delta Init" is ticked.
    Hope it helps !
    Mickael

  • Inventory - No Marker update is set for delta loading, any impact ?

    Dear all,
    Since several days the daily delta on inventory cube is done with flag "no marker update set".
    What are the possible issue ?
    Do we have to reload the data or can we just set the flag as unchecked ?
    Thanks for your help
    Best regards
    Christophe
    Edited by: Christophe Courbot on Sep 15, 2011 5:04 PM

    Hi,
    Pl check below
    Marker Update is used to reduce the time of fetching the non-cumulative key figures while reporting. It helps to easily get the values of previous stock quantities while reporting. The marker is a point in time which marks an opening stock balance. Data up to the marker is compressed.
    The No Marker Update concept arises if the target InfoCube contains a non-cumulative key figure. For example, take the Material Movements InfoCube 0IC_C03 where stock quantity is a non-cumulative key figure. The process of loading the data into the cube involves in two steps:
    1) In the first step, one should load the records pertaining to the opening stock balance/or the stock present at the time of implementation. At this time we will set marker to update (uncheck 'no marker update') so that the value of current stock quantity is stored in the marker. After that, when loading the historical movements (stock movements made previous to the time of implementing the cube) we must check marker update so that the marker should not be updated (because of these historical movements, only the stock balance / opening stock quantity has been updated; i.e. we have already loaded the present stock and the aggreagation of previous/historical data accumulates to the present data).
    2) After every successful delta load, we should not check marker update (we should allow to update marker) so that the changes in the stock quantity should be updated in the marker value. The marker will be updated to those records which are compressed. The marker will not be updated to those uncompressed requests. Hence for every delta load request, the request should be compressed.
    Check or uncheck the Marker Option:
    Compress the request with stock marker => uncheck the marker update option.
    Compress the loads without the stock maker => check the marker update option.
    Relevant FAQs:
    1) The marker isn't relevant when no data is transferred (e.g. during an delta init without data transfer).
    2) The marker update is just like a check point (it will give the snapshot of the stock on a particular date when it is updated).
    Reference information:
    Note 643687 Compressing non-cumulative InfoCubes (BW-BCT-MM-BW)
    Note 834829 Compression of BW InfoCubes without update of markers (BW-BEX-OT-DBIF-CON)
    Note 745788 Non-cumulative mgmnt in BW: Verifying and correcting data (BW-BCT-MM-BW)
    Note 586163 Composite Note on SAP R/3 Inventory Management in SAP BW (BW-BCT-MM-IM)
    Thanks and regards

  • Request Status not Activating

    Dear All,
                  I have created Datasource and DSO and flat file and also created DTP.  If i request perticular request id , its not activating.  request status not activating.
    With Regards,
    Baskaran.

    Hi Baskaran,
    Follow these steps.
    Do the loading process as you are doing i.e. using Info package load to PSA, then using DTP to DSO.
    Then after loading data, you go to manage. Then Select your green request and then click activate.
    A new window will open. There your request will be green. Again select it and click on start (do not click on stop).
    Then you will find refresh button there. Click on it. Your green request will turn yellow. Now go on clicking refresh until your request disappears from there. After that close the window.
    Then again click on manage. Click on refresh. Now select active data. Your data will be displayed.
    Hope this helps.
    thanks,
    rahul

  • Error in activating init flag for delta load

    Hi everybody, I am trying to activate the init flag for delta load, when I schedule the infopak it is taking too long to execute and the status is remaining in yellow for a week. I checked in details tab the error message is u201C no data available in source system u201C Please helpu2026

    Hi Vinod,
    When there is no data available in the source system, you will have yellow flag for the delta init request. Check for the delta queue entry (RSA7) on the source system. Delta mechanism starts working once this flag is created. After that schedule the delta infopackage.
    Also check on the source system whether there is any data avilable in the application tables related to this datasource. Take the help of functional consultants if required.
    Regards,
    Sreenivas.

  • Unable to delete the request id in ODS....indicating partially activated

    Dear All,
    When I tried deleting a request from ODS, am unable to turn the QM status to red, itz indicating that the request is partially activated.  When I tried deleting the request without changing the status, the delete icon is popped up, but eventually goes back to the previous status and hence does not get deleted.
    Due to the above, the subsequent requests coming into the ODS are not getting activated at all...
    I tried running the function module  RSBM_GUI_CHANGE_USTATE, to delete the request, but to no success.  Similarly, when I tried locating the requests in the four tables RSICCONT, RSMONICDP, RSODSACTUPDTYPE and RSODSACTREQ, could not found the request id to be deleted in any of these 4 tables.
    Please suggest some solution as it is of high importance...
    Thanks and Regards,
    Edited by: sachitp on Feb 27, 2011 12:25 PM

    Hi,
    You can try the below options,
    1. Remove the request data from the active table using the function
    to delete data selectively.
    You must enter selection criterion to select the data of the
    aborted request.
    2. Use Transaction SE37 to execute the 'RSAR_ODS_API_DEL' function
    module as follows:
    I_REQUEST <Name of the activation request>
    I_DATE <current date>
    3. Use Transaction SE16 to delete all entries for this request and
    for this ODS object from the RSICCONT, RSMONICDP, RSODSACTUPDTYPE
    and RSODSACTREQ tables.
    Thanks,
    Vinod

  • Update activity status based on Customer request status,

    Hello,
    I have a requirement to update the status field of a service request activity to Completed when the service request status = closed. Any suggestions?
    Thanks,
    SKJ

    If the field they are updating is in the same object it shouldn't be an issue. If another object needs to be updated then the workflow won't work.
    Integration events can be used for this. generate a event and have a external process poll the integration event queue for new events. when received, it can do whatever is necessary via web services.

  • Job terminated in source system - Request set to red during delta load

    Hi All,
    There is issue with the delta load where as full load works fine and it results in below job termination with below log.
    Job started
    Step 001 started (program SBIE0001, variant &0000000128086, user ID ALEREMOTE1)
    Asynchronous transmission of info IDoc 2 in task 0001 (0 parallel tasks)
    DATASOURCE = 2LIS_13_VDITM
    RLOGSYS    = BWP_010
    REQUNR     = REQU_DA9R6Y5VOREXMP21CICMLZUZU
    UPDMODE    = R
    LANGUAGES  = *
             Current Values for Selected Profile Parameters               *
    abap/heap_area_nondia......... 0                                       *
    abap/heap_area_total.......... 17173577728                             *
    abap/heaplimit................ 40000000                                *
    zcsa/installed_languages...... DE                                      *
    zcsa/system_language.......... E                                       *
    ztta/max_memreq_MB............ 2047                                    *
    ztta/roll_area................ 3000000                                 *
    ztta/roll_extension........... 2000000000                              *
    Object requested is currently locked by user ALEREMOTE1
    Job cancelled after system exception ERROR_MESSAGE
    Please help me to resolve this issue.
    Thanks,
    Madhu,

    Hello,
    As per the screen shot provided below, data soruce belongs to LO, so first check in RSA7, whether it has got mark in RSA7, for which you have entries in RSA7 against the data source. If you are not able to find the data source in RSA7, then you need to set-up the update methods, based on the requirement.
    1) Direct Delta
    2) Queued Delta
    3) Unserialised V3 Update
    Once it is done, Delete the Previous Initilisation, again perform the Re-Init With Out data and now schedule the Delta Data Loads
    Hope this may Help you.
    Thanks
    PT

  • Repair request for Delta load? Orders missing in Billing line Items

    Hi
    I am using BW 3.5; Some Orders are missing in BW for Billing line item reports (2LIS_13_VDITM) according to the users.
    The report is based on Cube directly, ODS is not used. I planned to do a repair full request for this month's data so as to get the missing orders.
    Could you please advice me on correct procedure to do that? Delta loads runs every day and todays delta is completed.
    Thanks and BR
    P.B

    While it's usually recommended to execute setups during "quiet time", it's not required. Especially in this case. Since you're going to be restricting the setup to only extract a range of Billing Documents that are representative of the dates of data missing (or purely the identified missing documents), there is no need to wait for "quiet time" because you'll pick up the data either in your Full Repair extract or in the delta extract. Depending on how the target InfoProvider for this data is setup (cumulative v. non-cumulative), you may have to look out for duplicate data.
    My recommendation would be to run your setup for only those documents that have been identified as missing. That way, you're limiting the amount of data that's required to be extracted to the setup table and then into BW, but also will remove any risk of duplicate data in your target InfoProviders.

Maybe you are looking for