SD从零开始25 装运的组织单元（Organizational Units in Shipping）

组织结构-后勤Organizational Structure-Logistics

Plant在后勤中扮演重要的角色，plant是一个生产设施或者处理物料库存的特定场所（或者相邻场所的集合），这些单独的场所叫做storage location；库存在storage location的层次上管理；

一个工厂仅分配给一个公司代码，这样，你就能够独立地管理每个公司的库存和库存价值；

组织结构-装运Organization Structure-Shipping

一个shipping point是位于一个固定location的一个独立的组织单元，用于处理和监控outbound delivery以及goods issue，shipping point直接位于client下；

一张outbound delivery在一个单独的shipping point处理；

在订单的item level决定responsible shipping point；

一个shipping point可以处理几个工厂的outbound delivery，只有当工厂位置相邻才有用；

可以为一个plant分配几个shipping point，然而，它们可能有不同的loading equipment或者不同的processing times；

允许的shipping point和plant的组合在企业结构的配置程序中定义；

组织结构-仓库Organization Structure-Warehouse

为了达成有效地处理goods receipt和goods issue，你可以使用如下组织单元：

仓库号码Warehouse number：整个仓库结构通过一个仓库号码来管理，这个号码显示仓库的联合体；

存储类型Storage type：不同的仓库区域，具有不同的组织和技术特征，定义为storage types（例如，high-rack warehouse with random storage, picking warehouse with fixed bins, shipping area）；

采集区域Picking area：采集区域从picking的视角将存储类型中的storage bin组合到一起，它与storage section对等，storage section从putaway的视角将storage bin组合到一起；例如，一张delivery能够分割到不同的采集区域以并行的进行采集；

集结待命区Staging area：货物卸载后或装载前的短暂存储区域；

门Door：仓库的一扇门既可以用于inbound delivery也可用于outbound delivery；

Door和staging area已经在outbound delivey header中定义，它们可依赖于customer自动决定；

仓库号码和工厂/库位的联系Connection between Warehouse Number and Plant/Storage Location

仓库组织单元和MM库存管理的联系发生在给一个工厂和存储位置的组合分配仓库号码；

一个工厂中的几个存储位置能够指向同一个仓库号码，由此从库存管理的不同视角形成了仓库的联合体；

[原创]SD从零开始26 交货中的控制元素（Controling
Elements）

交货类型Delivery Type

Delivery
type控制整个的交货，你可以在delivery header中看到delivery；

Delivery
type考虑delivery processing中的不同的business transactions，标准系统

定义的delivery types包括：

LB：Delivery for
subcontract order；

LD:
Decentralized shipping (used in decentralized shipping in connection with R/2
RV)

LF:
Outbound delivery；

LO:
Delivery without reference (no sales order necessary in order to create a
delivery)；

LP:
Delivery from project；

LR:
Returns delivery；

NL:
Replenishment delivery；

RL:
Returns vendor；

使用控制元素，你可以配置每个delivery type来执行不同的功能；你可以调整标准系统中的delivery types来满足你的业务需求；但是，如果需要大的调整，推荐建立新的delivery type；

交货行项目类别Delivery Item
Categories

Delivery
Item category控制items在shipping process中如何被操作和处理；可用的控制元素提供了高度的自动决定和检查；

你也可以配置item categories来满足你的系统的特殊需求；

从订单复制行项目类别Coping Item
categories from the order

复制订单item到delivery时，系统也复制order item的item category到delivery item；

如果订单的item category或者分配给它schedule line与delivey相关，则为delivery item定义与之相同的item category；

决定交货单中的行项目类别Determination Item
Categories in Deliveries

系统不能为订单独立的delivery items（例如包材）或者不引用订单的deliveries（例如delivery type LO）复制item categories；

在这种情况下，系统根据配置中指定的assignments来决定delivery的item category；为了决定item category，系统考虑delivery type以及item物料主记录中的item category group；

为一些functions内在地设置了附加用法，例如：

PACK
for generating packing items；

CHSP
for a batch split；

PSEL
for product selection；

对于由这些functions产生delivery items，系统能够决定不同的item category；

复制控制Copying control

在coping control table中你指定：

哪些销售分销凭证类型能够复制到哪些delivery类型；

哪些item categories从引用凭证中复制；

什么条件下数据从订单复制到outbound delivery；

什么条件下几张订单可以合并到一张outbound delivery；

哪些数据将要传递；

参考是否应该记录在凭证流中；

具有相同shipping criteria的到期交货的订单行项目一起出货；必须的shipping criteria包括shipping point、the route、ship-to party；标准系统中的某些shipping criteria是可选的并且可以作为splitting criteria从copying control table中移除；

你还能够定义附加的splitting criteria，如果定义的fields有不同的值则不允许joint shipping；

销售中出货相关的配置Shipping-relevant
Customizing in Sales

你通过指定以下内容来控制订单类型：

为outbound delivery带出哪个delivery type；

订单中是否带出一个请求的交期以及在未来多长时间；

当订单保存时是否在后台自动创建outbound delivery；

Order
item category level的delivery relevance仅对text或者value items有效；例如你可以设置一条text item与delivery相关，则它会从标准订单复制到outbound delivery并且记录在delivery note中；

使用接口到MM库存管理模块的实际交货只有在使用schedule lines时才可能发生；这就是为什么在标准情形下order item category必须允许schedule lines并且schedule line
category必须设置为relevant for delivery；

Goods
issue移动类型（或者return deliveries的goods receipt移动类型）定义在schedule line
category level；

[原创]SD从零开始27 订单中装运相关的功能

装运点决定Shipping Point Determination

每个订单行项目都会决定一个shipping point；系统会自动带出一个shipping point，你可以在有限的范围内修改；

Shipping
point依赖于以下条件：

为每个订单行项目确定的delivering plant（从客户-物料信息记录，ship-to party record，或者物料主记录）；

Shipping
requiements（例如，快递）包含在shipping conditions字段中；

必须的装载设配包含在物料主记录的Loading Group字段中；

如果为sales document type分配了一个shipping condition，则shipping condition从销售凭证类型带出，否则，从sold-to party的主记录中带出；

一张outbound delivey总是由一个shipping point处理，你不能修改outbound delivery中的shipping point；

当一张订单由shipping point处理交货时，系统只复制为该shipping point定义的订单行项目到outbound delivery中，因此，具有不同shipping point的order items不会copy到同一张outbound delivery；

路线定义Route Definition

Route定义了出货的路线以及其他的因素，例如运输方式和运输服务代理商；

一条路线可由许多阶段（stages）组成，一个阶段可以是a leg, a load
transfer point, or a border-crossing point；

你必须定义legs以及load transfer points和border-crossing
points的起点和终点作为运输连接点（transportation
connection point）；

你可以定义任何的location作为运输连接点，你也能够引用客户，供应商或者特殊的组织单元如shipping point或者plant；

为了shipping的目的，可能使用不是由stages组成的routes就足够了，在这种情况下，你可以使用目的区域作为route的名字；但是你应该指定transit and
transportation lead times因为这些时间用于制定运输计划；

Route可用作deliverying process的选择标准（selection criterion）；

在R/3系统中，route也是运输和对外贸易必须的，在这些情况下，你可能需要维护额外的数据；

路线决定Route Determination

路线决定在订单行项目上执行并且依赖于：

Shipping
point的国家和启程地域（departure zone）（配置中分配）；

Sales
document type中定义或sold-to party中输入的shipping condition；

分配给物料的transportation group；

Ship-to
party的国家和运输区域（transportation zone）（客户主记录中分配）；

你可以手动修改订单行项目中决定的route；

你可以基于重量（weight）在outbound delivery中重新决定route，是否重新决定route依赖于delivery type的配置；

计划Scheduling

当你创建一张订单，系统能够决定基于客户要求的delivery date的物料可用日期；需要交货的货物必须在该时点及时可用于shipping；

Scheduling考虑以下的时间：

Transit
time：Time required in
order to ship a delivery to the ship-to party；

Loading
time: Time required for loading the goods；

Pick/pack
time: Time required for picking, packing, and so on；

Transportation
lead time: Time required for organizing the transportation；

接下来，系统在订单中执行反冲排程（backward scheduling），如果结果是过去的日期，则系统执行前向排程（forward scheduling），这需要确定一个新的请求交货日期；这同样发生在物料在物料可用日期时不可用的情况；

当你创建一张outbound delivery之后你可以再次执行前向计划，这种情况一般用于当订单中决定的物料可用日期处于创建outbound delivery之前（创建订单时延迟），你可以为每个delivery type指定是否重新排程；

对于每个shipping point，你决定系统是否执行精确排程或日排程；当你为shipping point维护了“working hours”，排程根据working hours来执行并且结果显示至分钟；

交货排程Delivery Scheduling

Delivery
scheduling包括pick/pack time和loading time，这些时间依赖于交付订单项目的shipping point；

你可以为每个sales document type指定是否执行delivery scheduling；

对于每个sales document type，你还可以定义是否只有pick/pack itme（不是loading time）在交货排程中考虑；

还可以为每个shipping point定义pick/pack time和/或loading time是否应该被考虑；

你能够选择为pick/pack time和loading time定义的全局时间在shipping point level是否足够或者是否应该使用基于更多标准的更详细的时间定义；

这些标准包括：

Shipping point；

Weight group（for pick/pack time）或者loading group（for loading time）：来自物料主记录；

Route（可选）；

如果route不是为决定pick/pack time和loading time的一个必要标准，你可以进行适当的设置；在这种情况下，在scheduling table中输入的route应该是空白；如果你使用不同的运输方式，这对于在不同的routes间区分是有意义的；

运输排程Transportation
Scheduling

Transportation
scheduling包括决定transit time和transportation lead
time；两个时间区间都从订单项目决定的route中带出；

你可以为每个sales document type定义是否执行运输排程；

你可以为route指定不同于为shipping point指定的日历，这使你能够定义，例如，某些routes能够在周六使用；

精确排程和日排程Precise and Daily
Scheduling

在精确排程中，系统计算和显示排程的结果到分钟；在日计划中，系统使用天，小时和分钟来计算，但仅显示结果日期；

你可以决定系统为每个shipping point使用哪个scheduling logic，如果你已经为shipping point维护了working times，系统执行精确排程；

Shipping
point的working hours由一个日历（该日历须与shipping point中存储的工厂日历一致）和一个班次顺序组成；shift sequence定义了每个工作日的班次，班次定义了开始和结束工作的时间；

在精确排程中，pick/pack和loading时间指定为小时和分钟，在排程中要考虑shipping point的工作时间；

Route用来决定transportation lead
time，精确排程使用shpping point的working time，日排程使用shipping point的factory
calendar；

Route还用来决定transit time，两种类型的排程都使用route的factory calendar来决定route何时开始；

外向交货单中的用户定义的日期User-specific Dates
in the Outbound Delivery

除了在排程中决定的日期，系统允许你创建用户指定日期来控制delivery process；你可以在outbount delivery中为用户指定日期输入计划和实际值以及location
specification和variance reasons；说明可以用天/小时/分钟；

例如，你想要在系统中记录运输代理商执行delivery的实际日期，为此，你可以创建一个“actual delivery date”；计划日期是系统决定的delivery date并且一个不同的日期可以连同差异原因一起存储；

MARK：系统执行排程时不考虑用户指定日期，它们仅用来存储交货处理中附加的相关信息；

路线排程Route Scheduling

你可以使用一个route schedule来组织从一个特定的shipping point到不同的ship-to party（例如，客户或者子公司）的有规律的和经常按相同route次序发生的outbound deliveries；

Route
schedules也可用作shipping process中的单个steps选择标准，例如你能够为属于相同route schedule的所有deliveries一起拣货；你可以从交货监控形成一组deliveries；

Route
schedule基本地包含：

A
route；

A
weekday as thedeparture dateand adeparture time；

A
list ofship-to parties；

Optional:
Anitinerary；

       你可以在销售订单，库存转移订单和外向交货单中使用route schedules，系统自地动确定它们；

创建外向交货单的选项Options for Creating Outbound Deliveries

你可以手动地创建outbound delivery引用或者不引用特定的订单，然而如果你手动创建delivery，你不能delivery采购订单或者其他的requests；

如果你使用集中处理（delivery list），你可以为所有类型的shipping documents交货，在这种情况下，系统自动地创建若干的outbound deliveries，这可以在线处理也可以后台处理；

交货清单Delivery List

Delivery List是需要交货的所有交易的清单；

你使用不同的标准选择凭证来集中处理delivery，下一步，系统自动创建outbound deliveries；如果shipping criteria相同，系统合并这些凭证到一张outbound delivery；反过来，系统分割一个交易到几张outbound deliveries；

你可以用delivery scenarios来为不同的deliveries业务流程建模；当你处理delivery list，你仅需要选择一个scenario；

交货场景的例子Examples of Delivery
Scenarios

一个delivery scenario模型化了为交付货物以满足不同的类型订单的一个业务流程；例如，有一个delivery scenario允许你按照行项目来完成SD订单的deliveries；该dilivery scenario已经在系统中定义；

由Delivery process产生的requirements用user roles（也叫做list profiles）来建模，它们使你能够调整你的delivery list处理，它们让你控制selection的范围，delivery list的显示，the type of delivery等等；

在标准系统中，为每个delivery scenario分配了一个user role；你能够在配置中维护user roles；

如果用户经常或一直使用相同的scenario，则可以将它设置为用户的default scenario；

选择和显示交货单Selection and
displaying the delivery list

选择到期交货单的不同的标准显示在tabstrips；tabstrips的数量和选择标准因不同的 delivery scenario和user role而不同；

用户可以在用户自定义scenario中定义变量并由此创建了用户自定义的选择条件；

当你创建了你的选择后，系统根据你的选择条件显示应该交货的所有凭证的清单，user role中的设置还会影响到清单的显示；

在清单中有许多的ABAP list viewer功能可用，例如排序、求和以及筛选；

从这个清单，你能够在线创建deliveries或者在后台创建并跳转到相应的凭证；

当你通过访问display variants来使用清单时，你也可以修改该list的显示；

决定拣货位置Determining the
Picking Location

如果订单项目中没有指定拣货的storage location，系统在创建outbound delivery时决定storage location并复制到delivery item；订单项目中输入的storage location复制到outbound delivery；

系统基于delivery type中定义的rule来决定picking location；标准系统提供的rules：

MALA：取决于shipping point，deliverying plant，物料主记录中定义的物料的storage condition；

RETA and MARA：主要用于贸易场景；

你也可以为picking location
search定义自己的rules；

为每个delivery item type激活Picking location
search；

修改和添加外向交货单Changing and Adding
to the outbound Delivery

Delivery凭证保存后你可以修改或添加；但是你应该确保像ship-to party和shipping point这样的信息一旦你创建了outbound delivery之后是不可更改的；

例如，你可以添加项目到outbound delivery，这些项目可以引用其他订单（deliver order
function），对于增加订单项目，应用和在集中处理中合并订单相似的分割标准；

你还可以添加独立于订单的项目到outbound delivery；对这样的item，系统使用通常的rules（见Controlling Elements
of the Outbound Delivery）来决定item type；

不完全项目日志Log of Incomplete
Items

如果你调用不完全项目日志，系统检查outbound delivery中的数据是否完全；从生成的清单，你可以直接跳转到维护不完全fields的屏幕；

你可以从delivery processing中调用log of incomplete
items，或者用一个特殊的报表来选择incomplete delivery
documents，这会产生一个需要处理凭证的清单；

在outbound delivery中，系统可以在header和item层同时检查完整性；

在配置中，你能够控制哪些字段如果不输入会导致outbound delivery不完整以及这对后续的活动如picking，packing，goods issue，billing会有哪些影响；（例如，如果item中的volume缺失，picking可能不被允许）；

导致delivery不完整的字段选择依赖于delivery type和delivery item
category；

另外，你可以使用相应的配置功能来设置partner function和texts为必须的；如果凭证中必须的partner function的指定是空的或者必须的text不存在，则会输入一条记录到log of incomplete
items；

外向交货单监控Outbound Delivey
Monitor

外向交货单监控清单显示了所有需要处理的或者已经处理的deliveries；

你可以从众多的标准中选择来筛选需要的凭证；系统显示所选择outbound delivery的清单，然后你可以在这张清单执行后续的功能；这包括处理shipping的output type，像delivery note；另外，你可以调用delivery environment的信息；

你可以为选择和显示凭证定义user-specific variants（选择变量或显示变量）；

你还可以使用外向交货单监控来为多个清单在后台一起执行重要的后续功能（例如，为picking创建transfer orders，或者posting goods issue）；