MM Important Tables in Purchasing

Purchasing Documents
Important Tables/Fields
Thomas Klemm
 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 1

Overview
 Purchasing documents
 Purchase Order (PO)
 Request For Quotation (RFQ)
 Contract (Agreement)
 Delivery plan (Scheduling agreement)

P = Purchase Order R = Request for quotation
C = Contract (agreement) D = Delivery plan (scheduling agreement )
+ = obligatory - = not allowed . = allowed ! = special case
Table Description P R C D general

EKKO Header + + + + 1)
EKPO Item + X1) + + + 2)
EKET Schedule line + + - X2) ! X3) 3)
EKKN Account assignment . - X4) . . 4)
NAST Output message . . . . 5)
KONV Document . . - . 6)
conditions


(some) Time dependent - . . . 7)
Conditions
EKPA Partners . . . . 8)
(some) Service data . . . - 9)
EIKP Import data header . - - . 10)
EIPO Import data item . - - . 10)
RESB Subcontracting . - - . 11)

components


(some) Texts (header/item) . . . . 12)
(some) changedocuments . . . . 13)
EKPV Delivery data . - - . 14)
VETVG Shipping index . - - . 14)
EKUB STO index . - - . 15)


EKBE Po history . - - . 16)
EKBZ Po history . - - . 17)

(delivery costs)
EKES Confirmations/ . - - . 18)
Shipping notification
EKAB Contract history - - . - 19)

1) EKKO contains information about the type of the document, the vendor/
supplying plant and other informations valid for all items of the document;
2) EKPO contains information about what is ordered to which price; you can
order material (with or without material number!) or services; a document
contains between 1 and 99999 items;
3) In EKET we find the desired delivery date and the quantity we‘ve ordered
for each delivery date; for each item we can maintain between 1 and 9999
schedule lines;

4) In EKKN account assignment datas are stored (G/L account, cost center,
order,...); we need account assignment data every time, the material will not
be posted to stock; then the data are directly used at time of goods receipt
and invoice receipt to generate the financial document; it is possible to
enter between 1 and 99 account assignments for one item; if you‘ve more
than one account assignment the goods receipt can‘t be posted valuated,
means that then no financial document can be created;
sap customers are able to add own account assignment fields to EKKN
and other structures via customizing (IMG);
you‘ll find entries in table EKKN every time when EKPO-KNTTP ne space and
EKPO-KZVBR ne U;

5) Normally every document needs an output message record to send the information
to the vendor; the determination of output message records is customizable; there
are processes where you don‘t need information flow (e.g. stock transport order);
6)7) Regullarly the goods we order are not free and we‘ve to pay for them. In these
cases the item contains conditions; we can identify such items by the following fields:
- EKPO-REPOS ne space or EKPO-XCONDITIONS ne space (4.6C)
The following items can contain conditions (e.g. delivery costs):
- EKPO-REPOS eq space and EKPO-PSTYP eq 7 (stock transport order)
For the difference between document and time dependent conditions please
have a look at paper ‚CONDITIONS and PRICING‘; if possible to switch, this is
ruled by EKKO-STAKO which is filled from T161-STAKO (document type); the
document conditions are linked to the purchasing document through EKKO-KNUMV,
time dependent conditions through various Axxx condition table entries

8) Partners are used to store information about sender of the invoice, supplier of the
goods or another address where the po should be sent to; the determination of partners
and the options for maintaining them in the doucment is ruled by a partner scheme
stored in T161 (document type); for more information please read the paper ‚partners
in purchasing‘
9) Whether an item contains service data or not is ruled by the item category
(EKPO-PSTYP); service data and limits are necessary when EKPO-PSTYP = 1
(blanket po) or EKPO-PSTYP = 9 (service); the service data are linked to the po item
through EKPO-PACKNO, this is the key for the service database tables; for more
information please have a look at paper ‚services‘

10) Import data are necessary if the vendor belongs to another country than the
receiving plant; depending to the company code you can decide whether the
import data screens should be processed never, ever, for every import or only
if it is an import inside the EU (T001-IMPDA); the import data are linked to the
purchasing data through field EKKO-EXNUM which is the key of tables EIKP and
EIPO
11) Subcontracting components are necessary when item is of category ‚subcontracting‘
(EKPO-PSTYP = 3); there are different components stored for each schedule line;
RESB linked with EKET through field EKET-RSNUM; relinked via RESB-EBELN,
RESB-EBELP, RESB-ETENR;

12) Texts are possible on header and item level; texts are stored in database tables
STXH and STXL; header texts with TDOBJECT = EKKO, item texts with
TDOBJECT = EKPO; the possible text id‘s are customized (see various transactions
in menue OLME);

13) Changedocuments are written if you create or change a document; there are different
types of changedocuments:
 Insert or delete a record (e.g. item, schedule line, account assignment data)
 Change a record  for each field of the record which is changed and the appropriate flag
in the data element of the field is switched on in DDIC one changedocument item is written
containing the old and the new value of the field
Note: not for all database tables in purchasing we do have changedocuments (KONV,
RESB,...)
Changedocuments are stored in tables CDHDR and CDPOS;
You will find all changedocuments for one document searching with
OBJECTCLAS = EINKBELEG and OBJECTID = EKKO-EBELN;

14) EKPV and VETVG are written for all items which need a delivery through LES
application; this is the case in stock transport orders (EKKO-RESWK ne space) and
return items (EKPO-RETPO ne space and EKPO-LFRET ne space); LES shipping is
only possible if the item has an material master;
most of the data of EKPV are derived via function module
SD_TRANSFERDATA_DETERMINE; EKPV-LEDAT is filled with the lowest shipping
date of all open schedule lines; a schedule line is open in that mind when
EKET-MENGE GT EKET-GLMNG; shipping date is determined through function
module ME_CALCULATE_LEDAT (beginning with 4.5);
VETVG is used from LES to create the deliveries; VETVG-LEDAT is calculated
as the minimum of EKPV-LEDAT of all items of the document; if VETVG-LEDAT
is 0 the record will be deleted;

15) EKUB is stored for stock transport orders (EKKO-RESWK ne space); the index is
used in MRP to display and calculate the requirements in the delivering plant
(EKKO-RESWK); if an item is no more open EKUB will be deleted (regullarly) to save
performance in ATP checks;

16) One EKBE record is written for every goods receipt (GR), invoice receipt (IR), delivery,
goods issue, service entry or down payment posted against a po or delivery plan item;
EKBE is used every time we need information about how many we‘ve received until
now, how many is invoiced, what is the open quantity of the item;
17) One EKBZ record is written for every delivery cost condition at time of goods and
invoice receipt; for delivery costs you have to maintain an additional invoice item;
To save performance there is the option to comprimize EKBE and EKBZ and to store
The original data in other data base tables EKBEH and EKBZH. This is used often for
Delivery plans because customer‘s are working with the same delivery plan over some
Years.

18) In EKES we store the information about confirmations and shipping notifications;
both are documents from the vendor to confirm that or at which time he can deliver the
ordered material and in what quantity; main purpose of EKES is that ATP/MRP can
calculate using the most actual knowledge about material flow; EKES is more actual
than EKET is;
19) One EKAB record is written every time you create an po or delivery plan item against
a contract item; EKAB is used every time you need information about the open quantity
of a contract item;

X1) In ME21N it is possible to park a po without any items

X2) There is a solution implemented for IS-Retail to allow schedule lines in contracts
ruled by T161-KOETT (which is NOT maintainable in IMG)
X3) Schedule lines are the main part of a delivery plan; nevertheless you can‘t
maintain schedule lines when you create/change a delivery plan; you can
maintain schedule lines in a separate transaction (ME38) afterwards;
to save performance there is the option to comprimize EKET records and save the
original ones in another database table EKETH; this option is necessary only for
delivery plans;
X4) We don‘t store account assignment information in the rfq, even though the
rfq is created with reference to a requisition with account assignment information;
the account assignment data are copied lateron from requisition to po when the rfq
is converted into a po

EKKO (0)
Key data
- MANDT client
- key field in all application data base tables, see ‚client concept‘
- EBELN document number

- normally determined from the system via number range of the document type, external number
possible, when the document is saved the number can‘t be changed anymore

EKKO (1)
Status data
- BSTYP document type

- A Request For Quotation
- F Purchase Order
- K Contract
- L Delivery Plan
- BSAKZ document category

- T STO stock transport order
- LOEKZ deletion indicator

- X document is archived (but the archive data are not deleted from DB)

EKKO (2)
Status data
STATU status
- A RFQ with maintained quotation for 1 item at minimum
- Rest creation indicator gives information about
- Which application has created the document (e.g.: 1 -> APO, K -> BBP, F -> KANBAN)
- In which transaction the document was created (e.g.: B -> ME59, 9 -> ME21N)
AEDAT creation date (description in DDIC is wrong)

- Date of creation (you can find the time of creation in a change document written at time
of creation, this record can only be displayed on database using SE16/SE17, it is not
displayed in the reports of purchasing)
ERNAM name of creator

- Name of the createrof the document

EKKO (3)
Status data
BEDAT order date

Document date, written on the po, used for pricing (often) and other things
FRGRL has to be released

X Document is blocked through release strategy, no follow-on functions possible
(e.g. goods receipt, invoice receipt)
MEMORY uncomplete (since 4.6)

X po is not complete, maybe contains some errors, possible only in the new
enjoy transaction for po‘s

EKKO (4)
Organizational data
- EKORG purchasing organization

- Purchasing organization which is responsible for this document
- Negotiates conditions with the vendor
- BUKRS company code

- Company which is responsible for this document
- Has a local currency -> many currency conversions from document to local currency
- Company code exists as well on item level
- EKGRP purchasing group

- Purchasing group (buyer) which is responsible for this document
- Used to select and control documents (my documents), determines the printer,

EKKO (5)
Commercial data
- LIFNR vendor
- Supplier (vendor) of the goods or services
- Is filled in normal po‘s, can be filled as well in stock transport orders (especially cross company)
- RESWK supplying plant

- Internal plant which delivers the goods (stock transport orders)
In each purchasing document you enter the supplier or the supplying plant!
BSART document type

determines category of document (-> EKKO-BSAKZ), fieldselection list, possible
item categories, LIS update, number range, partner scheme,

EKKO (6)
- WAERS currency
- Each document has a document currency, default comes from vendor master, normally
the invoice will be send in this currency
SPRAS language
- Each document has a document language, default comes from vendor master, the
document is printed in this language, texts are determined in this language,
ZTERM, ZBD1T, ZBD1P, ZBD2T, ZBD2P, ZBD3T payment terms
- Are used during invoice verification and to calculate the effective price of an item
- INCO1, INCO2 incoterms

- Are ruling who (vendor or customer) has to pay cost, insurance and freight
- Available on item level as well

EKKO (7)
Reference data
- KALSM pricing scheme

- determines which condition types can be used in a document
- Depends on vendor and purchasing organization
- Can be changed in customizing, standard RM0000
- KNUMV number of the conditions
- is the link (key) to the document conditions, can‘t be seen on screen
- STAFO statistic group
- Rules whether the document writes data into LIS (logisitics information system)
- EXNUM number of import data
- is the link (key) to the import data, can‘t be ssen on screen
- ADRNR number of adress data
- is the link (key) to vendor adress data, are stored every time you change the vendor adress data
which are defaulted from vendor master, mandatory if vendor is cpd vendor
(conto pro diverse, einer für alle),

EKPO (0)
Key data
- MANDT client
- see EKKO

- see EKKO
- EBELP item number

- can be set manually by user, normally set automatically from system using the item interval
EKKO-PINCR which is derived from document type T161-PINCR; once the item number is set it
can‘t be changed afterwards; there is no renumbering available for document items;
- if the item is a subitem (EKPO-UPTYP ne space) another interval EKKO-UPINC is used (defaulted
from document type T161-UPINC);

EKPO (1)
Status data
- BSTYP document type (the same as in EKKO!!)

- A Request For Quotation
- F Purchase Order
- K Contract
- L Delivery Plan
- LOEKZ deletion indicator

- L logical deleted -> item is fulfilled or cancelled, can be set by archiving program
RM06EW30
- S blocked -> item is interrupted, no followon functions allowed until the item is
unblocked

EKPO (2)
- STATU status
- A RFQ item with maintained quotation
- F item originated from a production order, netplan or wbs element (PP)
- V item originated from a sales order (SD)
EKPO-STATU F and V are only possible if you create the po with reference to a requisition because
Both (PP and SD) are generating only requisitions and only when such a requisition is transfered
Into a po EKPO-STATU is set to F or V;
- AEDAT date of last change

- the last change can happen via change transaction or archiving program RM06EW30; the field is
not updated when a goods receipt or another document is posted against the po item;

EKPO (3)
- ELIKZ final delivery indicator

- X no further goods receipt awaited ; item is completed for MRP/ATP; nevertheless it is
possible to post additional goods receipts! Can be set manually in change transaction or
at time of goods receipt (semi-automatic, depending on customizing and delivery
tolerances (EKPO-UEBTO, EKPO-UNTTO, EKPO-UEBTK));
- EREKZ final invoicing indicator

- X no further invoice awaited; item is completed for FI/CO; nevertheless it is possible to post
additional invoices! Can be set manually in change transaction or at time of invoice
receipt (only manually);
- EGLKZ final shipping indicator (stock transport order)

- X no further delivery awaited; item is completed for MRP/ATP in the delivering plant;
it is possible to encrease existing deliveries! Can be set manually in change transaction
or at time of delivery creation (only automatically, depending on EKPO-KZTLF);

EKPO (4)
- XOBLR item is relevant for FI/CO

- X at least one financial application is interested in this item (e.g. to write commitments);
regullarly set in all items with account assignment, but also possible in items going to
stock; can‘t be set manually; can‘t be seen on screens;

EKPO (5)
Organizational data
- WERKS plant
- receiving plant; the goods are delivered to this plant; default delivery adress comes from the
plant; many material data are different from plant to plant (delivery time); plants can have
different calendars, conditions and prices;
- BUKRS company code

- Company to which the plant belongs; normally all items belong to the same company; since 4.6C
it is possible to maintain items with different company codes in one po (restriction: all
companies must have the same local currency)
- LGORT storage location

- place where the goods are stored; each plant is divided into several storage locations; not that
important in purchasing, but can be used to determine the delivery adress; important at time of
goods receipt;

EKPO (6)
Commercial data
- MATNR/EMATN material number

- Material master provides a lot of descriptive (short text, long text, weights, units of
measurement) and ruling (responsible purchasing group, planned delivery time, type of
procurement -> internal/external) data; some of the data are stored in document item because
they are needed in followon functions (base unit of measurement, conversion factors, weights);
- We‘ve 2 fields for the material number; normally both are filled with the same value; in MPN
(manufacturer part number) case they are filled differently; MATNR is the stock keeping material
(e.g. spark-plug), EMATN is the more specific material from a specific manufacturar (e.g. spark-
plug from BOSCH); on the item overview screen you enter the EMATN;
there is an important data base index on EKPO-MATNR (no one on EKPO-EMATN); this index
is used in MRP as well as in reports to list all purchasing document for one material;

EKPO (7)
- MATKL material group

- If you don‘t order a material with material master you‘ve to enter a material group (otherwise
it is derived from material master); there are not that much master data available for a material
group as it is for a material; so if you don‘t enter an inforecord or something else as reference
you‘ve to maintain more data manually;
- TXZ01 short text

- If you don‘t order a material with material master you‘ve to enter a short text (otherwise
it is derived from material master);

EKPO (8)
- MENGE/MEINS quantity in order unit

- EKPO-MENGE is the sum of all EKET-MENGE; if the item contains only one schedule line they
are identical; the quantity can be rounded by the system (rounding profile EKPO-RDPRF);
- EKPO-MEINS is defaulted from inforecord or material master; in case of contract reference the
order unit can‘t be different from order unit of contract; otherwise the order unit can be chosen
when it is allowed for the material or inforecord; in the old transactions you‘ve to chose the order
unit when entering the item; the order unit is only changeable afterwards in the new enjoy
transaction; in stock transport orders the order unit is defaulted with the issue unit of material
master segment of the delivering plant;
- NETPR/WAERS/PEINH/BPRME price per unit 10 USD / 1000 PC

- regullarly the price is determined from the system during pricing mechanism ruled by the pricing
scheme (EKKO-KALSM); the price can be entered as well manually;
- we don‘t allow different currencies in the items; but it is possible to enter different currencies in
each condition; on the item overview screen the net price is presented in document currency;

EKPO (9)
- PSTYP item category

- The item category rules how the material/service is procured; some attributes are derived
from the item category (T163) (e.g. WEPOS, REPOS, whether account assignment category is
forbidden, allowed or obligatory, see following slides);
Internal external (on the screen, language dependent)
0 normal
1 blanket item B
2 Consignment K
3 Subcontracting L
5 third-party S
7 stock transport U
9 service D
categories 4 and 8 are only used in contracts; category 6 text is not that important;

EKPO (10)
- KNTTP account assignment category

- Controls whether the material is posted to stock at time of goods receipt or not;
- Item with EKPO-KNTTP blank is only allowed if you order material with material number, for the
material valuated stock has to be enabled;
- If EKPO-KNTTP is not space then you‘ve to maintain the accounting data which are transfered to
FI/CO at time of goods or invoice receipt;
- The different account assignment categories allows the user to enter different fields (e.g. for K
you‘ve to enter a cost center, for P you‘ve to enter a WBS element (project));
- Very often some of the accounting data are derived automatically by the system so that the user
don‘t have to enter many data manually (they are FI data -> critical);
- In customizing T163A it is clearly decided which account assignment categories are allowed for
which item category;

EKPO (11)
- WEPOS inidicator for goods receipt (GR)

- X item with goods receipt
- For some item categories GR is mandatory (consignment, stock transport),
for others it is optional (third-party), for some it depends on the account assignment indicator
(normal with account assignment indicator blank -> mandatory,
normal with account assignment indicator filled -> optional);
- WEUNB indicator for unvaluated goods receipt

- X goods receipt will happen without financial document
If we‘ve more than one account assignment for one item then you can choose between:
- no goods receipt
- Unvaluated goods receipt

EKPO (12)
- REPOS indicator for invoice receipt (IR)

- X item with invoice receipt
- For some item categories no invoice receipt is allowed (consignment, stock transport), for
others it is optional;
if EKPO-REPOS is set to blank, then all conditions are deleted (exception stock transport
because of delivery costs);
WEBRE indicator for GR-related invoice verification

X item with GR-related invoice verification
If this indicator is set to X then you‘ve to maintain for each GR a seperate invoice item; to
Link GR and IR the fields LFBNR, LFPOS, LFGJA in table EKBE is used;

EKPO (13)
Reference data
- KONNR/KTPNR contract number/item

- contract reference if the item was created with reference to a contract
- rules that an EKAB record is written for the contract item
- ANFNR/ANFPS rfq number/item

- rfq reference if the item was created with reference to a rfq
- BANFN/BNFPO requisition number/item

- requisition reference in contract and delivery plan; also filled in the new enjoy po (nevertheless
is the reference stored in the schedule line the real and important one);

EKPO (14)
Reference data
- ADRNR/ADRN2 numbers of delivery adress

- delivery adress data are stored in po item if you change the default data or if you enter
anexisting adress number
- PACKNO number of service package

- in service items (EKPO-PSTYP = 9) and blanket items (EKPO-PSTYP = 1) you‘ve to enter service
or limit data; both are linked with the item during EKPO-PACKNO;
- FPLNR number of invoicing plan

- if an invoicing plan is entered for an item these data are linked to the po item with EKPO-FPLNR;

EKPO (15)
Reference data
- CUOBJ number of configuration

- if you order a configurable product you can display the characteristics and their valuations in the
purchasing document; these data can be find with EKPO-CUOBJ;
- in release 4.6C it is possible to change the valuation of the characteristics in the po; then a new
CUOBJ is generated;
- STAFO statistic group

- rules whether the item writes some data in LIS (logistics information system)
- INFNR number of the inforecord

- inforecord can be found by the system when you‘re ordering a material with material number; the
number has to be entered manually otherwise when you want to reference it;

EKET (0)
Key data
- MANDT client
- see EKKO

- see EKKO
- EBELP item number

- see EKPO
- ETENR schedule number

- set from the system;for delivery plans a program exists which can renumber the schedule lines
to avoid gaps between the forgiven numbers;

EKET (1)
Status data
- ESTKZ creation indicator

- R created manually (Realtime)
- B created via MRP (Batch)

EKET (2)
Commercial data
- MENGE/(MEINS) quantity in order unit

- for each delivery date you‘ve to enter a quantity (in EKPO-MEINS);
- EKPO-MENGE = SUM(EKET-MENGE)
- EINDT/LPEIN/UZEIT delivery date and time

- for each delivery date you can decide in which format (EKET-LPEIN Day/Week/Month) you want
to enter it; in data base table every time the day (not week or month) is stored; in addition to the
day you‘ve the option to enter a delivery time; this is not that much needed, but is getting more
attracted using SAP-APO;

EKET (3)
Status data
- WEMNG goods receipt quantity

- when a goods receipt is posted against an item the goods receipt quantity is distributed to the
schedule lines; in case of overdeliveries EKET-WEMNG can be greater than EKET-MENGE;
- WAMNG goods issue quantity

- when a goods issue is posted against an item (STO) the goods issue quantity is distributed to
the schedule lines; in case of overdeliveries EKET-WAMNG can be greater than EKET-MENGE;
- GLMNG delivered quantity

- when a delivery is created against an item (STO or returns) the delivered quantity is distributed
to the schedule lines; in case of overdeliveries EKET-GLMNGcan be greater than EKET-MENG

EKET (4)
Status data
WEMNG, WAMNG and GLMNG are calculated in program SAPLEINU. The EKBE record
is transfered to SAPLEINU and then the appropriate field is en- or decreased. For correction
purposes a correction report is available via oss note.
All three fields are not necessary for purchasing purposes, because this is handled by the
EKBE records (what quantity is open? ...). The fields are only needed for MRP/ATP purposes
because otherwise it would be to time consuming to determine the open quantity and to
distribute the EKBE quantities to the delivery dates which is necessary for MRP/ATP.

EKET (5)
Status data
- DABMG quantity not relevant for MRP

- when a mrp relevant confirmation or shipping notification is posted against an item the quantity
is distributed to the schedule lines;

EKET (6)
Reference data
- BANFN/BNFPO requisition number/item

- reference to the requisition if the schedule line was created with reference to a requisition;

MM Important Tables in Purchasing

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MM Important Tables in Purchasing

Uploaded by

Copyright:

Available Formats

Purchasing Documents

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 1

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 2

Table Description P R C D general

EKPO Item + X1) + + + 2)

EKET Schedule line + + - X2) ! X3) 3)

EKKN Account assignment . - X4) . . 4)

NAST Output message . . . . 5)

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 3

Table Description P R C D general

(some) Service data . . . - 9)

EIKP Import data header . - - . 10)

EIPO Import data item . - - . 10)

RESB Subcontracting . - - . 11)

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 4

Table Description P R C D general

(some) changedocuments . . . . 13)

EKPV Delivery data . - - . 14)

VETVG Shipping index . - - . 14)

EKUB STO index . - - . 15)

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 5

Table Description P R C D general

EKBZ Po history . - - . 17)

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 6

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 7

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 8

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 9

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 10

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 11

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 12

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 13

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 14

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 15

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 16

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 17

X1) In ME21N it is possible to park a po without any items

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 18

- EBELN document number

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 19

- BSTYP document type

- BSAKZ document category

- LOEKZ deletion indicator

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 20

AEDAT creation date (description in DDIC is wrong)

ERNAM name of creator

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 21

BEDAT order date

FRGRL has to be released

MEMORY uncomplete (since 4.6)

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 22

- EKORG purchasing organization

- BUKRS company code

- EKGRP purchasing group

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 23

- RESWK supplying plant

BSART document type

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 24

- INCO1, INCO2 incoterms

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 25

- KALSM pricing scheme

 SAP AG 2001 SAPNET/mmint (Thomas Klemm) / 26

- EBELN document number

- EBELP item number