Request Status stays yellow after successful load

We recently started loading two infocubes from the same data source. 
- The Monitor shows that the load completed normally with no errors. 
- Manage on the first cube shows that the status is green and the data available for reporting. 
- Manage on the second cube shows the data is not avaialble and the status is yellow. 
There seems to be no problems with the load. I can manualy force the status from yellow to green and the data is available for reporting.  But I don't want to have to manully change the status after each load.  Any ideas on why the status stays yellow?  Any thoughts on what I can do?
Thanks,
Chris

Nagesh,
Looks like your suggestion will solve this.  It was not checked for the one that was staying yellow.  It was checked for the cube that would go to green.  I'll run a test then come back and award points.
Thanks,
Chris

Similar Messages

  • Request Status Stay Yellow

    Hi Expets,
    I am using load 0HR_PT_2.
    Because the load gets warning in the source system the request stay in status yellow
    (HR say all the data is good)
    In the Details tab of the monitor under Extraction i see the warning
    "warnings have appeared when extracting data" (message R3 401)
    And i have to change it to green every morning (because all the data is in received in to the BW)
    how can ignore the warnings or chagne it to green automaticly?
    Or what else can i do?
    Thanks and BR,
    Or.

    Hi,
    In the DTP on the extraction tab you can set the DTP extraction mode to ignore warning and make the request status as green. Once you do this setting your request will become green automatically.
    But I don't know if there is any similar setting in BI 3.5.
    Regards,
    Durgesh.

  • Request still yellow in manage screen after successful load

    Hi ,
    I have loaded the data into the cube .The load is init .Even thought the load is successfully load the manage screen shows request still yellow in color. I checked everywhere but did not find relevant setting.
    Any help please.
    Thanks

    Hi,
    Chk for any active job in SM37 still going on which is related to this load...
    And then under details tab chk under extraction--->is the data selection ended or not?
    And chk in the manage screen->Environment(in the menu bar)>Autoimatic request proceessing>set quality status to OK is checked or not?-> Chk this box and refresh....
    If u chk all the things are in green and successfull u can manually turn the status into green in the manage screen....then auotmatically the reporting symbol comes if there are no aggregates...
    rgds,

  • Request Status for Master Data Attributes Load

    Dear All,
    We are trying to load attribute master data and volume of which is relatively huge around 10,000 records.
    We are facing challenge while updating attribute data from master data info object , the load status remains in yellow status and when we went to details screen it states that data is transfered to transfer rule . ( it has been loaded successfully in to PSA).
    Could anybody please give some hint on this challenge ??
    Regards
    Kapadia

    Hi  Paolo Siniscalco,
    You are right, as number of records are more , i have chosen update of "Only PSA" and then "Subsequently in Data Targets".
    I tried other option also which is infopackage  schedule "Execute in Back ground" and                                                         
    "Request batch process runs untill all data is updated in BW". And process went in to infinite loop.
    Some how i am not able to track out why the request status is not changing .
    Regards
    Kapadia

  • Appropriation Request: Status 'In process' after all approvals (IMA11)

    Hello,
    We are using IMA11 and associated workflow tasks to create and approve a appropriation request. Occasionally, the status of the appropriation request wouldn't change to 'Approved' even after all the approvals. When we look at the corresponding workflow, the status of the task "New status for appropriation requests" would be 'In process'. There would be no error messages shown in the workflow log and there won't be any short dumps.
    The same appropriation request, when restarted for the second or third time, would complete without any issues and the status of the appropriation request would change to 'Approved'.
    Can someone let me know what could be the reason for occasional failure of the appropriation request workflow?
    Thanks,
    Surya

    Here is another issue for the same workflow approval process.
    There are 4 approval levels. Identifying the agent and the approval happens in a loop.
    Occasionally, the workitem fails with the message 'Work item XXXXXXXX locked by user XXXXXXX (enqueue error)' The workitem is  getting locked by the previous approver. Is there any specific reason for this lock or do I need to add a wait step for each loop?
    The approver, approves the workitem from his Business Workplace. I checked other threads, but I am not able to figure out a reason. These are all synchronous processes.
    Thanks,
    Surya

  • I can't get my games to stay open after they load. Please help.

    My games load but when games are about to start after loading they completely shut down.  No errors. Any suggestions?

    Hi Pam0656!
    I have an article for you that should be able to help you address this issue with your apps:
    iOS: An app you installed unexpectedly quits, stops responding, or won’t open
    http://support.apple.com/kb/ts1702
    Thanks for coming to the Apple Support Communities!
    Cheers,
    Braden

  • Skype status stays [Online] after sign out

    Hi
    Recently my skype has left online when I sign out. Over night my skype was logged in.
    I changed my password then went offline and asked a friend. They confirmed I was still logged in.
    Any ideas?

    I'm having the same issue. I use Skype for Windows and Skype for Android (on two devices). Even when I sign out on these devices and I turn them off and I also sign out and turn off my computer, all my friends confirms that I remain Online. It is not like for few minutes, I remain Online for all the time, I just never go offline. I tried to change my password like four times, I even try to reinstall Skype on all my devices and nothing changed. I'm starting to be a little scared. Could anyone help my please?

  • REQUEST STATUS YELLOW WHILE MONITOR STATUS GREEN - BI7

    Hellow,
    I try to load data with 0CO_OM_OPA_1, 0CO_OM_WBS_1 into Z cubes which are similar to the business content cubes 0OPA_C11 and 0WBS_C11 respectively.
    ETL is BW3.5 (transfer rule and update rules). When I look at the request in the monitor, I see that everything is green but the request status is yellow and not available for reporting. I can change the status to green manually but this is not a good solution for me.
    By the way the same load works well with te standart cubes.
    I use BI7 but I use BW3.5 business content.
    What could be the reason for such problems?
    Regards,
    Hadar

    Hi Hadar,
    We have exactly the same proble. Have you found a solution to it? I'm using Datasource 0HR_PT_2 to load data into Infocube ZPT_C01 (a copy of 0PT_C01). The monitor of the infopackage is green. There are no errors whatsoever. The status for the request in the Infocube>Manage is set to yellow and the data is not available for reporting. I can set it manually to green, but as you said yourself, it'd be nice to have an automated wway of doing this. Is there any way around this problem?
    Thanks
    Michalis

  • Data Request remains in yellow status after RSAPO_CLOSE_TRANS_REQUEST

    Dear all,
    I am working on BI 7.0 and I need to load data from a Real-Time Cube (in planning mode) to a Standard Cube. I am using a Process Chain with a program which calls function module RSAPO_CLOSE_TRANS_REQUEST providing the technical name of the Real-Time cube to this function module. I see that this function module works in general, because afterwards I see the number of data records transferred and added appearing in the data request. However, the status of the data request is still yellow. In order to load the data from this cube to another it has to be in green. It is not acceptable to do this manually, it has to be automated. Data entry on the Planning Cube is via a BI-IP Query. The data arrives correctly in the cube, when checking the InfoCube content the data appears to be fine.
    I have used this function module in many projects without such a problem. Does anyone have an idea why the data request is not set in green status?
    I have also tried to use the function modules RSAPO_SWITCH_TRANS_TO_BATCH and RSAPO_SWITCH_BATCH_TO_TRANS to convert from Planning mode to normal mode and then back from normal to planning mode. The result is the same, data request remains yellow.
    Many thanks for your help
    Claas

    Thanks Rishi,
    I have tried this with the standard Process Chain steps to switch the mode, but the issue remains. It first switches the Cube to Load-Mode, I see data records in the request being added to the cube, the next step tries to switch the cube back into Planning mode, This step now gives an error because the data request is in yellow status, so the cube cannot be switched back to planning.
    Error Message:
    Request APO_R4EX2HO4TYDLBCNQPQY82K8ZOJ(0000020181) is yellow or red in InfoCube DRI_P301; cannot switch to planning
    Message no. RSM068
    The Problem is that after the Cube was switched to Load-mode the request is still yellow.
    I do not understand why data records get added to the cube but the request does not get turned into green status. Any more ideas?
    Cheers
    Claas
    Edited by: Claas Bartels on Aug 29, 2009 10:29 PM

  • Dispatcher status yellow after kernel update.

    Hi exsperts.
    my system SQL2005 on Windows2003.
    After updating kernel from 146 to 179 system status in sapmmc turned yellow with info:
       dispatcher Runnig but Dialog Queue info unavailable, J2EE:All processes runing.
    second issue:
       In sapmmc : AS ABAP WP Table is empty.
    Any idea what is wrong ?
    Below Abap Trace  of disp+work.exe
    trc file: "dev_disp", trc level: 1, release: "700"
    sysno      44
    sid        ERD
    systemid   562 (PC with Windows NT)
    relno      7000
    patchlevel 0
    patchno    179
    intno      20050900
    make:      multithreaded, Unicode, 64 bit, optimized
    pid        5332
    Sun Oct 26 10:37:29 2008
    kernel runs with dp version 241000(ext=110000) (@(#) DPLIB-INT-VERSION-241000-UC)
    length of sys_adm_ext is 576 bytes
    SWITCH TRC-HIDE on ***
    ***LOG Q00=> DpSapEnvInit, DPStart (44 5332) [dpxxdisp.c   1285]
         shared lib "dw_xml.dll" version 179 successfully loaded
         shared lib "dw_xtc.dll" version 179 successfully loaded
         shared lib "dw_stl.dll" version 179 successfully loaded
         shared lib "dw_gui.dll" version 179 successfully loaded
         shared lib "dw_mdm.dll" version 179 successfully loaded
    rdisp/softcancel_sequence :  -> 0,5,-1
    use internal message server connection to port 3944
    Sun Oct 26 10:37:34 2008
    WARNING => DpNetCheck: NiAddrToHost(1.0.0.0) took 5 seconds
    ***LOG GZZ=> 1 possible network problems detected - check tracefile and adjust the DNS settings [dpxxtool2.c  5418]
    MtxInit: 30000 0 0
    DpSysAdmExtInit: ABAP is active
    DpSysAdmExtInit: VMC (JAVA VM in WP) is not active
    DpIPCInit2: start server >sap-dev_ERD_44                          <
    DpShMCreate: sizeof(wp_adm)          28032     (1752)
    DpShMCreate: sizeof(tm_adm)          58861440     (29416)
    DpShMCreate: sizeof(wp_ca_adm)          80000     (80)
    DpShMCreate: sizeof(appc_ca_adm)     160000     (80)
    DpCommTableSize: max/headSize/ftSize/tableSize=2000/16/2208064/2208080
    DpShMCreate: sizeof(comm_adm)          2208080     (1088)
    DpSlockTableSize: max/headSize/ftSize/fiSize/tableSize=0/0/0/0/0
    DpShMCreate: sizeof(slock_adm)          0     (104)
    DpFileTableSize: max/headSize/ftSize/tableSize=0/0/0/0
    DpShMCreate: sizeof(file_adm)          0     (72)
    DpShMCreate: sizeof(vmc_adm)          0     (1864)
    DpShMCreate: sizeof(wall_adm)          (416064/346352/64/192)
    DpShMCreate: sizeof(gw_adm)     48
    DpShMCreate: SHM_DP_ADM_KEY          (addr: 000000000F020050, size: 62108928)
    DpShMCreate: allocated sys_adm at 000000000F020050
    DpShMCreate: allocated wp_adm at 000000000F0221F0
    DpShMCreate: allocated tm_adm_list at 000000000F028F70
    DpShMCreate: allocated tm_adm at 000000000F028FD0
    DpShMCreate: allocated wp_ca_adm at 000000001284B750
    DpShMCreate: allocated appc_ca_adm at 000000001285EFD0
    DpShMCreate: allocated comm_adm at 00000000128860D0
    DpShMCreate: system runs without slock table
    DpShMCreate: system runs without file table
    DpShMCreate: allocated vmc_adm_list at 0000000012AA1220
    DpShMCreate: allocated gw_adm at 0000000012AA12A0
    DpShMCreate: system runs without vmc_adm
    DpShMCreate: allocated ca_info at 0000000012AA12D0
    DpShMCreate: allocated wall_adm at 0000000012AA12E0
    MBUF state OFF
    DpCommInitTable: init table for 2000 entries
    rdisp/queue_size_check_value :  -> off
    ThTaskStatus: rdisp/reset_online_during_debug 0
    EmInit: MmSetImplementation( 2 ).
    MM global diagnostic options set: 0
    <ES> client 0 initializing ....
    <ES> InitFreeList
    <ES> block size is 4096 kByte.
    Using implementation view
    <EsNT> Using memory model view.
    <EsNT> Memory Reset disabled as NT default
    <ES> 767 blocks reserved for free list.
    ES initialized.
    mm.dump: set maximum dump mem to 96 MB
    J2EE server info
      start = TRUE
      state = STARTED
      pid = 5888
      argv[0] = D:\usr\sap\ERD\DVEBMGS44\exe\jcontrol.EXE
      argv[1] = D:\usr\sap\ERD\DVEBMGS44\exe\jcontrol.EXE
      argv[2] = pf=D:\usr\sap\ERD\SYS\profile\ERD_DVEBMGS44_sap-dev
      argv[3] = -DSAPSTART=1
      argv[4] = -DCONNECT_PORT=64999
      argv[5] = -DSAPSYSTEM=44
      argv[6] = -DSAPSYSTEMNAME=ERD
      argv[7] = -DSAPMYNAME=sap-dev_ERD_44
      argv[8] = -DSAPPROFILE=D:\usr\sap\ERD\SYS\profile\ERD_DVEBMGS44_sap-dev
      argv[9] = -DFRFC_FALLBACK=ON
      argv[10] = -DFRFC_FALLBACK_HOST=localhost
      start_lazy = 0
      start_control = SAP J2EE startup framework
    DpJ2eeStart: j2ee state = STARTED
    rdisp/http_min_wait_dia_wp : 1 -> 1
    ***LOG CPS=> DpLoopInit, ICU ( 3.0 3.0 4.0.1) [dpxxdisp.c   1692]
    ***LOG Q0K=> DpMsAttach, mscon ( sap-dev) [dpxxdisp.c   12408]
    Sun Oct 26 10:37:35 2008
    DpStartStopMsg: send start message (myname is >sap-dev_ERD_44                          <)
    DpStartStopMsg: start msg sent
    CCMS: AlInitGlobals : alert/use_sema_lock = TRUE.
    CCMS: Initalizing shared memory of size 60000000 for monitoring segment.
    CCMS: Checking Downtime Configuration of Monitoring Segment.
    CCMS: start to initalize 3.X shared alert area (first segment).
    DpJ2eeLogin: j2ee state = CONNECTED
    DpMsgAdmin: Set release to 7000, patchlevel 0
    MBUF state PREPARED
    MBUF component UP
    DpMBufHwIdSet: set Hardware-ID
    ***LOG Q1C=> DpMBufHwIdSet [dpxxmbuf.c   1050]
    DpMsgAdmin: Set patchno for this platform to 179
    Release check o.K.
    Sun Oct 26 10:38:14 2008
    MBUF state ACTIVE
    Sun Oct 26 10:38:15 2008
    DpModState: change server state from STARTING to ACTIVE
    Sun Oct 26 10:40:24 2008
    J2EE server info
      start = TRUE
      state = ACTIVE
      pid = 5888
      http = 54400
      https = 54401
      load balance = 1
      start_lazy = 0
      start_control = SAP J2EE startup framework
    Sun Oct 26 13:32:51 2008
    SoftCancel request for T22 U508 M0 received from IC_MAN
    Sun Oct 26 13:34:56 2008
    SoftCancel request for T16 U509 M0 received from IC_MAN
    Sun Oct 26 20:59:29 2008
    SoftCancel request for T20 U875 M0 received from REMOTE_TERMINAL
    Mon Oct 27 07:11:15 2008
    ***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4424]
    ERROR => NiIRead: SiRecv failed for hdl 7 / sock 260
        (SI_ECONN_BROKEN/10054; I4; ST; 172.18.254.229:1902) [nixxi.cpp    4424]
    Network error of client T19, NiBufReceive (-6: NIECONN_BROKEN), dp_tm_status=3
    Client address of T19 is 172.18.254.229(sap-dev.etos.pl)
    ***LOG Q04=> DpRTmPrep, NiBufReceive (17761SAPSYS 19 sap-dev ) [dpxxdisp.c   12086]
    RM-T19, U17761, 000       SAPSYS, sap-dev, 06:09:33, M0, W0, SESS, 2/0
    Mon Oct 27 12:25:13 2008
    SoftCancel request for T28 U18469 M1 received from REMOTE_TERMINAL
    Mon Oct 27 12:26:07 2008
    SoftCancel request for T28 U18469 M0 received from REMOTE_TERMINAL
    Mon Oct 27 17:09:37 2008
    SoftCancel request for T36 U19479 M0 received from REMOTE_TERMINAL
    Mon Oct 27 17:12:41 2008
    ***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4424]
    ERROR => NiIRead: SiRecv failed for hdl 15 / sock 152
        (SI_ECONN_BROKEN/10054; I4; ST; 172.22.17.122:4298) [nixxi.cpp    4424]
    Network error of client T22, NiBufReceive (-6: NIECONN_BROKEN), dp_tm_status=3
    Mon Oct 27 17:12:42 2008
    Client address of T22 is 172.22.17.122(0278-n.etos.pl)
    ***LOG Q04=> DpRTmPrep, NiBufReceive (19469A.JODKO 22 0278-n ) [dpxxdisp.c   12086]
    RM-T22, U19469, 401      A.JODKO, 0278-n, 16:52:23, M0, W1, VF03, 2/1
    Mon Oct 27 17:23:29 2008
    SoftCancel request for T19 U18317 M0 received from REMOTE_TERMINAL
    Mon Oct 27 17:25:58 2008
    SoftCancel request for T19 U18317 M0 received from REMOTE_TERMINAL
    Tue Oct 28 07:38:37 2008
    ***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4424]
    ERROR => NiIRead: SiRecv failed for hdl 6 / sock 340
        (SI_ECONN_BROKEN/10054; I4; ST; 172.18.254.229:3843) [nixxi.cpp    4424]
    Network error of client T17, NiBufReceive (-6: NIECONN_BROKEN), dp_tm_status=3
    Client address of T17 is 172.18.254.229(sap-dev.etos.pl)
    ***LOG Q04=> DpRTmPrep, NiBufReceive (21618SAPSYS 17 sap-dev ) [dpxxdisp.c   12086]
    RM-T17, U21618, 000       SAPSYS, sap-dev, 06:36:54, M0, W0, SESS, 2/0
    Tue Oct 28 08:55:49 2008
    ***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4424]
    ERROR => NiIRead: SiRecv failed for hdl 9 / sock 224
        (SI_ECONN_BROKEN/10054; I4; ST; 172.20.1.21:1708) [nixxi.cpp    4424]
    Network error of client T18, NiBufReceive (-6: NIECONN_BROKEN), dp_tm_status=3
    Client address of T18 is 172.20.1.21(0082-d.etos.pl)
    ***LOG Q04=> DpRTmPrep, NiBufReceive (18414A.KACPERSKA 18 0082-d ) [dpxxdisp.c   12086]
    RM-T18, U18414, 401  A.KACPERSKA, 0082-d, 10:15:55, M0, W0,     , 2/0

    I have fixed this problem yesterday.
    Problem was in different verssions of sapstartsrv.exe
    Vincent Lim you are right, good answer good points
    Regards

  • Status of Info packages and process changes become yellow after Unicode con

    Dear Friends,
    We have been facing very critical issue in Production system after Unicode conversion.
    Sequences of Details are provided for your reference.
    1.  We suspended all BW loads for 48(2 days) hours before Unicode starts and Handover the BW system to Basis.
    2.  Basis started doing Unicode conversion on BW and they found some standard jobs ( BI_* , Ex: BI_PROCESS_LOADING) which are released status and they assumed that these jobs would run any time so that they suspended all of them but they didnu2019t inform to BW team that they had done. We didnu2019t know that when they did that like pre-Unicode installation, during the Unicode conversion and post Unicode.
    3. Basis handover the system to BW team for Unicode testing (we called five finger testing) and we didnu2019t find any issues in the testing. Again we handover the system to Basis for post installations settings for Unicode and back up things. That time we didnu2019t release any jobs to load data to BW because Basis didnu2019t inform us that we can start loads. 
    4. After post installation is done and basis told us that you can start loads from Monday. Entire Unicode activity had been done on weekend.
    5. Before releasing all BW loads to run regularly, I found the all completed process chains status become yellow and I did further detailed analysis to find why; then found some more strange things those are as follows.
              1. Only info packages in process chains are become yellow and other process variants are fine like activation,
                   DTPu2019s, index and DB stats.
              2. Requests in PSA which were completed successfully are become yellow.
              3. Info packages in the process chains are successfully completed are not updating correct status instead of green it
                  showing yellow because of that other dependent objects are not triggering.
    We all thought that suspension of standard jobs must have been caused the problem.
    How can we change the status of IPs, PSA and process chains automatically?
    We reactivate all PCu2019s and released to run tomorrow.
    Could you please share your thoughts about the issue and help us resolve?
    Thanks in Advance,
    Nageswar.

    Nageswar,
    A couple of questions :
    1. If your previous  PC runs were in yellow status - it would not impact furute PC runs..
    2. If your IPAKs are in yellow - then you might have an issue with deltas happening since the last status would have been shown as incomplete.
    3. Suspension of the standard jobs will not affect the status since the jobs were suspended but not the actual loads i.e the loads were not stopped halfway but only the released jobs were stopped - you might have to schedule the process chains again to get back the old schedule.
    Usually in a Unicode conversion - the data is exported out of the DB and imported back - this might have caused some inconsistency in the database for the RS tables used for the monitors.
    Which version of BW are you in ..?
    were there any errors in the export / import procedure for unicode conversion ?
    As part of testing did you check if loads went through properly ..?
    Was stats run on the tables after unicode ?
    Also if possible regenerate all the indices on the files.
    Rerun stats and indices for all RS* tables

  • PSA request is in yellow status

    Hi
    We got the problem when loading the 2LIS_03_BF data into cube. We have around 4 cubes and 2 ods.
    The data got loaded into all the cubes and ods except on Cube. There was a problem of table space and now it is solved.
    Now the request is in yellow status in PSA. It cube it shows no of records added and transferred but the status is in red color.
    How can i upload the delta data into the cube from PSA when PSA request is in yellow color.
    I feel strange that when the request is in yellow color how come the data is loaded into all other cubes.
    REgards
    Annie

    You should be able to load request from PSA to data target using the option available in PSA. When you manage on Datasource, you see all requests. You can select that PSA request and use Scheduler option in that screen to update that particular request.  It will run infopackage as usual. It will execute all the routines if there are any in update rules.
    When you say you have some programs running in process chain, they must be after this failed load right?
    If that is the case, all you need to do is push process chain further. Below are steps to push process chain further if you any step is stuck in yellow or if mually carry out any red step in process chain. In you case, load that failed step manually using scheduler form PSA manage tab and then push PC further using these steps. That will continue PC further and run any programs that run after load.
    Execute in SE38 -> RSPC_PROCESS_FINISH
    Fill the following parameters on screen and rest all can be left blank.
    1. LOGID - you will find this when you do monitor of your process chain. Every time you run process chain, unique LOGID is created.
    2. TYPE - If step is ODS activation then TYPE wud be ODSACTIVAT and if it is infopak loading TYPE wud be LOADING and if it is DTP Load TYPE wud be LOAD. In your case it will be LOADING.
    3. VARIANT - In the process chain monitor mode, right click on step which you executed manually -> Display Messages. Go to chain tab and there you will find VARIANT
    4. INSTANCE - In the process chain monitor mode, right click on step which you executed manually -> Display Messages. Go to chain tab and there you will find INSTANCE
    5. STATE - Value wud be G
    After entering above parameters, click execute. It will be done in fraction of second and wont give any popup. Now when you will check process chain monitor, you will see that step 4 is green and next step has started executing.
    Abhijit

  • Request status in infocube is always in yellow status..

    Hi Friends,
    We are loading the data from 3 ODS to one infocube but all the requests from ODS to infocube is always haivng yellow status ( even though load is completed without any errors). We are manually changing the status to Green.
    Any suggestions regarding this problem...
    Thanks in advance

    Symptom
    All requests in InfoCubes have the QM status 'yellow traffic light'.
    Solution
    In the InfoCube administration in the menu
    'Environment -> Request handling...'
    activate the flag 'Set quality automatically' on the popup 'Maintenance of the automatisms'.
    This flag was of no importance before BW Release 2.0.
    This flag is interpreted actively as of BW Release 2.0. For InfoCubes where this flag is deactivated, every request must be set manually to green (available for reporting) or red (incorrect) by a QM action.
    As a result, the individual request can have a different status independent from its monitor load status in different InfoCubes.
    After upgrading from BW1.2B to BW2.0, the flag is interpreted, but is not set for any of the old InfoCubes.
    Therefore data, including old data, is not automatically visible in reporting, if it is not rolled up or compressed.
    In order to accomplish this, you can either activate the flag 'Set quality automatically' or set every request manually to green (administering the InfoCube on the 'Requests' tab in column 'QM status of the request after update').
    This is a button column that only affects the status of this request in this InfoCube!
    By setting the QM status in the monitor for the load log of this request you can set all QM statuses of this request in all updated InfoCubes simultaneously.
    If you change this flag, you choose button 'Refresh' in the tabstrip 'Requests' so that the flag will interpreted and the requests are set to 'Green' in the InfoCube and thus displayed in Reporting.

  • DSO reporting icon was displayed although load status was "Yellow"/"Red"

    Hi,
    Whilst loading a DSO, I observed that the reporting icon was displayed even when the load was in status "Yellow" and in one instance, the reporting icon displayed even when the status of the load to the DSO was "Red" i.e it had failed. I would reckon that the DSO reporting icon would be displayed only after the load was successful including the activation step. Why then was the reporting icon displaying when the load was not successful.? Is this an SAP bug.
    Any thoughts, gurus!
    Thanks
    Kevin

    Hi,
    I don't understand this. In a Standard DSO if the Quality Status is set to Automatic then the report shows as Green in the Quality Status Icon. However, data is still in the "New Data Table" and is not yet updated in the Active data table/change log unless the activation is done. If the Activation is done, only the will the data be available in the Active Data table/Change log.
    It is only afther this data is available that the reporting icon is displayed.
    If the Qualilty status is Yellow/Red the activation cannot be done. In whcih case there is no question of data being available in Active Table/Change log and hence the reporting icon should not be displayed.
    Therefore, I am not able to understand the anomalous behavior of the display of the reporting icon even when the Qualtiy Status is Yellow/Green
    @Experts: Is there something that I am missing
    Thanks
    Kevin

  • BDocs stay yellow - status I02 Written to qRFC Queue (intermediate state)

    We upgraded our system from SAP CRM 7.0 EHP3 SP3 to SP4.
    Now all the BDocs in smw01 stay yellow. I can manually reprocess them, then they become green. There is no error message and there are no dumps in st22.
    The CSA* queues are registered. The scheduler says "inactive" (and briefly goes to active when saving a business partner, product or transaction, as it should).
    The CSA* queues relevant for each "stuck" business partner, transaction or product is in status "STOP".
    There's a note, 1593693 - BDoc's in state I02, but it doesn't help. We don't have a problem with the number or load of the RFC processes (as far as I can tell), there is very little going on on the system, right now I am the only one logged on) and the queues are not in status READY, either.
    MW_CHECK says "All post-processing steps are done."
    GENSTATUS counts 0 errors or waiting.
    MW_MODE is on, of course.
    smw3_00 is empty (which it was before the SP installation, too).
    The CRM is not connected to an ERP system, it sends búsiness partner and transactional data via the XIF adapter (via web services). Which, up to now, worked just fine.

    I was given the solution: Use transaction smq2, search for CSA*, click on the queue, click the unlock button. That worked.

Maybe you are looking for