qFRC, delta initialisation and enhancing the datasource

[Former Member]

Hi,

We are using the queued delta (LBWQ) and going to fill the billing extractor (13). For reducing the downtime an early delta initialisation will not help and the system has to be down (correct?). Or can we set the block billing doc's during set-up?

<b>(I read Roberto's weblog!)</b>

If we enhance the extract structure for an already in use extractor, the LBWQ and RSA7 have to be empty. Is this enough or do we have to 'remove/empty' anything else? Maybe we could get problems with different versions of structures?!(don't know exactly which structures the FM mcex_update_13_QRFC refers to).

Hope to get some helpfull answers.

Best regards,

Brian.

[Former Member · Accepted solution]

For filling the extract tables, the system shall be blocked (you can lock all users, or, lock all transactions, or??) from posting txns. If you want to specifically block billing docs (because you are only setting that up), you can think of blocking the corresponding txns in SM01 (remember it can still be posted if there are BAPI/BDC or other such interfaces posting such docs).

If you enhance, follow the weblog. That is all you need to do. Empty RSA7 (load twice to BW), deactivate delta, empty setup tables, empty SM13/LBWQ/SMQ1, delete delta queue in RSA7 (did I miss anything?).

There would not be many versions of the same extractor if you follow what has been suggested in the weblog.

[Former Member · Accepted solution]

Hi Ajay,

Thanks for the anwer.

But i still have the question regarding the OLIBW9. If i read the help for the 'block all billing docuements' I suggest that this should be enough to block the billing doc's update. I only want to block the system for billing doc's. Your SM01-proposal looks a bit risky to me (chance of missing something).

Is it a MUST to delete the setup tables for the following 2 scenarios:

1. the change has to be effective from the change on (so no history).

2. we fill the field in a customer exit (so we just changing the structure.

BR,

Brian.

[Former Member · Accepted solution]

Brian,

If you sit with security guy he can tell which users working on Billing related activities. Involve your SD Functional guy also into this. Block the Users.

comming to Changing the extract Structures...

before transporting new extract structure from DEV to Poduction(Changed one with new fields), you need to delete the entries in RSA7 and LBWQ. check the entries in SM13 also. run the V3 Job 4 or 5 times. BW IP schedule the job for every 10 mins till RSA7 entries will get 0.

(Note: when you make changes to ES or Service Pack Implementation or Version Upgrade you need to emplty the RSA7, LBWQ and SM13.)

Filling the setup tables is depends on the requirement, if you need History with new added fields... you need to load the into Setup tables. fill the setup tables using background job.

I never used that option(block all billing documents), let me check that. i will get back to you.

all the best.

Regards,

Nagesh Ganisetti.

[Former Member · Accepted solution]

Hi,

I use a Data Acquisition ODS (with overwrite).

What could go wrong in the following scenario where I don't block the billing document processing in R3:

I do an init without data and let the system create entries in RSA7.

In the meanwhile i perform a setup of the history and load this with a full repair into my ODS.

Directly after this I run my first delta package (to eventually adjust the data from the full repair).

[Former Member]

Hello Brian,

you need to ideally stop the R/3 transaction(billing documents postings) during the set up run.

Also to change/enhance the extract structure, there should be no records in the delta queue, so u delte it from rsa7. Try and empty the set up tables using delte set-up option in the lo cockpit.

if u r using only the 13_vditm datasource, you need not activate the other extract structures in sales like 11, 12 etc.

Hope it helps...