Stop delta loads in R3

how to stop delta loads from R3

Hi,
if u want stop loads for particular application (11,12,13) like that stop V3 jobs
in LBWE try with job control
or
if u want to stop load particulre data source select the job in SM37
Job----->delete
if u want to stop load temp.
Goto TC SM 37 job overview
Select the job (Use LIS)
Get job details PID number
In SM50 find the PID number
In menu cancel without core
in this case u can recover the delta resechduling ot "V3" jobs.
Message was edited by:
Soma Venkateshwarlu
Message was edited by:
Soma Venkateshwarlu

Similar Messages

No initial load of Customers, Material and delta load of Sales Orders.

Hi Experts,
I am facing a very troublesome issue. I am not able to setup the Middleware portion for initial and delta loads. I read a lot of documents and corrected a lot of things. finally, the connectivity is done with R/3 and CRM. Initial load of all objects is successful (as per Best PRactices guide). Customizing load is successful.
But after now I have these open issues for which I am unable to find any answers (am really exhausted!!):
- Customer_main load, it was succesful, but no BP's of R/3 are available.
- Material, it failed in SMW01, SMQ2, the errors are:
Mat. for Initial Download: Function table not supported
EAN xxxxxxxxxxxxxxxxxx does not correspond to the GTIN format and cannot be transferred
EAN yyyyyyyyyyyyyyyyyy does not correspond to the GTIN format and cannot be transferred
Plant xx is not assigned to a business partner
- Sales order, it shows green bdoc, but error segments says "No upload to R/3" and the order does not flow to R/3.
We had our system setup 3 years back for data transfer and Middleware. But few things changed and connectivity stopped. I did all that again now, but am not yet successful. Any inputs will be greatly appreciated.
Thanks,
-Pat

Hi Ashvin,
The error messages in SMW01 for MAterial initial load is :
     Mat. for Initial Download: Function table not supported
     EAN 123456789000562 does not correspond to the GTIN format and cannot be transferred
     EAN 900033056531434 does not correspond to the GTIN format and cannot be transferred
     Plant 21 is not assigned to a business partner
I have done the DNL_PLANT load successfully. Why then the plant error?
Some of the messages for BP:
Messages for business partner 1331:
No classification is assigned to business partner 1331
For another,
     Partner 00001872(469206A60E5F61C6E10000009F70045E): the following errors occurred
     City Atlanta does not exist in country US
     Time zone EST_NA does not exist
     You are not allowed to enter a tax jurisdiction code for country US
     Validation error occurred: Module CRM_BUPA_MAIN_VAL, BDoc type BUPA_MAIN.
Now, the time zone EST is assigned by default in R/3. Where do I change that? I do not want to change time zones as this may have other impacts. Maybe CRM I cna change this, not for sure in R/3. City check has been deactivated in R/3 and CRM, still the error.
Till these 2 are not solved, I cannot go into the Sales order loads.
Any ideas will be greatly appreciated.
Thanks,
-Pat

Issue in the Delta load using RDA

Hi All,
I am facing an issue while trying to load delta using RDA from R/3 source system.
Following are the steps followed:
1. Created a realtime Generic Datasource with timestamp as delta specific field and replicated it to BI.
2. First I have created the Infopackage(Initialization with data transfer) and loaded upto PSA.
3. Created a standard DTP to load till DSO and activated the data.
4. Then created a realtime delta infopackage and assigned it to a Daemon.
5. Converted the standard DTP to realtime DTP and assigned the same to the Daemon.
6. Started the Daemon, giving an interval of 5 minutes.
In the first time, Initialization with data transfer is taking the records correctly. But when I run Daemon for taking delta records, its taking all the records again, i.e. both the previously uploaded historical data and the delta records).
Also after the first delta run, the request status in the Daemon monitor, for both Infopackage and DTP changes to red and Daemon stops automatically.
Can anyone please help me to solve these issues.
Thanks & Regards,
Salini.

Salini S wrote:
In the first time, Initialization with data transfer is taking the records correctly. But when I run Daemon for taking delta records, its taking all the records again, i.e. both the previously uploaded historical data and the delta records). .
If I understand you correctly you Initially did a full load. Yes? Well next you need to do intialise & after that delta.
The reason is that if you will select delta initialisation & initialisation without data transfer- it means delta queue is initialised now & next time when you will do delta load it will pick only changed records
If you will select delta initialisation & initialisation with data transfer- It means delta queue is initialised & it will pick records in the same load.
As you know your targets will receive the changed records from the delta queue.
Salini S wrote:
Also after the first delta run, the request status in the Daemon monitor, for both Infopackage and DTP changes to red and Daemon stops automatically.
I take it the infopackage has run successfully? Did you check? If it has and the error is on the DTP then i suggest the following.
At runtime, erroneous data records are written to an error stack if the error handling for the data transfer process is activated. You use the error stack to update the data to the target destination once the error is resolved.
To resolve the error, in the monitor for the data transfer process, you can navigate to the PSA maintenance by choosing Error Stack in the toolbar, and display and edit erroneous records in the
error stack.
I suggest you create an error DTP for an active data transfer process on the Update tab page (If key fields of the error stack for DataStore objects are overwrite On the Extraction tab page under Semantic Groups, define the key fields for the error stack.) The error DTP uses the full update mode to extract data from the error stack (in this case, the source of the DTP) and transfer
it to the target that you have already defined in the data transfer process. Once the data records have been successfully updated, they are deleted from the error stack. If there are any erroneous data records, they are written to the error stack again in a new error DTP request.
As I'm sure you know when a DTP request is deleted, the corresponding data records are also deleted from the error stack.
I hope the above helps you.

Delta load from r3 to bw ?

i have one question on the mechanism of data transfer from r3 to bi 7.0. the followings is my concerns:
scenario:
The total numer of data is 1000 rows and these rows are seperated into 10 data package , each package contains 100 rows.
Now bw is trying to recieve these 10 packages from r3 in sequence.
When 5 data packages have been transfer to bi psa. the network is broken and the tranfer is canceled at the 6th data package.
What i want to know is when the network is reconnected ,Does the transfer start from the 6th data package?
How to find out whether its a delta load or a full load if a transfer is scheduled from r3 to bw ? For both CUBE & ODS.
How to find out how many records have been transfered from r3 to bw while the transfer has ended in
the middle ? I mean how to check how many records have been successfully transfered from r3 to cube/ods .Please tell me for ods as well as cube.
Is the continuation of transfer process is same for both ODS & INFOCUBE, if it ends in the middle ?
What is the procedure for full load & Delta load in case of CUBE & ODS ? I mean how to reschedule the transfer.
And if the whole scenario is is in the support, SO I will be handling these issues on the live production server. Am I right ? So in this case my user id should have access to all the production r3 and production bw to do these change status to red and delete the request and reload the request etc., So I should be logging on to the production server and do all the manipulation, Am I right ?
Last doubt, what is repair request and so if the transfer stops in the middle we change the status to red and reload the request again , Is it called repair request ?
What is the difference between repeat delta & repair request & repair delta ? When do we choose these options, In which scenarios ?
How do we schedule a daily load job from r3 to bw without the use of process chains ? I mean daily it should fetch the records from r3 to bw from the SD datasources at 10.00 PM ,how do we do that ?
Please I am having all these doubts and I want you SAP experts to answer them please so that I can clear my doubts in production support . I really appreciate if someone explain me the scenarios here. It will be a really great help if someonce clears these doubts.

Hi......
What i want to know is when the network is reconnected ,Does the transfer start from the 6th data package?
If your connection is broken in between......inspite your load is through PSA...........you have to delete the request from the target(after making the QM status red)............then you have to reload it again............But before repeating the load check the connection is ok or not in SM59........
How to find out whether its a delta load or a full load if a transfer is scheduled from r3 to bw ? For both CUBE & ODS
This you can check in IP scheduler in the Update tab...........whether it is delta or full load.......
or you can also check in IP monitor(You can go here through RSMO..........IP monitor screen will open directly here............or you can also go through RSA1>> Find your IP >> Double click on it >> Click on the monitor icon in the top >> From the you will go to the IP monitor>> the under the Header Tab you can see whether it is a delta or Full update...........
Or you can check the datasource also..........
If it is a generic datasource go to RSO2..........and check...........If it is a standard datasource check it in RSA5...........
How to find out how many records have been transfered from r3 to bw while the transfer has ended in the middle ? I mean how to check how many records have been successfully transfered from r3 to cube/ods .Please tell me for ods as well as cube
Your load cannot be ebded in the middle.........it can failed.............if it fails then you have to delete the request from the target..........and then repeat the load.......
Is the continuation of transfer process is same for both ODS & INFOCUBE, if it ends in the middle
Yes.........
What is the procedure for full load & Delta load in case of CUBE & ODS ? I mean how to reschedule the transfer
If a full or delta load fails after extraction got completed due lock issue or SID issue.....etc..........and if you load is through PSA.............then just delete the request from the target without making the QM status red.......and reconstruct the request.........no need to repeat the whole load again........
But if you r load is not through PSA..........then make the QM status red........delete the request from the target........and repeat the load...........
And if the whole scenario is is in the support, SO I will be handling these issues on the live production server. Am I right ? So in this case my user id should have access to all the production r3 and production bw to do these change status to red and delete the request and reload the request etc., So I should be logging on to the production server and do all the manipulation, Am I right ?
Yes.......
What is repair request and so if the transfer stops in the middle we change the status to red and reload the request again , Is it called repair request or reload request?
Suppose you delta load has failed ............and you have deleted the request from the target without making the QM status red............In this case your data will be lost and your delta mechanism will get corrupted............In this situation.............
1) Delete the init flag........
2) You have to do Full repair..........(After filling the set up table)
3) Init without data transfer to set back the init flag
4) Then Delta upload.............
In case of an ODS............you cannot load Full update and delta upload parrallely..............Your ODS activation will fail...........suppose you want full upload in the ODS..............then you have to go for Full repair............
What is the difference between repeat delta & repair request & repair delta ? When do we choose these options, In which scenarios ?
I think Full repair concept is now clear............
Suppose your delta load fails...........After that you delete the request after making the QM status red............Then system will ask for a repeat delta when you will try to repeat the load...........which means it will pick the same delta records of the failed load..........
How do we schedule a daily load job from r3 to bw without the use of process chains ? I mean daily it should fetch the records from r3 to bw from the SD datasources at 10.00 PM ,how do we do that ?
This you can do via infopackage or infopackage group...........schedule it at the specific time.....
Check these links :
http://help.sap.com/saphelp_nw04/helpdata/en/20/ad673844a7114be10000009b38f842/frameset.htm
Re: Schedule Infopackage for last day of a fiscal period
Hope this helps you.........
Regards,
Debjani...........

Delta load of customer from R/3 (ECC5.0) to CRM5.0

We have done an initial load of customers from ECC to CRM (R3AS). A change is done on a customer in ECC. I expect the changes to be reflected in CRM as a delta load. I do not see the changes. What am I missing?
All responses are appreciated and will be rewarded.

Hi Mani,
Here are some clues on how to proceed with processing of incomplete or failed BP deltas:
First of all you have to note that during the initial download, no delta download can occur. In particular, no delta download of customers occurs if the initial download of materials occurs at the same time. This is because the material download depends on the customer download.
During the delta download, the CRM system uses the inbound queues R3AD_CUSTOME<nnnnnnnnnn> where <nnnnnnnnnn> corresponds to the customer number in the R/3 system. If an error occurs during the download, the inbound queue for this customer is stopped. You can see the error messages in the flow trace. For the delta download, you have the option to use Transaction CRMM_BUPA_MAP for the error analysis. If you enter the customer and press Enter here, you can display the business partner number for a customer and all open BDocs (that is, those which contain errors or are being processed). To do this, you only have to click the 'Queues and BDocs during download' pushbutton. The system issues an overview of the queue and the open BDocs for this customer and in particular, you can 'look into' the BDoc. As a result, you return to the flow trace and you can display the error messages which occured as described above. During the delta download, you have the option to send the same BDoc again. This is useful if you can simply solve the problem by correcting Customizing in the CRM system. To do this, you simply click the corresponding icon in the flow trace (currently, this is the second icon from the left).
If you have to correct the error in the R/3 system, you have to delete the existing BDoc since it cannot be processed further. As a result, the inbound queue in the CRM system is released again. In this case, you are recommended to delete all existing open BDocs and to make the changes in the R/3 system.
If inconsistencies occur between the R/3 system and the CRM system, you can start a request for the customer. To do this, click the 'Get customer from the R/3 system' pushbutton. This starts a request which uses the inbound queue R3AR_CUSTOMER. Process possible errors as during an initial download.
If you still have problems and don't know how to fix, please post more specific information from the BDoc queue, such as what error message you are getting. It helps us better identify the problem.
Regards,
Rahul
PS. Please award points if it helps!
PPS. For future reference: this info was found in note 362621: Error drng data exchange customer<->business partner

Cannot deactivate delta load of materials from R/3

Hi,
we have a problem deactivating the delta load of materials from R/3.
I deactivated the adapter objects MATERIAL and PRODUCT_MAT in R3AC1.
I even deleted the class MATERIAL in R3AC4.
The Bdoc's are not created any more, but the queues are still getting generated in SMQ2:
R3AD_MATERIA***
Am i wrong in assuming that this settings have to prevent queue creation?
Is this an error that anyone encountered or are there any other settings that I forgot to check?
Thank you,
Borut

Hi,
I have a similar problem. I have to deactivate delta flow of materials from ONE SITE only (F6A) and keep it flowing from other sites N6A and A6A - our CRM system is connected to multiple backends.
For the required site, i have removed all the conditions in the filter settings but still delta queue keeps on coming. Also, the queue is in SYSFAIL state - we are not able to download material from other sites - supposedly material from the other two sites gets queued up in this stuck queue.
Is there any way to stop the download from one particular site only?

Difference: Full load, Delta Load & INIT load in BW

Hi Experts,
I am new to SAP BW Data warehousing.
What is the difference between Full load, Delta Load & INIT load in BW.
Regards
Praveen

Hi Pravin,
Hope the below helps you...
Full update:
A full update requests all the data that corresponds with the selection criteria you have determined in the scheduler.
You can indicate that a request with full update mode is a full repair request using the scheduler menu. This request can be posted to every data target, even if the data target already contains data from an initialization run or delta for this DataSource/source system combination, and has overlapping selection conditions.
If you use the full repair request to reload the data into the DataStore object after you have selectively deleted data from the DataStore object, note that this can lead to inconsistencies in the data target. If the selections for the repair request do not correspond with the selections you made when selectively deleting data from the DataStore object, posting this request can lead to duplicated data records in the data target.
Initialization of the delta process
Initializing the delta process is a precondition for requesting the delta.
More than one initialization selection is possible for different, non-overlapping selection conditions to initialize the delta process when scheduling InfoPackages for data from an SAP system. This gives you the option of loading the data
relevant for the delta process to the Business Information Warehouse in steps.
For example, you could load the data for cost center 1000 to BI in one step and the data for cost center 2000 in another.
The delta requested after several initializations contains the upper amount of all the successful init selections as the selection criterion. After this, the selection condition for the delta can no longer be changed. In the example, data for cost
centers 1000 and 2000 were loaded to BI during a delta.
Delta update
A delta update requests only the data that has appeared since the last delta. Before you can request a delta update you first have to initialize the delta process. A delta update is only possible for loading from SAP source systems. If a delta update fails (status red in the monitor), or the overall status of the delta request was set to red manually, the next data request is carried out in repeat mode. With a repeat request, the data that was loaded incorrectly or incompletely in the failed delta request is extracted along with the data that has accrued from this point on. A repeat can only be requested in the dialog screen. If the data from the failed delta request has already been updated to data targets, delete the data from the data targets in question. If you do not delete the data from the data targets, this could lead to duplicated data records after the repeat request.
Repeat delta update
If the loading process fails, the delta for the DataSource is requested again.
Early delta initialization : This is a advanced concept, but just for your information ...
With early delta initialization you can already write the data to the delta queue or to the delta tables in the application while the initialization is requested in the source system. This enables you to initialize the delta process, in other
words, the init request, without having to stop posting the data in the source system. You can only carry out early delta initialization if this is supported by the extractor for the DataSource that is called in the source system with this data
request. Extractors that support early delta initialization were first supplied with.

Re: Delta Load for master attribute CUSTOMER

Dear All,
I have got the delta loading into 0customer_attr and 0 material_attr in production. Yesterday the load failed because the previous change run run has been terminated and locked the attributes of characterstics 0 material and 0customer.
To solve this i went back and ran the attribute change run and all the locks got released.
Now i know that i need to repaeat the delta load.
If we go to the RSMO for the failed load i see that under details tab in processin option we have as follows
Transfer rules(67-->67 records):No errors(This is Green)
   Master data received:Processing being started(Green)
   Transfer 67 data records in communication structure(Green)
This is where the processing stopped.
Update(0new/0changed)(in red): Errors occured
My doubt is if i now repeat the load in process chain will the 67 records come into the0customer infoobject.
Will this have any impact on the next day delta load.
Kindly advice.
Regards
Madhuri

Hi abhijit,
When i tried to do a repeat delta the load failed again and when i check for the error message i get the following
Diagnosis
    The application program for the extraction of the data was called using
    update mode R . However, this is not supported by the InfoSource.
System Response
    The data extraction is terminated.
Procedure
    Check for relevant OSS Notes, or send a problem message of your own.
Procedure for System Administration
How do i proceed further.
Regards
Madhuri

MAster Data - Delta Load Error?

Hi,
I am having error in 0COSTCENTER delta load. In the Info Package of 0COSTCENTER, it was not selected to PSA. It was selected to InfoObject directly.
Since this is a delta load for Master data, how can i correct this error?
Thanks!
Venkata

Hi Venkat,
You can done a full upload without affecting Delta upload. Make a test on Dev or Qual and you will see that a full on Master Data does not stop delta process.
Ciao.
Riccardo.

About delta loading for master data attribute

Hi all,
We have a master data attribute loading failed which is a delta loading. I have to fix this problem but I have two questions:
1. how can I find the those delta requests because I need to delete all these failed requests first, am I right ? Master data is not like cube or ods that we can find the requests in Manage, for master data how can we find them ?
2. Could you please let me know the detailed procedures to perform this delta loading again ?
Thanks a lot

Hi...
1. how can I find the those delta requests because I need to delete all these failed requests first, am I right ? Master data is not like cube or ods that we can find the requests in Manage, for master data how can we find them ?
Look.....for master data.....no need to delete request from the target..........just make the status red.......and repeat the load.....But problem is that master data sometimes does'nt support Repeat delta..........if u repeat......then load will again fail with Update mode R.........in that case u hav to do re-init.......
1) delete the init flag.......(In the IP scheduler >> in the top Scheduler tab >> Initialization option for source system)
2) Init with data transfer(if failed load picks some records)..........otherwise .....init without data transfer.....if the last delta failed picking 0 records.......
3) then Delta.......
2. Could you please let me know the detailed procedures to perform this delta loading again ?
1) Make the QM status red.........to set back the init pointer.......
2) Repeat the load.....
After that.........if again load failed with Update mode R.....
1) delete the init flag.......
2) Init with data transfer(if failed load picks some records)..........otherwise init without data transfer.....
3) then Delta.......
Regards,
Debjani.....

Compare data in R/3 with data in a BW Cube after the daily delta loads

Hi Friends,
How can I compare data in R/3 with data in a BW Cube after the daily delta loads? Are there any standard procedures for checking them or matching the number of records?

Hi Sunil,
If you want to check the records daily instead of checking the data in R/3 manually ......
You can try this...
If you have staging DSO(level 1) that means whatever data is in source system load it to Staging DSO without any routines or any modifications.
Now load this DSO data to Cube or DSO(level 2) as per your requirement with routines etc.
Now Staging DSO contains Source system data.
Now the level 2 Cube or DSO contains BW data with some modifications.
Now create a Multiprovider based on level 1 and level 2 data targets.
Now create a report on which keyfigures you want to test the data.
In Multiprovider there is a field called 0infoprovider in data packet dimension.
you can drag this infoprovider to the columns and restict your keyfigures with level 1 and level 2 data targets.
In the first column you can see the level 1 DSO data ( source system data),in the 2nd column you can see the BW data.
Now create a formula which gives the diffrence b/n level 1 and level2.
that is R/3 data - BW data.
If the diffrence is zero both R/3 and BW data are same.
if the diffrence is not eqaul to zero check whether any routine is there or not.

What is the diffrence between full load and delta load in DTP

hI ,
I am trying to load the data into CUBE from another cube using DTP ..
There are 2 DTPS ..
1: DTP with full load
2: DTP with DELTA load ..
what is the diffrence betwen thse two in DTP ...
Please can somebody help me

1: DTP with full load - will update all the requests in PSA/source to the target,
2: DTP with DELTA load - will update only new requests to the datatarget
The system doesnt distinguish new records on the basis of changed records, rather by the request. Thats the reason you have datamart status to indicate if the request has been loaded to further datatargets.

Delta Loads are not working: 0FI_GL_10 With enhancement : HR Data in source

Hello Friends. Thanks for your answer on theory which I know, Please help me with this situation. I read all the sdn response to my message and have below for your suggestion
QUES1: Why the 0RECORDMODE is not coming in Standard DSO and hence it is not there in Transformation in between Infosource and DSO. What do I need to include 0RECORDMODE in standard DSO. What is the correct OSS to Implement on SP 10 to solve this.
Ques2. As suggested by you If I run the Delta loads after waiting for 1 hour of Init load. say init load was done at 11 am . i will do the delta at 12:10 am to psa via Infopack and then wait for an hour to run the DTP from PSA to DSO. Delta Records come in but it also bring in the records in DSO that are not changed from about 7 hours in ECC. and make our total Balance incorrect.
Ques3: We have this Cocatenation of Keys in DSO since we exceeded the total number of 13 key in DSO.
Cocatenation#1 GL ACCT and CHRT OF ACCTS
Cocatenation#1 SEGMENT AND CONT AREA
Cocatenation#1 Version, Value Typem, Valuation view, Currency Type.
<b>
Since business want to include HR Data in Keys Like Employee Number, Emp Code, EMPSPIMCODE. Payroll ID and I can not remove these fields from Key in DSO as per the business.</b>
Also the above fields GL ACCT , CHRT OF ACCTS, SEGMENT, CONT AREA
exist in Data FIELDS OF DSO. so what are the steps to modify the design to fix this asap.
Please email me at [email protected] if you have any docs to resolve the above
Thanks
Soniya
null

Did the full load bring all records from sourcesystem to PSA?
Was this an issue with the first delta you have tested ?
Concatentaion of multiple keys into one should not be an issue here as that must have been happening in DSO and delta brings incorrect records to PSA itself.
Are you validating delta records against FAGLFLEXT inputing the timestamp value or RSA3 ..how ?
<b>Check if this note helps</b>
Note 1002272 - NewGL-DataSource 0FI_GL_10, 3FI_GL_*: Missing record.
Is delta bringing incorrect records to PSA or DTP brings incorrect records to DSO from PSA ?
May be you should revisit the logic behind for the enhancement of 0FI_GL_10.
I am facing a similar issue as well but here delta doesnot even bring a single record ( ODS has 20 keys )...will update if resolves and you do the same.
Message was edited by:
Jr Roberto

Error in delta loading from a planning cube

hi all,
I am using a delta load from one planning cube to another.When the changed records are of a magnitude of 100 then it is successful but when the records are of magnitude of 100000 then it stays yellow with no data records sent and eventually fails.the packet size is 20000.
any help is appreciated.

Hello Ajay,
Have you checked that your Request is closed in the planning cube? FM RSAPO_CLOSE_TRANS_REQUEST will do it
It is a customizing issue to tell the infopackage to end "green" when it has no data.
Transaction Spro ==> SAP Netweaver ==> SAP Business Information Warehouse ==> Automated Processes ==> Monitor Settings ==> Set Traffic Light Color. There you have to set the Traffic light on green if no data is available in the system.
Hope that helps
best regards
Yannick

SAP Mobile Sales 2.0 delta load issue for Sales Orders

Hello,
we have used Mobile Sales 2.0 with a Windows app for a while now. Our current issue is that sales reps won't see any historical sales order data on their devices.
Background
Due customer requirements, we need to make small changes to customer master data attributes and reload all customers from ERP to CRM. Then we ran delta loads (MAS_PARTNER followed by all other objects) to DOE, in which virtually all 5000+ customer accounts were compared. The delta load ran for about 3 days (some performance bottleneck we haven't located yet).
During the delta load, data on devices was inconsistent. Accounts were missing and all transaction data disappeared. After the delta loads, all accounts and contacts are OK, save for a few. Data from activities (appointments, tasks) have reappeared, as they should. Only sales orders won't reappear. The sales orders exist in the backend and belong to active accounts and sales reps.
Settings and troubleshooting so far
We don't have any limitations for sales orders in CRM Sales Mobile configuration.
We've run delta loads for all objects in transaction SDOE_LOAD.
MAS_CUSTOMIZATION etc seem fine.
We've re-run initial load for sales orders from CRM.
In the test system, we've even reinitialized the whole CDS database on DOE and on the devices, then re-ran the loads.
Checked steps suggested in discussion
SAP CRM 2.0 initial load issue
Historical sales orders (those created before the master data reload) exist in the backend, but don't show up on the device.
If I change one of those historical sales orders in the backend, it gets sent to the device.
If I create a new sales order in the backend or on the device, it is saved and replicated just fine.
To sum it up, it seems DOE is unable to identify the sales orders relevant for replication.

First Doubt i got clarify by my self as we can go with Unwired Runtime option .
But i still have doubt in :
2. How can i Modifying the Main Menu for iOS.
i am able to customize the same for windows using files SybaseCRM.Configuration.xml file.
Same how can i do for iphone/ipad.

Stop delta loads in R3

Similar Messages

Maybe you are looking for