CO Internal Orders
`
`The following Help Topics are available:
`hltr~;lucJ~
`Ma_sie.r_J:)a~
`
`Ar, tual2~tJ~
`
`For Help on Help, Press F1
`Version
`
`SAP-00005945
`
`

`
`Version
`Prepared for R/3 Release 2.2.
`August 1994
`
`SAP-00005946
`
`

`
`Copyrights
`
`@1994 SAP AG. All rights reserved.
`Neither this documentation nor any part of it may be copied or reproduced in any form or by any
`means or translated into another language, without the prior consent of SAP AG.
`SAP AG makes no warranties or represenations with respect to the content hereof and specifically
`disclaims any implied warranties of merchantability or fitness for any particular purpose. SAP AG
`assumes no responsibility for any errors that may appear in this document. The information
`contained in this document is subject to change without notice. SAP AG reserves the right to
`make any such changes without obligation to notify any person of such revision or changes. SAP
`AG makes no commitment to keep the information contained herein up to date.
`
`SAP-00005947
`
`

`
`Introduction
`
`This section provides an introduction to uses and classification of internal orders in modern
`business.
`
`-...................................
`
`Order management within a company usually differentiates between:
`¯
`sales-oriented orders and
`¯
`internal orders
`Sales-oriented orders are used mainly for controlling the logistics of input factors and sales
`activities, whereas with internal orders, we distinguish between:
`¯ orders used purely to monitor objects within cost accounting (such as advertising or trade fair
`orders) and
`¯ productive, value-added orders, that is, orders which can be capitalized (such as in-house
`construction of an assembly line).
`
`Sales-oriented
`For
`inventory
`
`Fordirect
`sales
`
`I
`
`I
`
`Not to be
`capitalized
`
`Internal
`
`To be
`capitalized
`
`Overhead orders I Capitalspending I
`
`I
`
`I
`
`I I
`
`I Customer
`I I
`
`I
`Logistic functions
`Quantity
`
`External services
`
`Warehouse
`
`Cost center
`
`I
`
`Stock
`
`I
`Cost accounting functions
`Values
`
`I nternalactivities
`
`I I
`I I
`
`The management of internal orders represents the most detailed operational level of cost and
`activity accounting and can be used:
`¯
`for cost management, for example, where costs are to be considered according to aspects
`other than those used in cost element or cost center accounting
`for decision making, in situations where you have to decide between in-house production and
`external procurement
`
`¯
`
`SAP-00005948
`
`

`
`S02300 I
`Building
`
`BuildingA
`_~2310
`Admin.
`
`S03000 I
`
`L~2410Truckfleet I
`
`,.~-I,
`
`General
`admin.
`
`Support ctrs
`
`4110 I
`Machinist
`
`Isr°u2ck°f’°eet I
`IS04100
`Admin._1 ooI
`Personnel I
`I
`
`2320
`Building B
`Warehouse
`
`2330
`Building C
`
`I
`ProductionI
`
`3200
`
`4120
`Electrician
`c,
`
`3300
`Sales
`
`I
`
`4130
`Painter I
`
`With an internal order you can
`¯ plan costs (see Planninq)
`¯ post costs (see Actual Postinc!#)
`¯ allocate costs (see Order Settlement)
`¯ evaluate costs (see
`
`S04300 I
`Product. B
`
`_~4320
`--~ Product. II
`/
`I
`
`I
`
`SAP-00005949
`
`

`
`Classifying Internal Orders
`
`The internal orders in an organization can be classified according to the following aspects:
`¯ order contents (functional classification)
`¯
`controlling objectives
`
`SAP-00005950
`
`

`
`Classifying Orders According to Contents
`
`Internal orders can be used for different purposes (see also Classif~ Orders AccordincLto.
`@r).t.rol.lj.n ..QbigcJ.iy#~. This functional classification is reflected in the different order types whose
`attributes define the way orders are processed in the system.
`
`Job Orders
`
`The main purpose of this type of order is to collect the planned and actual costs incurred for a
`commodity or an operational measure. This means you can monitor the costs using up-to-date
`variance analyses at any time.
`
`Order 711
`Painting
`
`Building A
`
`Cost element Description
`
`400
`615
`415
`
`655
`
`Material
`Labor hrs
`External services
`
`09/92
`
`3500
`1200
`2400
`
`Total costs
`Job-ordersettlement
`
`7100
`-7100 m
`
`Cost center
`
`Building A
`
`Cost element Description
`
`09/92
`
`655
`
`Job-ordersettlement 7100
`
`Job orders are used only within cost accounting, and include orders used purely for object
`monitoring (advertising, trade fair orders) and productive, value-added orders which are not
`capitalized (orders for repair and maintenance work).
`Example
`You create a job order for the painting work on one of your buildings, and use it to collect all the
`costs which are incurred for these maintenance tasks. You then allocate the costs to a cost
`center each month.
`
`Capital Spending Orders
`
`Capital spending orders allow you to monitor the costs for assets produced in-house, for example,
`the construction of an assembly line. Major maintenance tasks that are to be capitalized (for
`example, the replacement of an engine) also fall into this category.
`The costs are settled to a G/L account or to an asset at the end of the year or after the order has
`been completed.
`
`SAP-00005951
`
`

`
`Order913
`Construct. of a conveyor-belt Hall 1
`
`Cost element Description
`
`Actual
`
`400
`661
`431
`663
`
`811
`
`20000
`Production material
`6000
`Material OH
`15000
`Direct labor costs
`7500
`Manufacturing OH
`48500
`Total costs
`Capitalizedservice - 48500 m
`
`G/Laccount 11000machines
`
`Cost element Description
`
`Actual L~
`
`811
`
`Capitalizedservice
`
`48500
`
`Production Orders
`
`You can also use internal orders as production orders, as long as you are not using bills of
`materials or routings.
`The quantities and values posted to the production order come from different sources. The most
`important origins are:
`¯ primary costs from financial accounting
`¯
`secondary costs applied as overhead
`¯ activities provided by cost centers
`¯ material issues for parts and semi-finished products
`The actual costs collected on the production order can be allocated to stock periodically, or when
`the production process is complete.
`
`SAP-00005952
`
`

`
`812
`Order
`Product ABC
`
`Cost element Description
`
`403
`410
`661
`431
`663
`
`Parts
`Supplies
`Material OH
`Direct labor costs
`Manufacturing OH
`Total costs
`892 Change in inventory
`
`Actual
`
`1500
`350
`500
`1200
`600
`4150
`- 4150
`
`G/Laccount 791 Finished products
`
`Cost element Description
`
`Actual
`
`892 Change in inventory
`
`4150
`
`SAP-00005953
`
`

`
`KClassifying Orders According to Controlling Objectives
`Each order type can be managed as an individual, standing or statistical order.
`
`Individual Orders
`
`An individual order is distinguished by its uniqueness and differing durations.
`You can create an order for an individual job, and collect all costs incurred in performing that job.
`Such orders are often planned step by step, depending on the progress of the technical planning
`and the work itself.
`
`35
`Order
`Trade fair Seattle
`
`Cost element Description
`
`Actual
`
`464
`471
`477
`439
`472
`
`Fees
`250
`2000
`Rent
`Advertising material
`25000
`Person n el costs
`15000
`Expenses
`30000
`72250
`Total costs
`653 Job-ordersettlement -72250
`
`m
`
`Credit: after completion
`
`Cost center 3300 Sales
`
`Cost element Description
`
`653 Job-ordersettlement
`
`Actual I~
`72250
`
`You can allocate the actual costs collected on an individual order:
`¯
`in the month the costs were incurred
`¯ after all the work is completed
`to display the costs as a total not only on the order, but also on the receiver
`because the receiver had not yet been determined when the order was created
`Typical examples of individual orders are
`capital spending orders for fixed assets produced in-house
`¯ orders for major repairs
`¯ development and design orders
`¯ CO production orders
`¯ orders for services to a third party
`¯ advertising and trade fair orders
`
`Standing Orders
`
`Standing orders are most often used to allocate the costs incurred for recurring deliveries and
`
`SAP-00005954
`
`

`
`services.
`
`tPainting
`
`Painting
`
`Material
`Wages
`External services
`Total costs
`
`Painting
`
`BuildingC
`09/92
`
`Buildin
`09/92
`
`09/92
`3500
`1200
`2400
`7100
`
`Settlement painter
`
`- 7100
`
`Credit: periodic
`
`I Cos center
`I Costcenter ~ V Building B Actual
`
`BuildingC
`
`Costcenter BuildingA Actual I 11000
`
`Settlement painter
`
`Actual 2750
`7100
`
`They allow you to monitor costs in more detail than is possible using a cost center. In addition,
`serious cost center variances can be broken down and analyzed more easily using such orders.
`The actual costs collected on standing orders are normally settled monthly.
`Standing orders often remain open for several years. Some of the typical applications include
`¯ minor repairs
`¯ maintenance of small equipment, such as wiring, light fixtures, and so on.
`¯
`individual vehicles of the company fleet
`¯ operation of"administrative" equipment, such as photocopiers, telephone systems, etc.
`
`Statistical Orders
`
`Statistical orders are a typical instrument for evaluating costs which cannot be itemized in detail in
`cost element or cost center accounting. These orders allow evaluations according to criteria other
`than those used in cost center accounting.
`You achieve this by assigning all postings of actual costs to a statistical order, as well as to a cost
`center. The costs will then appear under the original cost element both on the cost center (real
`costs) and on the order (statistical, for information purposes only).
`Unlike the "real" internal orders, you can neither settle statistical orders, nor apply overhead to
`them.
`Example:
`You create a statistical order for each vehicle in your truck fleet.
`
`SAP-00005955
`
`

`
`You post the costs for fuel, repairs, insurance, and so on, to the cost center "Truck fleet", with
`an additional account assignment to the relevant statistical order.
`On your cost center, you see the total costs incurred for all vehicles.
`The individual orders show you how high the costs were for each vehicle.
`
`I
`
`F-ZZ110
`M -YY220
`S -XX330
`
`I
`
`Cost element
`
`Description Actual
`
`421
`
`451
`
`469
`
`Fuel
`
`Repanrs
`
`Insurance
`
`480
`
`125
`
`800
`
`Total costs 1405
`
`Actu:
`
`75d
`
`75d
`
`Credit: none
`
`~V
`Costcenter Truck fleet
`
`Costelement Description Actual
`421
`1395
`Fuel
`451
`200
`Repalr.~
`469
`Insurance
`800
`Total costs 2395
`
`SAP-00005956
`
`

`
`Model Orders
`
`Model orders contain only default values and serve as a reference when you create a regular order.
`Model orders simplify the creation of orders by:
`¯ saving you entering data which is used repeatedly in orders within an order type
`¯
`reducing the possibility of typing errors or incorrect entries
`You can, however, overwrite the default values, if needed.
`Example:
`Your marketing orders are always allocated to the sales cost center. If you have stored that
`cost center as a default value, you no longer need to worry about it when you create a new
`marketing order.
`On the other hand, you could overwrite the cost center stored in the order if you decide to
`allocate the order to another cost center.
`
`SAP-00005957
`
`

`
`Master Data
`
`The master data defines the attributes of an order, such as
`¯
`its purpose, as defined by the order type.
`¯ the tasks you can carry out on an order, as defined by the order status and the allowed or
`disallowed transactions.
`Master data is used partly for technical, partly for business purposes and either does not change at
`all, or only insignificantly, during the life of an order.
`.Numb.er..RaJt eL.S
`. O. rd .e r...’[’.~__.#_A
`
`o LerJ3r
`
`SAP-00005958
`
`

`
`Number Ranges
`An order must be uniquely identified in the system. This is achieved by storing each order under a
`separate number. The number is taken from the number range to which the order type is
`assigned.
`The order number can be assigned either internally or externally:
`¯ With internal number assignment, the system assigns a sequential number to the order.
`¯ With external number assignment, you have to assign a number yourself. This "number" need
`not be numeric. You can also use mnemonic numbers (alphanumeric).
`How the order number is assigned depends on how the number range has been defined for the
`respective order type during system configuration.
`
`SAP-00005959
`
`

`
`Order Types
`
`The order type subdivides orders according to their purpose (see also Classify. Orders Accordin~
`~tJ:Q!!i.r~ .Q.b.e.ctJ.y~s.). An order type is used to group together orders with similar
`characteristics, such as status management, settlement receiver and frequency, or duration.
`Order types are defined for each client during system configuration. Among other things, they
`control
`¯ whether open item management is active.
`¯ whether classification is active.
`whether revenue postings are allowed (an order with revenues can only be settled to a G/L
`account or a business segment).
`the retention periods before the orders are archived.
`
`SAP-00005960
`
`

`
`Business Transactions
`
`Many of the actions that change an order in some way are defined in the system as business
`transactions. These are represented by a four-character key and an explanatory text. Typical
`examples of business transactions are:
`RKP1
`Plan costs
`KZPP
`Plan periodic overhead
`KZPI
`Actual periodic overhead
`BFRE
`Release
`RFBU
`Post to G/L account
`RKU1
`Transfer costs
`RKL
`Allocate costs
`KOAO
`Settle actual costs
`Set deletion flag
`LVMS
`If you attempt to carry out one of these transactions, the system first checks whether the respective
`transaction is allowed for the order concerned. Status management controls which transactions
`can be performed on an order at different times.
`
`SAP-00005961
`
`

`
`Status Management for Internal Orders
`
`An order is not a static object, but has its own life cycle that begins when you create it and ends
`after you close it. During this time, different things happen to an order: for example, costs are
`planned, posted and settled. Thus, the life cycle of the order can be divided into different phases.
`
`The Phase
`
`We differentiate four phases for the internal order:
`¯ opened
`¯
`released
`¯ technically completed
`¯
`closed
`In the order, the system logs when the individual phases were reached. You can also store a
`planned date for the last three phases.
`The current order phase is documented by a system status of the same name. In each phase, the
`system status allows only certain business transactions. For example, you cannot
`¯ post actual costs in the phase "Opened".
`¯ make changes to the plan in the phase "Technically completed".
`¯
`carry out any cost relevant business transactions in the phase "Closed".
`In the phase "Released", you can perform all business transactions.
`Changing the phase of an order is itself a business transaction and is carried out using a master
`data function (for example Edit--~ Release). You cannot usually reverse phase changes
`(exception: you can return from the phase "Closed" to "Technically completed").
`For internal orders, you can choose between the following types of status management:
`¯
`If you do not want to define your own statuses, you can use the predefined phases.
`¯
`If you want to control when certain transactions are to be allowed, then you can choose
`betwe e n:
`general SAP status management and
`order status management
`It is recommended that you use the general SAP status management functions because these are
`also used in other areas (for example, for projects, production orders, and so on).
`
`SAP-00005962
`
`

`
`KSAP Status Management
`
`This topic describes the general SAP status management functions. To activate this form of status
`management for internal orders, you simply assign the status profile you want to use to the order
`type in question. This type of status management is recommended if you want to define your own
`status control.
`
`The Status
`
`The current processing status of an object is documented by one or more statuses. A status is an
`indicator fulfilling two functions:
`¯
`it informs you that a particular status has been reached (for example, "order has been
`released")
`¯
`it influences the number of allowed business transactions
`If you perform a particular business transaction, this can in turn set or delete one or several
`statuses for the object concerned.
`The interaction between status and business transaction can be illustrated as follows:
`
`Performing a
`function inthe
`ordere.g
`- release
`-close
`
`changes IThe numberof
`
`of active
`statuses
`
`determines IThe business
`
`I~ transactions
`
`allowed
`
`An object can have as many statuses as desired.
`Example
`In a production order, the following statuses can all be set simultaneously:
`released
`preliminary costing
`printed
`confirmed
`Statuses are represented in two different ways in the system:
`¯ as a 4-character identification code
`¯ as a 30-character text
`Both can be translated into different languages.
`A status can either be active or inactive:
`¯ a status is active if it is currently in effect
`¯ a status is inactive if it
`has not yet been active
`was active, but has since been deactivated
`A status can
`
`SAP-00005963
`
`

`
`¯ allow a business transaction.
`¯ allow a business transaction with a warning.
`¯ prohibit a business transaction.
`If a transaction is allowed with a warning for a particular object, the system issues the warning
`message when you perform the business transaction. You can then decide whether to ignore the
`warning and continue with the business transaction.
`Example
`You want to flag a released order for deletion. However, the order is not yet reached the status
`"Closed". In this case, the system first issues a warning pointing out that the order has not yet
`been closed.
`To be able to perform a business transaction, the following requirements must be met:
`¯ At least one active status must allow the business transaction.
`¯ None of the active statuses may prohibit the transaction.
`The general SAP status management functionality distinguishes between system status and user
`status.
`
`System Status
`
`A system status is a status set by the system which informs the user that a certain function has
`been performed on an object.
`Example
`If you release an order, the system automatically sets the system status "Released". You can
`only influence this status by carrying out another business transaction which causes the status
`to change.
`
`User Status
`
`You can further differentiate the existing system statuses by creating your own user statuses.
`User statuses are defined in a status profile and you can create and activate as many as you
`require.
`System statuses and user statuses influence business transactions in exactly the same way.
`
`Object Type
`
`The object type is used to distinguish objects with differing systems of status control. The object
`type determines which system statuses are activated automatically when creating a new object and
`which transactions are allowed.
`Every object that uses SAP status management is assigned to a particular object type.
`Typical examples of object types are
`¯ projects.
`¯
`internal orders.
`¯ production orders.
`¯ networks.
`
`Status Profile
`
`SAP-00005964
`
`

`
`The status profile contains the user statuses and rules defined by the user. You can use it for one
`or more object types. You usually specify which status profile a particular object is to use during
`system configuration.
`Example
`For orders, the order type determines the status profile to be used. You can use the same
`status profile for several order types.
`In the status profile, you can define as many user statuses as you need and identify them using a
`four-digit identification code.
`These status IDs can all be translated into other languages. However, you can only make
`changes to a status profile in its master language.
`
`Sequence Number
`
`User statuses can be used to determine a sequence for the different steps used in processing an
`object. For each step, you define a user status and give it a sequence number. You should
`assign these numbers so that they are processed in ascending order.
`A status that does not have a sequence number can be set or deleted at any time and regardless of
`whether other user statuses are already active.
`However, you can only have one user status with a sequence number active at any one time. If
`you then set another user status with sequence number, the previous user status is automatically
`deleted.
`You control the sequence in which the user statuses with sequence numbers can be set using the
`lowest and highest sort numbers.
`Example
`The individual steps in the construction of a building are to be monitored using user statuses.
`You define the following user statuses in a status profile:
`Status Profile
`SON
`Status
`
`Short text
`
`Lowest SON
`
`Highest SON
`
`10
`20
`30
`40
`50
`
`PLAN
`APRV
`CNST
`HDVR
`CMPL
`
`Planning
`Plan approval
`Construction
`Handover
`Completed
`
`10
`10
`30
`30
`50
`
`20
`30
`40
`50
`50
`
`The statuses are usually processed according to the sequence numbers. However, it would be
`impossible to change directly from status PLAN to status CNST because the status profile specifies
`that from sequence number 10 you can only change to sequence number 20. After you have
`reached the status CNST, you can no longer return to the statuses PLAN or APRV.
`
`Initial Status
`
`In the status profile, you can also define one of the user statuses as the initial status. This status
`then is set automatically when you create a new object (order, project, and so on). You can
`specify as many initial statuses as you like, but only one of these can have a sequence number.
`
`Controlling Business Transactions
`
`A user status can
`
`SAP-00005965
`
`

`
`allow or forbid business transactions.
`be set or deleted by a business transaction.
`Example
`In the above example, you could define your status profile so that the user status CMPL is set
`automatically when you carry out the function Edit --> Techn. complete in the order master.
`
`Displaying the Status
`
`The active statuses for an object can be displayed either as a list or in a status line.
`The status line can contain a maximum of eight statuses at once. You define the position at which
`a user status appears in this line in the status profile. You can also define more than one status
`for the same position. In this case, the status that is actually displayed is determined using the
`column Priority in the status profile.
`The list display contains all the active statuses sorted according to position and priority.
`
`SAP-00005966
`
`

`
`Technically completed
`
`Order Status Management
`In addition to the general SAP status management, there is still the old order status management
`which you define directly for each order type. This type of status management is described in the
`topic below.
`The phases allow only a rough subdivision of the order life cycle. Frequently, however, a finer
`detailing, aligned to the transactions carried out on an order, is necessary.
`Example:
`The transactions for a trade fair order might be as follows:
`Phase
`Transactions
`Opened
`Planning
`Posting of setup costs
`Released
`- booth rental
`- trade fair fees
`Posting of running costs
`- material issues
`- internal activities
`- external services
`Posting of follow-up costs
`-hotel bills
`-travel expenses
`Settling the costs
`None
`Closed
`You see that we have different transactions in the "released" phase, namely the posting of setup
`costs (incoming invoices) and of running costs. Posting of follow-up costs in the "technically
`completed" phase again consists of incoming invoices.
`It would be likely, for example, that you want to limit these transactions to a certain period. You
`would perhaps only allow external invoices to be posted before the actual work starts. After the
`order has been completed, you might not want to allow any more internal activities to be posted.
`You can achieve this by dividing your "released" phase and assigning the transactions to the
`sub-phase where they are to be allowed.
`You can divide a phase into several statuses and assign transactions to these statuses using
`transaction groups.
`Status management defines, among other things, the following:
`¯ DSt
`Which status is proposed when you create an order
`¯ TGrp
`Which transactions are allowed or disallowed in which status
`¯ PID
`Whether and when planning documents will be written
`¯ Attributes
`Which attributes the screen fields have during master data maintenance in each status
`¯ DF
`When you can flag the order for deletion
`
`SAP-00005967
`
`

`
`Each order type has its own status management and therefore allows a different structure,
`depending on the function of the orders.
`You define status management during system configuration.
`
`Ordertype 0400 Trade fairorder
`
`PID DSt DF
`
`X
`
`X
`
`XX
`
`TGrp
`
`PLAN
`STU P
`ALL
`INV
`Sqq-L
`
`Orderstatus
`
`LSt HSt Opn Rel Cmp Cls
`
`X
`
`XX
`
`XX
`
`X
`
`10
`20
`30
`40
`50
`60
`
`Planning
`Setup costs
`Running costs
`Follow up costs
`Settlement
`Closed
`
`10 20
`10 30
`20
`50
`30 50
`40
`60
`60 60
`
`For this example we defined six statuses (status 10 to 60). The columns have the following
`contents:
`¯ Order status
`The first two columns from left to right contain the numeric order status and its description.
`¯ LSt, HSt (lowest status, highest status)
`These two columns determine how you can change the status, and therefore also the phase, in
`the order. You will find a detailed description on how to do this in the example below.
`¯ Opn, Rel, Crop, Cls (opened, released, technically completed, closed)
`These four columns contain check boxes for the different phases. To assign the status to a
`phase, mark one of the columns. In doing so, you must adhere to a sequence from left to right,
`just as you must also adhere to a numerical ascending sequence for the status.
`¯ TGrp (transaction group)
`This column contains the transaction group that is allowed in the respective status.
`¯ PID (planning documents)
`In this column, you mark whether you want to log changes to the order planning in this status.
`This causes line items, which you can display, to be written for every change in order planning.
`Of course, the allowed transaction group also has to include planning activities, otherwise, you
`cannot plan and this indicator has no effect.
`¯ DSt (default status)
`You mark the default status in this column. This is the status which the orders of this order type
`should have when they are created. This is usually the status with the lowest number.
`You can overtype the default value in the order, if required.
`¯ DF (delete flag)
`In this column, you mark in which status the order may be flagged for deletion. To be able to
`flag an order for deletion, its balance must be zero, which means the order never had any
`values posted to it, or it has been settled in full.
`The following example illustrates how the status management can affect an order.
`
`SAP-00005968
`
`

`
`Example
`You have planned your order in status 10 and want to release it now. The column HSt shows
`that you can set it as high as status 20 at the most (setup costs). You change the status
`directly in your order to 20.
`This has the following effects:
`you have changed the phase to "released" at the same time
`the released date was set automatically in the order
`you can now post the external invoices for your setup costs
`If you now, for example, wanted to return to the planning status again which is allowed
`according to Column LSt (lowest status = 10), the released date would be cleared out again.
`From status 20, you can proceed to status 30, where all actual postings (activity group ALL) can
`occur. In this case, the phase does not change. If you do planning changes now, these are
`captured in planning documents according to column PID.
`
`Ordertype
`
`0400 Trade fairorder
`
`PI D DSt
`
`DF
`
`X
`
`X
`
`XX
`
`TGrp
`
`PLAN
`STUP
`ALL
`INV
`S-I-I’L
`
`Orderstatus
`
`LSt HSt
`
`Opn Rel Cmp CIs
`
`X
`
`XX
`
`XX
`
`X
`
`10
`20
`30
`40
`50
`60
`
`Planning
`Set up costs
`Running costs
`Follow up costs
`Settlement
`Closed
`
`10 20
`10 30
`20 50
`30 50
`40
`60
`60 60
`
`If you do not expect follow-up costs, you can immediately move forward from status 30 to status
`50 and skip status 40 in this case. At the same time you have then again changed the phase
`which also sets the completed date. You can now settle the order.
`But now you realize that one of your employees had not yet submitted his travel expenses.
`Since you cannot post these in status 50 because only the settlement his allowed here, you
`must reset the status in the order again.
`The lowest status (LSt) determines that you can only go from the settlement status back to
`status 40.
`At the same time the following happens: the system notes the highest status which the order
`had already achieved, therefore the lowest status to which you may return no longer changes.
`Thus, you cannot go from status 40 back to 30 again, although, according to LSt, status 40
`would normally allow this.
`Having posted your follow-up costs, you can change the status to 50 again to settle the order.
`As soon as the order is settled completely, you can set the delete flag, since this column is
`marked for status 50.
`You can also set the order to status 60 after it is settled. As indicated in Column LSt and HSt,
`you now cannot make any further status changes. You can no longer post to the order at this
`point. You can, however, still use it for evaluations in reporting.
`
`SAP-00005969
`
`

`
`Field Selection
`
`The structure of an internal order is only defined once in the system and is thus the same for all
`order types. Depending on the purpose of your orders, however, you will not always use all (or the
`same) fields.
`Field selection allows you to define fields as active or inactive. Active fields are those which
`appear on the screen, inactive fields are those which do not.
`You can define the field selection for the entire order via the order type. However, you can also
`define it for each individual status if you are using order status management. The field attributes of
`the status are then combined with those of the order type.
`The decision about how to handle a field is made when setting up the order types during system
`configuration.
`The active fields can also differ with respect to other attributes such as
`¯ open for input
`¯ not open for input
`¯ highlighted
`¯ mandatory
`¯
`invisible
`
`Fields Open for Input
`
`Fields of this type can include data that
`¯
`is not validated because it is mainly for information purposes (for example, texts)
`¯
`is validated because it
`must correspond to a certain value (for example, you can only enter a certain status in the
`order if this is also defined for the order type)
`must adhere to a certain format (for example, a date)
`
`Fields not Open for Input
`
`These fields prevent you changing their contents.
`is permanent (for example the order type).
`
`They are used for displaying information which
`
`Highlighted Fields
`
`Such fields stand out optically.
`
`Mandatory Fields
`
`If you do not make entries in these fields, the system will issue an error message and you cannot
`continue to work until you have filled it in. These fields are always identified by a question mark.
`
`SAP-00005970
`
`

`
`Order Group
`An order group consists of several orders that are grouped together to represent a certain structure.
`You can set up such a structure using as many levels as you wish. The orders themselves are
`always at the lowest level of the group.
`An order may be assigned to different groups at the same time. Order groups are
`client-dependent, therefore you can use a group name only once.
`Order groups can be used for:
`¯ planning.
`¯ overhead calculation.
`¯
`settlement.
`¯
`reporting.
`Example
`You have three buildings (A, B, C) on which maintenance work is being done by three
`maintenance shops (plumber, painter, electrician). You create an order for each building and
`each workshop and group these nine orders together to form the order group shown below:
`
`MAINT01
`
`l Maintenance I
`
`BIc
`
`J.A
`
`BIc
`
`J.BI
`
`Plumber Electric-
`ian
`
`Painter
`
`Plumber Electric-
`ian
`
`4Painter
`
`4Painter
`
`I Bid
`
`J.cI
`
`Plumber Electric
`ian
`
`The figure on the previous page shows the order group MAINT01 which groups together the
`orders according to buildings.
`To do this you create the top node and name it, for example, MAINT01 "Maintenance".
`To this node, you add three further nodes, one each for building A, building B and building C
`respectively.
`To each building node you assign the orders of the workshop that carries out the work on this
`building.
`Using this group you can analyze both the entire maintenance costs for the three buildings as
`well as the costs for each individual building.
`You can also set up a second group using the same orders. Instead of creating building nodes,
`you create three workshop nodes to which you then assign the respective orders. This
`alternative group allows you to evaluate the maintenance costs for each workshop:
`
`SAP-00005971
`
`

`
`MAINT02
`
`I M aintenance I
`I
`
`t
`
`I Electrician I
`
`I Painter I
`
`BIdg.A BIdg. B BIdg. C
`
`BIdg. A BIdg. B BIdg. C
`
`BIdg.A BIdg. B BIdg.C
`
`The group MAINT02 contains the same orders as MAINT01, this time grouped by workshop.
`
`SAP-00005972
`
`

`
`Archiving
`
`During archiving (reorganization), orders are saved to an external storage medium and
`simultaneously deleted from the data base.
`When archiving, you specify a date as selection criterion. This date is compared with the date the
`orders were last changed. The system selects only those orders that have not been changed
`since this date. The selected orders are then checked to see whether they are to