 Setting a stuck DTP (process chain yellow,

DTP green) to finished in certain conditions

18 October 2016

In certain conditions it can happen that i.e. a process chain is staying yellow even though the
DTP load process had been finished and is green (request green in monitor and data target)
but something prevented the proper raise of the event that it has been finished so the process
chain run cannot be continued (in most cases a short dump has been created in the system).
You can check all processes within the DTP Monitor if they have been finished successfully.
There is at least one job where you will find the information in the job log that the process has
been terminated with a short dump of type MESSAGE_TYPE_X.

There is the possibility to manually trigger the correct update of the finishing event. To do so
you have to check and find some information to be able to start the update program.

First of all some checks have to be executed:

o Check if the DTP load has a green status overall

o Check if all data packages have been processed correct
o Check if the DTP is having a green status in the data target

If all information can be verified to be correct you can proceed further with finding the correct
information. Therefore right-click the DTP process step in the process chain and select
"Displaying Messages…" from the context menu. Change to tab "Chain".
There you will most likely see in the "End" Section that the entry "with status" is showing "still
running". Obviously this is not true.
Still on tab "Chain" look at the middle section named "Generated Instance". The information
needed is within the fields "Variant" and "Instance". Open another session and navigate to
transaction SE16. Fill in table RSPCPROCESSLOG. On the selection screen fill in the values to
the respective fields: value from "Variant" to field "VARIANTE" and value "Instance" to field
"INSTANCE" and execute. You will get the entry of the process log. Here you need several
information.

The next step is to open another session and call transaction SE38. Execute program
RSPC_PROCESS_FINISH. At the selection screen fill the following fields:

o LOGID: Value from RSPCPROCESSLOG-LOG_ID

o TYPE: Value from RSPCPROCESSLOG-TYPE
o VARIANT: Value from RSPCPROCESSLOG-VARIANTE
o INSTANCE: Value from RSPCPROCESSLOG-INSTANCE
o STATE: Fill in "G"

After hitting the "Execute" button the relevant process steps are checked and the finish event
is getting raised. When checking the process chain, the next process step should be triggered
and start to run. In case the process chain doesn't continue afterwards and there is no change
on the tab "Chain" of the process messages contact some other consultant. Then something
more serious has happened.
Caution: whenever some information is not fine or the process is really still running, do not execute

this program. You are producing inconsistencies that can lead to data loss or system damage. Check

the situation with a more experienced consultant in such cases, whenever you are feeling unsure. This

program can be helpful but use caution to just use it in the right situations.
Conversion error!

Hi,
there seems to be an issue with these document caused by the unit conversion (TD  PAA)
I have no idea how to correct this in a regular way.
I checked the documents at it seems that the already rejected until last week.
So whatever is done now its seems to be senseless.

I selected the records from the PSA table (/BIC/B0000071001) for the actual request
deleted the records for the mentioned document
removed the red request from the 2 DSW cubes (ZB_SAD203, ZB_SAD33B)
made a repeat with scheduler
and after this was finished successfully I skiped the PSA update in the chain

Hope this is last time these documents appear.

wbr Frank

Von: Wittrock Frank

Gesendet: Mittwoch, 18. Mai 2016 09:42
An: ITG-D CC_SAP MIS <ITG-DCC_SAPMIS@swarovski.com>; Gerhold Michael
<Michael.Gerhold@swarovski.com>; Hauer Gerhard External
<gerhard.hauer.external@swarovski.com>
Betreff: Issue with order transfer to BW (Inc. 1414178)

Dear all,
last week Cesc created an Inc. 1414178 with problems in order transfer (2lis_11_vaitm).

Today we had the same issue again.

It seems that there are several SGD orders
6720081022
6420592590
6720081929
6420592593
6420603344
with not convertible units (TD  PAA)
As soon as the TD (1) position is changed the system cannot convert TD to PAA anymore
as material master and price tables are already switched to PAA.

For today I deleted all transferred records from the PSA as they were already rejected in the past.
As long as these TD positions are not changed again there should not be a problem.

@Gerhmi
I am not sure if there is a customizing error in table T006

Maybe PAA should have STUECK instead of AAAADL (without dimension)

as this seems to be the basis for the error given in fuction module
UNIT_CONVERSION_SIMPLE

can we discuss this?

wbr Frank
Dear Sharon,

We found that there is a strange record in sales org 1650. As it is not contain any
customer details, we deleted the record from the active data and change log of
ZO_CM001.

Afterwards, we repeated the error steps and it is fine again.

Best Regards,
Teddy Wong

SWAROVSKI GREATER CHINA LTD.

Teddy Wong
IT Business Consultant
Finance & Controlling
IT Application Services
9/F, 1063 King's Road, Quarry Bay / Hong Kong
Tel.: +852 2969 6243
Fax: +852 2979 0129
mailto:teddy.wong@swarovski.com
www.swarovski.com

This communication may contain information that is legally privileged, confidential or exempt from disclosure. If you are not the
intended recipient, please note that any dissemination, distribution, or copying of this communication is strictly prohibited.
Anyone who receives this message in error should notify the sender immediately by telephone or by return e-mail and delete
this communication entirely from his or her computer.

本資訊文件包含享有法律特權、保密或免於披露的資料。如果閣下並非預定的收件人，請注意，對本資訊文件的任何傳播、分發
或複製均被嚴格禁止。誤收此件的人士應立即通過電話或回電郵通知發件人，並從其電腦中完全刪除此資訊文件。
From: Bettencourt Sharon
Sent: Wednesday, April 06, 2016 4:39 AM
To: Hau Sing; Wong Teddy
Cc: Cheung Wilson
Subject: Customer Master Issue

Hi Sing and Teddy

ZSIS_Master_01 data failed from zo_cm001 to zc_custsl due to a bad record – I am not sure where
this record is coming from but I cant find it in P10 – if you fix this can you let me and Wilson know what
you did as I guess I am not clear on how to fix when it’s coming from a DSO vs the PSA

Thanks,
And sorry to leave you the mess 
Sharon

@5C@ ZC_CUSTSL : Data record 241 ('011650000000iere '): Version '011650000000iere ' is not
valid RSDMD 194 @35@ @3R@
OIH FAILED DUE TO MISSING SALES ORG….

ZC_ICGRP is not maintained in /BI0/PSALESORG ZBW 40

Return code 4 when converting field /BIC/ZC_ICGRP in record 18509 RSAR 118

Go to the PSA (/BIC/B0000417000) and delete the bad record after getting Sales Doc number

Create a ticket for SD team and ask them to reorg S571 USING OLI7 to correct the record

Go to the requests of the cube – to the reconstruct tab -> Process Monitor (for failed request) -> Status
-> Double click on Total and turn it green in the monitor and reconstruct – this should make the rest of
the chain go as well
 dispatch 16:00 SNA PER SAS Export SNA (open hub)

Dear colleagues,

In case you are facing such issues, please read the error message carefully. There were long ago
exported requests in the Open Hub Destination that have been left with status red and not weren’t
deleted.
The best way to delete the red requests to display the DTP, go to the monitor and extend the free date
selection to no date selection to display all logs of the runs. Then go into the respective log and hit the
delete button.
In case there are more, delete all of the red ones.

After a repeat in the chain, the export should be working again.

The handling is similar to a delta DTP. The next export is only working while the previous one was
green or deleted.

I’ve corrected the old log entries already and did a repeat.

Have a great day,

Markus

Von: Wittrock Frank

Gesendet: Montag, 21. Dezember 2015 17:35
An: ITG-D CC_SAP MIS <ITG-DCC_SAPMIS@swarovski.com>
Betreff: dispatch 16:00 SNA PER SAS Export SNA (open hub)

Dear dispatcher,
seems that this chain is cancelling.

I will clarify tomorrow with Bettina

The reason might be that Bettina already inserted Open Hub interface for 2016, which is
canceling and 2015 is green.
Seems that the cube for 2016 (restriction in the properties) doesn’t like to give data for 2015
(which is selected in the infopackage by a routine)

Lets see tomorrow.

wbr Frank
 Asia Stock failed in A113

I just removed now the red request from the data target and the preceeding PSA and did a repeat first
to just test. It seems that it's working now.
Dear all,
in this case I corrected the entry in the PSA tabel (190  1900, but not 100% sure if its
correct but it seems the best).

Afterwards in the past we set the delta to green an skipped the process waiting on a full of
the interface to load all records again
cause a repeat leads to the error message that this is not possible (record mode R not
possible for master data).
But it also works with the repeat with scheduler functionality.

I have no ideas if this always worked and if it only works in case data is loaded into a DSO
instead of infoobject directly.

So the process can be the following

- Change the record in PSA (change mode is available) if possible and you know how it has to
be corrected (check with P10 team)
- Set the request to green
- Update with scheduler
- Skip process in chain
the following process in the chain should run as usuall.
wbr Frank

Von: Wong Teddy

Gesendet: Mittwoch, 1. April 2015 04:38
An: Wittrock Frank
Betreff: Material material attribute error in P10 side

Dear Frank,

We had an error in the InfoPackage of the material master attribute that the authorization group is not
correct. It's looks like the authorization group was maintained with the wrong value.

I am not sure if I should correct the value in PSA. Would you please help to check this issue? Thanks.
Hello,
it seems that we have sometime inactive transformations after transport,
even the TRF seem active in RSA1.

The easiest way is as Sing described, use the program (6.) and activate the relevant TRF again.
You should use the “ACT” version in the program only in case there is no “ACT” version use the “INA”
version.
Details of the TRF you can find in table RSTRAN.

wbr Frank

Von: Hau Sing

Gesendet: Dienstag, 17. März 2015 03:44
An: Bettencourt Sharon
Cc: DL-IT_SAPMIS_SUPP; Wong Teddy
Betreff: RE: Asia Stock Chain - Failed

Hello Sharon,

Yesterday we had the same issue as well.

Searching through the internet using assign type conflict I saw that they were referring to that the
transformation is probably inactive, although it is showing active.

Therefore I looked into SE03 transaction and searched for transport which contains the (target)
infoprovider. Because usually if a transformation is inactive it is most likely due to transport. And it was
bulls-eye!  This confirms that the “inactive” transformation could be the problem.

In short:
1. Assign type conflict issue
2. Look for the infoprovider (target)
3. E30, transaction SE03 to look for the infoprovider within transport
4. If found and it was indeed transported recently
5. Go back to P30, and start transaction SE38
6. Run program RSDG_TRFN_ACTIVATE
7. Fill in the transformation ID of that flow and run
8. If nothing happened, please change the “INA” into “ACT”
9. Run it again and afterwards you can delete the red packets and repair/restart the process
step.

Hope this does not confuse you. If there are any questions, please feel free to contact me.

Best regards,
Sing

From: Bettencourt Sharon

Sent: 17 March 2015 01:58
To: Wong Teddy; Hau Sing
Cc: DL-IT_SAPMIS_SUPP
Subject: Asia Stock Chain - Failed

Hi Everyone,

Sorry I could not fix this one… not sure what this message meant – who ever fixes it please let me
know so I will know next time

Thanks,
Sorry to leave a mess,
Sharon

It died on line 638 of this code … 

Missing PG in OIH etc but exist in the source system …. Check the query to see if it is using the
navigational attribute.. if it is a brand new item (especially at year end) the change run may be stopped
and the attributes are not getting updated
Hey!

I had to correct a view things in this chain, but now it is running fine again. But it is running delayed
compared to its normal time frame.
Anyway, I think the delay shouldn’t affect any other process chain.
In case that a change run and a BWA-roll-up are locking each other please be aware of the following
steps:
- Restart the change run in the monitor
 And in the monitor will appear a symbol for the restart of the change run

- Repeat the change run in the process chain (that the chain will continue)
- Repeat the BWA roll-up job

KR
Michael
 @5C@ Recreation IC ZB_SAD403: Request ID 3.086.267 is less than rollup-ID 3.086.268;
no insertion @35@ when trying to update from PSA

the cause for that problem was, that a manual roll-up into the BWA was done before the chain was
finished, so the wasn’t unable to insert the request with a lower number into the cube, cause a higher
request number was already rolled up into BWA. The BWA doesn’t allow inserts in between, you only
can put something on top.
I removed the BWA index of that cube, made an update with scheduler from PSA into the related cube
(ZB_SAD403), made a skip in the chain and let it run.
Once the chain was finished, I had to create the BWA index for that cube again. That wasn’t a big
deal, but it’s annoying when it happens.

I already talked to Cesc, that he should take care, when doing manual steps on the cubes and first
check the runs of the process chains.

Whenever it says in the messages or websites “Aggregates”, mostly in our system landscape it then
has to do something with the BWA.

Thanks for researching the problem.

Talk to you soon,
Markus

Hi

I didn’t get to talk to you this week and I hope you had a very good vacation. I am sorry I have
to start my first e-mail with a problem. I thought you probably would log in over the weekend
 and I think you are dispatcher anyways for Monday so that Is why I just sent this to only
you.

Today I have to leave at 12 and the Asian Sales order PC failed with this message

@5C@ Recreation IC ZB_SAD403: Request ID 3.086.267 is less than rollup-ID 3.086.268;

no insertion @35@ when trying to update from PSA

All requests are green – I googled the message and it said to deactivate the aggregates and I
wasn’t sure how to do this …. Can you tell me what I should have done for the future?
Hopefully next week you can fill me in on your vacation  -

Sorry to give you more work.

Hope it’s an easy fix for you

Br,
Sharon
During the data loads there are different errors with sometimes misleading
error messages. The correction / handling should be described in here.

2lis_11_vaitm
Following error messages came up within the last periods.

No cons code found

At the moment I know two reasons for this error.

Missing product hierarchy entry in document line

As the coding takes the product hierarchy of the document line to find the relevant
business out zbw_prodhier table to evaluate the correct customer master data. If this
product hierarchy is empty no business could be evaluated which leads to the
misleading message “no cons code …” as this seems to be a customer issue.

Solution
Correct the PSA table with the product hierarchy from material master (TA: MM03)
and create an incident for SD team to correct the document.
Attention: when SD team did the correction there will be again the same issue
caused by the before image record.

No Business in table zbw_prodhier

Within table zbw_prodhier (TA: SM30) no entry for the product hierarchy is
maintained

Solution
Maintain zbw_prodhier with the correct Business (check with Business) and repead
dataload afterwards.
No plant available
Reason  missing plant entry in the document line

Solution
Check the document and clarify with SD team which plant should be used (normally
it’s the same for all positions), also create an incident for SD team to correct the
document.

Reason  missing plant in BW

The plant is used in different steering tables which are used for price calculation. The
process is described in the How To paper. Follow the instructions in the paper and
repeat the load.

Change PSA & reload

In the above described scenarios it is necessary to correct the data in PSA and
repeat the upload. A change of the PSA is only possible if the request (in this case it
is red not in all but in some of the cubes) is deleted from all relevant providers
(Cubes, DSO). Afterwards you can maintain the relevant records in the PSA table.
Afterwards you can start a repeat from PSA to providers (2. Step in the chain).

Hint: Check all errors in the PSA table (not only the first mentioned in the error
message).
As this process (delete out of all cubes and reload) can take some time and the error
is most of the time only cause by one cube (region) another solution is also possible.
For this you need “debug & replace” authorization, which can be requested via IDM
(IT self service) tool with the “SAP: emergency process”.

After requesting the authorization it will take up to 15 min (you will receive an email)
from Servicedesk “(INFO) Your SAP permission has been changed”.
With this permission you can change PSA table with “Dirty Harry” (/H) logic.
First delete the request only out of the concerned cube(s) (where the request is red)
and after this you can adapt the records within PSA. If this is finished update the
request with scheduler only in those providers where the request is missing.

After the request is updated in the targets the process ”update from PSA” in the chain
can be skipped (two step process).
Hint:
If in the chain a single step process is used, this will become green after the update
with scheduler is finished so that there is no further step necessary in the process
chain.
ASIA Master Data failed due @5C@ Cannot find CGBVPO from VISREG,COUNTRY ! ZBW 86

Means

Go to process monitor and change the status to green (say yes to the qm message) – then go to the
targets and change the red request to green - --- master data cannot be repeated so after turning

both green next step should just start (do a refresh of the process chain to check) - business should

be told to fix bad record (as full load of master data is done 1 time a week this is ok to do this)

Missing business due to new pg/ig = check table zbw_prodhier and fill appropriately

SE24 – Places to check for pricing logic etc.

ZCL_2LIS_13_VDITM - GET_DATA

Zcl_2lis_11_vaitm
Missing traffic conversion rates – how to reload
(this is the recording that Markus did)
http://ccp.internal.swarovski.com/p01/0006/001/000043/priv/wiki/KHT%20Videos/RSIS%20TOMAX%2
0History%20Bettencourt%20Sharon.%20.%20.%20-%20Sep%2023%202013%2005.01.47.wmv
or

http://ccp.internal.swarovski.com/p01/0006/001/000043/priv/Dispatcher%20Documentations/P30/SIS_
Global%20manual/RSIS%20GUID.docx
Dispatching bible – messages and prayers - this is for reference and is just blurbs of e-mails etc that
have been put in here - ---- needs a lot of work to become perfectly meaningful!

ASIA Day Materdata

Object locked …..
Just did a repeat on the activation step – after the person locking the data was done
Bad sales….

BELNR 2320048013 POSNR 001060

BELNR 2320049827 POSNR 000420

BELNR 2320050475 POSNR 000630

BELNR 2320050475 POSNR 001480

BELNR 2320051787 POSNR 002410

BELNR 2320051787 POSNR 002600

BELNR 2320052491 POSNR 001560

BELNR 2320052666 POSNR 004040

the best thing is to delete the wrong sentences out of the psa with the /h

delete the wrong request out of the Asia Cube and then load it again from the psa

I wanted to skip the OIH load for Asia, but the problem is, that stock and OIH are loaded in one
process chain...
If loading text and it is coming from a DTP – go to administer target delete red request and issue the
repair/repeat button - do not repeat if data source is delta coming from P10 or P60 just turn green –
Fridays master data can go if bad because Saturday is a full.
ASIA stock died – with above message…. Talked to Markus his response….
ah, I think it's a BWA issue this time, I think I forgot to tell you, that SAP is working on some things to
solve the issue with the BWA, like today or on tuesday

I'll ask Basis about the status

Seems P31 is unavailable…. Hmm that could be the problem

Another time same problem – repeated step and ….

Reason:
Repartitioning in BW /BIC/4 shadow table.
During this process SAP creates some shadow tables /BIC/4…. (with Cube name) as a copy to be
save in case of errors.
These /BIC/4… tables are not deleted afterwards and that’s seems to be the reason for the index
problems.

Solution:
There is a report to delete RSDD_REPART_SH_TABLES_DELETE
After deletion of these /bic/4 tables it should be possible to recreate the indices (maybe this has to be
done via TA: SE14) correctly.

In some cases remaining /BIC/4 indices have to be deleted by using Oracle Enterprise Manager.

SAP Notes:
1008833 repartitioning how it is done
1360381 repartitioning deleting shadow tables

----------------------------------------------------------------------------------------------------------------------------------------
--------------------------

Process Generate Index, variant CONDITIONS Rest of World has status Undefined (instance )

DROP INDEX "/BIC/FZB_SAD41C~07" [DBMAN099]

SQL-END: 28.01.2013 15:15:23 00:00:02 [DBMAN099]

SQL: 28.01.2013 15:15:23 ALEREMOTE [DBMAN099]

DROP INDEX "/BIC/FZB_SAD41C~08" [DBMAN099]

Process Execute InfoPackage, variant 2LIS_13_VDKON_DELTA has status Ended with errors (instance
ERRO_DEJQ9ZOMGC7VHS77HQWST43VQ)

Last delta upload not yet completed. Cancel [RSM1084]

Diagnosis
In the BW system there is no information from the source system. No Info-IDoc was found with an info status (rqstate) > 1 in the BI system. This at
least confirms that the data selection was started.
In this case, the BW assumes that the extraction process is not yet completed. The system is not in the position of determining whether or not the
extractor in the source system has registered the request as a delta request or not.
The request is set to red in the monitor, because the maximum wait time has already run out, after which the system valuated a request as being
incorrect (the timeout time for yellow) .

Procedure
If you are sure that the extraction process is completed and the request actually needs to be valuated as being incorrect, meaning it has to be set
to red, set this status manually in the monitor by using the QM action (tab page Status -> pushbutton Total).
Otherwise, search according to cause to see why neither Info-IDocs nor data are arriving in the BW.

Process Read PSA and Update Data Target, variant Condition Update has status Ended with errors (instance
PSAP_DEJQAJP6UARWS5LWWORVV6EG6)

Variant doesnot contain a valid combination request/data target [RSMPC116]

Conditions failed after a repeat due to a system shut down – go to rsa1 and check info packages for
2LIS_13_vdkon for P10. Need to turn them to red?

Go into the BW monitor (RSMO) and find the failed delta load. On the
Status tab, click the pushbutton labeled "Total" near the top of the
window. Set the overall status to Red. Click Save. Re-run your delta load
(not the init,) and it should restart this time.

Kept repeating – and manual running this wasn’t clear to me either

Double clicked on yellow box and red lights were there with log not found errors message – just be
patient and it will turn to green hopefully
Master Data load failed with message

The analysis of chain CRM_MARKETING_ATTR_2 showed th

Process DTP_LOAD DTP_D3W19QZ35NXQJT2CUWKITZDPU was
Terminated However the process has either successors
Are executed if errors occur) or a metachain. Run
EKETQSQI6MNN9F6RTJF75T5K could not be ended due to
ermination. It may be the case that a metachain was
nformed about the error Continue run for chain
RM_MARKETING_ATTR_2 and any corresponding metachain

Click NO You may have to continue clicking no – no one seems to know if no or yes is the
right answer but everyone is clicking NO for consistency. This message was a result of some
earlier chains failing and some DTP and transformations not being active. Find the DTP and go
to RSA1 to see if its active also check transformation. If the transformation is not active run
the following program thru SE38 RSDG_TRFN_ACTIVATE – USE THE TECHNICAL NAME OF THE DTP

if it does not fit in the selection user the arrow button and fill it in there. After this is activated the DTP

should also activate (recheck on RSA1) then back to process chain – REPEAT (and cross your fingers)
SIS_MATERIAL_MASTER_PRICE

Error message from the source system

Diagnosis
An error occurred in the source system.

System Response
Caller 09 contains an error message.

Further analysis:
The error occurred in Service API .
Refer to the error message.

Procedure
How you remove the error depends on the error message.

Note
If the source system is a Client Workstation, then it is possible that the file that you wanted to load was being
edited at the time of the data request. Make sure that the file is in the specified directory, that it is not being
processed at the moment, and restart the request.

Delete the requests and repeat the run

ASIA_SALES_ORDERS

This was caused by the rollup of the cubes was still running from a previous job in this case SNA sales
was still green. The SNA sales job could not create the indexes so we stopped SNA sales and Asia
Sales and checked all cubes requests for rollups and made sure the rollup was successful or re-ran it
and then deleted the indexes to all the cubes. We then went back to the SNA job – skipped the create
index step so that PC would turn green, next we skipped the delete index step in the ASIA chain and
18on it went
Stock running forever………………………………. ASIA STOCK

Check to se e if the cubes are in the BIA – if not then create the BIA index

Click on the Create button and then right top ACTIVATE AND FILL BWA index
(NOT THE QUICKEST JOB IN THE WEST)
1800 EUR PER SiS RETAIL TECHTRANS – just did a repeat on these 2 seems to have worked
Hi,

in case that a change run fails due to not indexed characteristic values (collision with master data delta
daemon), you can restart the canceled change runs in RSA1.
In the first 2 pictures you can see the messages which might appear in the monitor. You then can go
to RSA1 and search for menu entry “Tools” -> “Apply Hierarchy/Attribute Change”.
On bottom of the Dynpro is a button with caption “Monitor and Start Terminated Change Runs”. There
you’ll find an entry for the terminated change run with a red traffic light. There you can click the
“Execute” button (watch symbol).
After successful execution (just hit refresh) you can go back to normal monitor and restart the
terminated red process variant of the change run. After that it’s also possible again to restart
terminated processes for Roll-Up.

Please check before restarting Roll-Up processes into BWA:

If no change run has terminated (also check other process chains), you can restart the process
immediately.
If there is a terminated change run, first solve the change run issue with RSA1, restart the process for
the change run in monitor, then restart the Roll-Ups in monitor.

Thanks,
Markus
Check to see if PSA_DEL_ALL_BW_CONTENT is running – then there will be contention – after this
is done – repeat the process and delete old requests that are red

Seems that there is a problem with writing data into PSA table.
I thought that there are maybe to many request or data in the PSA table and tried to delete several
request from PSA manually.
I don’t know if its finished because it took too long for my session.

But maybe the reason is somewhere else

The weekly process chain to delete old PSA entries is running at the same time
and maybe there is a conflict with writing and deleting at the same time.
I suggest to reschedule the weekly PSA – changelog deletion

5_Friday: PSA / CHANGE LOG DELETE BW Content MAIN

from Friday 2 pm to 6 pm to avoid such conflicts in the future.

continues on next page….

in this case probably first try would be deleting the request out of the data target (do you know how to
access “Manage” on info objects?) and then make a repeat.
If it fails the second time, I would just set it to green, since it’s text 
I’m afraid I’ve hadn’t seen this message before. Maybe something like a version mismatch within the
program?!!?

In this case it’s no problem to make a repeat, since the source isn’t outside BW and not a real master
data extractor. 

Have fun, 
Markus

From: Bettencourt Sharon

Sent: Monday, March 04, 2013 9:04 PM
To: Jordan Markus
Subject: What does this mean? - answer when you get bored (if ever)

Hi Markus,

I was looking at some other jobs in RSPCM besides the Asia chains and one I got to turn
green, but didn’t know what the heck to do with this one - -

Have you seen this message before? I did a google but it still was nonsense to me. What
would you have done with it?

Thanks,
Sharon
Delete the red request and repeat the process
Correct Plant on Sales PC 2LIS_11_VAITM I.E ASIA_SALES_ORDERS

From Process chain log go to PSA Maintenance (hamburger) – search the table for erroneous
records in all data packages – double click and get the vbeln (document number) – it’s easier if
you change layout to Sharon for displaying the table.

Find all the data targets where this PSA was loaded to and delete the request id from them

Go to correct data by opening another session – find info source 2lis_11_vaitm – manage – go
to hamburg (select all and find the records) – you can either filter on the vbelns from above or
blank plant. Fix records

Go back to process chain and repeat the step. Also, you could delete just the red targets and
do a run with scheduler but then you need to go back to Process chain to skip the step that
failed
Hi Markus,

Thank you as usual – you are really too nice! – (but don’t change )

You scared me with the master data failure statements but thankfully they were all green – I had a few reds
ones, the ones highlighted in green have now turned red – the cgb availability is still red 

Here is what is their status :

-
SIS_STOCK_LATAM - This failed in the step for Venezuela and I did a repeat which seemed to work fine. The
first message Database system cannot be reached – was repeat the right thing?
Change run for Masterdata…
In case the change run in SNA Masterdata fails, you have to go to RSA1 -> Tools Menu -> Apply
Attribute-/Hierarchy Change… -> Button on bottom “Monitor and Start Terminated Change Runs”.
There you’ll find a red entry, start the process with the restart button on the right in this column. Wait
till it’s finished successfully (if it fails again, make a restart once again )
After that make a repeat of the process chain process Change Run in SNA Masterdata. Once it’s
finished you can repeat all other terminated processes that were blocked from that process.
---------------------------------some mail with some things and how to fix.......................
no problem at all.
Gladly it went green, not like yesterday. On the last and first day of month and on Sunday this process
chain is sometimes colliding with another load.
So in case you’re the lucky dispatcher again, you now already know what to do. 

You did a good job with restarting the processes.

Venezuela is often losing power, in this time the database cannot be reached. 
CGB availability is probably the most annoying thing we’re having in BW. It’s failing every Wednesday
cause of some not allowed characters within a comment field.

I finally got to fix it. You always have to go to P10 searching for the not correct comments in a
maintenance view and then you have to do a lot of steps manually and in case you forgot a line you’re
ending up doing it 4 to 5 times like I did today. That’s the most horrible process chain in BW.

From: Bettencourt Sharon

Sent: Wednesday, May 01, 2013 9:33 PM
To: Jordan Markus
Subject: RE: Hi - and a question of course....

Hi Markus,

Thank you as usual – you are really too nice! – (but don’t change )

You scared me with the master data failure statements but thankfully they were all green – I
had a few reds ones, the ones highlighted in green have now turned red – the cgb availability
is still red 

Here is what is their status :

-
SIS_STOCK_LATAM - This failed in the step for Venezuela and I did a repeat which seemed
to work fine. The first message was Database system cannot be reached – was repeat
the right thing?
RSIS2SIS_DAILY – I Repeated the failed step but the rollup of the zb_sabrh said it was still
running, so I skipped that step and went on – went back and still said rolling up for the next
couple hours – I then rolled up manually – not sure if it was the right or wrong thing to do.
What do you do when the rollup never ends I tried googling but didn’t find much

Z_CGB_AVAILABILITY_2 – I tried repair and that didn’t work so I left it as it was not on the
SNA or Asia list I wasn’t sure how critical it was? How do you fix this one? Who does this
belong to?

This one dies as the result of incorrect characteristics – will be reviewing it with Markus to see
if we can add code to change these to spaces

ZCATS - CALL_FUNCTION_CONFLICT_TYPE – this is strange to me – – I decided to try a

repeat and it worked so god knows…
ASIA stock

Repeat worked
12:30 SNA DAY RSIS/SIS LATAM and TOMAX – Failed in activation step with deadlock on table –
Go to DSO activate manually restart the job
please make sure to set ANY delta request to red status in the monitor before deleting it from any data
store object / info object in case of errors and read the error messages carefully.
I had immense problems to find out the right request and setting it to red status to make it possible to
activate ZO_CM001 again.

Please keep in mind that the system is tracking all status and serialization for delta requests for correct
delta handling.
Asia Stock - ….. repeated that step
SIS Retail Daily Tech

User ALEREMOTE locked the load of master datas for characteristic ZC_GUID [RSDMD174]
Diagnosis
User
ALEREMOTE
is preventing you from loading master data for characteristic ZC_GUID
. The lock was set by the master data loading process with the request number (DataPackage number)
DTPR_DFFASZGIJQBUB3TEVJEWDFUMW(000001)
on
20130611,181514(448000)
.
System Response
For reasons of consistency, the system cannot allow the update to continue, and it has terminated the process.
Procedure
Wait until the process that is causing the lock is complete. You can call transaction SM12 to display a list of the locks.
If a process terminates, the locks that have been set by this process are reset automatically.
Retail Daily Tech

This failed due to a lock – there was no repeat for this step – so what I wanted to do but was too
chicken ( but also had to go to a meeting for the rest of the day) was to delete the red request – re-run
the DTP and then skip this step - .... was that what I should of done?
How to do a change run = rsa1 – tools – apply hier and attrib change – deselect all and pick one you
want – keep refreshing

Sending specific customers –

Run the customers thru zc_cm001 (use t10 or whatever)

Then run to zc_cm003
Then run again to zc_cm001
Activate dso’s along the way – then do zc_cm001 to zc_custsl (texts don’t come from t10 )8

SENDING STATUS MAIL

Public folders – ladestatus – status mail for America…. Double click – change from to IT SIS

Shop Code Load in Global Daily– if the file has errors need to send an incident to SUPPORT.MIK to
have them fix it – let it stay Red – inform Asia Dispatcher red is ok
To fix this you can try to do a manual update by clicking on the package in error (right click I think)
This is just a mail so more blah blah than meat….

Hi

First of all sorry to burden you guys with this – it stinks to be alone 
Please check this if you can…. ASIA_SALES_ORDERS
I guess that 2014 cubes were added and I think the lock happened then – but not sure if that is what
confused the Process chain – but we (Harry) updated the PSA with scheduler then after 2 hours…
I have more messages but it is still is yellow  ….

Sorry again for the extra work…

Best regards,
Hi,

I have a problem with the Asia Sales Orders – probably a BW 101 (which means I should have know
this) so please tell me how I should have fixed that for next time

First it was locked by Majcst …. Who was gone by the time I saw this so I don’t know what he was
doing…

So I did a repeat on this step which then turned green

… and then the next step failed due to the following message which I had never seen before - I tried
to google it but got no good answers…
The problem is that no BWA index exists anymore, I've started the re-indexing.

And then repeat the step

Check to see if cube is in bia – if not create index
Hi Sharon
it is a little bit hard to correct this issue not knowing the details to solve it.
Problem was a missing entry in the zbw_prodhier table (p30) for PG/IG 0267
I added this entry, deleted the remaining request in the cubes and repeated the process.

Now its finished

From: Bettencourt Sharon

Sent: Tuesday, December 31, 2013 9:53 PM
To: Hau Sing; Marimon Munoz Francesc
Cc: Jordan Markus; Wittrock Frank
Subject: Beginning to feel like the grim reaper :(

Hi,

The Asia Sales PC died today due to I think the PG/IG changes – the sales orders have some pg/ig
changes on them and it caused it to fail… I deleted the red requests and was going to fix the PSA but
then because of all the year end stuff going on wasn’t quite sure what to do with it so I ended up
leaving it - it is difficult being here without anyone to ask sorry… hasn’t been a very good last few
days dispatching….hope the world turns a bit greener in 2014 

here is the sales order and item that had the issue

Sales Doc… 300263890 and item 1066754 with pg/ig 0267 – says no business found.

As usual sorry for giving you extra work….

Problem with ZSIS_MASTER_01 -

I just got informed that the VPO-Regions are usually maintained when creating a new VIS-Region.
In BW we do this ourselves with the information we get from the Business – however, this was missing
in case of VIS-Region 611F.
I have caught up on it and now data load is eventually green.

Best regards,
Sandra

From: Piwonka Sandra

Sent: Friday, January 10, 2014 7:53 AM
To: Bettencourt Sharon
Subject: RE: Problem with ZSIS_MASTER_01

Hi Sharon,

the problem is, that CGBVPO is filled from master data of VISREG, but for 611F no VPO-Region is
maintained, hence it gives us an error.
I’ll ask business to maintain the relevant region and hope the problem will be solved then.

Best regards,
Sandra

From: Bettencourt Sharon

Sent: Thursday, January 09, 2014 7:27 PM
To: Hau Sing; Piwonka Sandra
Cc: Lamprecht Michael; Jordan Markus; Gruber Barbara
Subject: Problem with ZSIS_MASTER_01

Hi

I saw this had a problem during the day but I was not sure how to fix the record in question – what
value to put in ….. is there a problem with zc_visreg master data or the actual record in the request?
Please let me know what to do with this problem in the future (do I fix the request or the master data
table or contact someone up above?)
Thanks,
Sharon
Maintain Dispatcher File

Go to ….

http://ccp.internal.swarovski.com/p01/0006/001/000043/priv/Dispatcher%20Information/Forms/AllItems
.aspx

in left hand corner you will see

Double click on Asia Dispatcher file

Edit Dispatchercheck_America

Open it and on tab 1 change date

And add any comments necessary

Go to tab 2
Go to SAP – go to RSPCM – sort by date and time – and columns to look like below
Copy and paste the whole thing and put in into tab 2 – save
How to fix the BUT0ID problem

First delete the red request

Then go to RSA1 – info source 8zo_endu
Find request that wasn’t updated yet – filter on identification type zemplo
Look for bad dates – take
the best guess for fixing – save and then repeat the failed step in PC
Asia Master Data PC Error - the chain is red?
this is an 3.x update from the DOS zo_cm001 to the next target (I think zc_custsl in this case).

You can find the relevant Infopackage within

Datasources with name 8zc_cm001.

In former days (3.x) an export datasource was created if you have a further update
with a leading 8 and the name of the DSO.

As it is master data best way is to set the request to green (and normaly do a full afterwards, which is
in the case zc_custsl not the best)
and additionaly to a repeat afterwards to be sure next run will be green and doesn’t block further
processes.

wbr Frank

From: Hau Sing

Sent: Wednesday, May 28, 2014 5:36 AM
To: Bettencourt Sharon; Wittrock Frank
Cc: Cheung Wilson
Subject: RE: Asia Master Data PC Error - the chain is red?
Hello Sharon,

FYI regarding to what Update DSO data (Further Update) means

http://scn.sap.com/thread/431974

I think this is mainly used in the old days (3.x), but not sure about this though.

Have a nice day! 

Best regards,
Sing

From: Bettencourt Sharon

Sent: Wednesday, May 28, 2014 2:33 AM
To: Wittrock Frank; Hau Sing
Cc: Cheung Wilson
Subject: Asia Master Data PC Error - the chain is red?

Hi,

Could someone please tell me what I should have done with this …because I think I broke it …. I did
not know how to fix it because I could not really find an error message  that meant anything to me
so I did a repeat and then the change run failed –

sorry if this is a stupid error and I should know what to do with it.

This was my first problem…

What exactly is this variant doing – I don’t think I ever used it before 
So I tried a repeat which I guess was the wrong thing to do because then I got this

Is this due to a data collision?

FIX DTP GUIDE
First we need to check what the issue is. This can be done by right clicking the red process in the
process chain and choose “display messages”

In this case we see that there is a serious error, however we cannot gain any knowledge about the
issue.
Therefore we need to go to Process Monitor.
And we expand it so that we see the messages and click on it. You will get the following screen:

Here you see that there is some hexadecimal characters in the description and therefore caused the
error.

To solve this, first we have to locate the package which failed to load.
Then we go to the target infoprovider to manage the requests

In this case there is only 1 target therefore we only need to remove the failed request from this
infoprovider. (please note that before remove the failed request you have to make the request red and
then deleting it.)

Now we need to adjust the erroneous record in the source. And we go to manage that infoprovider.
 Most of
the time the erroneous record(s) is in the last request(s) therefore we copy the request ID of the last
request and go to the change log at the contents tab.

Here we just fill in a part of the content that was mentioned in the message to find the record.

If you press the goggle sign you will see that the full details of the record.
Here we see that there is a hash pound key “#” within the TXTLG. This is not accepted by the BW
system therefore we need to remove it. This can be done by the “transaction” /h to enter the debug
mode.
Once entered the debug mode. Press F5 key once and you will see the following screen.

Press the pencil and change the “SHOW” into “EDIT”. (Please note the field is capital sensitive). Then
press F8 and you will enter the edit mode
Now you can remove the # sign and save the record.

To be consistent this also needs to be done in the active data table of the DSO in this case. And
afterwards you can do a repeat of the failed process in the process chain.
SIS Material Master Price ….. bad record in ZO_VENDOR

18:00 EUR DAY SIS Material Master Price & Procurement P10 - "#" found in characteristic TAX_NUM
in ZO_VENDR.

Solution:

ZO_VENDR = Delete red requests

0VENDOR_ATTR = Go to PSA, Select all Entries,
Search a Tax code 1 = #
Find it, edit it, delete it, save it.
After that update with scheduler and repeat the whole data loading process. Activate the requests and
then continue the process chain.

The problem is, this has to be corrected at the source and since nobody in Wattens is available there
was no chance.

I have raised an incident with the information of the wrong data set:
P10
Data Source: 0VENDOR_ATTR
Vendor: 0000106826
Country: TR
Creation Date: 20.06.2013

Tax Code 1 = #