COVP Sample Data PO Invoices & Other FI docs

BELNR	BUZEI	PERIO	WTGBTR	GJAHR	KSTAR	VRGNG	MEINB	EBELN	EBELP
200487643	001	04	48.00	1997	420226	COIN	YD	4500002310	00010
203719164	003	04	120.37	1999	420262	COIN	SET	0000768499	00030
204389827	015	09	15.93	1999	420160	COIN	PAA	4500139910	00150
202391881	002	06	2,002.08	1998	420262	COIN	LT	4500069365	00020
201569014	001	12	227.64	1997	420386	COIN	H	4500057944	00010
202190084	005	05	41.93	1998	420232	COIN	FT	0000734653	00050
203463724	018	02	36.32	1999	420160	COIN	EA	0000764010	00180
200270896	001	02	630.00	1997	420070	COIN			00000
200270894	001	02	996.87	1997	420050	COIN			00000

A fast SE16 select for this information is (This is wicked fast if done just against COEP!)

View field	Key sample values	Table	Field name	Type	Length
LEDNR	00	COEP	LEDNR	CHAR	2
OBJNR	PR00008065-PR00008067 (project 7824300)	COEP	OBJNR	CHAR	22
WRTTP	31,03-12	COEP	WRTTP	CHAR	2
VERSN	000	COEP	VERSN	CHAR	3
KSTAR	400000-499999 (expenses)	COEP	KSTAR	CHAR	10
VRGNG	COIN	COEP	VRGNG	CHAR	4

But when I used PR00009444 & PR00009468 -PR00009469 it became very slow on COEP (and I assume on COVP). In fact it turned into a sequential read!!!! This is caused by the "3rd column blues", a known bug in Oracle. Index COEP______1 is the index that this query was designed to use. OBJNR is the third column in the index counting MANDT. Therefore, the bug is encountered and a dbscan happens! Try this search but including a specific GJAHR. Allan thinks this will get around the bug.

I discovered that MARM is the underlying table that holds the unit of measurement values for each material group.

Last Updated on 4/12/1999
By Carolyn Fuller
Email: fuller@mit.edu