某医疗器械公司作为复杂医疗产品的集成商，必须保持高质量部件的及时供应。为了实现这一目标，该公司欲开发一采购系统。系统的主要功能如下：
- 检查库存水平。采购部门每天检查部件库存量，当特定部件的库存量降至其订货点时，返回低存量部件及库存量。
- 下达采购订单。采购部门针对低存量部件及库存量提交采购请求，向其供应商通过供应商文件访问供应商数据下达采购订单，并存储于采购订单文件中。
- 交运部件。当供应商提交提单并交运部件时，运输和接收（SR）部门通过执行以下三步过程接收货物：
(1) 验证装运部件。通过访问采购订单并提单进行比较来验证装运的部件，并将提单信息发给SR职员。如果收货部件项目出现在采购订单和提单上，则已验证的提单和收货部件项目将被送去检验。否则，将SR职员提交的装运错误信息生成装运错误通知发送给供应商。
(2) 检验部件质量。通过访问质量标准来检查装运部件的质量，并将它验证的提单发给检验员。如果部件满足所有质量标准，则将其添加到接受的部件列表用于更新部件库存。如果部件未通过检验，则将检验员创建的缺陷装运信息生成装运错误通知发送给供应商。
(3) 更新库存量。库管员根据收到的接受的部件列表添加本次采购数量，与原有库存量累加来更新库存部件中的库存量。标记订单采购完成。
现采用结构化方法对该采购系统进行分析与设计，获得如图1-1所示的上下文数据流图和图1-2所示的0层数据流图。
这个采购系统需要以下关键数据来确保其功能的有效运行：
-
库存数据：
- 部件的当前库存量。
- 部件的订货点（库存量达到此点时需要下订单）。
-
采购订单数据：
- 采购订单的详细信息，包括部件编号、数量、供应商信息等。
- 采购订单的状态（已下达、已接收、已检验等）。
-
供应商数据：
- 供应商的详细信息，如名称、联系方式、地址等。
- 供应商的信用评级或历史交易记录。
-
运输和接收数据：
- 运输提单信息，包括部件编号、数量、运输日期等。
- 接收记录，包括接收日期、接收状态（已接收、检验中、检验不合格等）。
-
质量检验数据：
- 质量检验标准和流程。
- 检验结果，包括合格与否、缺陷描述等。
-
库存更新数据：
- 接收的部件列表及其数量。
- 更新后的库存量。
-
错误和异常处理数据：
- 装运错误信息，如提单与采购订单不符、部件质量问题等。
- 错误处理记录，包括错误类型、处理措施、处理结果等。
-
系统用户数据：
- 用户角色和权限（如采购部门、检验部门、库管员等）。
- 用户操作记录，用于审计和追踪。
这些数据对于确保采购系统能够高效、准确地执行其功能至关重要，包括库存管理、订单处理、质量控制和库存更新等。
采购订单状态的更新是采购系统中一个关键的流程，它确保了订单处理的透明度和效率。根据您提供的系统功能描述，采购订单状态的更新可以按照以下步骤进行：
-
下达采购订单：
- 当库存水平达到订货点时，采购部门生成采购订单。
- 采购订单在系统中被标记为“已下达”。
-
供应商确认：
- 供应商收到采购订单后，进行确认。
- 系统更新订单状态为“已确认”。
-
供应商发货：
- 供应商准备发货，并将发货信息（如预计到达时间、运输单号等）提供给采购方。
- 系统更新订单状态为“已发货”。
-
运输和接收（SR）部门接收货物：
- SR部门通过访问采购订单和提单进行比较来验证装运的部件。
- 如果验证成功，系统更新订单状态为“已接收”。
- 如果验证失败，系统更新订单状态为“接收错误”，并生成装运错误通知发送给供应商。
-
检验部件质量：
- 检验员根据质量标准检查接收的部件。
- 如果部件通过检验，系统更新订单状态为“已检验”。
- 如果部件未通过检验，系统更新订单状态为“检验不合格”，并生成缺陷装运信息发送给供应商。
-
更新库存量：
- 库管员根据接受的部件列表更新库存量。
- 系统更新订单状态为“已完成”，标记订单采购完成。
-
异常处理：
- 在任何阶段，如果出现异常情况（如供应商延迟发货、部件损坏等），系统应更新订单状态以反映这些异常，并可能需要人工干预来解决问题。
在整个过程中，系统应该能够记录每个状态变更的时间和原因，以便进行追踪和审计。此外，系统还应该提供通知机制，以便在订单状态变更时通知相关人员。这样的流程确保了采购订单的透明度和可追溯性，有助于提高采购效率和质量控制。
以下从结构化分析设计角度，梳理各要素关联，补全可能的数据流图逻辑（因图表未显示，基于文本推导）：
上下文数据流图（概念层，简化版）
- 外部实体：供应商（提供部件 ）、库存部件（被检查对象 ）、采购部门（发起流程 ）、S/R部门（处理交运 ）、检验员（质量把关 ）、库管员（更新库存 ）
- 主要数据流：
- 采购部门→系统：低存量部件及库存检查请求、采购订单请求
- 系统→供应商：采购订单（基于供应商文件数据 ）
- 供应商→系统：提单、交运部件
- 系统→S/R部门：提单信息、待检验部件（验证后 ）
- 系统→检验员：已验证提单、待检部件
- 检验员→系统：缺陷/合格判定结果
- 系统→库管员：接受的部件列表
- 系统→采购部门：低存量部件及库存反馈
0层数据流图（细化业务流程，基于文本功能拆解）
可拆为 “检查库存”“下达订单”“交运处理（含三子类 ）” 三个加工：
-
加工1：检查库存水平
- 输入：采购部门的库存检查请求、库存部件数据
- 处理：每日核查部件存量，判定是否达订货点
- 输出：低存量部件及库存反馈（给采购部门 ）
-
加工2：下达采购订单
- 输入：采购部门的采购请求、供应商文件（供应商数据 ）
- 处理：生成采购订单，关联供应商信息
- 输出：采购订单（存入采购订单文件 ，并发送给供应商 ）
-
加工3：交运部件处理
又细分为三个子加工：- 子加工3.1：验证装运部件
- 输入：供应商提交的提单、采购订单文件（采购订单 ）
- 处理：比对提单与采购订单，识别匹配/不匹配项
- 输出：匹配项→待检验部件（给子加工3.2 ）；不匹配项→装运错误通知（给供应商 ）、提单信息（给S/R职员 ）
- 子加工3.2：检验部件质量
- 输入：待检验部件（来自3.1 ）、质量标准文件
- 处理：依据质量标准检查部件
- 输出：合格→接受的部件列表（给子加工3.3 ）；不合格→缺陷装运通知（给供应商 ）、已验证提单（给检验员 ）
- 子加工3.3：更新部件库存
- 输入：接受的部件列表（来自3.2 ）、库存部件数据
- 处理：累加采购数量更新库存，标记订单完成
- 输出：更新后的库存部件数据
- 子加工3.1：验证装运部件
若需精准补全，需实际图表辅助，但基于文本可先梳理出 “部门-功能-数据-文件” 的流转逻辑，是结构化分析中“分解-建模”思路的体现，核心是清晰呈现“谁（部门/角色 ）在什么环节，处理什么数据，产出什么结果，关联哪些文件” 。你可基于实际图表（若有 ），核对流程节点的数据流输入输出是否匹配~
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
