MM Important Tables in Purchasing

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

Thomas Klemm

Important Tables/FieldsPurchasing Documents

Purchasing Documents


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 conditions

. . - . 6)




(some) Time dependent

Conditions

- . . . 7)

EKPA Partners . . . . 8)

(some) Service data . . . - 9)

EIKP Import data header . - - . 10)

EIPO Import data item . - - . 10)

RESB Subcontracting components

. - - . 11)




(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

(delivery costs)

. - - . 17)

EKES Confirmations/

Shipping notification

. - - . 18)

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);

- WEUNBindicator 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

Documents

Transcript of MM Important Tables in Purchasing