11企业物流管理信息系统课件.ppt

1、企业物流管理信息系统1、企业基本资料2、系统目标3、需求分析4、重要流程5、重要功能1、企业基本资料生产销售型的集团企业生产分布在全国的多个地区在全国建立有比较完善的销售体系，销售人员占整个企业的比例较大销售体系中可以代销其他企业的同类商品产品包括：家电类、计算机等信息产品1、企业基本资料家电生产企业网络产品生产企业通信类产品生产企业销售公司计算机生产企业集团公司产品生产隶属关系产品销售隶属关系家电网络产品通信产品销售公司计算机区域销售分公司直属销售分公司省级销售公司省级销售公司经营部仓库仓库经营部经营部仓库仓库经营部区域销售分公司：华北、东北、华中、华东、西北、西南、华南直属销售分公司：广东

2、、山东、新疆、四川、海南、江西、广西1、企业基本资料存在问题：一种典型的“垂直型”的销售架构各个分公司、直属公司之间的销售货物不能互相补充仓库的产品调配只能由上级公司负责各个仓库之间不存在联系商品的供应、冲红、退货由上级公司负责经营部事业部销售中心客户分公司销售公司总部分公司产品部集团机构模式下单机构审单机构总部客户分公司事业部经营部分公司产品部大客户分公司TULIP机构模式机构模式需求分析TULIP由执行和计划两大系统组成。TULIP执行系统实现了分销物流流程中的流程闭环处理以及运作数据的采集，统计，和可视化；TULIP计划系统将管理和支持网络整体库存的优化工作。需求分析第一阶段经营部在网上

3、按照发货要求（自提或配送）填写要货订单经营部在网上填写冲红申请单事业部计划员根据业务情况审核经营部提交的订单事业部计划员审核经营部提交的冲红订单RDC管理员根据收发货指令进行仓库作业运输管理员根据订单指令进行运输作业。需求分析第二阶段CDC库存管理补货计划管理RDC调拨计划管理干线运输管理 在第一阶段基础上提出一个流程优化，支持多产品，计划信息平台解决方案 第一阶段流程订单处理流程订单管理模块实现客户订单的输入，提交；订单接收方的审核，订单执行；订单运作信息的实时查询；订单冲红的输入，审核和实现；以及订单状态的实时查询。订单管理模块完成订单从产生到签收完毕之间的完整闭环的信息处理。主要使用者为

4、经营部和事业部（分公司）的计划员。订单处理模块功能新建订单新建订单 修改订单修改订单 取消订单取消订单 订单冲红订单冲红 订单锁定订单锁定 计划员审批订单计划员审批订单 订单查询订单查询 订单打印订单打印 打印财务签字审核审核打印联单客户RDC分公司物流部（事业部）经营部客户出库操作接收到货信息验货签收作废要货申请传真YNYN承运商财务开单签字确认R D C联运输操作配送联录入Tulip经营部计划员 库存查询 库存的查询是经营部计划员作为填写订单的一个重要条件，系统可以提供经营部计划员随时在网上查询库存情况，其中库存分为两大类型（）正常品和（）残次品。正常品是指能够下达订单要货的物品。残次品是

5、指未经过修复不能直接下达订单要货的物品。经营部计划员 填写订单 经营部计划员直接从客户或通过业务员收集和汇总客户订货信息,经财务审核后，如果库存满足订单需求,就开始填写订单。由于所填写的订单中的要货信息是经过经营部财务审核后的，所以被视为有效，合法的订单，在订单提交并审核后后不得随意提出冲红请求，此项可以视为经营部的考核标准之一。为了配合物流改革的模式，经营部填写完订单提交之后，系统会检查该张订单是客户订单还是经营部自己的订单，如果是客户订单，系统可用库存随之减少。如果是经营部自己的订单，系统本着客户订单优先要货、尽量减少经营部要货的原则，不会根据订单的数量来删减可用库存，直到事业部计划员审核

6、该张订单后库存才会减少。在系统未完全取代手工操作之前，经营部计划员要将订单打印出来交经营部财务签字确认后将该订单传真至分公司等待审核（待到运行稳定后将取消传真的操作，订单转为完全电子化）以保持订单的严谨性.这时经营部计划员要及时登录到系统查看订单的状态，当发现提交的订单分公司已审核，经营部财务要依此订单在财务系统上开单。输入：要货信息 输出：订单 经营部计划员 查询订单经营部计划员或业务员可以随时在网上查询订单的状态（未审核、已审核、安排运输、在途、签收）。取消订单当经营部计划员需要取消所下的订单时首先在网上查询订单的状态，如果该订单未被审核系统允许取消订单，可用库存量随之增加。如果该订单已经

7、被审核则无法进行取消操作，而要进行冲红处理。订单冲红 当订单被事业部计划员审核之后，经营部如果有订单变更或取消的业务需求时要进行冲红操作。事业部计划员会酌情进行部分冲红或全部冲红的审核工作，具体要求参考事业部计划员冲红审核（分公司）。打印订单 经营部计划员 客户管理 经营部可以自主管理属下的客户，在新建订单时需要的客户信息全部在该功能中提前输入，为了保证历史数据的一致性，所有录入的客户资料系统不提供删除功能，对于需要删除该客户的要求系统提供停用该用户的功能，一旦该用户被停用在新建订单时，客户列表不会出现该客户名称，如果情况发生变化该客户又开始参与业务活动，经营部计划员只需要将该用户重新启用即可

8、。事业部计划员（分公司）库存查询库存的查询是事业部计划员（分公司）作为审核经营部订单（客户和经营部自己的订单）的一个重要条件，计划员看到的库存结构与经营部看到的库存略有不同，不但提供的可用库存的信息还提供了实际库存和待出库数量的信息。库存结构公式：实际库存可用库存待出库 实际库存：仓库里真实存在的物品数量 可用库存：能够满足订单需求的物品数量 待出库：已下达订单未进行发货操作的余留数量 事业部计划员（分公司）订单锁定考虑到在分公司层面可能会出现多个计划员审核订单的情况，在审核订单之前计划员必须要对其准备审核的订单进行锁定，这样就防止了多个计划员操作同一张订单的情况发生。操作指引：分公司计划员进

9、入待处理订单列表后选择要处理的订单后面的选定框进行锁定，锁定后进入订单审核功能。事业部计划员（分公司）订单审核分公司计划员在做订单审核时原则上采取见单处理的原则，即要看到经过财务签字的传真件，但考虑到实际情况，如果经营部需要立即审批的货物需打电话向分公司申请后立即审核。在未到订单处理时间点之前经营部可以取消订单，可用库存随之增加。因此当查询到的库存数量不能满足订单需求时每个经营部可以在隔段时间再次查询可用库存是否满足订单需求。分公司计划员在系统过渡期必须见到有经营部财务签章的打印订单传真件作为审核订单的依据。对于经营部提交的订单原则上全部通过，分公司计划员也可根据实际情况对订单的数量进行调整或

10、拒绝该张订单。为了保障经营部能够及时准确的查询到订单的执行状态，要求分公司计划员在第一时间内进行审核操作。为保证传真件和实际的审核数一致，当审核人员对经营部提交的订单数要进行调整时，建议先取消整个订单（拒绝），通知填单人员根据调整数重新填写新的订单，再将新订单传真到分公司。事业部计划员（分公司）订单冲红审核 当订单冲红申请被经营部提交上来后，分公司计划员要根据实际情况进行冲红的审核操作，冲红的对象只限于下达订单未做实际发货处理的部分（只可以冲减余留数量）。订单查询 分公司计划员可以随时在网上查询订单的状态（已审核、安排运输、在途、签收），以便安排自己的工作内容。具体操作方法见用户手册。注：对于

11、未审核的订单因为会存在取消的可能性所有不作为正式订单在订单查询里出现。涉及单证：订单、订单冲红申请单 冲红申请审核签字/盖章3PL3PL分公司物流部分公司物流部经营部经营部接受指令执行指令订单冲红流程作废NY传真计划员执行结果反馈冲红结果接收传真计划员执行结果查询RDCRDC管理模块管理模块 RDC管理模块实现RDC的库存数量可视化管理。它提供仓库出入库指令查询，出入库结果记录，库存实时查询，以及库存和发货的统计和分析。主要使用者为RDC管理员，物流经理，物流运作管理部门，管理RDC的3PL。RDCRDC管理模块功能管理模块功能 计划入库计划入库 计划出库计划出库 非计划入库非计划入库 非计划

12、出库非计划出库 库存查询库存查询 出库记录查询出库记录查询 入库记录查询入库记录查询 出库单、入库单打印出库单、入库单打印 汇总报表汇总报表 RDC售后货到验货确定好坏机Tulip系统非计划入库运输承运商RDC入库入库RDC出库出库承运商RDC 装货开出库单备车分公司RDC联开送货清单分公司承运联RDC仓管员 计划入库 与补货计划的接口功能 非计划入库 非计划入库是为了解决在Tulip2.0系统未实施前代替流程中的部分环节所作的临时功能。目前的仓库入库操作必须全部使用非计划入库来完成。根据不同的入库指令仓库管理员需要先选择入库类型然后才能填写入库单内容。入库类型（补充）补货入库 调拨入库 退换

13、货入库 修还入库 冲红入库 入库类型说明（补充）补货入库：对应补货计划进行的入库操作，仓管员必须并填写相应的补货计划号和发货的CDC名称后才可以进行入库单内容的输入。调拨入库：跟补货计划相同也是为了弥补Tulip2.0为上线前的流程空缺，仓管员选择了入库类型为调拨入库后，必须选择相应的发货仓库的名称和对应的调拨计划的计划好后才可以进行入库单内同的输入。退换货入库：当发生客户退换货需要进入RDC的时候，仓管员先要检查收到的退换货计划的传真件和实物是否一一对应，同时要经过售后部门对物品进行鉴定后按照好坏机区分入库的原则进行入库单的填写，在原单单号栏必须填写退换货计划的计划号，以便日后查对之用。修还

14、入库：当需要将维修好的机器重新入库时将使用到该类型。仓管员在做修还入库时必须将原有的维修出库单的单号录入原单单号的文字栏中以便核对维修出库领用的型号、数量是否可以和入库的型号、数量相对应。做完入库处理，系统会增加好机数量。冲红入库：该出库类型是为了修正非计划入库时产生的填写错误而导致库存不准确的情况而设立的，在填写冲红入库时一定要填入出错的入库单号作为以后核对库存的依据。RDC仓管员 计划出库所有的订单出库都必须为计划出库，在页面上可以看到计划出库的待处理数量，点击进入后就可以看到每一条计划出库指令就是一张订单，考虑到在实际发货的时候会出现余留的现象，计划出库提供了分次执行出库指令的功能，如果

15、根据订单所作的每一次出库没有完全将订单执行完毕，系统会自动将已执行完毕的数量减去并提示需要继续处理的信息。操作指引：仓管员进入计划出库后查看相应的出库指令，点击进入后可以看到出库指令的详细内容，这时需要将出库指令打印出来作为仓库检货的信息指导，待装完货后，填入实际出库的物品数量后提交生成正式的出库单，这个功能是为了防止在实际操作中先生成出库单后由于各种特殊情况无法完成出库单上全部物品的出库操作而产生的出库单冲红现象的发生。RDC仓管员 非计划出库 非计划出库是为了解决在Tulip2.0系统未实施前代替流程中的部分环节所作的临时功能。目前的仓库出库操作除了正常的客户订单使用计划出库外其它类型的出

16、库仓库管理员均需要选择出库类型然后才能填写出库单内容。非计划出库类型（补充）维修出库 返厂出库 调拨出库 冲红出库 非计划出库类型说明（补充）维修出库：当售后服务中心需要将仓库中的坏机进行维修领用时将使用到该类型。仓管员在做维修出库时必须将售后服务中心开具的维修领用单的单号录入原单单号的文字栏中以便日后同维修领用单上标注的型号、数量进行核对。做完维修出库库处理后，系统会减少坏机的数量。返厂出库：该出库类型较少使用，当仓管员接到事业部下达的返厂计划后将使用该类型进行返厂出库。仓管员在做返厂出库时必须将事业部下达的返厂计划的计划号录入原单单号的文字栏中以便日后进行核对。调拨出库：同调拨入库一样只是

17、功能相反，仓管员选择了出库类型为调拨出库后，必须选择相应的收货仓库的名称和对应的调拨计划的计划好后才可以进行出库单内容的输入。冲红出库：该出库类型是为了修正非计划出库时产生的填写错误而导致库存不准确的情况而设立的，在填写冲红出库时一定要填入出错的出库单号作为以后核对库存的依据。RDC仓管员 查询库存 库存的查询是仓库管理员在进行盘点时核对仓库实物数量和系统反映数量的一个重要依据，不但提供的可用库存的信息还提供了实际库存和待出库数量的信息。库存结构公式：实际库存可用库存待出库 实际库存：仓库里真实存在的物品数量 可用库存：能够满足订单需求的物品数量 待出库：已下达订单未进行发货操作的余留数量。注

18、：显示待出库的数量时是为了提醒仓管员还有部分物品是处于余留状态的以便指导其工作。RDC仓管员 查询入库记录 对仓库在任何时段进行的入库进行查询，此功能是为了对日常的入库业务进行数据跟踪而提供的，点击进入后填好查询条件后即可查到业务发生的原始记录，具体操作见用户手册。查询出库记录功能和操作方法同查询入库记录。运输管理模块运输管理模块 运输管理模块实现支线的配送指令查询和运输结果信息的输入和查询，以及运输结果的统计分析。主要使用者：运输承运商，物流经理，物流运作管理部门。运输管理模块功能运输管理模块功能 生成送货清单生成送货清单 送货清单打印送货清单打印 送货清单维护送货清单维护 生成冲红通知单生

19、成冲红通知单运输管理模块功能说明运输管理模块功能说明 生成送货清单生成送货清单根据订单生成送货清单：系统设计的根据订单生成送货清单：系统设计的原则是一张订单可以对应多张送货清单运。原则是一张订单可以对应多张送货清单运。因此输管理员可以根据运力情况来决定是一因此输管理员可以根据运力情况来决定是一次还是多次执行该订单，如果分次执行该订次还是多次执行该订单，如果分次执行该订单则系统会在下一次生成送货清单时将以发单则系统会在下一次生成送货清单时将以发运的数量减去直到完全执行完订单的数量为运的数量减去直到完全执行完订单的数量为止。止。运输管理模块功能说明运输管理模块功能说明 维护送货清单发运工作开始后，

20、维护送货清单便成为订单执行情况跟踪的数据源 车辆离开中转仓后，中转仓仓管员通知物流经理货已出库的信息。物流经理便可以在网上随时监控订单的执行情况。当货物在途中时运输管理员可以不断的对到达时间和途中发生的情况进行修正，这些改动会立即在网上体现出来，以便物流经理可以随时的掌握货物的动向。货物到达目的地后，收货方在随运输人员到达的送货清单上填写实际收货数量。运输人员可以实时也可以事后将这些信息反馈给运输管理员。运输管理员将这些信息录入系统后，签收的信息随即体现出来。运输管理模块功能说明运输管理模块功能说明 生成冲红通知单生成冲红通知单如客户签收的货物数量与送货清单上的如客户签收的货物数量与送货清单上

21、的货物数量不相等，系统自动显示该页面，让运输货物数量不相等，系统自动显示该页面，让运输公司填写冲红通知单，主要用于记录货物运输过公司填写冲红通知单，主要用于记录货物运输过程中发生货损、货差的状况。程中发生货损、货差的状况。该功能是由系统自动完成的，如果客户该功能是由系统自动完成的，如果客户的签收数量与实发数量不符，则系统认为产生了的签收数量与实发数量不符，则系统认为产生了货险，自动打开货险冲红功能，由运输管理员填货险，自动打开货险冲红功能，由运输管理员填写货损原因后提交，系统自动会生成货险冲红挂写货损原因后提交，系统自动会生成货险冲红挂帐单。物流经理可以通过货险冲红挂帐单的内容帐单。物流经理可

22、以通过货险冲红挂帐单的内容进行相应的处理。进行相应的处理。第二阶段业务流程第二阶段业务流程 补货计划处理流程 CDC管理流程 干线运输管理流程 干线运输货险冲红流程 RDC调拨处理流程 通用业务处理流程实现的目标是建立一套支持多元化产品及多渠道销售的信息平台。第二阶段流程设计第二阶段用户角色定义 事业部计划员：主要负责补货计划、调拨计划的编制，审核，确认 物流中心计划员：主要负责发货指令的执行，运输商的选择 CDC仓管员：主要负责货物在CDC出入库操作 第三方物流(干线)：主要负责货物的干线运输，签收 货险处理员：主要负责干线运输出现货险后的处理 补货计划处理流程 提交补货订单补货订单初稿草稿

23、正式稿Start接收补货订单 填写补货计划销售预测数据生成补货计划补货计划初稿再次调整补货计划正式稿最终审批EndCDC/RDC库存数据调整计划补货计划草稿物流运作部物流运作部CDC/RDCCDC/RDC事业部计划协调员事业部计划协调员事业部计划员事业部计划员分公司分公司补货计划处理流程描述v事业部计划员（TV、AV事业部计划员）v生成补货计划初稿 v补货计划的产生是由三个前因来驱动的（分公司的要货申请、RDC库存、总部销售预测），事业部计划员填写补货计划提交给物流中心。（系统里要标识该补货计划是由分公司的要货订单驱动的，还是由总部自主进行补货）v补货计划的主要内容包括(发货CDC名称、收货R

24、DC名称OR收货单位的名称、计划内容)v输入：要货申请、RDC库存、销售预测v输出：补货计划 生成补货计划初稿（补充）制作补货计划参考的因素主要有以下六点：要货计划、CDC库存、RDC库存、销售数据、电话沟通、销售预测 补货计划有两种方式：直接对分公司提交的补货订单进行审核后直接生成补货计划；由主动补货引发的手工填写的补货计划。事业部计划员完成计划后发到物流运作部，物流运作部根据运力情况并与事业部计划员协商后调整发货计划的数量，后交由事业部计划协调员做最终审核后下达物流运作部执行。在传递过程中会产生3次数值，一次是初始值，第二次是物流部修改的值，第三次是事业部最终确定的数值。总部计划在参考CD

25、C库存的时候只参考这个CDC的合计库存而不管其内部是如何分布的，因为仓库产品类型和存货量分布非常的不均匀。补货计划处理流程描述生成正式补货计划 事业部计划员收到经过物流运作部调整的后的补货计划，经过事业部计划协调员的最终审核后交由物流运作部进行运作。当物流运作部开始运输流程时计划员可以对发货计划的情况进行跟踪。输入：经过物流运作部根据运力调整后的补货计划输出：正式补货计划 补货计划处理流程描述v物流中心干线计划员v调整补货计划 v物流中心干线计划员对各事业部计划员提交的发货计划进行数量上调整后，交还给事业部计划协调员员进行最终确认。v输入：事业部计划员交来的补货计划v输出：经过运力调整的补货计

26、划 补货计划处理流程描述v事业部计划协调员v最终审核发货计划 v事业部计划协调员员对发货计划进行最终确认。v输入：运力调整后的发货计划v输出：最终的发货计划CDC管理流程 开始结束是否合格取消入库(NO)办理入库(Yes)办理入库单准备入库入库检验仓管员仓管员入库流程入库流程CDC管理流程描述CDC管理员填写入库单CDC管理员接到由工厂送来的货物后通过随货物到达的批次计划检验货物，满足入库条件后允许入库。同时填写入库单修正库存输入：工厂发来的批次入库计划输出：入库单 出库流程提货单自提出库结束客户签收送货清单送货清单(签)开始接单核单按单找货核对记帐拣货装车盘点余数复核放行报表处理结束库存总帐

27、配送/自提(自提)货物出库处理配送处理(配送)出库单是否符合(Yes)等待处理(No)End发货计划CDC日库存报表CDC日发货统计CDC余留报表分公司物流部分公司物流部CDCCDC仓管员仓管员3PL(3PL(配配送处理送处理)客户方客户方(自自提处理提处理)CDC管理流程描述CDC管理员填写出库单根据计划部门下达的补货计划生成出库单，在这里要说明的是由于目前Tulip系统无法对CDC内部的物理仓库进行管理因此制作出库单的依据是各物理仓库上报的内部出库单。由于目前仓库已经在使用K3系统，因此可以考虑Tulip系统与K3系统进行对接。输入：审核后的发货计划输出：出库单 干线运输管理 正式下达正式

28、补货订单补货订单正式下达发货指令选择运输商补货订单正式出库准备出库准备运输准备运输签收返回签收结果签收情况客户客户/RDC/RDC3PL3PLCDCCDC物流运作部物流运作部事业部事业部干线运输管理流程描述 物流中心干线计划员 对事业部下达的发货指令进行承运商的分配工作 根据事业部下达的发货指令选择运输商，提交系统后会将各承运商所需要操作的订单分发。由于CDC部门无法实现对具体物理库的管理因此需要手工标注装货地点。输入：发货指令（补货计划、调拨计划、返厂计划等）输出：标注了承运商信息的发货指令 干线运输管理流程描述 3PL运输管理员 根据物流运作部下达的运输计划生成送货清单根据物流部下达的运输

29、计划结合自身的运输能力一次或分次执行运输计划，生成一张或多张送货清单供签收用。输入：发货指令（补货计划、调拨计划、返厂计划等）输出：送货清单 对送货清单进行跟踪维护送货清单生成后交由具体运输人员携带，在运输过程中运输管理员可以随时通过各种方式同运输人员进行联系，及时了解运输的情况并维护入送货清单。这样所有的人员（计划员、物流运作人员等）可以随时在网上关注发货计划的执行情况。输入：送货清单输出：维护了过程信息的送货清单 送货清单的签收信息录入货物到达后，收货方进行签收。运输管理员可以将签收信息维护录入系统，以便相关人员了解货物的签收情况。输入：送货清单输出：送货清单（签收）干线运输货险处理 货运

30、事故报案表运输中出现事故Start冲红通知单审核冲红账目修复货损重新调账货险冲红处理物流管理中心帐目挂帐冲红通知单挂帐单冲红冲红处理根据冲红请求生成冲红挂帐计划冲红（红单）（负数）询问经营部或中转仓是否需要补货生成对应要货计划的补发货计划(Yes)结束(No)计划冲红（蓝单）（正数）计划员计划员物流运作部物流运作部3PL3PL干线运输货险处理流程描述 干线运输货险处理员 生成货运事故处理单由于干线运输情况比较复杂，目前干线运输发生事故有两种情况和处理办法。输入：货运事故报案表（手工）输出：货险冲红单 （1）货损处理货损是指货物在运输过程中没有太大的损坏，通过业务模式和补发物料可以解决的。对于这

31、部分货物不会做冲红处理而是通过赔付和补发物料的情况来解决。（2）货差处理货差是指在运输过程中发生了比较大的事故导致货物无法完成既定功能的。这部分的处理一定要进行冲红处理。鉴于这两种情况我们的建议是一旦不能部分或全部签收，系统即生成货运事故处理单 3PL在送货清单上标明是货损还是货差。物流运作部的货运事故处理员根据系统自动生成的货运事故处理单和3PL提交的货运事故报案表来进行货损货差的处理。对于货损的情况完成了赔付和补发物料的操作后点击处理后，流程终止。而对于货差的情况点击冲红按钮系统生成货险冲红请求等待计划员处理。注：冲红单的主要内容包括(货运事故报案表编号、原发货计划号、发货冲红内容)对货险

32、冲红挂帐单进行处理事业部计划员作出发货计划冲红审核后，即生成货险冲红挂帐单。出现货损的货物的所有权即转为物流运作部，货险处理员有义务对该挂帐单进行处理，直到发生货险的货物被完全完毕。输入：货险冲红挂帐单输出：处理过的货险冲红挂帐单 事业部计划员 审核货险冲红申请单事业部计划员根据物流部上传的货险冲红单进行审批，系统随即会对要冲红的发货计划进行冲红同时会询问是否要对收货方继续发货，如果要继续发货则自动生成新的发货计划（进入新的发货计划处理流程），如果无需继续发货则不做处理。输入：货险冲红单输出：审核后的货险冲红单、新的发货计划（可选）生成货险冲红挂帐单一旦计划员审核了由物流运作部提交的货险冲红单

33、，无论是否继续发货系统都会生成货险冲红挂帐单并将收货方改为物流运作部。输入：审核后的货险冲红单 输出：货险冲红挂帐单 RDC调拨处理 填写调拨计划销售预测数据生成调拨计划调拨计划初稿Start初稿草稿正式稿最终审批End调拨计划正式稿库存信息准备出库库存信息准备入库调整计划调拨计划草稿物流运作部物流运作部RDC2(RDC2(调入调入)RDC(RDC(调出调出)事业部计划协调员事业部计划协调员事业部计划员事业部计划员RDC调拨处理流程描述 事业部计划员 生成调拨计划初稿调拨计划的产生是由两个前因来驱动的（分公司的调拨申请、总部销售预测），事业部计划员填写调拨计划提交给物流中心。注：调拨计划的主要

34、内容包括(调出RDC名称、调入RDC名称、计划内容)输入：调拨申请（手工）、各RDC库存、销售预测输出：调拨计划 生成调拨计划初稿（补充）（1）制作调拨计划参考的因素主要有以下六点调拨申请调出RDC库存调入RDC库存销售数据电话沟通销售预测（2）事业部计划员完成计划后发到物流运作部，物流运作部根据运力情况并与事业部计划员协商后调整计划，后交由事业部计划协调员做最终审核后下达物流运作部执行。在传递过程中会产生3次数值，一次是初始值，第二次是物流部修改的值，第三次是事业部最终确定的数值。生成正式调拨计划事业部计划员收到经过物流运作部调整的后的调拨计划，经过事业部计划协调员的最终审核后交由物流运作部

35、进行运作。当物流运作部开始运输流程时计划员可以对调拨计划的执行情况进行跟踪。输入：经过物流运作部根据运力调整后的调拨计划输出：正式调拨计划 RDC调拨处理流程描述 物流中心干线计划员 调整调拨计划物流中心干线计划员对各事业部计划员提交的调拨计划进行调整后，交还给事业部计划协调员员进行最终确认。输入：事业部计划员交来的调拨计划输出：经过运力调整的调拨计划 RDC调拨处理流程描述 事业部计划协调员 最终审核调拨计划事业部计划协调员员对调拨计划进行最终确认。输入：运力调整后的调拨计划输出：最终的调拨计划 物流管理系统软件架构TULIP系统的软件架构业务模型设计思路设计模式实现架构软件架构-业务模型R

36、DC1CDC2RDC2DC1分公司1事业部1订单补货调拔经营部2经营部3补货补货调拔经营部1DC2管理客户客户客户客户客户CDC1调拔调拔补货下订单。每个客户有且只有一个为之服务的xDC.。经营部通过客户来决定可以查看的xDC库存.。分公司可以管理多个xDC补货订单工厂CDCRDCDC客户。工厂到CDC。工厂到RDC。工厂到DC。工厂到客户。CDC 到 RDC。CDC 到 DC。CDC 到 客户。RDC 到DC。RDC 到RDC。RDC 到客户。DC 到客户物流网络模型下单机构审单机构总部分公司事业部经营部分公司产品部大客户分公司CDCRDCDC工厂CDCRDC客户CDC。客户在一个DC的服务

37、范围内。客户属于某个下单机构。下单机构通过客户来决定可以查看哪个DC的库存。下单机构隶属于某个审单机构。审单机构可以管理多个DC。该审单机构下所有下单机构的所有客户的隶属DC都在该审单机构的管理之下。客户客户物流与商流软件架构-设计原则系统之间的低耦合降低系统的耦合度，尽量使每个业务单位的子系统都可以独立运行。减少各系统间的依赖关系。系统的扩展与可配置注重对接口的设计，增强与其它系统的数据交换能力。面向对象的分析与设计应用面向对象的分析与设计技术，采用原型法来进行系统开发。软件架构-设计原则小结：TULIP系统的重点并非提供一个在每个业务环节都非常完整及完美的软件系统，而是为了实现对订单的实时

38、跟踪，统一管理以及对整个销售网络中库存的实时监控，及时准确地反映业务数据，以整合规范业务流程为主要目的的IT系统。因此，要求TULIP系统中的每个子系统均以低耦合度相连，将来被其它系统所代替时，不会影响业务流程的完整性。软件架构-设计模式代理关系机制应用代理技术来实现系统中某些业务对象之间的业务关系。使重组或更改业务关系变得更容易。设计模式应用Factory,Agent,Singleton,Handler,Controller等设计模式，保持代码的清析与易懂。例如：public class OrderManagerFactory private static OrderManager ivOr

39、derManager;public OrderManagerFactory()public OrderManager getManagerBy(String manager)return(new OrderDefaultManager();public static OrderManager getDefaultFactory()if(ivOrderManager=null)ivOrderManager=new OrderDefaultManager();return ivOrderManager;软件架构订单仓储运输报表系统管理(产品,客户,机构,用户等)系统接口Java Platform其

40、它系统CRMJXCDBReport软件架构ManagerBOBCHandlerDBJSPBO=BusinessObjectBC=BusinessObjectController从JSP客户端发出的每次请求，经过SessionManager的处理后，根据不同的Command分发给不同Handler来处理，Handler然后调用相应的Manager来处理业务逻辑，最后由Controller来完成对数据库的操作。SessionManagerTULIP系统的数据库设计主要数据模型订单处理入库出库运输与货险机构管理用户及权限代理关系产品管理数据库设计OrderIDTypeSenderShippingMe

41、thodPickingAddressRequiredDateRequiredTimeReceiverReceivingAddressReceiverContactPhoneCreaterCreationDateSubmitterConfirmDateCommentBizStatusStatusRDCIDOriginalIDVARCHAR2(18)VARCHAR2(2)VARCHAR2(6)VARCHAR2(2)VARCHAR2(100)VARCHAR2(16)VARCHAR2(16)VARCHAR2(6)VARCHAR2(100)VARCHAR2(20)VARCHAR2(20)VARCHAR2

42、(6)VARCHAR2(16)VARCHAR2(20)VARCHAR2(16)VARCHAR2(200)NUMBERNUMBERVARCHAR2(6)VARCHAR2(20)OrderAdjustmentIDTypeCreationDateSenderSubmitterOrderAdjustedOrderStatusConfirmDateCommentOriginalIDVARCHAR2(16)NUMBERVARCHAR2(16)VARCHAR2(6)VARCHAR2(20)VARCHAR2(18)VARCHAR2(18)NUMBERVARCHAR2(16)VARCHAR2(100)VARCH

43、AR2(20)ReceivingDocumentIDTypeReceiptDateWarehouseSenderConsignmentNoteOperatorCreaterCommentStatusVARCHAR2(16)VARCHAR2(2)VARCHAR2(16)VARCHAR2(6)VARCHAR2(20)VARCHAR2(18)VARCHAR2(20)VARCHAR2(6)VARCHAR2(100)NUMBER主要数据模型TULIP系统中的主要数据模型为订单，出库单，入库单，冲红单，送货清单，挂帐单，库存，产品，机构等之间的关系模型，而且也主要以处理以上几种业务对象的关系为主。Disp

44、atchDocumentIDTypeDispatchDateWarehousePickerPickingTicketCreaterOperatorCommentStatusVARCHAR2(16)VARCHAR2(2)VARCHAR2(16)VARCHAR2(6)VARCHAR2(20)VARCHAR2(18)VARCHAR2(6)VARCHAR2(20)VARCHAR2(100)NUMBERConsignmentNoteIDOrderCarryTypeTruckModelOrderIDReceiverReceivingAddressReceiverContactReceiverPhoneTr

45、uckLisenseDriverNameDriverIdentificationDriverPhoneSealNumberDispatchDateRequiredDateETAReceiptDateShipperSenderCreaterCreationDateSubmitterTraceInfoCommentStatusVARCHAR2(16)VARCHAR2(18)VARCHAR2(2)VARCHAR2(2)VARCHAR2(18)VARCHAR2(20)VARCHAR2(100)VARCHAR2(20)VARCHAR2(20)VARCHAR2(10)VARCHAR2(20)VARCHAR

46、2(20)VARCHAR2(20)VARCHAR2(20)VARCHAR2(16)VARCHAR2(16)VARCHAR2(16)VARCHAR2(16)VARCHAR2(6)VARCHAR2(20)VARCHAR2(20)VARCHAR2(16)VARCHAR2(20)VARCHAR2(200)VARCHAR2(100)NUMBER数据库设计订单FK_ORDERAUD_REFERENCE_ORGANIZAFK_ORDERAUD_REFERENCE_WAREHOUSFK_ORDERAUD_REFERENCE_ORDERFK_ORDERADJ_REFERENCE_ORDER1FK_ORDERAD

47、J_REFERENCE_ORDER2FK_ORDER_REFERENCE_ORDERTYPFK_ORDERADJ_REFERENCE_ORDERAD3FK_ORDERADJ_REFERENCE_PRODUCTIFK_ORDERPM_REFERENCE_ORDERFK_ORDER_REFERENCE_BUSINESSFK_ORDER_REFERENCE_SENDERFK_ORDER_REFERENCE_RDCIDFK_PICKLIST_REFERENCE_ORDERFK_PICKLIST_REFERENCE_PRODUCTIFK_PICKLIST_REFERENCE_UNITFK_ORDER_R

48、EFERENCE_ORGANIZAFK_ORDERADJ_REFERENCE_ORGANIZAFK_APPLYLIS_REFERENCE_ORDERAPPOrderIDTypeSenderShippingMethodPickingAddressRequiredDateRequiredTimeReceiverReceivingAddressReceiverContactPhoneCreaterCreationDateSubmitterConfirmDateCommentBizStatusStatusRDCIDOriginalIDVARCHAR2(18)VARCHAR2(2)VARCHAR2(6)

49、VARCHAR2(2)VARCHAR2(100)VARCHAR2(16)VARCHAR2(16)VARCHAR2(6)VARCHAR2(100)VARCHAR2(20)VARCHAR2(20)VARCHAR2(6)VARCHAR2(16)VARCHAR2(20)VARCHAR2(16)VARCHAR2(200)NUMBERNUMBERVARCHAR2(6)VARCHAR2(20)OrderAdjustmentIDTypeCreationDateSenderSubmitterOrderAdjustedOrderStatusConfirmDateCommentOriginalIDVARCHAR2(

50、16)NUMBERVARCHAR2(16)VARCHAR2(6)VARCHAR2(20)VARCHAR2(18)VARCHAR2(18)NUMBERVARCHAR2(16)VARCHAR2(100)VARCHAR2(20)OrderAdjustmentListItemLineNumberOrderAdjustmentProductProductSpecOrderQuantityQuantityUnitDiscountValueCommentNUMBER(10)VARCHAR2(16)VARCHAR2(16)VARCHAR2(100)NUMBER(10,2)NUMBER(10,2)VARCHAR