on 11-24-2015 4:45 PM
I'm loading a DSO with data from 2 other DSO's and need to figure out how to limit the data load from the 2nd DSO to just the records that are in the Target DSO.
Looking at the image below when I load data from the first DSO I'm moving 4K records to my Target DSO. I also have a filter on the DTP to only load data that has a GL Account Between a certian range.
Now I need to load data from the 2nd DSO but I only want to load the data that has a matching record in the target DSO. In my case the 2nd DSO contains 28K records but I only need from 4K of those records. Whats happening is that the 2nd DSO is loading all 28K records so I end up with data I don't need. The issue with my 2nd load is that it does not contain the GL Account number so I'm unable to filter this DSO's DTP to only select data with a GL Account Range.
This image is an image that shows teh keys of the Target DSO. DSO 1 and DSO 2 both contain these fields and i'm mapping to them.
So back to my origianl question, how am I able to restrict the data from the 2nd DSO to just the 4K reocrds that are currently existing? Maybe a start routine is not the best way to go about this.
Ideas? Suggestions?
Thanks
Hi Larry,
Please confirm below things.
Please let me know this .
Thank you,
Nanda
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Nanda, you are correct, DSO 1 has a GL Account and DSO does not. DSO 1 is the GL Line item DSO and DSO 2 is the Tax table for Accounting Documents which dosen't contain the GL Account. However, the 2 DSO's do have account document number, company code, document type and period in common.
Basically, I'm trying to create a new DSO that will only hold that data for a specific set of GL Accounts (DSO 1). DSO 2 contains the tax information along with some customer information that I need to update the existing records with. However, the way its set up i'm loading everything from the 2nd DSO since I dont' have a way to restrict the data.
Hi Larry,
Do like this.
In target DSO DTP(DSO2-->Target DSO), for "Account document number" write routine as like below.
Thank you,
Nanda
Both of these appear to do exaclty the same thing but one is in the DTP where as the other is in the start routine. Of the two (and being pretty green and not knowing better) I think I prefer the start routine since I tend to over look the logic in the DTP. Regardless I believe they pretty much follow the same logic and i need a little help with the syntax.
DSO 2 Start Routine:
Select Distinct Accounting document number from the target dso. This will give me a list of valid records (accounting documents) that I need to load from the second dso.
Now I need to delete the records from the source package where the accounting document number is not in the list above. Im not sure if you can do a delete like this but in SQL I would do something like the following (Granted this is not valid syntax but hopefully you get the idea).
DELETE SOURCE_PACKAGE WHERE AC_DOC_NR Not In GT_VALID_RECORDS
So I have the following code in my start routine but this does not validate and not even sure you can do this. When I check the syntax it says that GT_VALID_RECS does not have the structure of a seclection table.
So Im not sure if I can do a deletion this way or will I have to create a loop and loop over each record and delete the records 1 by 1?
Thanks
Hi Larry,
Since in initial question you said Start routine is not preferable hence I suggested routine in DTP.
Anyway here is the idea to delete records from source package
Please check this.
Thank you,
Nanda
Hi Larry,
I fear with both approaches that it can lead to technical problems. SQL select statements cannot deal with thousands of distinct values. Also FOR ALL ENTRIES without a distinct list of values can lead to memory problems.
Furthermore, your DELETE statement needs a selection table (i.e. like a range table).
Since the target DSO is rather small, I suggest to load the entire table into an internal table. Alternatively, you can filter on Company Code, Fiscal Year/Period and Fiscal Year Variant (i.e. leave out Accounting Document Number). But then you have to do a preliminary step to prepare an FAE (For All Entries) table to be used in the SELECT.
Then you can LOOP over the source package and check if the Accounting Document exists in the target DSO. If not, delete.
Coding could look as follows:
DATA:
gt_fae TYPE _ty_T_SC_1.
REFRESH gt_fae.
gt_fae = source_package[].
SORT gt_fae BY comp_code fiscper fiscvarnt.
DELETE ADJACENT DUPLICATES FROM gt_fae COMPARING comp_code fiscper fiscvarnt.
SELECT DISTINCT ac_doc_no comp_code fiscper fiscvarnt
FROM /bic/azfi_o0100
INTO CORRESPONDING FIELDS OF TABLE gt_valid_records
FOR ALL ENTRIES IN gt_fae
WHERE comp_code = gt_fae-comp_code AND
fiscper = gt_fae-fiscper AND
fiscvarnt = gt_fae-fiscvarnt.
LOOP AT source_package ASSIGNING <source_fields>.
READ TABLE gt_valid_records TRANSPORTING NO FIELDS
WITH KEY ac_doc_no = <source_fields>-ac_doc_no
comp_code = <source_fields>-comp_code
fiscper = <source_fields>-fiscper
fiscvarnt = <source_fields>-fiscvarnt.
IF sy-subrc <> 0.
DELETE <source_fields>.
ENDIF.
ENDLOOP.
Best regards,
Sander
User | Count |
---|---|
84 | |
10 | |
10 | |
9 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.