in Tab1
details of PS1_VBRK table load is perfectly fine
in Tab5:
//ZBI0 - NAST
Left Join(PS1_VBRK)
PS1_NAST_ZBI0:
LOAD
ERDAT as ZBI0_Created_On,
ERUHR as ZBI0_Created_At,
KSCHL as ZBI0_Type,
OBJKY as Billing_doc,
VSTAT as ZBI0_Status
FROM
$(SAPPath_New)$(SAPPrefix_New)NAST.qvd
(qvd)
WHERE KSCHL = 'ZBI0';
RIGHT JOIN(PS1_NAST_ZBI0)
NoConcatenate
LOAD
MAX(ZBI0_Created_On) as ZBI0_Created_On,
MAX(ZBI0_Created_At) as ZBI0_Created_At,
ZBI0_Type,
Billing_doc
RESIDENT PS1_NAST_ZBI0
GROUP BY ZBI0_Type, Billing_doc;
Although you gave the table a name (PS1_NAST_ZBI0) Qlik will not produce such table, because you are also joining it to PS1_VBRK (Left Join(PS1_VBRK))
So technically table name PS1_NAST_ZBI0 never existed (as separate table) but it's data is part of PS1_VBRK
Related
I have to join two tabled ACDOCA and BKPF. I have written the follow code for it.
SELECT a~rbukrs,
a~racct,
a~bldat,
a~blart,
a~kunnr,
a~belnr,
a~sgtxt,
b~xblnr,
a~budat,
a~hsl,
a~prctr
INTO TABLE #it_final
FROM acdoca AS a
LEFT OUTER JOIN bkpf AS b
ON a~rbukrs = b~bukrs
AND a~gjahr = b~gjahr
WHERE a~rbukrs IN #s_bukrs
AND a~Kunnr IN #s_kunnr
AND a~Budat IN #s_budat
AND a~Belnr IN #s_belnr
AND a~rldnr IN #s_rldnr
AND a~blart = 'DR' OR a~blart = 'ZK' OR a~blart = 'UE'.
Facing the following errors:----
Runtime error: DBSQL_SQL_INTERNAL_DB_ERROR
SQL error "SQL code: 2048" occurred while accessing table "ACDOCA".
Short Text: An exception has occurred in class "CX_SY_OPEN_SQL_DB"
How do I resolve this? please help.
A few things:
Selecting directly from the database tables is error prone (e.g. you'll forget keys while joining) and you have to deal with those terrible german abbreviations (e.g. Belegnummer -> belnr). Since quite some time there are CDS Views on top such as I_JournalEntryItem with associations and proper english names for those fields, if you can use them, I would (also they're C1 released).
As already pointed out by xQBert the query does probably not work as intended as AND has prescendence over OR, and as such your query basically returns everything from ACDOCA, multiplied by everything from BKPF which likely leads to the database error you've posted
With range queries you might still get a lot of results (like billions of entries, depending on your company's size), you should either limit the query with UP TO, implement some pagination or COUNT(*) first and show an error to the user if the result set is too large.
I would write that like this:
TYPES:
BEGIN OF t_filters,
company_codes TYPE RANGE OF bukrs,
customers TYPE RANGE OF kunnr,
document_dates TYPE RANGE OF budat,
accounting_documents TYPE RANGE OF fis_belnr,
ledgers TYPE RANGE OF rldnr,
END OF t_filters.
DATA(filters) = VALUE t_filters(
" filter here
).
SELECT FROM I_JournalEntryItem
FIELDS
CompanyCode,
GLAccount,
DocumentDate,
AccountingDocumentType,
Customer,
AccountingDocument,
DocumentItemText,
\_JournalEntry-DocumentReferenceID,
PostingDate,
AmountInCompanyCodeCurrency,
ProfitCenter
WHERE
CompanyCode IN #filters-company_codes AND
Customer IN #filters-customers AND
DocumentDate IN #filters-document_dates AND
AccountingDocument IN #filters-accounting_documents AND
Ledger IN #filters-ledgers AND
AccountingDocumentType IN ( 'DR', 'ZK', 'UE' )
INTO TABLE #DATA(sales_orders)
UP TO 100 ROWS.
(As a bonus you'll get proper DCL authorization checks)
2048 is/can be a memory allocation error: Too much data being returned. Given that, this line is highly suspect
AND a~blart = 'DR' OR a~blart = 'ZK' OR a~blart = 'UE'.
I'd consider this instead. Otherwise ALL blart ZK and UE records are returned regardless of customer, year, company et...
SELECT a~rbukrs,
a~racct,
a~bldat,
a~blart,
a~kunnr,
a~belnr,
a~sgtxt,
b~xblnr,
a~budat,
a~hsl,
a~prctr
INTO TABLE #it_final
FROM acdoca AS a
LEFT OUTER JOIN bkpf AS b
ON a~rbukrs = b~bukrs
AND a~gjahr = b~gjahr
WHERE a~rbukrs IN #s_bukrs
AND a~Kunnr IN #s_kunnr
AND a~Budat IN #s_budat
AND a~Belnr IN #s_belnr
AND a~rldnr IN #s_rldnr
AND a~blart IN ('DR','ZK','UE').
However, if you really did mean to return all blart ZK, UE records and only those that ar DR and in the defined parameters... you're simply asking for too much data from teh system and need to "LIMIT" your result set and somehow let the user know only a limited set is being returned due to data volume
I'd also ensure your join on keys is sufficient. Fiscal Year and company code represent an incomplete key to BKPF. I dont' know ACDOCA data table so I'm unsure if that's a proper join which may be leading to a semi-cartesean contributing to data bloat. I'd think in a multi-tenant db, you may need to join on mandt as well... possibly a doc number and some other values... again, this lookst to be an incomplete join on key.... so perhaps more is needed there as well.
I am trying to read the table TIBAN only in the cases when the field BANKN of the KNBK table contains the string "IBAN". The problem that I am having is reading the table TIBAN. For the KNBK table I used the key kunnr to search the table, but the table TIBAN does not contain this field. The code is as follows:
LOOP AT lt_data_bsec ASSIGNING <ls_data_bsec>.
READ TABLE lt_data_knbk ASSIGNING FIELD-SYMBOL(<ls_data_knbk>)
WITH KEY kunnr = <ls_data_bsec>-kunnr BINARY SEARCH .
IF <ls_data_knbk>-bankn_kn CS '<IBAN>'.
>>>>> READ TABLE lt_data_tiban ASSIGNING FIELD-SYMBOL(<ls_data_tiban>).
IF <ls_data_bsec> IS ASSIGNED
AND <ls_data_tiban> IS ASSIGNED
AND ( <ls_data_bsec>-banks_bs NE <ls_data_tiban>-banks_kn
OR <ls_data_bsec>-bankl_bs NE <ls_data_tiban>-bankl_kn
OR <ls_data_bsec>-bankn_bs NE <ls_data_tiban>-bankn_kn ).
ENDIF.
The declaration of the lt_data_knbk table is:
SELECT kunnr,
banks AS banks_kn,
bankl AS bankl_kn,
bankn AS bankn_kn
FROM knbk
INTO TABLE #DATA(lt_data_knbk)
FOR ALL ENTRIES IN #lt_data_bsec
WHERE kunnr = #lt_data_bsec-kunnr
ORDER BY PRIMARY KEY.
And the declaration of the lt_data_tiban is:
SELECT banks AS banks_tb,
bankl AS bankl_tb,
bankn AS bankn_tb
FROM tiban
INTO TABLE #DATA(lt_data_tiban).
Also the declaration of the lt_data_bsec is of the type gty_out:
BEGIN OF gty_out,
bukrs TYPE bukrs,
belnr TYPE belnr_d,
buzei TYPE buzei,
budat TYPE budat,
kunnr TYPE kunnr,
banks_kn TYPE banks,
bankl_kn TYPE bankk,
bankn_kn TYPE bankn,
banks_bs TYPE banks,
bankl_bs TYPE bankk,
bankn_bs TYPE bankn,
banks_tb TYPE banks,
bankl_tb TYPE bankk,
bankn_tb TYPE bankn,
END OF gty_out,
I am having an error in the line that I have marked in the code as it needs a key field to do the reading of the table.
May anyone know what type of field do I need to do a search of the TIBAN table, just like I did for the KNBK table?
I would recommend you to acquire your bank data by doing a LEFT OUTER JOIN with TIBAN.
SELECT knbk~kunnr AS kunnr,
knbk~banks AS banks_kn,
knbk~bankl AS bankl_kn,
knbk~bankn AS bankn_kn,
knbk~bkont AS bkont_kn,
tiban~iban AS iban
FROM knbk
LEFT OUTER JOIN tiban ON
tiban~banks = knbk~banks AND
tiban~bankl = knbk~bankl AND
tiban~bankn = knbk~bankn AND
tiban~bkont = knbk~bkont
INTO TABLE #DATA(lt_data_knbk)
FOR ALL ENTRIES IN #lt_data_bsec
WHERE knbk~kunnr = #lt_data_bsec-kunnr
ORDER BY knbk~banks knbk~bankl knbk~bankn knbk~bkont.
The result will be a table with all entries from KNBK, plus a field IBAN which will be filled from TIBAN if a corresponding row exists and be initial when no corresponding row exists.
Now you can just determine whether or not you have an IBAN like this:
LOOP AT lt_data_knbk ASSIGNING FIELD-SYMBOL(<ls_data_knbk>).
IF <ls_data_knbk>-iban IS INITIAL.
" classic bank number + account number account
ELSE.
" IBAN account
ENDIF.
ENDLOOP.
Your task is a perfect case where ABAP CDS associations aka Lazy Join come into play.
If you are on the recent version of ABAP and is able to create CDS, nothing prevents you from creating this
#AbapCatalog.sqlViewName: ‘ZCUST_TIBAN_SQL’
#AbapCatalog.compiler.compareFilter: true
#AccessControl.authorizationCheck: #CHECK
#EndUserText.label: ‘TIBAN’
define view ZCUST_TIBAN as select from knbk as cus
association [0..1] to tiban as _an
on cus.kunnr = _an.kunnr
and cus.banks = _an.banks
and cus.bankl = _an.bankl
and cus.bankn = _an.bankn
and cus.bkont = _an.bkont
{
cus.kunnr,
cus.banks AS banks_kn,
cus.bankl AS bankl_kn,
cus.bankn AS bankn_kn,
cus.bkont AS bkont_kn,
_iban~
} WHERE cus.bankn like '%IBAN%'
Then you can use this association in all your further requirements:
SELECT banks_kn, bankl_kn, bankn_kn, bkont_kn
\_iban-iban AS IBAN,
\_iban-valid_from AS IBAN_validity
FROM zcust_tiban
WHERE kunnr IN #lr_customers
INTO TABLE #DATA(lt_data_knbk).
...
READ TABLE lt_data_knbk ASSIGNING FIELD-SYMBOL(<ls_data_knbk>)
WITH KEY kunnr = <ls_data_bsec>-kunnr BINARY SEARCH.
...
Key points to pay attention to:
an association with 0..1 cardinality like above does not do actual JOIN until the fields from the associated table TIBAN are requested like in the above SELECT. This can be more performant and more universal than LEFT OUTER JOIN approach suggested by Philipp.
it is reusable and can be used in further selects/associations as a source
I want to know which order position (EBELP from EKPO in SAP MM) appear in which G/L account (HKONT in BSEG in SAP FI with koart = 'S').
I'm working with SQL queries on a redshift database which has the tables copied from SAP.
which has the tables copied from SAP.
If you copied ALL the tables you can improve your query in a following manner.
There is a wonderful table EKBE which is order document history and resembles all order data from EKPO. It contains both order numbers and corresponding material document numbers
EKBE: MSEG:
BELNR -> MBLNR
GJAHR -> MJAHR
BUZEI -> ZEILE
This totally eliminates the need of MSEG/MKPF in your horrendous query. Probable SELECT can be following:
SELECT ekbe.ebeln, ekbe.ebelp, bseg.hkont
FROM ekbe
LEFT JOIN bkpf ON bkpf.mandt = ekbe.mandt AND left(bkpf.awkey,10) = ekbe.belnr AND right(left(bkpf.awkey,14),4) = ekbe.gjahr AND bkpf.awtyp = 'RMRP'
LEFT JOIN bseg ON bseg.mandt = bkpf.mandt AND bseg.bukrs = bkpf.bukrs AND bseg.gjahr = bkpf.gjahr AND bseg.belnr = bkpf.belnr
Note that field AWTYP should also be specified in JOIN, because any accounting doc can have many materials of different types in the year (AWKEY = <object number> + <year>).
Also, I do not appreciate the order you join the tables in your original SELECT. Usually source data table (EKPO in our case as we are searching account for each purchase order) is putted first and all others are joined to her.
But it is a matter of taste and also a matter of Redshift syntax which you knows better.
Okay, so I found an answer after a couple of days looking through forums and SAP tables column by column... since I am mainly interested in connecting order positions to G/L accounts, I was able to find them in EKKN which is directly linkable to EKPO. For some ebelp there are multiple sakto which is why we need "vproz" to be able to divide the EKPO-NETWR into the different sakto.
Going through all of it also made me shift my question from linking EKPO and BSEG to linking EKPO-EBELP and the G/L accounts. The BSEG-HKONT (with filter to BSEG-KOART = 'S') are also in EKKN-SAKTO.
SELECT ebeln, ebelp, netwr, sakto, vproz, vproz * netwr / 100 AS sakto_netwr
FROM ekpo
LEFT JOIN (
SELECT
mandt
,ebeln
,ebelp
,sakto
,SUM(vproz) as vproz
FROM ekkn
GROUP BY mandt, ebeln, ebelp, sakto
)
ekkn ON ekkn.mandt = ekpo.mandt AND ekkn.ebeln = ekpo.ebeln AND ekkn.ebelp = ekpo.ebelp
I am working in Oracle E-Business Suite.
Considering this field "CUSTOMER_SHIP_TO_NUMBER"
Oracle EBS Screenshot
I need to know the column and the table in the back-end database, from which the values of this field is getting populated.
I tried examining the Record History, and the data is being fetched from a View, namely the OE_Order_Lines_V. I tried searching through that view but couldn't figure it out. I need to know the actual location, namely the Table, where this data (CUSTOMER_SHIP_TO_NUMBER) is being stored.
You can use the below query to find the customer details.
SELECT hp.party_name "CUSTOMER_NAME",
hca.account_number "CUSTOMER_NUMBER",
csu.location "SHIP_TO_ORG_ID",hca.cust_account_id "CUSTOMER_ID"
FROM hz_parties hp, hz_cust_accounts hca,
hz_cust_acct_sites_all cas, hz_cust_site_uses_all csu
WHERE hp.party_id = hca.party_id
AND hca.party_site_id = cas.party_site_id
AND cas.cust_acct_site_id = csu.cust_acct_site_id
AND cas.address_type = 'SHIP_TO'
AND csu.location = <ship_to_org_id>;
The Data comes from the Table ONT.OE_ORDER_LINES_ALL, under the column of END_CUSTOMER_ID.
This should be joined with AR.RA_CUSTOMERS using the column CUSTOMER_ID to get the Customer Name and Number:
SELECT racust.customer_id
, racust.customer_name
, racust.customer_number -- this is the SHIP_TO_CUSTOMER_NUMBER
FROM AR.RA_CUSTOMERS racust
, ONT.OE_ORDER_headers_all oola
where oola.END_CUSTOMER_ID = racust.CUSTOMER_ID;
Read More Here: Oracle Order Management Technical Reference Manual
I'm trying to get data from a table CustomerCase of database TD_EDD; into a table CustomerCase of database DsVelocity. The problem is whenever I try to get the data, error message is generated because in CustomerCase table of TD_EDD database, there are 3 columns: LOB, ReferralSource and CaseType of type varchar; while in CustomerCase table of DsVelocity database, the 3 matching columns are LOBID, ReferralSourceID and CaseTypeID and are of type int.
I've simply tried to execute this query:
INSERT INTO [DsVelocity].[dbo].[CustomerCase]
([CustomerID]
,[Tier]
,[EscalationDate]
,[ReferralSourceID]
,[ICMSID]
,[LOBID]
,[TriggerRC]
,[TriggerAccount]
,[Project]
,[CaseTypeID]
,[DateDue]
,[SARFiledYes]
,[SARFiledNo]
,[TeamLead]
,[SARAmount]
,[InitialNotes]
,[WorkFlowStatus]
,[CaseDecision]
,[AccountsReviewed]
,[ActionDate]
,[SecondLvlReview]
,[CompanyType]
,[IfOther]
,[ClientType]
,[MergeFlag]
,[MergeCaseID]
,[AMLREP]
,[HighRiskYes]
,[HighRiskNo]
,[AutoCreated]
,[FileName]
,[SourceRefDate]
,[SourceRefID]
,[ETMAdd]
,[ETMRemove]
,[ETMDate]
,[Investigator]
,[InUseBy])
SELECT [CustomerID]
,[Tier]
,[EscalationDate]
,[ReferralSource]
,[ICMSID]
,[LOB]
,[TriggerRC#]
,[TriggerAccount]
,[Project]
,[CaseType]
,[DateDue]
,[SARFiledYes]
,[SARFiledNo]
,[TeamLead]
,[SARAmount]
,[InitialNotes]
,[WorkFlowStatus]
,[CaseDecision]
,[AccountsReviewed]
,[ActionDate]
,[2ndLvlReview]
,[CompanyType]
,[IfOther]
,[ClientType]
,[MergeFlag]
,[MergeCaseID]
,[AMLREP]
,[HighRiskYes]
,[HighRiskNo]
,[AutoCreated]
,[FileName]
,[SourceRefDate]
,[SourceRefID]
,[ETMAdd]
,[ETMRemove]
,[ETMDate]
,[Investigator]
,[InUseBy]
FROM [TD_EDD].[dbo].[CustomerCase]
and then ran into the following error:
Msg 245, Level 16, State 1, Line 1
Conversion failed when converting the varchar value 'CRR' to data type int.
CRR is a data in the column ReferralSource.
Similar messages may appear in case of LOB and CaseType columns
The database server I'm using is MSSQL Server 2008 R2.
What is the solution to this problem???
EDIT-1: Tried using Inner Join with LOB, CaseType and ReferralSource tables. Now the error has disappeared, query ran ok, but I get data from only 2 rows. I can't understand why?????? I had more than 40 data in the [TD_EDD].[dbo].[CustomerCase] table, so all these data were supposed to be passed to the [DsVelocity].[dbo].[CustomerCase] table. What's wrong?
EDIT-2: Got it. CaseType column in [TD_EDD].[dbo].[CustomerCase] had mostly NULL values, only 2 rows had valid data. Hence, only 2 rows were sent to [DsVelocity].[dbo].[CustomerCase] becasue no corresponding ID match can be made for null values. I guess I figured it out myself. Thanks everyone.
You could try casting as already suggested or probably you're referring the wrong field name, like (I shall focus only on the one that has an error):
SELECT
,[ReferralSourceID]
,[LOBID]
,[CaseTypeID]
FROM [TD_EDD].[dbo].[CustomerCase]
Instead of ReferralSource use ReferralSourceID, instead of LOB use LOBID and instead of CaseType use CaseTypeID.
Or probably you need to reference the Reference Table on those fields like:
SELECT
,[ReferralSourceID]
,[LOBID]
,[CaseTypeID]
FROM [TD_EDD].[dbo].[CustomerCase] CC
INNER JOIN Referral R
ON CC.ReferralSource = R.ReferralSource
INNER JOIN LobTbl L
ON CC.LOB = L.LOB
INNER JOIN CaseTypeTbl C
ON CC.CaseType = C.CaseType
Try casting your varchar columns to int (assuming the data in your source columns is valid for int columns in target)
SELECT CAST(ReferralSource AS int),
CAST(LOB AS int),
CAST(CaseType AS int)
--etc