Condition types are defined in general using the condition class and in detail using the condition category.

The calculation rule defines how the system calculates the condition value. A markup or markdown could be a percentage of the gross price, a fixed amount, or a quantity-dependent amount, for example. The plus/minus sign indicates whether the condition is treated as a positive or negative amount. Negative amounts are markdowns or discounts, positive amounts are markups or surcharges. Reference values for scales are also dependent on the condition type. Scales can relate to a quantity or a value, for example. An access sequence can be assigned to a condition type. The access sequence is a search strategy that defines the sequence in which the system searches through condition tables looking for relevant entries for a condition type. In the standard sequence, an access sequence is not assigned to the condition types for markups and markdowns (RA00, RA01 and so on), because they are maintained as additional conditions for the gross price (PB00). You can define your own condition types. Conditions in purchasing info records are always time-dependent. Conditions in purchase orders are not always time-dependent. Time-dependent conditions can apply to specific sites, or to all sites in a purchasing organization. In addition to time-dependent prices that are valid for specific purchasing data for the article (purchasing view in article maintenance), time-dependent conditions relating to more general price agreements can be defined (general conditions). Time-dependent conditions are limited to a particular validity period. No subtotals (net price, effective price) are formed for time-dependent conditions. Valid time-dependent conditions from purchasing info records are used as default values in purchase orders. Conditions are stored in the system as condition records. Condition tables refer to condition records. Condition tables enable you to vary the key of condition records. Condition tables with the following keys exist: Vendor, article, purchasing organization, info record category

Vendor, article, purchasing organization, site, info record category Vendor, article, purchasing organization, info record category, order unit Purchasing document, item, site Entries in condition tables consist of the key and the data. The data contains the number of the condition record. Condition records are stored in the following tables: KONP (time-dependent conditions) KONH (header information The calculation schema is used in price determination. It groups together all condition types that are involved in price determination. The calculation schema defines: which condition types are allowed for which condition types conditions can be automatically adopted ('Man.' indicator) which condition types are used to calculate net prices ('Stat' indicator) the sequence in which the condition types are used when calculating net and effective prices the condition types for which subtotals are calculated what requirements must be met to ensure a certain condition type is considered In addition, the reference level 'From' for percentage conditions is defined in the calculation schema. The reference level 'From' can be combined with a reference level 'To'. You can define the determination of calculation schemas for standard purchase orders, stock transport orders, market price determination in vendor evaluations, and service processing. You have the following options when assigning schemas for standard purchase orders: You can assign a calculation schema that is generally valid (such as RMISR0) You can make the assignment of a calculation schema dependent on a schema group for one or more purchasing organizations and/or a schema group for one or more vendors.

The schema group enables you to group together purchasing organizations or vendors that you want to assign the same calculation schema to. Schema groups are defined in Customizing. Purchasing organizations are also assigned to schema groups in Customizing, while vendors are assigned to a schema in the vendor master. For stock transport orders, the schema assignment is dependent on the purchasing organization, the document type, and/or the supplying plant. For market price determination in the vendor evaluation, schema determination is dependent on the purchasing organization. For service processing, the calculation schema is dependent on the document type. Here, for each document type, the same calculation must be used for the documents RFQ/inquiry (AN), purchase requisition (NB), and purchase order (NB). Markup calculations are one way of determining a suggested value for the sales price. Planned markups can be stored in the system for markup calculations. Planned markups are added to the (net/net) purchase price. They reflect both the profit that a company aims to make by selling certain articles and general cost components. Usually, you would define a planned percentage markup for a combination of sales organization, distribution channel and merchandise category. In wholesale, planned markups can also be defined for different price lists. As planned markups are condition types, you can also define them for other organizational levels, such as for individual articles. You can assign any number of product catalogs to a promotion. The term "product catalog" also refers to brochures and journals, amongst other things. Promotions can be broken down into one or more topics. Topics can be created using, for example, assortment structures or marketing strategies, for example, home care, photographic merchandise, modern living. By assigning promotional articles to topics, you can also group the articles within the promotion. Stores participating in the promotion are assigned to the promotion as groups. Different validity periods are defined for store groups. The promotion type specifies the technical requirements for particular promotions. The promotion type describes particular qualities for promotions and controls subsequent processing for the promotion by using default values and indicators. The default data for the promotion header is as follows:

Purchasing conditions leadtime for the start of promotion sales and end of promotion sales Promotion announcement lead time for the start of promotion sales Article listing leadtime for the start of promotion sales and end of promotion sales Leadtime for goods receipt at store before start of promotion sales Allocation table type for controlling defaulted data for the allocation table item category Application, schema and announcement category for controlling message determination Condition type group - Purchasing Condition type group Sales You use the promotion categories to classify promotions from a business point of view. The promotion category is an attribute of the promotion type. In the standard system, the promotion category is the same as the promotion type, and is a classification criterion in the information system. This means that promotions are indirectly classified by their promotion type in the RIS (Retail Information System). Therefore, promotion categories are maintained in such a way that they are identical to the promotion types. Consequently, it make sense to have identical descriptions for a promotion category and promotion type. The promotion category can be used by customers to create hierarchies and to group together promotion types according to their particular requirements. In this case, the same promotion category is stored for several promotion types and a separate info structure is defined for promotions with the promotion category and promotion type as a characteristic. The promotion type is used to provide a greater level of technical detail for promotions. It describes particular properties of the promotion and contains predefined settings and indicators to control subsequent processing. The following default data is maintained for the promotion header: Promotion category Condition type group for purchasing Condition type group for sales Lead time (in days) for purchase price conditions to the start of the promotional sales period and the end of the promotional sales period

Lead time (in days) for article listing to the start of the promotional sales period and the end of the promotional sales period Lead time (in days) for the promotion announcement to the start of the promotional sales period Lead time (in days) for goods receipt in the store before the start of the promotional sales period Allocation table type for controlling default data for the allocation table item category Announcement category for controlling message determination, application, and schema You can define different validity periods for different store groups that are participating in the promotion. A promotion for beachwear can, for example, begin earlier and last longer in warmer areas (for example, Miami) than in colder areas (for example, New York). If you define different periods of validity for different store groups, the entire promotion period is taken into consideration, meaning the earliest starting data to the latest finishing date for all the stores participating in the promotion. Fast entry: Entry of articles, planned sales quantity, promotion price Quantity planning: Detailed quantity planning for the promotion and procurement using the allocation table Price planning: VKP0 (standard sales price price) and VKA0 (promotion price) Logistics control: Check on listing rules; order/delivery date using the announcement Themes: Themes are used to divide a promotion up into smaller units Site groups: Different validity periods and other data can be maintained for each site group Product catalogs: Enables promotional merchandise to be included in product catalogs Modules: Promotion modules are created and assigned to the promotion site groups Purchase and sales price conditions: The promotion type is used to control whether conditions can be created Free goods: Are assigned to sales/purchase price conditions as inclusive/exclusive bonus quantities

Coupons: Allow the customer to take advantage of bonus buys Bonus buys: Special price conditions that apply if certain requirements are met Coupons are treated as articles in SAP Retail and therefore have their own article master record (article type COUP). The article type controls which views for the article are maintained. Coupons give customers a bonus when they buy certain articles. However, the bonus is only settled using a 'bonus buy', which the coupon must be assigned to. Coupon data is exported to the POS system at the same time as other promotion data. If the coupon is for a fixed reduction for a specific article (e.g. 50 cents off a certain brand of washing powder), this appears as a negative amount (-0.50) on the POS receipt when the coupon is scanned in at the POS. The amounts involved are posted to the vendor and/or store in line with the distribution ratio (shares for the cost object) in the coupon profile. The processing steps listing, supply source determination, allocation tables, additionals, price activation, and announcement can also be run in the background by triggering the appropriate reports. For more information about this, see the SAP Library SAP Retail Background Processing. Most in-store merchandise management systems can be linked to SAP Retail. Examples of systems include: A POS server with merchandise management functions. A store-based merchandise management system. In-store systems must be linked to SAP Retail in one of two ways. - via a certified converter/communication interface using the Retail POS Interface (SAP recommended Solution) - via your own converter/communication interface using EDI and SAP Intermediate Documents (IDocs). Some data can be downloaded to merchandise management systems directly using SAPs standard ALE technology. (Beyond the scope of this course.) SAP Retail applications are also EDI enabled for standard message transmission. (cf., course CA210 EDI Interface.) The central SAP Retail system also can be accessed remotely via an in-store terminal and via the internet using Retail Store. Types of business information that SAP Retail sends through the POS outbound interface to store systems. Article master data Article sales prices EAN/UPC assignments Customer data Exchange rates Products Set Assignments Taxes Merchandise Category Master Label data Physical Inventory

Assortment Lists

Promotions

Types of business information that SAP Retail can receive through the POS inbound interface from store systems. Sales Data (receipt-based and aggregated) Cashier data Payment types Financial Transactions External Messages Inventory (Store Orders, Goods movement and Physical count data) Article data changes Pricing conditions Customer data EAN/UPC assignments Specific master data must be available at the point of sale in a store for any transactions to take place at an electronic cash register. Point of sale systems have a variety of capabilities, many do not have large data bases to contain the same detailed master data that R/3 contains. Therefore, SAP Retail provides several message types to carry critical master data to the stores. The types of outbound master data that can be processed via SAP Retail POS Interface and the corresponding IDoc types and message types that may be used as a carrier for each of these data are shown. The Bonus buy message is only sent by direct request. The Assortment list data and message types are described separately as it is a special message type. The above list summarizes the types of inbound business data that can be processed by the SAP POS interface. In each case, also shown are the corresponding IDoc types and message types that may be used as a carrier for each of these business data. The last column indicates, whether or not the corresponding message can be generated and passed on to the inbound processing unit of the POS Interface, by the POS inbound simulation tool. In addition to the IDoc type/message type combinations shown in this list, the IDoc type WPUERR01 can go with message type WPUERR to send error messages from the converter to the SAP Retail system. These messages, however, are only displayed within the POS Interface Monitor and not passed for further processing by any other application within the SAP system.

Finally, IDoc type WP_PER01 and message type WP_PER can be used to communicate person data between store and SAP Retail system. After release 4.0, however, inbound processing of this message is not supported. Alternative Condition Analysis report, if used, should be run before executing the Change message report. The Initialization reports should be run prior to going live. Regardless of which type of article message you use to populate your POS systems, each store must be initialized before Change message outbound processing can be used. Change Message report for POS Outbound can be set to run nightly and the system checks for store open days. If, for example, some stores are open 7 days and others only 6, the report only prepares data for the stores that are open on the following day and not those that are closed. Direct request or manual reports are used for testing, replacing missing store data, or to change a particular price when you do not wish to run the entire change analysis. These reports can still be set to run in the background, saving system resources. Reorganization reports are described in the unit on performance issues. Subsequent Creation of trigger files is a report that is used infrequently to check if there is any prepared data for which a trigger file has not been created. A trigger file might have been not created because reorganization reports were not run and sufficient disk space was not available for the file. Bonus buy data can only be sent to the stores by a manual Outbound message. You select transfer Bonus buy data and identify the condition or conditions to transfer. SAP Retail provides two IDoc types, WPUUMS01 (message type WPUUMS) and WPUBON01 (message type WPUBON), for transmission of sales data at two levels of detail: Sales as per receipt The details of every sales transaction are transferred to SAP R/3 system. The store system itself may assign a unique receipt number to each sales transaction, which may be transmitted to the SAP Retail system (in field BONNUMMER in IDoc type WPUBON01). Via a user exit, the SAP Retail system can be set up to check validity of the receipt numbers received from the stores (no gaps, no duplicates, ...). This user exit may also be used to assign receipt numbers to sales transaction data received from a store if the store does not do so itself. The upload of sales data per receipt is recommended if all sales transactions are to be used for statistical analysis or auditing purposes.

Aggregated sales Sales data are aggregated over all sales transactions occurring at a particular store during a set period of time and then uploaded to the SAP Retail system. Details of individual sales transactions are lost. This option greatly reduces the amount of data to be transferred and is preferred if performance is a critical issue. The central document for sales to customers is the sales order. A sales order is assigned to one sales organization, one distribution channel and one division for organizational purposes, and to one order type (e.g. OR = standard order, AA = promotion order, BV = cash sale; see Customizing). A sales order consists of a header and one or more items that can be divided into a number of schedule lines if you want to send partial deliveries. Data that can be entered in the header of a sales order includes: Sales organization, distribution channel and division for the sales order The order type The number of the sales order The number of the sold-to party The required delivery date Data that can be entered in the item of a sales order includes: The item category The article number and short text The ordered quantity The supplying DC Billing data (incl. payer number and short text, Incoterms, payment terms, billing document indicator) Data that can be entered for each schedule line of an item includes: The schedule line item The delivery date for the schedule line Shipping data (incl. delivery and transportation planning date, shipping point, route, delivery block indicator).

The schedule line category (and its definition in Customizing) of the schedule line determines whether the schedule line of an item in a sales order is delivered via a warehouse or a third party. The schedule line categories permitted for a schedule line depend on the item category of the higher-level item (and on the RP type of the article). (In addition, the item categories permitted for an item depend on the sales document type, the item category group of the article (article sales data), the item use, and the item category of a higher-level item, if one exists.) For the purposes of our example, we will assume that the goods (or at least a number of items) ordered by the customer are delivered from the warehouse. Therefore, you must use a schedule line category that initiates a warehouse delivery (as defined in Customizing) for the schedule line(s) for these items in the sales order. These items are then included in a delivery due list, and from there are transferred to a delivery. In Customizing, you can specify for each order type and screen sequence group whether automatic promotion determination is to be carried out in the sales order (at item level). If the system finds that an item is involved in a promotion, it uses the promotion conditions (prices) for this item. There are two ways of creating invoices: 1. You enter a single, specific sales order or delivery for which you want to create an invoice. 2. You select a number of reference documents from the billing due list for which you want to create invoices. Possible selection criteria here are the sold-to party and the destination country. You can create any kind of billing document using one of these methods. Credit/debit memos and returns are then used instead of sales orders and deliveries as reference documents A billing document (that is, an invoice, credit memo, debit memo, and so on) is assigned to one company code for organizational purposes, and to one billing type (such as F1 = invoice, G2 = credit memo, L2 = debit memo; see Customizing) for the purposes of document flow. A billing document consists of a header and one or more items. Data that can be entered in the header of a billing documents includes: The company code of the billing document

The billing document type The number of the billing document The payer The payment date The terms of payment Data that can be entered for each item in the billing document includes: The item category The article number and short text The billed quantity of the article The net value of the item. The document flow for the item The retail price of the item (in the case of billing documents for warehouse orders between two different company codes)