mm important tables in purchasing

Purchasing Documents

Important Tables/Fields Purchasing Documents

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)


Purchasing DocumentsP = Purchase Order C = Contract (agreement)+ = obligatory

R = Request for quotation D = Delivery plan (scheduling agreement ). = allowed ! = special case

- = not allowed

Table EKKO EKPO EKET EKKN NAST KONV

Description Header Item Schedule line Account assignment Output message Document conditions

P +

R +

C + + - X2)

D + + ! X3) . . .

general 1) 2) 3) 4) 5) 6)

+ X1) + + . . . +

- X4) . . . . -



Table (some) EKPA (some) EIKP EIPO RESB

Description Time dependent Conditions Partners Service data Import data header Import data item Subcontracting components

P . . . . .

R . . . -

C . . . -

D . . . . .

general 7) 8) 9) 10) 10) 11)



Table (some) (some) EKPV VETVG EKUB

Description Texts (header/item) changedocuments Delivery data Shipping index STO index

P . . . . .

R . . -

C . . -

D . . . . .

general 12) 13) 14) 14) 15)



Table EKBE EKBZ EKES EKAB

Description Po history Po history (delivery costs) Confirmations/ Shipping notification Contract history

P . . . -

R -

C .

D . . . -

general 16) 17) 18) 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 weve ordered for each delivery date; for each item we can maintain between 1 and 9999 schedule lines;


Purchasing Documents4) 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 youve more than one account assignment the goods receipt cant 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);youll find entries in table EKKN every time when EKPO-KNTTP ne space and EKPO-KZVBR ne U;


Purchasing Documents5) 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 dont need information flow (e.g. stock transport order); 6)7) Regullarly the goods we order are not free and weve 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 ids 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 weve 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 customers 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 cant 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 dont 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 cant be changed anymore


EKKO (1)

Status data

-

BSTYP-

document typeRequest For Quotation Purchase Order Contract Delivery Plan

A F K L

-

BSAKZ-

document categorySTO stock transport order

T

-

LOEKZ-

deletion indicatordocument is archived (but the archive data are not deleted from DB)

X


EKKO (2)

Status data

STATU-

status RFQ with maintained quotation for 1 item at minimum 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)

A Rest

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 X

has to be released Document is blocked through release strategy, no follow-on functions possible (e.g. goods receipt, invoice receipt)

MEMORY X

uncomplete (since 4.6) po is not complete, maybe contains some errors, possible only in the new enjoy transaction for pos


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 pos, 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 statistic group number of import data number of adress data

is the link (key) to the document conditions, cant be seen on screen

STAFO-

Rules whether the document writes data into LIS (logisitics information system)

EXNUM-

is the link (key) to the import data, cant be ssen on screen

ADRNR-

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 fr alle),


EKPO (0)

Key data

-

MANDT-

client

see EKKO

-

EBELN-

document number

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 cant 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!!)Request For Quotation Purchase Order Contract Delivery Plan

A F K L

-

LOEKZ-

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

L S

-


EKPO (2)

-

STATU-

statusRFQ item with maintained quotation item originated from a production order, netplan or wbs element (PP) item originated from a sales order (SD)

A F V

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

X

-

EREKZ-

final invoicing indicatorno 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);

X

-

EGLKZ-

final shipping indicator (stock transport order)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);

X


EKPO (4)

-

XOBLR-

item is relevant for FI/COat 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; cant be set manually; cant be seen on screens;

X


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

-

Weve 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. sparkplug 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 dont order a material with material master youve 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 dont enter an inforecord or something else as reference youve to maintain more data manually;

-

TXZ01-

short text

If you dont order a material with material master youve 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 cant 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 youve 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 dont 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 0 1 2 3 5 7 9 normal blanket item Consignment Subcontracting third-party stock transport service

external (on the screen, language dependent)

B K L S U 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 youve 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 youve to enter a cost center, for P youve to enter a WBS element (project)); Very often some of the accounting data are derived automatically by the system so that the user dont 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)item with goods receipt

X

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 receiptgoods receipt will happen without financial document

X

If weve 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)item with invoice receipt

X

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

WEBREX

indicator for GR-related invoice verificationitem with GR-related invoice verification

If this indicator is set to X then youve 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) youve 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 youre 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

-

EBELN-

document number

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 indicatorcreated manually (Realtime) created via MRP (Batch)

R B


EKET (2)

Commercial data

-

MENGE/(MEINS)-

quantity in order unit

for each delivery date youve 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 youve 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

purchasing data

sapnetmmint thomas klemm

documents thomas klemm

purchasing documents

purchasing documents4

po item

x4 sap ag

import data screens