Billing type controls

SD document category:
A classification for the different types of documents that you can process in the sales and
distribution system (for example: quotations, sales orders, deliveries, and invoices).
Use
The document category determines how the system stores and eeps trac of document data.
!t enables the system to provide you with status information about delivery processing,
billing, and documents that are used for reference (for example, inquiries and quotations).
Posting Block:
"loced for transfer to accounting
!ndicates whether the system blocs automatic transfer of the billing document to accounting.
#rocedure
To bloc automatic transfer of the billing document to accounting, mar the field.
$ote
%uring document processing, you can manually transfer bloced billing documents to
accounting by selecting:
Billing &' Change &' Release accounting
Transaction group
A grouping that allows you to control certain features of transaction flow by sales, shipping,
and billing documents.
(se
The transaction group controls
)hich sales document types you can process with which system transactions during sales
order processing
*or which sales, shipping, and billing documents the system updates indexes for reporting
purposes
$ote
The transaction group that you assign to a transaction must match the group that you assign to
the respective document type. !f you leave the field blan when you define the document
type, the system does not chec for a transaction group.
Statistics
(pdate statistics
!ndicates whether the system stores information from billing documents of this type for the
purposes of statistical analysis.
#rocedure
!f you want to generate statistics using data from this billing type, mar the field.
Billing category
(sed to differentiate the billing documents by requirements for:
invoice printing (selection criterion)
billing document creation (selection criterion)
forwarding to *inancial Accounting
Document Type
The document type classifies the accounting documents. !t is stored in the document header.
Attributes that control the entry of the document, or which are themselves noted in the
document, are defined for each document type. !n particular, the number range assigned to
the associated documents is defined on the basis of the document type.
Negative posting
!ndicator that causes the transaction figures to be reset for a document item.
!f the indicator is set, then the transaction figure update is changed. A correspondingly set
posting on the debit side reduces the credits side of the account. A credit posting reduces the
debit side of the account.
(se
The indicator can be entered in billing types for credit memos and cancelations. !t only has
the required effect in *!, if the company code permites negative postings
Branch/head office relationship
The indicator controls which partner functions of the billing document can be forwarded to
*inancial Accounting
initial : !f the payer is different to the sold&to party, the payer is transferred to *inancial
Accounting as the customer and the sold&to party as the branch. Any branch+head
office relationship stored in *! is ignored.
A : The sold&to party is forwarded as the customer. Any branch+head office relationship
stored in *! for this customer is taen into account.
" : The payer is forwarded as the customer. Any branch+head office relationship stored in
*! for this customer is taen into account.
$ote:
!f the credit limit chec is active, the system always reacts as described in the entry ,initial,,
regardless of the setting.
ebate Settlement ! Billing type for rebate processing
!ndicates whether the billing type is used exclusively during rebate processing.
(se
!f you create a billing document of this type as the final settlement of a rebate agreement, the
system indicates in the agreement that the rebate has been completely paid.
$ote
!f you need to correct a rebate settlement, you can either correct the amount of the accrual or
you can ad-ust the statistics for the rebate settlement.
elevant for ebate:
Billing document is relevant for rebate processing
!ndicates whether billing documents of this type are relevant during rebate processing.
Use
!f you mar this field, the system uses the value of billing documents of this type to ad-ust the
sales revenue attributed to a customer. The sales revenue forms the basis for calculating
rebates for customers with whom you have rebate agreements.
"#ample
.ou can specify, for example, that debit memos of a certain ind are not to be taen into
account for purposes of rebate processing. !n this case, the value of such debit memos will
not affect a customer,s sales revenue and subsequently not affect any rebates the customer
receives.
Notes
This indicator must also be set for the billing types for rebate settlement (such as final
settlement, partial payment, rebate correction or manual accruals).
/ebate payments for a rebate agreement never affect the sales revenue of other rebate
agreements, regardless of whether the rebate payments are sub-ect to volume&based rebate or
not.
Delivery Te#t: 0opy texts from delivery note
Schedule line controls:
Delivery block
1pecifies a delivery bloc that the system applies automatically during processing.
(se
.ou can specify a delivery bloc for any of the following:
1ales document type
1chedule line category
%elivery type
1hipping activity, such as picing and goods issue
2xample
.ou can specify a delivery bloc, for example, for all free of charge deliveries. These
documents then have to be approved before further processing can tae place.
$tem is relevant for delivery
!ndicates whether the item that is related to a schedule line is relevant for delivery.
2xample
!f a sales order item is relevant for delivery, so are the schedule lines that belong to the item.
1chedule lines that belong to an item in a quotation are not relevant for delivery
%rder Type &Purchasing'
!dentifier allowing differentiation between the different inds of requisition and purchase
order in the 1A# system.
(se
The order type controls the number assignment for a purchase order, for example, and
determines which fields you must maintain.
$tem (ategory in Purchasing Document
!ndicator which shows the item features.
Use
The item category controls whether the following entries and procedures are necessary or
permitted for the item:
material number
additional account assignment
inventory management in the 1A# 1ystem
goods receipt
invoice receipt
2xample
!n the standard system an item in the 3normal3 category requires goods and invoice receipts.
4n the other hand for items in the 3 consignment3 category, (that is order item for
consignment material) invoice receipts are not allowed.
)ccount )ssignment (ategory
1pecifies whether accounting for an item is to be effected via an auxiliary account (such as a
cost center).
(se
The account assignment category, which can be specified when maintaining schedule line
categories, only concerns schedule lines relevant to #urchasing. !t is the account assignment
category of the purchase requisition that is to be created. !t must be strictly differentiated
from the account assignment category of the sales order item, which is derived from the
requirements class.
$ncompletion procedure for sales document
The number that uniquely identifies the incompletion procedure. The incompletion procedure
defines a number of fields in which the user must enter information.
(se
The system uses the incompletion procedure to determine which fields appear in the
incompletion log when the user does not enter information during sales order processing. !n
1% 0ustomi5ing, you can specify an incompletion procedure for each type of sales document.
2xample
6alidity periods and customer purchase order numbers are required entries for both contracts
and scheduling agreements. !n this case, the system automatically proposes the same
incompletion procedure for both types of document.
Transfer of re*uirements / Begin assembly order from SD
Transfer of requirements is to be carried out for the respective transaction.
The selection of this indicator is the precondition for transfer of requirements. .ou can
deactivate transfer of requirements at schedule line level. 0onversely, it can simply be left
inactive at schedule line level, as long as it is not already activated in the requirements class.
2xample
.ou do not set an indicator for maintaining the requirements class: Transfer of requirements
is not carried out, irrespective of the specification you mae at schedule line level for the
transaction.
.ou set an indicator for maintaining the requirements class: !n this case you can still decide at
schedule line level, whether or not you require transfer of requirments for the relevant
transaction.
)vailability check for sales
.ou must carry out an availability chec for the following transaction.
The indicator is determined as a proposal in con-unction with the respective requirements
type. !t can be changed in individual shipping transactions. 7owever, only one restriction is
effective.
2xample
.ou do not set an indicator for maintaining the requirements type. !n this case, no availability
chec is carried out. This is independent of the selection in the respective transaction.
.ou set an indicator for maintaining the requirements type. !n this case you can decide
whether or not you require an availability chec for the relevant transaction.
Product allocation active
#roduct allocation active
Delivery Types:
Default order type
Default order type for deliveries +ithout reference to order
The default for a 3pseudo3 order type for deliveries or delivery items that do not refer to an
existing order.
(se
)hen you create delivery documents that do not refer to existing orders, you must provide
some of the control criteria that are normally copied from a sales document header into the
delivery document.
2xample
A delivery document, for example, needs information about which item types need to be
defined.
#rocedure
.ou can define a pseudo order type in Table T6A8. )hen you create a delivery that does not
refer to an existing order, the system automatically uses the pseudo order type.
e*uirement for item that does not refer to a sales order
!dentifies a requirements routine for a delivery item that does not refer to a sales document.
The delivery item must meet the requirements of the routine before it can be further
processed.
(se
.ou can create your own routines according to the needs of your organi5ation.
2xample
%uring delivery processing, you may want to create delivery items for returnable pacaging.
.ou may also want the system to process these items and, for example, eep trac of stocs
of the pacaging material. .ou can create a routine that identifies such items and processes
them accordingly.
ule for determining the storage location for picking
1pecifies how the system determines the picing location when you create a delivery without
entering a storage location for the items.
Te#t determination procedure
!dentifies a group of te#t types that you can use in, for example, a sales document header.
The text procedure also determines the sequence in which the text types appear in the
document.
2xample
The text procedure for a sales document header could include the following text types:
A standard header text that the system automatically includes in the document
1tandard terms of delivery
1tandard terms of payment
Ne+ route determination: +ith or +ithout a check,
1pecifies whether, during delivery processing, the system uses the route that is determined
during sales order processing or whether it determines a new route.
(se
!f you want to manually change the route during delivery processing, you can also specify
whether you want the system to chec the validity of the new route. The system checs the
route against table T/4A9, which lists the routes that the system permits as actual routes in
delivery processing.
$ote that, if the system automatically determines a new route, the system does not carry out
an additional chec of this new route against table T/4A9.
Partner Determination Procedure
A grouping of partner functions. The procedure specifies which partner functions are
allowed for a particular business transaction (for example, for processing a sales order) and
which of those partner functions are mandatory.
(se
.ou define partner determination procedures in 1% 0ustomi5ing through Functions &'
Partner determinat.
!n sales documents, for example, you can specify the partner determination procedure
according to sales document type and item category. %uring order entry, the system
first proposes partners from the customer master record of the sold&to party. !f this
information does not exist in the customer master, the system automatically proposes
the mandatory partners from the partner determination procedure that you specify in
the document header.
*or billing documents, for example, you can specify a partner determination procedure
where the sold!to party, bill!to party, and payer are mandatory but the ship!to
party is not (for billing, you are more interested in who orders and pays for the goods
than in who receives them).
Perform Delivery Split )ccording to -arehouse Number
(sing this indicator you can control, in addition to the indicator for the delivery split, whether
a delivery split must be for one warehouse number only. !f both indicators contain an :, only
items are contained in the delivery whose storage location matches the delivery number
entered in the header. )hen you process the delivery&due list, setting the field to : causes a
delivery split, that is, items of different warehouse numbers are split up among different
deliveries.
Delivery Split for )dditional Partners
This indicator controls the systems, split behavior when delivering preceding documents that
are assigned to different partner functions.
2xplanation
%uring the checs to see whether two preceding document items can be collected in one
delivery, the following criteria are valid with reference to the partner data:
A delivery split always occurs when the preceding items are assigned to the same partner
functions but different partners. The delivery is also split when the partners are the
same but have different addresses.
!f one of the two items to be collected as a freight forwarder as an additional partner
function, then a delivery split always taes place and the items cannot be delivered in
a -oint delivery. This system behavior also taes into account the prominent role of the
freight forwarder in the delivery process.
!f the additional partner function in one of the items is not a freight forwarder, then the
items can be collected into one delivery, and the additional function is copied into the
header of the -oint delivery.
!f you do not require this system behavior, you can use the indicator to force a
delivery split.
(se
1et this indicator if different partner functions in the preceding items to be delivered should
always cause the system to perform a delivery split.
)utomatic packing using packing proposal
!f this field is checed, the automatic pacing proposal is retrieved when a delivery is created.
All items will be paced.
.eneration of Delivery $tems for /U Packaging 0aterials
.ou can use this indicator to dictate whether you want to permit generation of delivery items
for pacaging materials in deliveries of this delivery type.
!n the pacing function, you can control whether item generation occurs for particular
pacaging materials. .ou can mae this setting for each pacaging material type.
.ou can use pacaging&material item generation to bill pacaging materials to customers or
to maintain pacaging materials in inventory management. 1A# recommends that you only
implement item generation in goods receipt and goods issue.
.eneration of Delivery $tems for /U Packaging 0aterials
.ou can use this indicator to dictate whether you want to permit generation of delivery items
for pacaging materials in deliveries of this delivery type.
!n the pacing function, you can control whether item generation occurs for particular
pacaging materials. .ou can mae this setting for each pacaging material type.
.ou can use pacaging&material item generation to bill pacaging materials to customers or
to maintain pacaging materials in inventory management. 1A# recommends that you only
implement item generation in goods receipt and goods issue.
eschedule deliveries
.ou can control whether a redetermination of shipping deadlines should be run for
baclogged deliveries using this indicator.
%uring rescheduling, it is assumed that the activities that are to be carried out for the baclog
delivery can begin on the current day at the earliest. The new shipping deadlines are
redetermined from the current date using forward scheduling.
#rocedure
1et the indicator to ,:, if you want to reschedule baclog deliveries.
!f the indicator is set to ,., deadlines are redetermined even if there is a change in the routes
that were transferred from the order, or if a new route plan is determined.
!f the indicator is set to ,A, then the deadlines are also redetermined for the criteria entered
under ,., even if a new weighting group is determined when you create or change items.
!f this indicator is not set, the deadlines are copied directly from the order with no changes.
Delivery $tem category:
0aterial number 1ero allo+ed
0ontrols whether it maes sense to enter an item in the 1% document with this item category
without specifying a material.
(se
!t would mae sense to set this indicator for text items.
Statistics group for the item category
%efinition
1pecifies a statistics group for this item category and helps determine which data the system
updates in the logistics information system.
(se
.ou can assign statistics groups to each of the following:
!tem category
1ales document type
0ustomer
;aterial
)hen you generate statistics in the logistics information system, the system uses the
combination of specified statistics groups to determine the appropriate update sequence. The
update sequence in turn determines for exactly which fields the statistics are generated.
Stock determination rule
!ndicates the stoc determination rule.
The stoc determination rule and the stoc determination group are combined into one ey
for the stoc determination strategy.
.ou define which business process uses which rule in 0ustomi5ing for each application.
(se
The stoc determination rule has to be specified in the repetitive manufacturing profile of the
assembly before a stoc determination rule can be executed for the component.
(hecks for 1ero *uantity
1pecifies whether you can create an item that has a 5ero quantity and, if you do, how the
system reacts.
2xample
!f, for example, in a delivery without reference to a sales order, you create an item and enter a
material without a delivery quantity, the system gives you a warning before you can continue.
(heck minimum *uantity to be delivered
1pecifies whether the system checs the minimum delivery quantity, and, if so, determines
how the system reacts if the minimum is not met.
(se
.ou can specify the minimum delivery quantity in the
;aterial master record
0ustomer&material info record
The value you enter in the 0hec ;inimum <uantity field determines whether you receive a
warning or an error when the minimum quantity is not met. !f you leave this field blan and
have specifed a minimum delivery quantity, the system gives you a warning anyway.
(ontrol for checking for overdelivery
1pecifies how the system reacts when, during delivery processing, you exceed the original
order quantity.
(se
*or each delivery item category, you can specify whether the system checs for overdelivery
and, if so, whether you receive a warning or error during delivery processing. !f you have
specified an overdelivery limit in the sales order or in the customer&material info record, you
can use this indicator to control how the system reacts.
S+itch off availability check for delivery item
ounding indicator for +hole!number units of measure
!f decimal places are created from arithmetical operations with quantities with whole
numbers, this indicator controls whether or not the numbers are to be rounded, and, if so,
how.
This can be used, for example, for the correlation of multi&level bills of material in the
delivery if the non&availability of a particular partial "4; in another partial "4; were to
cause decimal positions.
elevant for picking or puta+ay
!ndicates whether delivery items of this type are relevant for picing or putaway.
(se
!n the case of outbound deliveries, only the delivery items that are relevant for picing are
transferred to the )arehouse ;anagement ();) component. 0ertain items such as text items
or service items (consulting activities) are not relevant for picing.
!n the case of inbound deliveries, this indicator controls whether the item is relevant for
putaway. This indicator must be set in order for the item to be included in a )arehouse
;anagement transfer order and then put away.
Storage location is absolutely necessary
!ndicates whether, during delivery processing, you must enter a storage location before you
can completely process delivery items of this type.
Determine storage location
!ndicates whether the system automatically determines a storage location for the delivery
item.
$ndicator: Do Not (heck Storage 2ocation
!ndicates whether the system should run a chec for the storage location that was determined.
This chec determines whether the material for that storage location has a corresponding
segment.
#rocedure
1elect this field if you do not want the system to perform this chec.
(se
!t is a good idea not to run this chec if the material for the storage unit that was deterimined
has not been created yet or if the material in question needs a storage location without a
storage location segment (a retail value&only article, for example).
$D: No batch check
0ontrols whether the system checs that the batch entered in the delivery exists.
#rocedure
!f you do not want the system to chec the batch, select the field.
(se
!t maes sense not to carry out a chec if the batch entered does not (or does not yet) exist in
the system. This happens, for example, when you create an inbound delivery. The same
applies if you use wor with the /+=&/+> lin and the batch only exists in the local system.
)utomatic batch determination
#rocedure
!f you want to use automatic batch determination for materials handled in batches with the
specified item category, activate this field.
(se
)hen you enter a material handled in batches in a sales order or in a delivery to which an
item category with this indicator is assigned, the batch or batches of this material that match
the customer,s requirements are determined automatically.
Packing control
!ndicates whether delivery items with this item category may be paced, cannot be paced, or
must be paced.
(se
!n the case where items must be paced, they must be processed for pacing before goods
issue.
Pack accumulated batches / movement type item
1pecifies if for a batch material only the main item with the accumulated batch quantity is to
be paced in the delivery, or if only items in which the batch is recogni5ed can be paced.
!f the field is not set to its initial value, only the main item will be paced.
(se
)hen this indicator is set, deliveries can be paced automatically, even if no automatic batch
split occurred.
$otes
!f a storage location is 7(&managed, that characteristic overrides this indicator. !t is not
possible to pac anything in the delivery regardless of its batch if handling&unit inventory
management is in use.
Te#t determination procedure
!dentifies a group of text types that you can use in, for example, a sales document header. The
text procedure also determines the sequence in which the text types appear in the document.
2xample
The text procedure for a sales document header could include the following text types:
A standard header text that the system automatically includes in the document
1tandard terms of delivery
1tandard terms of payment