In SAP SD, a Sales Order Document Type represents a unique category of sales order with predefined characteristics. Document types streamline business processes by determining key aspects such as pricing, delivery, and partner functions. Common examples include standard order types like OR and user-defined types like ZOR. This guide walks through transaction VOV8, explains why most implementations copy the standard OR document type rather than building one from scratch, and covers the number range and field settings worth reviewing once the new type is created. If you run into any errors while following along, feel free to send a screenshot to pramod@learntosap.com for help.
In SAP SD, a Sales Order Document Type represents a unique category of sales order with predefined characteristics. Document types streamline business processes by determining key aspects such as pricing, delivery, and partner functions. Common examples include standard order types like OR and user-defined types like ZOR.
Every sales order created in SAP SD - whether a standard sale, a rush order, a consignment order, or a contract-related order - is governed by a document type that controls how it behaves from the moment it's created through delivery and billing. The document type decides which number range the order draws from, which item categories and schedule line categories are proposed, how pricing is determined, whether credit checks apply, and how the order flows into subsequent documents.
SAP delivers a standard order document type, OR, out of the box, already configured with the settings a normal sales process generally needs. Many businesses copy this standard type rather than configuring one from nothing, since OR already carries proven pricing procedure determination, item category defaults, and document flow settings that would otherwise need to be rebuilt manually.
VOV8 technically allows a completely new document type to be created field by field, but in practice, almost every SD consultant copies an existing, well-behaved document type as the starting point rather than building one from a blank screen. For standard sales orders, that starting point is almost always the standard OR type.
| What Copying OR Brings Across | Why It Matters |
|---|---|
| Item category determination | Ensures line items on the new order default to the correct standard item category rather than requiring manual selection. |
| Pricing procedure determination | Preserves the linkage that determines which pricing procedure applies, so condition records are picked up correctly. |
| Standard document flow | Maintains the expected progression from order to delivery to billing without needing to rebuild copy control from scratch. |
| Proven configuration baseline | Reduces the risk of missing an obscure setting that only becomes apparent once order processing is already live. |
Building a custom document type on top of this proven baseline, rather than from an empty screen, is exactly why the example in this guide copies OR into a new type called EOR, rather than starting VOV8 with a blank entry.
The transaction itself is short, but each field carried over from the copied OR type is worth a quick review before saving, since these settings govern how every sales order created under the new type will behave.
Run transaction VOV8 directly, or follow the IMG path: SPRO → Enterprise Structure → Sales and Distribution → Sales → Sales Document → Sales Document Header → Define Sales Document Types.
Select the standard order document type OR in the overview list and use Copy As to create a new entry based on it, renaming it to Energy Standard Order for this example, rather than starting from a blank row.
Assign the new document type code - in this example, EOR - and select Save. Review the number range, pricing procedure determination, and other field settings that copied across from OR to confirm they still fit the new type's intended use.
Select Save. The system will usually prompt for a transport request if the system is configured to require one, which is standard practice for configuration changes so they can be tracked and migrated through the landscape (Development → Quality → Production) in a controlled way.
Copying OR gets the new document type most of the way there, but a handful of fields are worth a deliberate look rather than accepting the copied default without checking, since they directly shape how the new type behaves in daily use.
Pooja Mishra, an SAP SD consultant at Learn Pharma, was asked to set up a dedicated sales order document type for the company's energy products division, separate from the standard OR type used across the rest of the business. Sales manager Suresh Mehta explained that energy product orders needed their own number range and reporting visibility, since regulatory reporting for that division tracked orders separately from general merchandise.
Working with functional consultant Priya Patil, Pooja used VOV8 to copy the standard OR document type into a new type, EOR, standing for Energy Standard Order. Rather than rebuilding pricing procedure determination and item category settings from scratch, copying OR brought across the proven order processing behavior immediately. Business analyst Anita Shah then confirmed the new number range assigned to EOR, so energy division orders would be visually and numerically distinct from general orders in reporting.
Once saved and tested with a sample sales order, Suresh's team could see energy division orders flowing through their own document type, with the expected pricing and document flow behaving exactly as the standard OR type did - confirming that copying OR rather than starting from scratch had preserved the proven order processing logic the business depended on, while still delivering the separate reporting visibility that prompted the request in the first place.
Defining the document type in VOV8 is the foundation of sales order processing, but it is only one piece of a larger configuration picture. A handful of related settings, usually reviewed in the same project phase, determine whether orders actually process correctly end to end.
| Configuration Area | What It Controls |
|---|---|
| Item Category Determination | Which item category is proposed on line items under the new document type. |
| Schedule Line Category | Whether items on the order trigger delivery, availability checks, and requirements transfer. |
| Pricing Procedure Determination | Which pricing procedure and condition records apply to orders under the new type. |
| Copy Control | Governs which fields and quantities carry over when a delivery or billing document is created with reference to the order. |
A document type configured correctly in VOV8 but paired with incomplete settings in any of these related areas will often still let a user create the order, only to fail or behave unexpectedly at delivery or billing - which is why experienced consultants treat VOV8 as the starting point of a small configuration cluster rather than a standalone task.
Businesses rarely create a custom sales order document type without a specific operational reason behind it. A few patterns come up repeatedly across implementations, and recognizing which one applies helps confirm the new type is actually solving the right problem.
| Scenario | Why a Dedicated Order Type Helps |
|---|---|
| Divisional or regulatory reporting | A specific division or product line, such as energy products, needs orders tracked separately for compliance or internal reporting. |
| Different pricing needs | Orders for a specific customer segment or region require a distinct pricing procedure not used by the standard order type. |
| Different credit management rules | A new order category needs stricter or looser credit checks than standard orders, based on the business risk involved. |
| Rush or expedited orders | Certain orders bypass standard availability checks or scheduling rules to prioritize urgent fulfilment. |
Whichever scenario applies, the VOV8 configuration itself follows the same pattern shown in this guide - copy the standard OR type, rename it, and review the fields that matter for that specific business reason. Documenting which scenario prompted the custom type is worth doing at configuration time, so the reasoning isn't lost once the original project team has moved on.
Once the new sales order document type is saved, it's worth running through a short validation checklist rather than assuming the copy alone guarantees correct behavior. Create a test sales order (VA01) using the new document type and confirm the correct item category, pricing, and credit check behavior appear. Process the order through to delivery (VL01N) and confirm it flows correctly. Bill the delivery (VF01) and confirm the resulting invoice reflects the expected pricing and posts correctly. Finally, run a basic report filtered by the new document type to confirm it's reporting separately as intended.
Skipping this validation step is one of the more common reasons a newly configured order type produces confusing results in its first weeks of use - usually a pricing procedure that wasn't fully reviewed after the copy, or copy control settings that weren't adjusted for the new type's specific needs.
Transaction VOV8 and the underlying concept of copying an existing document type to create a new sales order type work the same way in SAP S/4HANA as in classic ECC, since sales document type configuration remains a foundational SD element unaffected by the Universal Journal or the simplified data model. What differs in S/4HANA is mainly on the reporting side: embedded analytics and Fiori apps in the launchpad make it considerably easier to track order volumes and performance by document type in near real time, which raises the practical value of assigning a clean, distinct number range and document type from the outset rather than retrofitting reporting separation after go-live.
| Transaction | Purpose |
|---|---|
| VOV8 | Define sales document types, including the standard order type. |
| VOV4 | Assign item category determination for a sales document type. |
| VOV6 | Define schedule line categories used in order processing. |
| V/08 | Maintain pricing procedures referenced by document type determination. |
| VTAA / VTFA | Maintain copy control between sales documents and between sales and billing documents. |
| VA01 / VA02 / VA03 | Create, change, or display a sales order under the new document type. |
Q: Why is OR typically copied rather than a new document type built from scratch?
Because OR already carries proven settings for item category determination, pricing procedure determination, and standard document flow - copying it preserves that proven behavior and reduces the risk of missing an obscure setting that only surfaces once orders are already live.
Q: What is the risk of not assigning a separate number range to a new sales order document type?
Orders would be numbered within the same series as other document types sharing that range, making it harder to identify and report on the new order category separately without additional filtering logic.
Q: Does creating the sales order document type alone enable end-to-end order processing?
No. The document type is the foundation, but item category determination, schedule line categories, pricing procedure determination, and copy control also need to be reviewed and, where necessary, adjusted for the new type to behave correctly through delivery and billing.
Q: What typically goes wrong if pricing procedure determination isn't reviewed after copying OR?
Orders under the new type can end up picking up an unintended pricing procedure, resulting in prices that don't reflect the correct condition records for that specific order category or customer segment.
Because document type codes are short - typically up to four characters - most SD teams agree on a naming convention before creating custom types, so codes like EOR remain self-explanatory to anyone reviewing the configuration later. A short prefix or suffix tied to the business reason for the custom type, as with EOR representing the energy division's standard order process, keeps the enterprise structure legible as more custom document types accumulate over a system's lifetime.
Governance also matters because document types, once in live use, accumulate real transaction history. Changing a document type's number range, pricing procedure determination, or credit check settings after go-live can affect historical reporting and open orders already created under it - which is why most organizations treat changes to a live document type as a reviewed, documented decision rather than a routine configuration update, in the same way they would for any other enterprise structure element already carrying production data.
Defining a sales order document type in VOV8 is a short configuration step on the surface, but it is the foundation every downstream order process setting - item categories, schedule lines, pricing, and copy control - ultimately builds on. Copying the standard OR type rather than starting from scratch, reviewing the number range and pricing procedure determination carried over from the copy, and testing a full sample order before go-live are what separate a document type that looks correctly configured from one that genuinely processes orders the way the business expects. Keep this guide handy the next time your project needs a dedicated order process for a new division, region, or product line.