0CRM_SALES_ACT_1 Delta Queue Issue

Hi,
I need to work with the delta queue for 0CRM_SALES_ACT_1 extractor.
I ran the init process with data succesfuly and I can see the the extractor "green" in TC RSA7
I checked if the BW Adapter is active in TC GNRWB and the BWA_DELTA3, BWA_FILL, BWA_QUEUE AND BWA_REL_CHECK are active (with x)
What do I miss..? No Delta in the Queue
My working environment:
CRM : 5 BBPCRM 500 level 11 SAPKU50011 & SAP_BW BI 7.0 700 level 0015 SAPKW70015.
BW : SAP_BW BI 7.0 700 level 0016 SAPKW70016.
for your advice
Eyal

Hi Eyal & Ben:
Can you please check in CRM,with transaction code SMW01 and execute with no limitation in 'Send Data and Time' as well as 'Update Date and Time". Now check is there any yellow 'State" and if you found any yellow state, delta is not process and you have to process Queue name. I faced this before.
Regards,
Md

Similar Messages

Critical issue - delta queues for LIS empty after upgrade BW3.5

The delta queue in R/3 for LIS sources (S260-261-262) remains empty,
even after a successful init delta. Hence I cannot extract delta
records.
BW3.5
PI2004.1
Does the BW upgrade has an effet on the delta queue management in R/3 ?
The previous configuration BW2.0B PI2004.1 did work fine in that
respect.
Laurent Querella
BI Consultant ALTI

Laurent,
from OSS Note 534296 'LBW0: DataSource generation possible for SAP info str.' you can read:
"(...)it is no longer possible to generate DataSources for info structures (transfer) Snn delivered by SAP (where nnn is between 001 and 500) in the BW interface for LIS info structures (TR: LBW0) in the OLTP. (...)The corresponding DataSources are delivered with the Business Content."
I think this is the issue...
However, are you saying that all infostructures are empty ?
And from where your init is taking data ?
After an init your delta tables have to be empty...did you empty all these tables before doing your upgrade ?
Bye,
Roberto

Issue in loading XML data in BW delta queue

Hello All,
My requirement is to stage small amount of XML data in SAP BW. For doing so, i have followed below steps...
1. Create File data source
2. Define Myself data source using file data source with Function module
3. Initialize load process without no data transfer
4. Using SOAP RFC service, Load xml records in delta queue.
Now in step number 4, i am unable to open the SOAP RFC service using which we can select the xml file.
Any help in this regard will be highly appriciated.
Thanks
Ketan

SOAP/RFC service is already activated. Only problem i am facing is as below.......
1. Created HTML page by copying html snipest
2. On created HTML page, select XML file as an input and URL of SOAP service which is pointing out to the application server
3. When i press "Send recordset" button, HTML page throws "Java script" error and data is not being pushed to BW delta queue....
Please share your ideas to resolve this issue.
Thanks in advance,
Ketan

Issue with Delta Queue

Dear All,
We have scheduled Delta Q on developement and it was working fine.
But on Quality side all the jobs for Application 11 are failing while application 13 are running successfully.
Please help on the same immediately.
Regards,
Sohil Shah.

Hi Sohil,
It seems that you have changed the structure of the datasource. When you change the structure of the datasource you have to make sure that there is no data in the delta queue or SMQ1 queue of the target system before you transport it. Delete the data from the delta queue and SMQ1 queue and reintialise the datasource.
Let me know if you have any doubt.
Regards,
Viren

No records in delta queue for 0CRM_SALES_ACT_1 & 0CRM_COMPLAINTS_I

Hi all,
we are linking a SAP CRM system 4.0 (patch level 10) with BW 7.0. We have initialized the delta extraction and everything was fine. Data was extracted and we can see the delta queue in RSA7 but no records are added. Users are creating new activities and nothing appears in the delta queue. We have other extractors delta capable which are working fine.
The main difference is that these two extractors have been enhanced using the Badi CRM_BWA_MFLOW. When we check the extractor using transaction RSA6, records include the information we add in the Badi.
We think the problem is in CRM because, it does not collect any delta data (queue is always empty). BW is capable to extract when initilitialization. We have tried the early delta initialization and the simple delta initialization.
Any help will be appreciated.
Thank you in advance.
As an extension: we can't see the extractors in the qRFC monitor (trans. SMQ1). We can see there the ones which are working...

Hi again,
we finally solved the problem. The thing was that no BDOCS with type BUS_TRANS_MSG were not being generated when creating or modifying CRM activities. Theses datasources need the BDOCS to work. Transaction SMW3_00 had the flag "Do Not Send" set. We unmarked it and everything seems to work now.

Issue with delta queue initialization

Hello
I am having a problem with an initialization of the delta queue for a certain extractor. The initialization was successfull, and I can see the extractor in the delta queue maintenance (RSA7) in ECC, but when users are posting transactions in ECC, they are not coming into RSA7.
The extractor is 0CO_OM_WBS_6, so its not standard LO cockpit where we have V3 (background) jobs which have to be triggered.
One more thing, the record which was posted was backdated, ie the date is sometime in the past. But I think the delta queue still picks the records. Can i know how the delta queue funtions based on the time stamp?
Please advise.

Here is the OOS note fro FI Datasources.
OSS 485958:
Symptom
The FI line item delta DataSources can identify new and changed data only to the day because the source tables only contain the CPU date and not the time as time characteristic for the change.
This results in a safety interval of at least one day.
This can cause problems if the batch processing of the period-end closing is still running on the day following the period-end closing and all data of the closed period is to be extracted into BW on this day.
Example:
The fiscal year of the company ends on December 31, 2002.
On January 01, 2003, all data of the closed fiscal year is to be extracted into BW.In this case, the FI line item delta DataSources only extract the data with a safety interval of at least one day.
This is the data that was posted with a CPU date up to December 31, 2002.
However, the batch programs for closing the 2002 fiscal year are still running on January 01, 2003.
The postings created by these programs with a January 01 date for the 2002 fiscal year can therefore only be extracted with delta extraction on January 02, 2003. However, extraction should already be possible on January 01, 2003.
Other terms
FI line item delta DataSources
0FI_AP_4; 0FI_AR_4; 0FI_GL_4
Reason and Prerequisites
This problem is caused by the program design.
Solution
The functions are enhanced as of PI 2002.1, standard version.
Due to a customized setting, it is now possible for the FI line item extractors to read the data up to the current date during the delta runs.
During the next delta run, the data is then read again from the day when the previous extraction was called, up to the current day of the call for the new extraction.This means that the delta extraction of the data always occurs with time intervals overlapping by one day.
The delta calculation by the ODS objects ensures that the repeatedly extracted data does not cause duplicate values in the InfoCube.
Activate the new functions as follows:
1. PI 2001.1 or PI 2001.2:
Implement the new functions with the correction instructions in this note.As of PI 2002.1, these changes are already implemented in the standard version.
1. Start a test run for an FI line item DataSource via transaction RSA3.
2. Two new parameters are now available in the BWOM_SETTINGS table.
3. Parameter BWFIOVERLA (Default _)
Set this parameter to "X" using transaction SE16, to activate the new function of overlapping time intervals.
Caution
The new function also uses a safety interval of one day to determine the To value of the selection, if the time limit set by BWFITIMBOR is not reached.This means that only data up to the day before the extraction was called is selected, if the extraction starts before 02:00:00 (default for BWFITIMBOR).
Correction: Parameter BWFITIMBOR (Format HH:MM:SS, default 020000)
The default value for this parameter is 02:00:00.Do not change this value.
If this time limit is not reached, only data up to the previous day (with BWFIOVERLA = 'X') or the day before this day (with BWFIOVERLA = ' ') is selected.
This logic prevents records with a CPU date of the previous day being contained in the posting when the extraction is executed.
Check any OSS notes for your data source.

BW Upgrade - Down time - Delta queue

Hello Experts,
We are in the process of upgrading the BW system from 3.1 to BI7 but not the R3.
Do we need to drain the delta queue from R3 before the upgrade or we can only go ahead about the BW Delta queue only?
As per the note: 506694, its talks about the BW alone when we are performing the BW upgrade but not R3.
Also let me know whether we need to take R3 down time when we do the BW upgrade alone?
Thanks
Raman

Dear Kedar,
Can we perform the left out steps directly in production? As per my understanding there wont be any issues if we perform the left over steps in production.as this will checks for the consistency check alone.
Interestingly I tried checkcing this program(RSUPGRCHECK).. for the infoobjects in my dev system. its trying to activate some of the infoobjects as well.
It showed a message like this: Activate all Dictionary objects ( 1422 )
I tried checking the number of objects in the system using RSDIOBJ.. where I can see that there are 2600 objects are in A version.!!
Does this message tells that this program has activated this many number of the infoobjects out of 2600? I tried this after the upgrade in the D.
Can you please clarify me on this.?
Final Question: How much period that we need to maintain the Down time in R3. Is it till the Upgrade starting from the PREPARE and till the end of the Post Upgrade activities and the Unicode? I will close this thread after this.
Many thanks again..
Raman
Edited by: Raman R on Aug 28, 2008 3:16 PM

Question about Note 886102 - Empty the delta queue of the connected SAP source systems

Dear expert
I'm doing the system refresh from ECC PRD to QAS using the hot backup of PRD
Before i start the database restore i was told to do the following step since this ECC has connection with one BW system
-----------------------Step -----------------------------
2.17 SAP note 886102 scenario C3
Empty the delta queue for all of the connected BW systems.
Execute all delta info packages two times on BW side, to clean up the delta queue in the source system. This is needed, because BDLS cannot rename the still available LUW-s in the qRFC queue.
----------------------Step-----------------------
But unfortunately i missed to execute this step
And the Q11 is now retoreing the backup of the database
My quesion
1. what will be bad consequence due to not execute this step? any way to makeup this error?
Best regards,

Hi Kate,
The probably issue which I could forsee is data getting wrongly updated into production if RFC connection from ECC to BW is not stopped.
Solution here could be to disable or deletethe RFC connections between ECC and BW before starting the SAP system at database level.
delete from sapr3.rfcdes where rfcdest = '<name>';
Once the system is up and running you can recreate them if required.
Also before starting SAP set the number of batch processes to 0 on the profile at OS level so that any released jobs don't start as soon as SAP is up.
Once the SAP system is up execute BDLS and change the logical system name.
Hope this helps.
Regards,
Deepak Kori

Direct Delta, queued , Non-serialized V3 Update

could someone out here help me in understanding the Direct Delta, queued , Non-serialized V3 Update...
i mean a detailed level explanation.... or just in case u have any document then kindly pass it on.... to [email protected]

Hi,
Update Methods,
a.1: (Serialized) V3 Update
b. Direct Delta
c. Queued Delta
d. Un-serialized V3 Update
Direct Delta: With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.
Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each DataSource into the BW delta queue, depending on the application.
Non-serialized V3 Update:With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
(serialized) V3
Transaction data is collected in the R/3 update tables
Data in the update tables is transferred through a periodic update process to BW Delta queue
Delta loads from BW retrieve the data from this BW Delta queue
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Issues:
Even though it says serialized , Correct sequence of extraction data cannot be guaranteed
V2 Update errors can lead to V3 updates never to be processed
direct delta
Each document posting is directly transferred into the BW delta queue
Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Less monitoring overhead of update data or extraction queue
Cons:
Not suitable for environments with high number of document changes
Setup and delta initialization have to be executed successfully before document postings are resumed
V1 is more heavily burdened
queued delta
Extraction data is collected for the affected application in an extraction queue
Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Suitable for environments with high number of document changes
Writing to extraction queue is within V1-update: this ensures correct serialization
Downtime is reduced to running the setup
Cons:
V1 is more heavily burdened compared to V3
Administrative overhead of extraction queue
Un-serialized V3
Extraction data for written as before into the update tables with a V3 update module
V3 collective run transfers the data to BW Delta queue
In contrast to serialized V3, the data in the updating collective run is without regard to sequence from the update tables
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3.This BW Delta queue is read when a delta load is executed.
Issues:
Only suitable for data target design for which correct sequence of changes is not important e.g. Material Movements
V2 update has to be successful
Hope this helps
regards
CSM Reddy

No records - FM Delta queue

Hi,
I did setup all steps for 0PU_IS_PS_44 data extraction from R/3. In doing so I did Initialized Delta process, logged to R/3 RSA7 transaction code to check the queue. At the time of Init I got 300 records. Today I created new Info package to extract the Delta records.
Here my problem is I could not see any Delta extraction to BW. In R/3 I could not see any records in the queue but where as in the RSA3 (Extract checker) the number of records are 324 meaning (324-300) 24 records were created from I did the Init and expected that records to appear in Delta Queue and also while Delta extraction to BW.
Appreciate if one could help me any steps I am missing out or any suggestions to see additional records to extract via Delta.
Thanks in advance.
Best Regards,
Murphy.

Hi Bhanu,
Thanks for your response at both places.
I got resolved the FM data source delta extraction. Adam responded to my post stating the IMG setting required for the activating Delta Queue.
I have the same issues with CO and FI data sources. Even the GL Account master data data source does not show the new/changed records/documents at Delta queue.
Appreciate if you could help me in resolving the problem.
Thanks.
Murphy.

Filtering Setup-Table and same filtering for Delta-Queue needed

Dear All,
I'm looking for the best solution to do the filtering for the delta-queue.
In program RMCVNEUA I'm filtering (excluding specific SalesOrg) data for the setup-table creation. I'm loading these data to the BW system.
BUT now my issue is, that with the delta-queue I'm getting also data for the SalesOrg I have excluded in the setup-table, as I have no filter for the delta-queue.
My Question: Where/How to filter by the same criteria the entries for the delta-queue?
Thanks for your support,
Peggy
some more details: Application 11; Queue-Name MCEX11; using 2LIS_11_VAHDR, 2LIS_11_VASTH, 2LIS_11_VAITM, 2LIS_11_V_SSL

Dear Arvind,
if there is no way in R/3 the solution must be in BW, but how exactly should that look like in the best/smartest way?
Let us look in detail at an Example:
DSO 0SD_O03 is getting data from 2LIS_11_VAHDR and 2LIS_11_VASTH.
1) For VAHDR I have the chance to delete not needed VKORG already in the InfoPackage, or load first to PSA and than filter in DTP or delete in Startroutine in Transformation.
2) BUT for VASTH, which has no VKORG information at all, I'm only able to delete the Dataset after it's loaded/activated in the DSO, as the rubbish-Dataset won't have any 0SALESORG. How to do that?
Thx,
Peggy

ABR delta extractor and entries written to the delta queue

Hello Everyone,
We have an ABR extractor and it's behaving like this:
For example fields: PM Order Number, Post Goods Issue Date, Start Date, Work Qty, Projected Qty
Create the PM order the entry is written perfect to the delta queue:
10019987, blank, 04/29/2009, 100 PC, 90 PC
Now, if we perform a confirmation on the PM order we see the following:
10019987, 04/29/2009, blank, 0 PC, 90 PC
Now if we change something on the PM order header we see the following:
10019987, blank, blank, 100 PC, 0 PC
When this comes over to BW we don't get good results in our ODS.
Basically we don't get our Post Goods Issue date and Work Qty gets blanked out. Basically, the last change to the order gets written to the ODS and isn't correct.
Shouldn't it do the following:
10019987, blank, 100 PC, 90 PC
10019987, 04/29/2009, 100 PC, 90 PC
10019987, 04/29/2009, 100 PC, 90 PC
10019987, 04/29/2009, 04/29/2009, 100 PC, 90 PC------this gets sent as last record with all fields updated. We choose all these fields in the extract structure.
Thanks

Hello Martin,
Below is a snapshot of the delta queue (you can see the Cancel). Question: How do you control what record is updated and what others are not? We thought the cancel won't update and the others will in order they were updated to the delta queue (and that appears how it's behaving):
Scenerio #1 (sorry, can't remember sequence of steps done in system, but thought I'd mention)
Cancel, Order Number, Release Date, Posting Date, Material, Plan Qty, Confirmed Qty
blank, 10019987, 04/29/2009, blank,       , 4415, 100, 0
blank, 10019987, 04/29/2009, 04/30/2009, 4415, 0,    100
blank, 10019987, 04/29/2009, blank,         4415, 100, 100
X,       10019987, 04/29/2009, blank,         4415, 100, 100
Scenerio #2
cancel, order, release date, posting date, material, plan qty, confirm qty
blank, 100019989, 04/29/2009, blank, 4415, 50, 0
then we perform a confirmation for 50 pieces and this is how the delta queue looks like
cancel, order, release date, posting date, material, plan qty, confirm qty
blank, 100019989, 04/29/2009, blank, 4415, 50, 0
blank, 100019989, 04/29/2009, 04/30/2009, 4415, 0, 50 <----
second line
Notice the second line now has plan qty at 0 and confirm at 50. Plan should always show 50 (or whatever the plan amount is. Something doesn't seem correct here??
Now, if we change something on the order header, we get the correct plan qty of 50 (and confirmed still 50), but then the posting date is blank. So when this comes over to BW we get correct plan and confirmed qty, but posting date is blank. This really makes no sense because if you have confirmed qty populated with a quantity then you have a posting date.
Thanks!

Failed to clean up BI delta queue before applying enhp1

Experts: Happy Holiday!
During applying enhp1 on BI7.0, we get the error that BW delta queue was not clean up before starting enhp1:
1) I remember I did do the clean up per the guide, why it complains? Should I do it in certain way?
2) how to fix it at this stage?
Thanks a lot!

The XXXX_XXXX is the data source for which the data belongs. Chances are that this is data in the delta queue (RSA7) or "Delta Repeat" data (ie. delta data from the last extract). Running the delta extract for the datasource twice should remove this. If not, check the date of the data in the Queue. If it is old and you are sure you have extracted all your data, then have your Basis Team delete this queue in SMQ1, you will not lose any data.
How to prevent any new data from entering the queues? Make sure you run your V3 collection jobs and delta extracts after all user processing has been finished (ie. just before you lock the system prior to installing the upgrade). Also, make sure all V3 collection jobs are not scheduled.
Tip: After the upgrade, replicate your data sources and try the delta extracts manually to insure they work. Do not schedule the V3 collection jobs until you are sure all your delta extracts work. If there is an error, you can fix without losing any data.
The only risk is to datasources where the upgrade changes the structure of the datasource (ie. add/remove fields). If you have customized the datasource by adding an Append Structure, then the upgrade will take care of this. If the datasources do not change, the then format of the data will remain the same and you will have no issues. Your Basis/Upgrade Team should be able to determine which datasource structures have been changed so that you are aware of potential risks.
Hope this helps.

How to deal with delta queue when importing Support Package/Kernel Patch

Hi,
From my experience, when importing a Support Package for an installation, the system will issue an error message and get stuck if this Support Package is about to alter the structures used in delta loads.
But I would like to double with you if there is possible that the support packet which is going to alter structure, but no error message. If so, the delta data will be lost.
Do we need to clear down the delta queue every time we import support package?
Anyway, is there anyone have any suggestions or steps regarding this question?
Many Thanks
Jonathan

Hi,
Delta queues during support package upgrade
Its always better to drain the delta queues before an upgrade.
As a standard practice we drain the delta queues by running the IP/ chain multiple times.
As a prerequiste we cancel/reschedule the V3 jobs to a future date during this activity.
The V3 extraction delta queues must be emptied prior to the upgrade to avoid any possible data loss.
V3 collector jobs should be suspended for the duration of the upgrade.
They can be rescheduled after re-activation of the source systems upon completion of the upgrade.
See SAP Notes 506694 and 658992 for more details.
Page 17
Load and Empty all Data mart Delta Queues in SAP BW. (e.g. for all export DataSources)
The SAP BW Service SAPI, which is used for internal and BW to BW data mart extraction, is
upgraded during the SAP BW upgrade. Therefore, the delta queues must be emptied prior to the
upgrade to avoid any possibility of data loss.
upgrade preparation and postupgrade checklist
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/472443f2-0c01-0010-20ab-fbd380d45881
/message/3221895#3221895
OSS notes 328181 and 762951 as a prerequisites.
Failure to follow the instructions in those notes may probably result in data loss.
https://websmp207.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700002662832005E
/thread/804820
Effect on BW of R/3 Upgrade
How To Tackle Upgrades to SAP ERP 6.0
/people/community.user/blog/2008/03/20/how-to-tackle-upgrades-to-sap-erp-60
Start with the Why Not the How When You Upgrade to SAP ERP 6.0
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/008dddd1-8775-2a10-ce97-f90b2ded0280
Rapid SAP NetWeaver 7.0 BI Technical Upgrade
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0c9c8be-346f-2a10-2081-cd99177c1fb9
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c2b3a272-0b01-0010-b484-8fc7c068975e
Hope this helps.
Thanks,
JituK

Problem to initialize delta queue of datasource from CRM 7.0.

Hi all,
I've some problem to initialize delta queue of datasource from CRM 7.0. After initialize the Init in BW, the delta queue was created but after the user changed data, this changed didn't populated into delta queue.
I tried the steps below but without any success. Anybody know how can I correct this issue?
Suggestion 3: Please check the following.
Please Check if the services have been generated in transaction GNRWB.
If they are not active(not marked 'X' before their names) then activate
the services following the steps here.
Go to transaction GNRWB
Select BUS_TRANS_MSG
Select (on the right, the services) : BWA_DELTA3, BWA_FILL, BWA_queue
Press Generate.
Also check for the following:
1. The delta should have been initialized successfully.
2. Confirm that all Bdocs of type BUS_TRANS_MSG
are processed with success in SMW01.
3. If there are queues in SMQ1 with erroneous status then activate
these queues.
In Transaction SMQ1 if there are Queues existing with
names beginning with CRM_BWAn (n is number) then
activate these queues in the same transaction.
4.a)If required activate the datasource
Go to transaction BWA5 > select the required datasource and
activate.
4 b) The Delta may not be active ,activate the delta in BWA7 by
selecting the name of the datsource and pressing the candle icon for
'activate delta'.
5. In BW system
Go to transaction RSA1 > modeling > infosources > select the
infosource > right mouse click on the selected
infosource > choose option replicate datasource
Activate the infosource.
6. Go to the scheduler for the infosource > select delta in the
update >choose the option PSA only (in the Processing tab)

Hi Peter,
Thank you for your answer.
But we need to find out what the reason for this import error is.
Our customer will not be very pleased to see that all IDocs from CRM system cannot be found in the IDOC folder.
IDX2 import of metadata is no issue.
We were successful for standard and customer Idocs here.
Additional information:
We are already importing Idocs from a SAP ECC 6.0 system into PI in another SWCV
successfully. So this is a CRM system specific issue in our environment.
Regards
Dirk
Edited by: Meinhard Dirk on Aug 27, 2010 10:30 AM

0CRM_SALES_ACT_1 Delta Queue Issue

Similar Messages

Maybe you are looking for