Configure SAP S4 HANA Sales Documents in 10 Minutes

In this post we will configure full sale cycles for most widely used sales process. To configure SAP S4 HANA Sales Documents in 10 Minutes, we will focus mainly on standard sales order (to customers) & sales to other plants (through intracompany & intercompany STOs).

Step 1. Sales Order Type Configuration

Sales document types control the functioning of sales document. For example, a returns order to receive goods back from a customer will function differently than a sales order or a quotation.

The sales document is comprised of three general levels of data and control:

• The sales document header, which is controlled by the sales document type
• The sales document item, which is controlled by the sales item category
• The sales document schedule line, which is controlled by the schedule line category

We will configure our own sales document types to be used in full sales cycle

 YOR (order) --> YOBD (delivery) --> YF2 (billing).

We will configure our own, Sales Order type YOR.

1.1 YOR -PPIN Std. Sales Order

The sales document type controls the central header details of the sales order

Let’s focus on the configuration of our standard basic sales
order process to be used for our car business.

• The number assignment should be internal.
• Item numbering should have an increment of 10.
• Order entry should begin with the Item overview screen.
• Checking open quotations or contracts is not necessary.
• Billing document type F1– SAP Standard
• Requested delivery date to be proposed automatically with a lead time of 10 days.
• Pricing should be based on the current date.
• Automatically propose the current date as the customer reference date (Cust.Ref. Date) .

Configuration of Sales order type with minimum possible fields but we will explain all the fields

1.1.1 Explanation of all fields chosen for YOR Order Type

First we will explain all the fields given on the top areas (shown in below screenshot)

1.1.1.1 Fields in Main Header Area

There are total 4 fields in this area given below

a) SD Document Type

Give our customized name here . We have chosen YOR – PPIN Std. Sales Order

b) SD Document Category

The document category is C, meaning a sales order document type, rather than a quote, etc.

c) SD Document Block

The sales document is not blocked for processing so can be used by the business.

1.1.1.2 Fields in “Number Systems” Sub-screen

There are a total of 4 fields in this area .

a) No. Range Int.

Internal number range interval is 01.

b) No. Range Ext.

We have configured Ext no. range 02 for our order type.

c) Item No. Increment

The items in the sales order increase in increments of 10

d) Subitem Increment

the sub-items increase in intervals of 10.

1.1.1.3 Fields in “General Control” Sub-screen

Below fields are present in this area.

a) Item Division

The division of the material or item is not to be copied into the sales order.

b) Check Division

There is a check with an error message to see if this division is equal to the header division. for our YOR it will raise an error if it is not equal.

c) Probability

The probability of this order being completed and fulfilled is 100 percent.

d) Read Info-Record

The system must read the customer material info record, should one exist.

e) Check Credit Limit

The credit limit check field is blank, which means no check.

f) Enter PO number

Blank means -The system must not check the purchase order number for our “YOR” order type

g) Output Application

The output application is assigned for sales. We assigned standard V1 for our order

h) Commitment Date

The commitment date is not checked. The commitment date will be recalculated if changes are made to the material, quantity, requested delivery date, or delivery time.

1.1.1.4 Fields in “Transaction flow” Sub-screen

Below fields are present in this area

a) Screen Sequence Grp

The screen sequence group controls the way data is displayed, and in what sequence.

b) Display Range

The display range determines what items in the sales order are displayed—We have selected UALL All items

c) Function code for overv.scr

The function code for overview screens is the function code that determines what data and layout you see in the sales order—for example, item overview or item detail.

d) Incompletion procedure

We have selected std incompletion procedure “11” for our YOR Sales Document

e) Transaction Group

The transaction group determines what indices must be updated with reference to this sales order. “0” means order.

f) Quotation messages

For our order type since we have not configured quotation process so we have set as “Do not Check”.

HINT

Quotation messages and contract messages are set with an indicator B. Quotations, contracts, and master contracts are the three preceding key document types. So when you create a sales order you may want the system to give you a warning if open quotations exist. This setting B checks to see if the item is available on any other quotations or contracts for this Sold-to Party. Perhaps the user would then create the order with reference to that quotation or contract.

g) Doc. Pricing Proc.

At present we have defaulted “A” for our order type. We will input our customized value for this field after configuration of pricing procedure.

HINT

The document pricing procedure is this indicator plus the indicator on the customer master and the relevant sales area these determine which pricing procedure to use.

Note:

Please see the below screenshot after completion of pricing procedure. Please click HERE to check the pricing procedure configuration

h) Status profile

Status profile is used to assign a status profile to the particular document type. It is also assigned at item category level. For our Document type it is blank i.e. we have not assigned any.

i) Message: Mast.contr.

We have used blank means “Do Not Check”.

HINT

Message master contract checks to determine if any master contracts exist while you are creating a document type “contract.”

j) ProdAttr.messages

We have chosen “A -Dialog”

HINT

With product attribute messages, the system can error or warn to check manually entered products for the attributes to see if the Ship To party accepts them. In the case of automatic material entry, such as material determination, this check is ignored.

k) Incomplet.messages

With the incomplete messages indicator blank for our order type, the system will inform at the time of saving that the document is incomplete. However, we will still be able to save the document.

1.1.1.5 Fields in “Scheduling agreement” Sub-screen

The scheduling agreement area is used by scheduling agreement document types. Below fields are present in this sub-screen

a) Corr.delivery type

The correction delivery type is used for scheduling agreements. it is blank as we not configuring scheduling agreement.

b) Usage

This field is blank for our order type

HINT

The usage field is used to indicate on the sales order what the customer uses the
material for. This entry will be copied into all items, or it may be placed into items individually in the sales order.

c) MRP for DlvSchType

It is blank for our order type means Delivery schedules are not used.

HINT

MRP for delivery schedule type is used for scheduling agreements in order for them to set if the system should use just in time (JIT) processing or forward the demands on to material requirements planning (MRP).

d) Delivery block

Delivery blocks can be automatically set for scheduling agreements. A blank entry indicates no delivery block.

1.1.1.6 Fields in “Shipping” Sub-screen

Below fields are present in this subscreen

a) Delivery Type

This field indicates that this document type is relevant for delivery, and the delivery type to be used for automatic processing is LF.

HINT

At present we are giving SAP standard delivery type here, but later on we will swap it with our own delivery type.

b) Delivery Block

We have chosen blank means there is no automatic delivery block entered in the sales order.

c) Shipping Conditions

It is blank for our order type. Means for this order type shipping conditions are to be taken from customer master records.

HINT

The shipping conditions are proposed by the customer master record. Should an entry have existed in this field, this entry would have taken precedence and overwritten those found on the customer master record. The shipping condition value is used to determine the shipping point.

d) Immediate delivery

We have chosen blank means “Create delivery separately” i.e. we do not want immediate delivery for our order type.

HINT

The immediate delivery indicator is not set. This flag creates a delivery automatically immediately after saving the sales order. The delivery is not completed and the picking, packing (if relevant), and goods issue must still be carried out.

1.1.1.7 Fields in “Billing” Sub-screen

Below fields are present in billing sub-screen

a) Dlv-rel.billing type

This document is relevant for invoicing and for delivery-related invoicing, the system automatically uses invoice document type F2. We will change later this to our customized billing type.

b) Order-rel.bill.type

When an order-related invoice is possible the system will use document type F2 for automatic processing as well. (This makes sense if you wish your order and delivery relevant products to be invoiced at the same time.)

c) Intercomp.bill.type

The inter-company billing document type for automatic processing is IV.

d) Billing block

There is no automatic posting of a billing block on our sales order.

HINT

It may be necessary, however, to have a billing block for credit notes. This means that the order cannot be billed until the billing block is removed. Using a billing block is a safety feature. For example, you may have a background job that creates invoices. When you save the order, this background job will see the order and then invoice it if it is for order-related billing. Using the billing block will prevent this from happening until the order has been checked and the billing block explicitly removed.

e) CndType line items

We have assigned std “EK02”. The condition type for line items is used to determine the costing of the line item. It must be equal to the condition type allocated on your pricing procedure.

f) Billing plan type

It is blank for our order type as we are not using any billing plan.

HINT

The billing plan type is either periodic billing, where the entire value to be billed to date is billed in full on the billing plan date (for example, a rental agreement), or milestone billing, where the total value to be billed is distributed between the
individual billing plan dates (for example, for a project based on project milestones, where the value billed on each date can be a fixed amount or a percentage).

g) Paymt guarant. proc.

We used “01-Standard”

HINT

Payment guarantee procedure indicates to the system what form of guarantee procedure to use for this sales document. These are risk management.

h) Paymt card plan type

We used “03-Payment Card”

HINT

Payment card plan type is an essential setting should you want your system to accept payment cards in the sales order process.

i) Checking Group

We used “01-Standard”

HINT

Checking group is used to determine how the system carries out the checking of payment card data

1.1.1.8 Fields in “Requested delivery date/pricing date/purchase order date” Sub-screen

These settings affect the requested delivery date

a) Lead time in days

Lead time in days is the requested delivery date in the sales order. we have selected 10 days for our order type.

b) Propose Deliv.Date

The propose delivery date checkbox is checked to propose the current date as the delivery date. We have selected this for our order type.

c) Date type

Date type allows the user to set the format of the delivery schedule line date for internal system use—for example, date, week, month, etc. We have chosen 1 which is “Day”

d) Prop.f.pricing date

Proposal for pricing date allows you to specify the valid-from date for the pricing of the reference document, or the requested delivery date, or the current date. we have selected blank which means “Proposal based on today’s date”

e) Prop.valid-from date

Propose valid-from date allows you to determine when the valid-from date for pricing should be. This is used, for example, in quotations. We have chosen blank means “No Proposal”

1.1.1.8 Fields in “Contract & Availability Check” Sub-screen

Below are the fields in this sub-screen

Since we have not configured contract so we are skipping this last section

Step 2. Sales Document Item Category Configuration & Determination

Please check the below post for the detail configuration of “Sales Document Item Category Configuration & Determination”

Mastering SAP Sales Item Categories: A Comprehensive Guide

Step 3. Schedule Line Category Configuration & Determination

Please check the below post for the detail configuration of “Sales Document Schedule Line Category Configuration & Determination”

SAP Schedule Line Categories Explained: Everything You Need to Know

Step 4. Delivery Type Configuration

Please check the below post for the detail configuration of delivery type

SAP Delivery Guide: Outbound to Inbound

Step 5. Delivery Item Category Configuration & Determination

Please check the below post for the detail of Delivery Item Category Configuration & Determination

Mastering SAP Sales Item Categories: A Comprehensive Guide – Item Category in Deliveries

Step 6: Copy Control : Sales Order –> Outbound Delivery

Here we configure the control data for the document flow of deliveries.

Here for a particular delivery type, we configure, which document type is to be assigned to copied reference documents, and which item categories are to be copied.

In this configuration we copy requirements and data transfer, quantity and value updates in document flow.

This is done for each copying procedure at header and item level on a detail screen.

6.1 Copy Control for Std Sales Document to Delivery Document

For our business scenario we use Standard sales document YOR to delivery document YOBD

Follow the below path

SPRO –> Logistics Execution –> Shipping –> Copying Control –> Specify Copy Control for Deliveries

Or use T-code VTLA

6.1.1 Header Data

We copy the header data from the YOR sales order type to the YOBD Delivery type

6.1.2 Item Data

Since we use item category as “YTAN” so we will specify copy control for “YTAN”

6.2 Copy Control for Third Party Sales with individual PO

In this scenario, we get back the finish goods into our WH stock from the vendor. After that we create the outbound delivery against customer sales order same as normal sales procedure.

The difference is item category “TAB” is used for the Third Party Sales with individual PO instead of “YTAN” used for standard sales scenario.

6.2.1 Header Data

It will be same as std sales as described HERE

6.2.2 Item Data

In the item data we will use copy control for the item category “TAB”

Step 7. Configuration of Billing

Please see the below post for detail configuration of billing

Master SAP SD Billing Configuration

Step 8. Assignment of Delivery Type & Billing Type to Sales order Type

Sine now we have configured our customized sales order type (YOR), outbound delivery (YOBD) & Billing (YF2). Let’s assign them as required to complete the flow as shown HERE & HERE

8.1 Assignment of YOBD & YF2 to YOR

In this configuration we assign the delivery type YOBD & billing type YF2 to the Sales order type YOR

Please check the below post for billing type YF2 configuration detail

Master SAP SD Billing Configuration – Billing Type for Standard Sales Order

This completes the sales document configuration