Ansicht
Dokumentation

Sales Order Processing ( RELNSD_SLS_SALORD_46AISR )

General Material Data   General Material Data  
This documentation is copyright by SAP AG.

Short text

Sales Order Processing

Scope of Functions

• Cross selling

• Market orders

• Country-specific sizes for apparel

• Elimination of duplicate sales orders

• Support for article order numbers in catalog sales

• Support for logististical variants

Cross selling

You can set up the system so that if a customer orders a specific article, a list of other suggested articles appear as well: for example, if a customer orders a VCR, the sales person might suggest some blank tapes as well. If the customer chooses to accept one of the suggested articles, the article is flagged in the sales transaction data indicating that this article was a result of cross selling. You can then analyze the results in the Business Workbench or Retail Information System to see how successful your cross-selling strategy is (that is, how frequently a suggested article is actually purchased by the customer).

In order to determine which products are most frequently sold together, you can analyze sales orders for a specified period time (for example, for the previous 30 days). The system will search through all the orders, list all the articles purchased, and how often certain pairs of articles (or even three or more) appeared in the same sales order: for example, 10% of the time, customers purchased a specific jacket-and-skirt combination. In this way, you can mine the R/3 database to find article combinations that might not have occurred to you (for example, a movie and a CD with the sound track for the movie).

Alternatively, you can manually assign combinations of articles for cross-selling purposes, based on other information you may have. For each article, you can assign one or more cross-selling articles.

To set up cross selling, you must make the following settings in Customizing for Cross Selling:

• Create the conditions tables, access sequence, and calculation schemes for determining cross-selling articles, since the cross-selling function relies on the conditions technique (Define calculation schema for cross selling). Or you can assign cross selling articles manually as mentioned above.

• Create a cross-selling profile (Define and assign cross selling profile).

• Assign the cross-selling profile to a sales area, document scheme, and customer scheme.

Market orders

During market weeks, buyers can preview new fashions and place orders at a special price. Variants of generic articles are particularly important in this arena. Since the suppliers are testing the market, they may need to create variants on the spot based on the buyer' requests, and have these immediately available for order in R/3.

For example, assume that a size 12 blouse is offered in red, blue, and yellow, while a size 14 blouse might be available only in red and blue. If a buyer requests the size 14 blouse in yellow, then you can create that variant in R/3 by simply clicking that 14 - yellow node and activate that variant.

As soon as you activate a variant node, R/3 creates the variant in the article master data so you can complete the sales order immediately. Even if the order is not saved (for example, if the buyer decides not to purchase that variant after all), the variant still exists in the article master data).

The variant inherits the header data and price from the generic article. It also inherits the reference site from the generic article, if it exists; if it does not, then the order taker must enter it manually.

Country-specific sizes for apparel

SAP Retail uses characteristics to distinguish styles from one another. Apparel usually has characteristics size and color, footwear may have an additional characteristic width. Characteristic value descriptions further define the merchandise; for example, a dress might have characteristics size and color, with characteristic value descriptions 14 and red respectively. These characteristics, however, vary by country. For example, British shoe size 10½ corresponds to American shoe size 9½.

For world-wide sales order processing, customers must to be able to order merchandise in the sizes and colors they are familiar with. With some customizing, you can make this simple for both the customer and the order taker: the characteristic values descriptions in the style selection matrix can be displayed in different formats, based on the customer's language and nationality.

• Colors are language-specific (English = yellow, German = gelb, Italian = giallo)

• Sizes are country-specific (British shoe size = 10½, American shoe size = 9½)

You can define country groups, then assign one or more countries to each group. This is done in Customizing for article master data under retail-specific settings. All countries within a given group would use the same method of specifying style characteristics. For example, Great Britain and Ireland might belong to the same country group, but USA would not.

There is a transaction within the Merchandise Category component where you can create country-specific characteristics. Take, for example, the characteristic size. You assign different sets of characteristic value descriptions to size. You can then assign country groups to each characteristic value description. So a combination of country group plus the characteristic value description would determine how the style matrix appears.

During a sales order transaction, when the order taker enters the customer's number, the system reads the customer's country from the customer master data. Based on this, the system knows to display the appropriate size. The order taker can also manually select a country group; for example, if an American customer is ordering from an American catalog, but is purchasing the merchandise for a friend in Britain who has only specified the British size, the order taker clicks a button to select the matrix for British sizes.

Elimination of duplicate sales orders

SAP Retail can search for all sales orders that have the same customer, currency, and total value of the order. From this list you can select pairs of orders and have R/3 drill down into the individual line items. If at least one of the line items differs between the two orders, the system will automatically let both orders proceed. If, on the other hand, the line items are all identical, you can then examine the individual sales orders and choose which one you want to cancel (for example, if one order has been partially delivered and the other not, you would want to cancel the one that has not yet been processed). This way you can catch unintentional duplication at an early stage and thereby reduce the frequency of merchandise returns.

When you run the duplicate order report, the system will list all the sales orders matching the criteria you have selected. Next to each customer, there will be either a green or yellow button:

• A green button indicates that there are no duplicate orders.

• A yellow button indicates that one or more sales orders for this customer have the same currency and total order value.

For each customer with a yellow button, you can further expand the list to show all sales orders. Individual sales orders will now have either a green or yellow button. Again, the yellow button indicates a possible duplication.

You can select any two - and only two - sales orders at a time, then press a button to have the system do a further analysis of the two orders. If the items within the sales orders are different, the yellow button will become green, indicating that there are no problems. But if all items match completely, a red button appears. You can then click on each of the orders to examine them, then decide which of the two to cancel.

You cannot cancel a sales order for which a full or partial delivery already been made.

Support for article order numbers in catalog sales

In sales orders, you normally enter the R/3 article number for the product being purchased. For mail order catalog sales, however, you may have order numbers (item numbers) that are associated with specific specific product catalogs. For example, R/3 can append the catalog code (source code or product catalog identifier) to the article number according to certain algorithms. This way you can track which catalog, or which pages within a given catalog, generated the sales order.

In Sales Order Processing, these order numbers are treated exactly like normal article numbers in the R/3 master data. The customer gives the order number, and the system automatically determines the catalog from which it came. This catalog code is then stored in the sales document at the header and item levels, which allows you to accumulate statistics:

• Catalog data at the header level allows you to evaluate the effectiveness of a catalog (e.g., how much total revenue the catalog generated for all merchandise within it).

• If an article appears multiple times within a catalog, catalog data at at the item level allows you to compare revenues generated for a single article based on where it appeared in the catalog.

If you want to use order numbers rather than article numbers, you must first change Customizing settings for sales document types (Maintain sales document types). For each sales document type, you can choose whether sales orders are to use the R/3 article number or the order number.

Support for logistical variants

You can assign various units of measure for a generic article, and a subset of those units of measure for each variant. This allows you to buy and sell variants of the same generic article by different units of measure.

Suppose you have a generic article T-Shirt, which comes in S, M, L, and XL, and in white, black, red, and blue. You buy T-shirts in pallet loads and cartons. You sell all the shirts individually to your consumers, but in addition you sell the white shirt in bulk (cartons) to your wholesale customers for silk screening. The purchasing unit of measure for the shirts would be carton and pallet, but the sales units of measure (logistical variants) would be as follows:

• Generic article: each, carton, pallet

• White T-shirt: each, carton

• Black, red and blue T-shirts: each

Damage caused to data by errors

Software/hardware requirements

Installation information

Effects on System Administration

Effects on Customizing

Effect on batch input

Changes to the Interface

Changes in procedure

Procedure for removing dataset errors

Dependent functions

Planning

Further notes

ROGBILLS - Synchronize billing plans   BAL Application Log Documentation  
This documentation is copyright by SAP AG.

Length: 12067 Date: 20240523 Time: 052814     sap01-206 ( 258 ms )