提交
This commit is contained in:
zlwu committed
1 parent
545ada33e5
commit
d336fd0226
4 files changed
+674
-254
No files matched your search
+82
@@ -0,0 +1,82 @@
|
||||
# macOS
|
||||
.DS_Store
|
||||
.AppleDouble
|
||||
.LSOverride
|
||||
._*
|
||||
|
||||
# Windows
|
||||
Thumbs.db
|
||||
ehthumbs.db
|
||||
Desktop.ini
|
||||
|
||||
# Linux
|
||||
*~
|
||||
|
||||
# 编辑器 / IDE
|
||||
.history/
|
||||
.idea/
|
||||
*.iml
|
||||
*.swp
|
||||
*.swo
|
||||
*~
|
||||
.project
|
||||
.classpath
|
||||
.settings/
|
||||
|
||||
# VS Code / Cursor（保留团队共享配置时可按需取消注释）
|
||||
# .vscode/*
|
||||
# !.vscode/extensions.json
|
||||
# !.vscode/settings.json
|
||||
|
||||
# 依赖与构建产物
|
||||
node_modules/
|
||||
dist/
|
||||
build/
|
||||
out/
|
||||
target/
|
||||
*.egg-info/
|
||||
.eggs/
|
||||
__pycache__/
|
||||
*.py[cod]
|
||||
*$py.class
|
||||
.Python
|
||||
*.class
|
||||
*.jar
|
||||
*.war
|
||||
*.ear
|
||||
|
||||
# 环境与密钥
|
||||
.env
|
||||
.env.*
|
||||
!.env.example
|
||||
*.pem
|
||||
*.key
|
||||
*.p12
|
||||
secrets/
|
||||
|
||||
# 日志与临时文件
|
||||
*.log
|
||||
logs/
|
||||
tmp/
|
||||
temp/
|
||||
*.tmp
|
||||
*.bak
|
||||
*.cache
|
||||
|
||||
# 测试与覆盖率
|
||||
coverage/
|
||||
.nyc_output/
|
||||
htmlcov/
|
||||
.pytest_cache/
|
||||
.tox/
|
||||
.coverage
|
||||
*.lcov
|
||||
|
||||
# 数据库与本地数据
|
||||
*.sqlite
|
||||
*.sqlite3
|
||||
*.db
|
||||
|
||||
# 上传与导出（业务附件、导出文件等本地目录）
|
||||
uploads/
|
||||
exports/
|
||||
@@ -1,254 +0,0 @@
|
||||
# 客户口述的需求
|
||||
- 公司介绍：中科兴皖，是一家做细胞医疗服务的。 主要业务是存储产妇脐带血，干细胞治疗等
|
||||
- 公司分为六大部分：市场营销部门（下设 采集部、临床部、中试服务部、支持中心、客服部） 、技术研发部、生产部、质量安全部、财务部、综合部
|
||||
- 公司主营业务：细胞存储、细胞培养及医疗应用
|
||||
- 细胞存储业务的流程：
|
||||
1、医院现场的采集专员会跟待产妈妈促销细胞存储业务，如果待产妈妈有意向（意向分两种：生产之前就签约了、生产之后签约的）。 细胞存储类型可以支持多种细胞的存储（围产期造血干细胞、脐带间充质干细胞、胎盘亚全能干细胞），细胞存储可以设置存储年份和价格。一个待产妈妈的协议可以有多份，每个协议可以同时存储多种细胞，每个协议里面根据存储细胞的数量和年份就会有个总价格。
|
||||
2、缴费支持两种模式：趸交和分期。 趸交就是一次性缴清。 分期就是分多少期，每期间隔几个月。 这块默认是6期，每期3个月。可以设置一个第一次缴费日期，后续分期缴费日期自动计算出来。后续又个专门的模块查询未来几个月需要缴费的用户的信息，方便市场营销部门跟踪提醒用户及时缴费
|
||||
3、如果提前签约的用户，有个预产期，在预产期前两周就要提醒对应的采集专员关注这个事情，做好采集准备。切勿错过采集时间。有的是客户是先采集，后续补协议和合同
|
||||
4、线下的过程：市场专员手上都有一堆的预置合同和协议号（协议号是唯一的）。用户如果需要签约，采集专员会让用户签订合同，然后专员把唯一的协议号的条形码贴在合同纸上，这个协议号就跟合同做了唯一的绑定。 所以我们需要采集专员将签约的合同拍照上传、同时将协议号与这个客户的这份合同协议绑定。
|
||||
5、细胞存储工单的信息包括几个部分：工单信息、客户信息 、协议信息、样本信息、存储信息
|
||||
5.1、工单信息包括：工单号、登记日期、创建时间、工单状态（待生效、生效中、已过期、已作废、 已毁约、已转科研），工单开始日期、工单结束日期、备注
|
||||
当【确定存储】时候，工单开始日期就是【确定存储】的当天。工单结束日期=最长的一种类型细胞存储周期+工单开始日期。 当前时间超过了工单结束日期，就表示已过期。在确定存储之前都是【待生效】。 当前时间在工单开始日期和工单结束日期之间，状态就是生效中。当用户不存储了或者样本异常，此工单可以作废。点击【作废】按钮后，这个工单就变成了【已作废】状态。点击【用户毁约】按钮后，这个工单就变成了【已毁约】状态，已作废或者已毁约等状态，需要线下给用户退款，所以缴费状态就会变成已退款
|
||||
5.2、客户信息包括：母亲姓名、母亲联系电话、母亲身份证号、预产期、分娩时间、母亲民族、母亲的出生年月、母亲的家庭住址、母亲的邮箱、母亲的有效联系地址、父亲姓名、父亲身份证号、父亲电话、新生儿姓名、新生儿性别、新生儿体重（克）、分娩方式、胎次、新生儿评分（1分钟）、新生儿评分（5分钟）
|
||||
5.4、协议信息包括：协议号、合同附件、合同总金额、缴费方式（趸交、分期）、分期缴费记录信息（搞一个子表记录）、缴费状态（如果是趸交，那就是已缴清、未缴费、已退款。 如果是分期， 那就显示已缴费几期/总分期数、已退款）。转账方式（微信转账、支付宝转账、现金、银行卡转账）、转账金额、转账时间、缴费附件。还需要弄个表专门记录分期的缴费的具体明细信息。合同审核流程（采集专员主动发起工作流审核）
|
||||
5.5、样本信息包括：采集专员id、采集专员名称、采集地区、采集医院、采集医护、销售人员、母血采集时间、样本采集时间、样本列表（细胞类型也称为样本类型，细胞条码（就是协议书的条形码），采集体积（ml）、备注）
|
||||
样本运输信息：分为三种方式，快递发货、人员携带。 如果选择了【快递发货】，需要写快递公司、快递单号、目的站点、快递费用、邮寄时间、预计到达时间（年月日时分秒） 、备注。 如果选择了【人员携带】，需要填写携带人员姓名、携带人员联系电话、目的站点、邮寄时间、预计到达时间（年月日时分秒）， 废弃原因、样本状态（待采集、 已采集、运输中、检测中、已入库、 已废弃）
|
||||
5.6、存储信息包括：该协议号所有类型细胞存储的信息（可以做个子表）
|
||||
5.7、可以转科研捐赠，也需要退款
|
||||
5.8、采集单有个信息提醒功能：采集审核人员如果发现采集单存在异常信息，可以点击提醒，写入备注。采集专员就会收到这个提醒信息，对采集单信息进行调整。调整后保存。
|
||||
5.9、样本采集完成邮寄出来了，质量安全部就会看到待接收的样本信息。当样本到达后，质量安全部会对样本的信息进行确认，确认的维度包括（包装完整性、封口严密性、无破损、无漏液、颜色正常、系绳牢固、无分层，这些维度可以在后台一个模块维护），样本接收预判的一个结果（是否合格）。记录一些数据（例如 温度、体积、净重等，这些需要记录的数据也可以有个模块来配置管理）、拍照上传附件。样本到达时间、运送人姓名、接收人（质量安全部的人）、备注、是否接收（接收、不接收）、如果接收，就会给每个样本一个入库样本编码，样本状态就变成检测中。
|
||||
5.10、接收后，就会向生产部推送一个生产工单，同时向质量安全部图送一个质检工单
|
||||
5.11、质量安全部看到质检工单，点击【开始检验】，勾选检测项目（检测项目可以在后台一个模块配置）， 检测机构（可以选择自检、第三方检测），选择了第三方检测，需要选择第三方检测结构名称、价格、运输方式（公司自送、快递、机构自取）、运输人员、运输时间等。检测结果出来后，需要质检人员经自检的结果（自检结果的内容项有个模块配置管理）和第三方的检测结果和报告上传记录，然后有个检测判定（是否合格）
|
||||
5.12、生产部会对这个工单进行处理，给个生产判定和备注。这里要把处理的方式，处理用的物料都记录一下，存在哪里。
|
||||
5.13、专门有个质检主管的角色，对这个存储工单做个最终的【放行审核】，审核通过后，就是已入库了。 审核不通过，就是已废弃
|
||||
5.14、客服人员线下会在样本接收后，给客户一个到库通知，暂时就是复制文本，线下有人员通过企业微信发送，样本合格入库了，给客户一个入库通知，暂时就是复制文本，线下有人员通过企业微信发送，
|
||||
5.15、满月待办：新生儿满月数据，统一办理团队保险，批量选择新生儿信息，导出excel，线下发给保险机构，保险机构将保单信息反馈后，记录到系统中
|
||||
5.16、储存证制作： 当入库后，由人员线下制作储存证完成后，上传到系统
|
||||
5.17、随访管理
|
||||
|
||||
- 科研捐赠业务过程：
|
||||
1、医院现场的采集专员跟待产妈妈聊科研捐赠，如果科研捐赠同意的话，就达成了协议。签订科研捐赠知情同意书
|
||||
2、系统要记录科研捐赠相关信息：与细胞存储的区别就是不用交费。其他流程是一样的。信息也是一样的。 科研捐赠暂时不开放转细胞存储。科研捐赠没有满月待办、没有存储证制作。没有各种用户通知
|
||||
3、虽然存储信息比较一致。但是科研捐赠采用独立的表模型，不要跟细胞存储业务共用业务表。
|
||||
|
||||
- 中试服务
|
||||
是一种中间渠道商销售细胞产品的模式。 渠道商先会跟公司签订协议，定义好各个细胞产品的价格。然后渠道商可以选择直接存储金额。或者购买细胞产品的份数并付款。渠道会自己去找客户，然后将客户信息和需要的服务登记过来，
|
||||
- 渠道信息包括：渠道名称、机构名称、统一社会信用代码、渠道类型、联系人姓名，联系人电话、联系邮箱、渠道协议（协议附件、协议开始时间，协议结束时间、备注、细胞产品（产品名称、细胞类型、细胞规格、价格））、开票信息、邮寄地址、备注
|
||||
授信金额、结算方式
|
||||
- 渠道第一步签协议、
|
||||
- 第二步下服务订单（服务订单分两种，一种是直接存储金额， 一种是购买细胞产品多少份数）
|
||||
- 第三步通过服务订单就可以登记用户发起中试服务。会生成一个中试服务订单。中试服务订单的内容包括患者信息登记、细胞产品、数量、时间等信息登记***待补充**
|
||||
- 患者的体检信息，有的患者已经体检了，有的没有体检的患者。我们会帮患者进行体检预约。选择患者，选个体检机构，选个体检项目，选个时间。 最终会根据体检机构反馈的人员、体检项目、费用登记一下，上传体检报告
|
||||
- 由渠道跟医生、患者沟通，确定好治疗方案，然后由我们的人员将治疗方案录入到系统中。治疗方案包括：细胞类型、规格、疗程数、疗程间隔（月）、输注途径、备注。 产生一个总费用，一次性扣除。
|
||||
- 生成一个订单确认书，线下患者、渠道确认下。
|
||||
- 根据治疗方案，就可以产生输注计划。 输注计划可以随时取消。剩余的没有输注的金额或者细胞产品的份数就会退到渠道商的账户
|
||||
- 输注计划会产生生成工单提醒到生产部、一个工单给到质量安全部
|
||||
- 在输注计划截止日期前3天会填写一个输注确认。确认患者是否需要这次输注。
|
||||
- 质量部会对这个出库产品做个检测、提供检测报告、然后交付给市场营销部。
|
||||
- 市场营销部确认后，将细胞产品交付给渠道。有两种运输方式：渠道自提（***有信息需要填写****）、快递发送（****有信息需要填写****）
|
||||
- 中试服务单完成了
|
||||
- 中试服务单要支持上传附件和写备注
|
||||
|
||||
- 临床应用
|
||||
是一种通过跟医院合作，由医院医生推荐客户来公司购买细胞产品，需要公司来跟客户联系。 整体流程跟中试很相近。
|
||||
- 第一步发起临床申请，****填写信息****，会跟患者收钱
|
||||
- 对于临床应用不需要体检，方案是由医生制定，多少钱也是医生定的。
|
||||
- 制定方案
|
||||
- 收费
|
||||
- 销售审批，会生成生产工单、会生成质检工单
|
||||
- 应用确认
|
||||
- 质量部产品交付给市场营销部
|
||||
- 患者需要签知情同意书
|
||||
- 市场营销部需要将细胞产品交付到医院，有运输方式（公司送达、快递运输）
|
||||
- 临床申请单完成了
|
||||
- 临床申请单要支持上传附件和写备注
|
||||
|
||||
- 客户管理模块、客户可以打标签
|
||||
- 样本溯源，这里要提前规划好，一个细胞样本全生命周期的管理
|
||||
|
||||
- 生产工单
|
||||
- 生产步骤，生产每个步骤要哪些物料（例如培养基，这里要把物料管理起来），量
|
||||
- 生产工序也搞个基础模块管理起来，有个工序库。每个工序要哪些试剂、哪些耗材及其标准的量（耗材可以打包成一个耗材包，方便选择）。每个工序完成后，需要记录哪些参数，参数规格、参数的量、参数的单位 。 工序可以有类别的概念
|
||||
- 支持提前将生产工序组合成工艺路线图 ， 后续可以直接用。使用后还可以再调整真实的生产工序路线图，加入新工序、删除工序。 工序还支持循环，循环几次。
|
||||
- 实际生产过程中，可以调整每个工序对耗材、试剂的实际消耗量
|
||||
- SOP文档附件管理
|
||||
- 生产工单可以由主管分配，分配给谁，谁就看见和操作这个工单
|
||||
- 主管还可以给自己下生产工单（预培养）
|
||||
- 每个工序可以提交偏差。附件上传、偏差描述。工序可以提交图片和附件
|
||||
- 产出物放在哪里、产品编号、生产批号
|
||||
- 库位管理：液氮罐、层、盒、每个盒子有多个位置。 低温冰箱
|
||||
- 生产的细胞放在哪里、产品编号、生产批号
|
||||
-
|
||||
- 生产工单分 样本制备、细胞生产、预培养
|
||||
- 细胞生产需选择一个细胞来进行工序
|
||||
- 细胞库
|
||||
|
||||
- 质量安全部
|
||||
- 也可以自己给自己下质检工单
|
||||
- 哪个批次 哪个细胞产品进行质检
|
||||
-
|
||||
|
||||
- 站点管理
|
||||
- 会涉及到存储设备的站点、在哪个站点生产的
|
||||
-
|
||||
|
||||
|
||||
|
||||
- 所有的表都加一个备注字段，
|
||||
- 所有的表都要有的字段
|
||||
`id` VARCHAR(64) NOT NULL COMMENT '主键ID',
|
||||
`remark` varchar(512) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '备注',
|
||||
`create_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '创建人',
|
||||
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
|
||||
`update_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '更新人',
|
||||
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
|
||||
`del_flag` tinyint(4) NOT NULL DEFAULT '0' COMMENT '删除标记：0-正常 1-已删除',
|
||||
- 所有数据都不可以直接删除，都必须要用虚拟删除（0/1， 0 表示 未删除， 1 表示 删除）
|
||||
|
||||
# 初步整理的思路
|
||||
|
||||
|
||||
## 市场营销
|
||||
|
||||
### 存储业务价格表
|
||||
- 在这里可以配置不同类型细胞，存储的年份及其价格
|
||||
|
||||
### 存储业务分期缴费跟踪表
|
||||
- 在这个界面用户可以自由设置看未来几个月内，需要缴费的用户的信息及金额。可以清晰看到是第几期的费用。同时用户缴费后，可以上传缴费截图。每次缴费需要对应第几期。
|
||||
|
||||
### 存储协议号制作模块
|
||||
- 在这里市场营销人员可以制作一批的协议号，然后打印成条形码，线下邮寄给医院现场的采集专员。
|
||||
- 协议的条形码生成的时候可以不用先绑定采集专员，当采集专员录入待产妈妈合同时候需要将协议条形码的条码值传上来，自动就绑定了
|
||||
|
||||
### 存储业务采集地区及该地区下医院的信息维护模块
|
||||
- 在这里维护采集地区和地区下医院的信息。
|
||||
|
||||
### 细胞存储管理
|
||||
- 细胞存储的全流程管理
|
||||
|
||||
### 科研捐赠管理
|
||||
- 科研捐赠的全流程管理
|
||||
|
||||
### 细胞存储合同审核
|
||||
- 这个模块可以对细胞存储的合同进行审核
|
||||
|
||||
### 样本运输检测
|
||||
- 显示运输中的样本（包括细胞存储和科研捐赠的样本），方便大家知道样本情况，不要快递到了无人接收的情况
|
||||
|
||||
### 保险机构
|
||||
- 这个模块专门用来登记合作的报销机构的信息。只做信息记录，基础模块中不会对保险机构发生的金额和交易进行记录
|
||||
|
||||
### 检测机构
|
||||
- 这个模块专门用来登记检测机构的信息的。只做信息记录，基础模块中不会对检测机构发生的金额和交易进行记录。
|
||||
- 检测项目 及 费用
|
||||
|
||||
### 体检机构管理
|
||||
- 维护体检机构及体检项目、费用
|
||||
|
||||
|
||||
### 客户信息
|
||||
- 这里是一个查看、管理客户的模块。
|
||||
- 在这里可以看到客户的信息，客户的各种业务工单（一个客户可以有多个细胞存储工单，也可以有细胞治疗工单），以及每个工单的具体情况。
|
||||
|
||||
### 营销产品管理
|
||||
- 这个模块专门用于登记营销产品的信息。
|
||||
|
||||
|
||||
## 研发生产
|
||||
|
||||
|
||||
## 质量安全
|
||||
|
||||
### 样本接收模块
|
||||
- 在这个模块可以看到发出的样本，包括细胞存储和科研捐赠的。质量部门是可以看到样本是细胞存储还是科研捐赠的类型的
|
||||
|
||||
|
||||
## 运营支撑
|
||||
|
||||
|
||||
## 财务信息
|
||||
|
||||
|
||||
## 基础信息
|
||||
|
||||
### 租户管理
|
||||
- 这是一个多租户的平台。这里提供一个租户管理模块，目前系统就一个租户“中科兴皖” 。
|
||||
- 每个租户有一个超级管理员。每个租户超级管理员登陆系统后，对该租户的数据进行单独的维护工作
|
||||
- 租户与租户之间的数据是互相无法访问的。A租户用户在数据权限这块只能看见本租户内的数据。具体数据权限还要更精细化的控制，是由数据权限模块的配置来决定的
|
||||
|
||||
### 组织管理
|
||||
- 支持多级组织，存在三级、四级组织等。每级组织都可以有用户数据
|
||||
- 组织不可以删除，可以启用、禁用。
|
||||
|
||||
### 用户管理
|
||||
- 支持在任何组织下创建用户
|
||||
- 用户主要信息：登陆账号、登陆密码、头像、用户名称、用户性别、手机号码、邮箱、状态
|
||||
|
||||
## 菜单管理
|
||||
- 这个模块用于系统菜单的管理功能。
|
||||
- 菜单要分web端和小程序端两种类型的，因为未来会建设小程序端和web端两个系统
|
||||
|
||||
### 角色管理
|
||||
- 支持配置系统角色
|
||||
- 角色的主要信息：角色编码、角色名称、状态、备注等
|
||||
- 角色可以设置数据权限：数据权限分为全部数据权限、本部门、本部门及以下、仅本人、自定义。 自定义就是支持配置部门及人员。配置部门表示该用户拥有这些部门的数据权限。配置人员表示该用户拥有这些人员的数据权限。两个都配置了，就表示该用户既拥有部门的权限，又拥有人员的权限。取他们的合集
|
||||
- 角色可以设置菜单权限：角色勾选配置了哪些菜单，就表示角色拥有了这些菜单，打开系统就可以看见这些菜单了
|
||||
- 角色中可以增加用户，就表示该用户拥有了这个角色。就拥有了这个角色对应的数据权限和菜单权限。
|
||||
- 一个用户可以拥有多个角色、一个角色可以配置多个用户
|
||||
|
||||
### 职位管理
|
||||
- 这个模块用于职位信息管理
|
||||
- 职位可以配置用户，就表示该用户的职位信息。
|
||||
|
||||
### 站点管理
|
||||
- 这个模块用于管理系统站点。
|
||||
- 站点当前默认就一个“中科兴皖”
|
||||
- 站点就是表示一个区域，这个区域可以进行拥有哪些功能。功能有血样采集功能、血样检测功能、细胞制备等功能。这个站点的功能我们可以做成一个字典表一个字典来管理
|
||||
|
||||
### 字典管理
|
||||
- 字典管理支持字典项管理和字典项中的字典值的管理（要支持树形结构）。例如字典项叫 站点功能。 字典值有 1-血样采集 2-血样检测 3-细胞制备
|
||||
|
||||
### 物料管理
|
||||
- 这个模块专门来管理各部门用到的物料信息。只做信息记录，基础模块中不对物料的采购、领用、使用等管理
|
||||
|
||||
### 流程引擎
|
||||
- 做一个类似阿里钉钉那样的流程配置功能。不需要像java版本的flowable那么复杂的工作流。
|
||||
- 阿里钉钉的工作流的功能配置清晰，功能也能满足客户的需求了。
|
||||
- 工作流要支持在线图形化编排工作流，配置审批人。工作流支持通过、退回、撤回等等常用功能。复杂功能可以暂时不考虑实现（如子工作流）
|
||||
|
||||
### 流程中心
|
||||
- 待办中心：在这里可以对所有需要当前登录人审批的数据展示出来，并且可以进行审批
|
||||
- 已办中心：在这里可以看见历史审批过的申请单和审批信息
|
||||
- 我的申请： 在这里可以看见自己各种业务的申请单及审批过程信息
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+314
@@ -0,0 +1,314 @@
|
||||
# 客户口述的需求
|
||||
- 公司介绍：中科兴皖，是一家做细胞医疗服务的。 主要业务是存储产妇脐带血，干细胞治疗等
|
||||
- 公司分为六大部分：市场营销部门（下设 采集部、临床部、中试服务部、支持中心、客服部） 、技术研发部、生产部、质量安全部、财务部、综合部
|
||||
- 公司主营业务：细胞存储、细胞培养及医疗应用
|
||||
|
||||
|
||||
# 系统角色划分
|
||||
|
||||
## 采集专员
|
||||
|
||||
|
||||
## 市场客服专员
|
||||
|
||||
|
||||
# 系统角色模块划分
|
||||
|
||||
|
||||
|
||||
# 市场营销模块
|
||||
|
||||
## 细胞存储采集协议单管理
|
||||
- 此模块用于管理细胞存储的采集协议单的管理。**特别注意：采集协议单也很多的关联信息**
|
||||
- 采集协议单的核心字段： id 、采集协议号[采集协议号管理]、状态（dsx - 待生效 、 sxz - 生效中、 ygq - 已过期 、 yzf - 已作废、 zky - 转科研）、 协议附件、登记日期（YYYYMMDD）、备注信息、协议生效时间、协议生效描述、协议过期时间、协议过期描述、协议作废时间、协议作废描述、协议转科研时间、协议转科研描述
|
||||
- 采集协议单状态当前有4个状态、创建协议单时候状态默认 dsx - 待生效 ， 后续提供四个按钮 协议生效、协议过期、协议作废、协议转科研 ，来改变协议状态
|
||||
|
||||
### 采集协议单中客户信息录入
|
||||
- 创建一个采集协议单的客户信息表
|
||||
- 采集协议单的客户信息表跟[客户管理]客户信息表customer中关系是这样的：
|
||||
- 在采集协议单的客户信息可以从客户信息表中查询（查询时候支持根据姓名和身份证号），
|
||||
- 如果有，直接复用客户信息到母亲信息，将客户id带过来。
|
||||
- 如果没有，则无法复用客户信息，需要用户自行填写。
|
||||
- 保存采集协议单的时候需要同步将这个母亲信息保存到客户信息表customer中，
|
||||
- 如果客户信息已存在就是信息修改，同步要看看客户类型是否包括了xbcckh， 如果没有包括，就加入这个类型xbcckh
|
||||
- 如果客户信息不存在就是创建，客户类型为xbcckh
|
||||
- 采集协议单中的客户信息表中有以下核心字段：采集协议单id、客户id，母亲姓名、母亲联系电话、母亲身份证号、母亲出生年月（YYYYMM）、母亲民族、母亲家庭住址、父亲姓名、父亲电话、父亲身份证号、新生儿分娩时间、新生儿性别（1 - 男 、0 - 女）、分娩方式（sc - 顺产、 pgc - 剖宫产）、胎次（生育第几胎的意思，生育第一胎就是1 ， 生育第二胎就是2，以此类推） 、 新生儿体重（克）、新生儿评分（1分钟）、新生儿评分（5分钟）、采集专员[用户管理，默认当前登录用户的id]
|
||||
|
||||
### 采集协议单中采集信息录入
|
||||
- 创建一个采集协议单的采集信息表
|
||||
- 采集信息表中核心数据包括：采集协议单id、采集地区[采集地区及医院管理]、采集医院[采集地区及医院管理]、采集医护、销售人员[用户管理，默认当前登录用户的id]、样本采集时间（YYYYMMDD hh:mm:ss）、母血采集时间（YYYYMMDD hh:mm:ss）
|
||||
|
||||
### 采集协议单中样本信息录入
|
||||
- 采集协议单中样本信息表，一个采集协议单支持多个样本。核心字段包括：样本类型编码[样本类型表]、样本编码[样本编码管理]、采集量、物品单位编码[物品单位管理]、物品单位名称[物品单位管理]、样本存储年份[样本类型表]、样本存储价格[样本类型表]、样本状态（已采集、 检测中、 已入库、已作废）、入库日期、存储到期日期、备注
|
||||
- 样本状态：创建样本信息时候，默认状态就是已采集 。 提供三个按钮 样本检测、样本入库、样本作废，分别来修改样本的状态。 样本入库按钮点击时候，会记录入库日期为当天。然后存储到期日期 = 入库日期 + 样本存储年份
|
||||
|
||||
#### 采集协议单中样本运输信息录入
|
||||
- 一个样本对应一个运输信息，在界面操作时候也支持勾选所有样本录入一份的信息，那就代表这些样本都是同样的快递信息
|
||||
- 采集协议单中样本运输信息表核心字段：采集协议单id、样本id、运输类型（kdys - 快递运输 、 ryxd - 人员携带 ）、快递公司[快递公司管理]、快递单号、目的站点[站点管理]、快递费用（元）、预计到达时间（YYYYMMDD hh:mm:ss）、携带人员姓名、携带人员联系电话。 如果运输类型是kdys 快递运输 ，则填写 快递公司、快递单号、目的站点、快递费用（元）、预计到达时间。 如果运输类型是ryxd - 人员携带，则填写 携带人员姓名、携带人员联系电话、目的站点、预计到达时间
|
||||
|
||||
### 采集协议单中缴费信息录入
|
||||
- 采集协议单中缴费信息主表核心字段： 采集协议单id、缴费方式（dj - 趸交 、 fq - 分期）、合同金额、分期期数、每期间隔（月）、趸交截止时间（YYYYMMDD）、分期开始时间（YYYYMMDD, 缴费方式为fq - 分期，这个字段要填，填写完成后，分期期数、每期间隔（月），就会自动在子表中生成数据 ）
|
||||
- 缴费方式中趸交就是一次性缴费的意思
|
||||
- 采集协议单中缴费信息子表核心字段：缴费信息主表id、转账方式（wxzz - 微信转账、 zzbzz - 支付宝转账 、 yhkzz - 银行卡转账 、 xj - 现金） 、转账金额、转账时间 、转账附件 、缴费状态（待缴费、已缴费、已退费） 分期期数（如果是趸交，这个期数就为空）、分期应缴费时间（YYYYMMDD 缴费方式为分期时候，才有这个值）、备注。 如果为缴费方式为 dj - 趸交， 则只有一条记录。如果为缴费方式 为 fq - 分期，则有分期数一样数目的记录。
|
||||
|
||||
### 采集协议单信息审核模块
|
||||
- 采集协议单有一条审核记录表，核心字段： 采集协议单id、审核人、审核备注、审核状态（shtg - 审核通过、 shth - 审核退回）
|
||||
|
||||
### 采集协议单满月待办模块
|
||||
- 生效中的采集协议单中已满月的新生儿信息， 这个满月待办表中，核心字段：采集单协议id、满月待办状态（1 - 已办报销 、 0 - 未办保险）、办理日期、办理备注、保险附件
|
||||
|
||||
### 采集协议单储存证制作模块
|
||||
- 生效中的，并且样本已经入库的采集协议单， 储存证表中，核心字段：制作状态（1 - 已制作 ， 0 - 未制作） 储存证图片、制作日期，备注
|
||||
|
||||
### 细胞存储用户随访管理
|
||||
- 根据采集协议单创建时间倒序排列，将采集协议单的用户显示出来。创建一个随访表， 核心字段： 客户id、随访时间、随访描述
|
||||
|
||||
## 科研捐赠采集协议单管理
|
||||
- 科研捐赠采集协议单管理跟细胞存储采集协议单唯一的差别，就是不用缴费。
|
||||
- 科研捐赠独立建设一套表模型进行业务数据维护，不跟细胞存储采集单共享。但是基础的样本类型管理、采集协议号管理、客户管理、样本编码管理、采集地区及医院管理，这些基础数据是共享的
|
||||
|
||||
## 中试服务管理
|
||||
|
||||
### 渠道服务购买订单管理
|
||||
- 渠道服务购买订单表，核心字段：渠道id、渠道名称、科室/部门、订单类型（ yfk - 预付款 、gmcp - 购买产品） 、预付金额（订单类型为yfk - 预付款 就是预付金额）、 购买总金额（订单类型为gmcp - 购买产品 ， 就是所有购买的产品总金额）、状态（待审核、 生效中、 已作废）、备注信息
|
||||
- 渠道服务购买订单-购买产品明细表， 当订单类型 为 gmcp - 购买产品。 这里存储购买产品明细，核心字段：项目编码、项目名称、细胞类型、规格、协议单价、购买数量、购买金额、备注
|
||||
|
||||
### 中试申请
|
||||
- 基于渠道的服务购买订单，渠道就可以提交中试申请单了，每个中试申请单必须跟一个渠道服务购买订单表关联。
|
||||
- 中试申请单这个表，核心字段：id、渠道服务购买订单id 、备注
|
||||
- 中试申请单患者信息表：支持从[客户管理]中选择。核心字段：姓名、性别、年龄、身份证号、联系电话、紧急联系人、紧急联系人电话、临床诊断、诊断附件、是否需要体检（1 - 需要， 0 - 不需要）
|
||||
- 在中试申请单的客户信息可以从客户信息表中查询（查询时候支持根据姓名和身份证号），
|
||||
- 如果有，直接复用客户信息，将客户id带过来。
|
||||
- 如果没有，则无法复用客户信息，需要用户自行填写。
|
||||
- 保存中试申请单的时候需要同步将这个信息保存到客户信息表customer中，
|
||||
- 如果客户信息已存在就是信息修改，同步要看看客户类型是否包括了zskh， 如果没有包括，就加入这个类型zskh
|
||||
- 如果客户信息不存在就是创建，客户类型为zskh
|
||||
- 中试申请单输注方案明细表，一个中式申请单会存在多个细胞输注方案，核心字段包括细胞类型、规格、总疗程数、疗程间隔、输注途径、输注开始日期、备注
|
||||
- 中试申请单输注计划明细表，一个细胞类型会产生多个输注计划，核心字段包括细胞类型、规格、输注时间、状态（待生产、已生产、已交付、已取消）、附件、备注
|
||||
- 中试申请单输注计划应用确认子表：一个输注计划就有一个应用确认信息，核心字段包括：确认人、确认时间、确认描述
|
||||
- 中试申请单输注计划交付信息子表：一个输注计划就有一个交付信息，核心字段包括：交付编号（自动生成）、备注
|
||||
- 中试申请单输注计划交付信息子表的物料清单表：一个交付信息会有多个物料清单：核心字段包括：物料名称、数量、单位
|
||||
- 中试申请单输注计划交付信息子表的交付方式表：一个交付信息会有一个交付方式：交付方式（ qdzt - 渠道自提 、 kdfh - 快递发货）、交付附件、发运时间、交接温度、备注 、自提人员、联系电话、发货人、快递公司、快递单号、快递费用、预计到达时间。 如果 交付方式 为 qdzt - 渠道自提，则需要填写 交付附件、发运时间、交接温度、备注 、自提人员、联系电话 。 如果交付方式为kdfh - 快递发货，则需要填写 交付附件、发运时间、交接温度、备注 、发货人、快递公司、快递单号、快递费用、预计到达时间。
|
||||
|
||||
- 中试申请单体检信息表，核心字段：中试申请单id 、体检机构、预约时间、预约的费用、实际体检时间、实际体检费用、费用是否结算、体检状态（待体检、已体检）、费用状态（未结算、已结算）、体检备注、体检报告附件
|
||||
- 中试申请单体检预约项目明细表：核心字段：项目名称、项目费用（元）、备注
|
||||
- 中试申请单体检实际项目明细表：核心字段：项目名称、项目费用（元）、备注
|
||||
|
||||
## 临床应用
|
||||
临床应用跟中试服务操作思路一致，有这些区别
|
||||
- 临床应用会从用户收费、中试服务是从渠道商扣费
|
||||
- 临床应用需要创建一个临床应用单位信息表：核心字段 单位名称、科室/部门、联系人、联系电话
|
||||
- 临床应用有个知情同意书签署的附件上传
|
||||
- 临床应用不需要体检
|
||||
- 临床应用的交付方式是（shsm - 送货上门、kdfh - 快递发货），交付附件、备注、交接温度、送货人姓名、联系电话、出发时间、预计到达时间、交通方式（ dc - 打车 、gsc - 公司车 、 qt - 其他）、交通费用(元) 、发货人、发运时间、快递公司、快递单号、快递费用、预计到达时间 。如果交付方式是shsm - 送货上门 ，则需要填写 送货人姓名、联系电话、出发时间、预计到达时间、交通方式（ dc - 打车 、gsc - 公司车 、 qt - 其他）、交通费用(元) 。 如果交付方式是 kdfh - 快递发货 ， 则需要填写 发货人、发运时间、快递公司、快递单号、快递费用、预计到达时间
|
||||
|
||||
## 体检机构及体检项目及价格维护模块
|
||||
- 体检机构表，核心字段：体检机构名称、体检机构地址、联系人、联系人电话、状态（1 - 正常、 0 - 停用）
|
||||
- 体检机构开票信息表，核心字段：单位名称、税号、单位地址、电话、开户银行、银行账号
|
||||
- 体检机构项目及价格表，核心字段：项目名称、项目费用（元）
|
||||
|
||||
## 样本类型管理
|
||||
- 此模块用于维护样本类型表，核心字段包括： 样本类型编码、样本类型名称、样本存储年份、样本存储价格
|
||||
- 目前样本类型有三种：wcqzxgxb - 围产期造血干细胞、qdjczgxb - 脐带间充质干细胞、 tpyqngxb - 胎盘亚全能干细胞
|
||||
|
||||
## 细胞存储分期缴费临期用户模块
|
||||
- 这个模块将分期缴费中最近7天缴费到期的数据展示出来。
|
||||
|
||||
## 采集地区及医院管理
|
||||
- 此模块用于采集地区和地区内医院的信息。
|
||||
- 创建两个表：采集地区表、采集地区内医院表
|
||||
|
||||
## 采集协议号管理
|
||||
- 此模块用于采集协议号表维护管理，核心字段：采集协议号、是否下发（1 - 是 、 0 -否）
|
||||
|
||||
## 样本编码管理
|
||||
- 此模块用于样本编码维护管理、核心字段：样本编码、是否下发（1 - 是 、 0 -否）
|
||||
|
||||
## 客户管理
|
||||
- 每个客户都有一个客户类型或者多个客户类型，客户类型的字典类型编码为 khlx
|
||||
- 每个客户都有个客户标签字段，这个字段存储着客户所有的标签，标签名称之间用逗号分隔。目前客户标签采取手动写标签名称，没有标准的客户标签
|
||||
- 客户信息表customer包括：客户姓名、客户性别、身份证号、年龄、联系电话、客户类型（多个类型之间用逗号分隔）、客户标签（多个标签之间用逗号分隔）。
|
||||
- 客户信息表中，客户姓名必须填写，但不要求唯一，因为存在重名的场景。如果身份证一样的，那就不要重复创建用户了，提醒用户已创建
|
||||
|
||||
## 渠道管理
|
||||
- 销售渠道维护管理功能。
|
||||
- 渠道基础信息表：渠道名称、统一社会信用代码、渠道类型（yy - 医院、hzjg - 合作机构 、 zs - 诊所、 zfjg - 政府机构 、qt - 其他 ）、联系人姓名、联系电话、联系邮箱、渠道协议附件、备注
|
||||
- 渠道开票信息子表：一个渠道可能会有多个开票信息。核心字段：单位名称、税号、单位地址、电话、开户银行、银行账号
|
||||
- 渠道邮寄地址信息子表：一个渠道可能会有多个邮寄地址。 核心字段：邮寄地址、邮寄联系人、邮寄联系电话
|
||||
- 渠道协议信息子表：协议类型（ kyxy - 科研协议、 zsxy - 中试协议 、 lcxy - 临床协议）, 业务类型 （如果 协议类型 为 科研协议 ， 业务类型 就是 kyyy - 科研应用 ， 如果协议类型 为 中试协议， 业务类型 就是 中试应用 ， 如果 协议类型 为 临床协议， 业务类型为 临床应用）、结算方式（ yj - 月结、 jj - 季结 、 nj - 年结 、dcjs - 单次结算）、授信额度（元）、生效日期（YYYYMMDD）、到期日期（YYYYMMDD）、协议状态（**协议状态这个字段先保留，后续在设计怎么使用**）
|
||||
- 渠道协议信息子表-细胞项目价格表，核心字段：项目编码、项目名称、细胞类型、规格、原价（元）、协议价（元）
|
||||
|
||||
## 细胞服务项目细胞类型管理
|
||||
- 细胞类型维护管理模块，细胞产品类型表 核心字段：细胞产品类型编码、细胞产品类型名称
|
||||
|
||||
## 细胞服务项目细胞规格管理
|
||||
- 细胞服务项目细胞规格管理模块、细胞规格表 核心字段： 细胞规格编码、细胞规格名称
|
||||
|
||||
## 细胞服务项目价格管理
|
||||
- 细胞服务项目价格体系维护管理模块。 细胞服务项目总表的核心字段：项目名称、项目编码、细胞类型编码[细胞服务项目细胞类型管理]、细胞类型名称[细胞服务项目细胞类型管理]、规格[细胞服务项目细胞规格管理]、单价
|
||||
|
||||
## 细胞服务项目价格体系管理
|
||||
- 细胞服务项目价格体系管理，就是将多个细胞项目组合在一起，方便后续跟渠道签协议时候使用
|
||||
- 细胞服务项目价格体系总表，核心字段： 体系名称、体系编码、状态（1 - 正常、 0 - 停用）
|
||||
- 细胞服务项目价格体系细胞价格子表，从[细胞服务项目总表]选择项目，调整价格形成的。核心字段[细胞服务项目价格管理]：项目编码、项目名称、细胞类型、规格、单价
|
||||
|
||||
# 系统基础模块
|
||||
|
||||
## 租户管理
|
||||
- 此模块给超级系统管理员superadmin 使用
|
||||
- 租户信息包括：id，租户编号（用户自由编排），租户名称、联系人姓名、联系电话
|
||||
- 目前系统就一个租户： 中科兴皖，租户编号 zkxw
|
||||
|
||||
## 组织管理
|
||||
- 要支持多级组织
|
||||
- 组织信息表sys_dept,核心字段包括：组织id、组织名称、父组织id、组织类别编码（数据见字典表，字典类型的编码：zzlbbm）、部门状态（0 - 停用 ， 1 - 正常）、部门负责人、部门负责人联系电话、排序号
|
||||
- 当前中科兴皖的组织：市场营销部门（下设 采集部、临床部、中试服务部、支持中心、客服部） 、技术研发部、生产部、质量安全部、财务部、综合部
|
||||
|
||||
## 用户管理
|
||||
- 支持对组织下的用户进行管理
|
||||
- 用户表：sys_user，核心字段
|
||||
```sql
|
||||
`dept_id` bigint(20) DEFAULT NULL COMMENT '部门ID',
|
||||
`user_no` varchar(30) NOT NULL COMMENT '用户账号',
|
||||
`nick_name` varchar(30) NOT NULL COMMENT '用户名',
|
||||
`email` varchar(50) DEFAULT '' COMMENT '用户邮箱',
|
||||
`phone_no` varchar(11) DEFAULT '' COMMENT '手机号码',
|
||||
`sex` char(1) DEFAULT '0' COMMENT '用户性别（0 - 男 1 - 女 2 - 未知）',
|
||||
`avatar` bigint(20) DEFAULT NULL COMMENT '头像地址（minio上图片的完整访问地址）',
|
||||
`password` varchar(100) DEFAULT '' COMMENT '密码',
|
||||
`status` char(1) DEFAULT '0' COMMENT '帐号状态（1- 正常， 0 -停用）',
|
||||
```
|
||||
|
||||
## 角色管理
|
||||
- 支持系统角色信息的维护管理。
|
||||
- 角色表 sys_role
|
||||
- ```sql
|
||||
`role_name` varchar(30) NOT NULL COMMENT '角色名称',
|
||||
`data_scope` char(1) DEFAULT '1' COMMENT '数据范围（1：全部数据权限 2：本部门数据权限 3：本部门及以下数据权限 4：仅本人数据权限 5：自定义数据权限 ）',
|
||||
`status` char(1) NOT NULL COMMENT '角色状态（1 正常 0 停用）',
|
||||
```
|
||||
- 在这个模块可以给角色授予用户
|
||||
- 在这个模块可以给角色授予菜单权限
|
||||
- 角色菜单关联表 sys_role_menu
|
||||
``` sql
|
||||
`role_id` VARCHAR(64) NOT NULL COMMENT '角色ID',
|
||||
`menu_id` VARCHAR(64) NOT NULL COMMENT '菜单ID',
|
||||
```
|
||||
- 在这个模块可以给角色授予数据权限,通过角色表的data_scope，但是涉及到了自定义数据权限。
|
||||
- 自定义数据权限表 sys_role_data_scope_detail
|
||||
- ```sql
|
||||
`role_id` bigint(20) NOT NULL COMMENT '角色ID',
|
||||
-- 核心字段：定义“范围”的类型和值
|
||||
`scope_type` varchar(20) NOT NULL COMMENT '范围类型：dept(部门), user(用户)',
|
||||
`scope_value` varchar(100) NOT NULL COMMENT '范围值：部门ID/用户ID',
|
||||
```
|
||||
- **特别注意：一个用户可能会存在多个角色。所以菜单权限和数据权限是要用这个用户所有角色的权限之和**
|
||||
|
||||
## 菜单管理
|
||||
- 在这个模块可以对web端和小程序端的菜单进行维护管理
|
||||
- 系统菜单支持多级菜单模式
|
||||
- 系统菜单表 sys_menu, 核心字段
|
||||
```sql
|
||||
`menu_name` varchar(50) NOT NULL COMMENT '菜单名称',
|
||||
`parent_id` bigint(20) DEFAULT '0' COMMENT '父菜单ID',
|
||||
`is_frame` int(1) DEFAULT '1' COMMENT '是否为外链（1 是 0 否）',
|
||||
`visible` char(1) DEFAULT '0' COMMENT '显示状态（1 显示 0 隐藏）',
|
||||
`status` char(1) DEFAULT '0' COMMENT '菜单状态（1 正常 0 停用）',
|
||||
```
|
||||
|
||||
## 字典管理
|
||||
- 字典管理用于给中科兴皖一体化门户系统中，所有的字典项进行统一管理
|
||||
- 字典数据表 TABLE `sys_dict_data` 核心字段：
|
||||
```sql
|
||||
`dict_label` varchar(100) DEFAULT '' COMMENT '字典标签',
|
||||
`dict_value` varchar(100) DEFAULT '' COMMENT '字典键值',
|
||||
`dict_type` varchar(100) DEFAULT '' COMMENT '字典类型',
|
||||
```
|
||||
- 字典类型表 TABLE `sys_dict_type` 核心字段：
|
||||
```sql
|
||||
`dict_name` varchar(100) DEFAULT '' COMMENT '字典名称',
|
||||
`dict_type` varchar(100) DEFAULT '' COMMENT '字典类型',
|
||||
```
|
||||
- 下面是系统初始化阶段有哪些字典类型及字典数据
|
||||
- 组织类别的类型编码： zzlbbm ， 字典数据 gs - 公司 、 fgs - 分公司、 bm - 部门
|
||||
- 站点类型的类型编码： zdlx ， 字典数据 zxjd - 中心基地
|
||||
- 站点业务范围的类型编码：zdywfw, 字典数据 ybcj - 样本采集、 ybzb - 样本制备 、zljc - 质量检测 、 xbcc - 细胞存储
|
||||
- 客户类型的类型编码： khlx, 字典数据 zskh - 中试客户 、 lckh - 临床客户 、 xbcckh - 细胞存储客户
|
||||
|
||||
|
||||
## 区域管理
|
||||
- 这个模块用于管理中国省市区的数据的
|
||||
- 区域表 sys_region , 核心字段如下
|
||||
```sql
|
||||
`code` varchar(20) NOT NULL COMMENT '行政区划编码',
|
||||
`name` varchar(50) NOT NULL COMMENT '行政区划名称',
|
||||
`short_name` varchar(30) DEFAULT NULL COMMENT '行政区划简称',
|
||||
`parent_code` bigint(20) DEFAULT '0' COMMENT '父级行政区划编码，顶级为0',
|
||||
`level` tinyint(1) NOT NULL COMMENT '层级（1：省，2：市，3：区/县，4：街道/镇）',
|
||||
`status` char(1) DEFAULT '0' COMMENT '状态（1 正常 0 停用）',
|
||||
`longitude` decimal(10,7) DEFAULT NULL COMMENT '经度',
|
||||
`latitude` decimal(10,7) DEFAULT NULL COMMENT '纬度',
|
||||
```
|
||||
|
||||
## 站点管理
|
||||
- 此模块用于维护管理公司站点信息。
|
||||
- 目前就一个站点：中科兴皖
|
||||
- 站点信息包括：站点名称、站点编码（自定义编写）、所属租户、站点类型（字典类型编码 zdlx ）、状态（1 正常 0 停用）、详细地址、联系人、联系电话、业务范围（字典编码的类型编码为：zdywfw）
|
||||
- 这里设置了站点，为了后续细胞存储、细胞生产、质量检测都可以选择站点，目前这个功能不做，默认所有的都在一个站点：中科兴皖
|
||||
|
||||
|
||||
## 职位管理
|
||||
- 这个模块用于职位信息的维护管理，支持职位绑定用户，一个职位可以绑定多个用户，一个用户可以绑定多个职位
|
||||
- 职位表 sys_post,核心字段包括： 职位名称、职位编码、排序号、状态（1 正常 0 停用）
|
||||
- 职位与用户关联表 sys_user_post, 核心字段： 用户id、职位id
|
||||
|
||||
|
||||
## 流程管理
|
||||
流程管理分为两部分：1、流程配置与启用 2、流程办理中心
|
||||
- 本次我们后端采用python语言实现一套全新的工作流系统。 实现目标类似钉钉宜搭工作流（低代码平台那种简易工作流）的配置，
|
||||
- 图形化配置审批流程。流程配置节点和连接线，节点包括但不限于开始节点、结束节点、审批人节点(支持配置用户、支持配置角色等)、条件分支（支持多分支）等节点 。节点之间用连接线进行连接。
|
||||
- 工作流还要支持流程变量：就是申请人的部门id等信息塞入到系统流程变量，也支持发起工作流时候动态塞入流程变量
|
||||
- 审批人节点要支持配置一个用户、支持配置多个用户、支持配置一个角色、支持配置多个角色、同时还要支持通过sql模式找到审批人（通过sql模式结合流程变量，就可以实现当前申请人部门的主管审批这样的场景）。
|
||||
- 审批人节点还支持配置一个人审批通过就算通过，还是所有配置审批人都审核通过了才算通过
|
||||
- 条件分支支持两个条件、也支持多个条件（例如，金额小于等于100，金额大于100，小于300， 金额大于等于300）走不同的分支。这里金额就是一个动态的流程变量
|
||||
- 工作流配置好了，下一步就是业务工单发起工作流，工作流的待办中心、已办中心。
|
||||
**这里后续在讨论，目前方案有两种：1、自研 2、使用三方的工作流，然后通过API方式对接。 目前个人建议自研**
|
||||
|
||||
|
||||
## 物品单位管理
|
||||
- 记录物品单位的表，核心字段： 单位编码、单位名称 (例如：单位编码 g 、 单位名称 克)
|
||||
|
||||
## 快递公司管理
|
||||
- 维护快递公司信息表，核心字段：快递公司编码、快递公司名称
|
||||
|
||||
|
||||
# 技术要求
|
||||
- mysql 5.7 数据库
|
||||
- 所有表都有的公共字段
|
||||
- `id` VARCHAR(64) NOT NULL COMMENT '主键ID', 采用UUID
|
||||
- `tenant_no` VARCHAR(64) NOT NULL DEFAULT 'zkxw' COMMENT '租户编号'
|
||||
- `order_num` int NULL COMMENT '排序号'
|
||||
- `remark` varchar(512) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '备注',
|
||||
- `create_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '创建人id',
|
||||
- `create_dept_id` VARCHAR(64) NOT NULL COMMENT '创建人部门ID',
|
||||
- `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
|
||||
- `update_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '更新人id',
|
||||
- `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
|
||||
- `del_flag` tinyint(4) NOT NULL DEFAULT '0' COMMENT '删除标记：0 - 正常 1 - 已删除',
|
||||
- 所有数据都不可以直接删除，都必须要用虚拟删除（0/1， 0 表示 未删除， 1 表示 已删除）
|
||||
- 系统中附件都是支持多个附件的、用一个字段存储。存储方式：多个附件的minio地址用逗号分隔
|
||||
- API接口返回数据在没有特殊排序要求的，都是按照创建时间倒序排列
|
||||
- 文档中对于信息字段的字典码表描述（例如：状态（dsx - 待生效 、 sxz - 生效中、 ygq - 已过期 、 yzf - 已作废、 zky - 转科研）），最终都要集合到[字典管理]统一管理
|
||||
- 后端用python语言
|
||||
- 前端用 https://github.com/Daymychen/art-design-pro 这个开源的框架，然后使用pnpm clean:dev 进行精简，在精简版本上开发
|
||||
- 小程序端使用hbuilderx创建一个空的UNI-app工程，然后在这个工程上使用vue3、vant-ui来开发业务功能
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+278
@@ -0,0 +1,278 @@
|
||||
# 1、客户口述的需求
|
||||
- 公司介绍：中科兴皖，是一家做细胞医疗服务的。 主要业务是存储产妇脐带血，干细胞治疗等
|
||||
- 公司分为六大部分：市场营销部门（下设 采集部、临床部、中试服务部、支持中心、客服部） 、技术研发部、生产部、质量安全部、财务部、综合部
|
||||
- 公司主营业务：细胞存储、细胞培养及医疗应用
|
||||
|
||||
|
||||
## 1.1、细胞存储
|
||||
- 业务流程：
|
||||
采集专员创建细胞存储协议单，细胞存储协议单创建后会触发两个流程：一个签订协议缴费流程 ，一个是采集、运输、检测、入库的流程
|
||||
- 签订协议缴费流程：采集专员在现场跟客户线下签订协议，将签订的协议拍照上传到系统，用户缴费的截图上传到系统。由市场支持专员审核后，标注为已缴费
|
||||
- 采集、运输、签收、检测、入库的流程：采集专员在现场采集到细胞样本后，通过快递或其他方式将样本送到站点、站点签收，如果这时候发现样本不合理，此样本作废。流程终止。如果样本正常签收 。 签收成功后会触发两个流程：样本检测、样本制备。 样本检测如果不正常，样本作废。 样本制备如果制备异常，制备终止。如果样本检测正常、样本制备正常，最后由质检专员点击，表示该细胞样本入库成功，开始存储了。这中间只要涉及到不成功，都需要给用户退款（退款流程由市场支持专员发起，财务人员完成）
|
||||
- 如果中间客户提出毁约，细胞存储协议单也会被作废掉。给用户退款（退款流程由市场支持专员发起，财务人员完成）
|
||||
|
||||
|
||||
## 1.2、科研捐赠
|
||||
【后续补充】
|
||||
|
||||
## 1.3、中试服务
|
||||
|
||||
|
||||
## 1.4、临床应用
|
||||
【后续补充】
|
||||
|
||||
|
||||
# 2、系统功能菜单
|
||||
|
||||
- 系统管理
|
||||
- 租户管理[2.1.1、租户管理]
|
||||
- 字典管理[2.1.2、字典管理]
|
||||
- 组织管理[2.1.3、组织管理]
|
||||
- 用户管理[2.1.4、用户管理]
|
||||
- 角色管理[2.1.5、角色管理]
|
||||
- 菜单管理[2.1.6、菜单管理]
|
||||
- 站点管理[2.1.7、站点管理]
|
||||
- 职位管理[2.1.8、职位管理]
|
||||
- 物品单位管理[2.1.9、物品单位管理]
|
||||
- 快递公司管理[2.1.10、快递公司管理]
|
||||
- 细胞存储管理
|
||||
- 采集协议单[2.2.6、采集协议单]
|
||||
- 采集协议单审核[2.2.7、采集协议单审核]
|
||||
- 采集协议单收款确认（财务确认）[2.2.8、采集协议单收款确认（财务确认）]
|
||||
- 采集协议单退费确认（财务确认）[2.2.9、采集协议单退费确认（财务确认）]
|
||||
- 科研捐赠
|
||||
- 中试服务管理
|
||||
-
|
||||
- 基础信息管理
|
||||
- 客户管理[2.2.1、客户管理]
|
||||
- 细胞样本类型管理[2.2.2、细胞样本类型管理]
|
||||
- 采集地区及医院管理[2.2.3、采集地区及医院管理]
|
||||
- 采集协议号管理[2.2.4、采集协议号管理]
|
||||
- 样本编码管理[2.2.5、样本编码管理]
|
||||
|
||||
## 2.3、中试服务
|
||||
|
||||
|
||||
|
||||
## 2.2、细胞存储管理
|
||||
- 表模型层级关系
|
||||
- 客户信息表: customer
|
||||
- 客户随访表：核心字段客户id、随访时间、随访描述
|
||||
- 细胞样本类型表
|
||||
- 采集地区医院表
|
||||
- 采集协议号表
|
||||
- 样本编码表
|
||||
- 采集协议单表:（id、采集协议号[采集协议号管理]、状态（dsx - 待生效 、 sxz - 生效中、 ygq - 已过期 、 yzf - 已作废、 zky - 转科研）、 协议附件、登记日期（YYYYMMDD）、备注信息、协议生效时间、协议生效描述、协议过期时间、协议过期描述、协议作废时间、协议作废描述、协议转科研时间、协议转科研描述 。 采集协议单状态当前有4个状态、创建协议单时候状态默认 dsx - 待生效 ， 后续提供四个按钮 协议生效、协议过期、协议作废、协议转科研 ，来改变协议状态）
|
||||
- 采集信息表 : (采集协议单id、采集地区[2.2.3、采集地区及医院管理]、采集医院[2.2.3、采集地区及医院管理]、采集医护、销售人员[2.1.4、用户管理][默认当前登录人]、样本采集时间（YYYYMMDD hh:mm:ss）、母血采集时间（YYYYMMDD hh:mm:ss）)
|
||||
- 样本信息表 :（1对多的关系，1个采集协议单会有多个样本信息）(采集协议单id、样本类型[2.2.2、细胞样本类型管理]、样本编码[样本编码管理]、采集量、单位[2.1.9、物品单位管理]、价格、存储年限（年）、样本状态（ycj - 已采集、 jcz - 检测中、 yrk - 已入库、yzf - 已作废）、入库日期（YYYYMMDD）、检测开始日期、作废日期、存储到期日期（YYYYMMDD）（= 入库日期 + 存储年限（年））、备注。 样本状态：创建样本信息时候，默认状态就是 ycj -已采集 。 提供三个按钮 样本检测、样本入库、样本作废，分别来修改样本的状态。 样本检测 按钮点击后，样本状态会变成jcz - 检测中，检测开始日期为当天。样本入库 按钮点击时候，会记录入库日期为当天，样本状态变成 yrk - 已入库。 样本作废 按钮点击后，样本状态就变成了 yzf - 已作废，作废日期 为当天)
|
||||
- 运输信息表 : (一个样本对应一个运输信息，在界面操作时候也支持勾选所有样本录入一份的信息，那就代表这些样本都是同样的快递信息)(采集协议单中样本运输信息表核心字段：采集协议单id、样本id、运输类型（kdys - 快递运输 、 ryxd - 人员携带 ）、快递公司[2.1.10、快递公司管理]、快递单号、目的站点[2.1.7、站点管理]、快递费用（元）、预计到达时间（YYYYMMDD hh:mm:ss）、携带人员姓名、携带人员联系电话。 如果运输类型是 kdys - 快递运输 ，则填写 快递公司、快递单号、目的站点、快递费用（元）、预计到达时间。 如果运输类型是ryxd - 人员携带，则填写 携带人员姓名、携带人员联系电话、目的站点、预计到达时间)
|
||||
- 缴费信息表: (采集协议单中缴费信息主表核心字段： 采集协议单id、缴费方式（dj - 趸交 、 fq - 分期）、合同金额、分期期数、每期间隔（月）、趸交截止时间（YYYYMMDD）、分期开始时间（YYYYMMDD, 缴费方式为fq - 分期，这个字段要填，填写完成后，分期期数、每期间隔（月），就会自动在子表中生成数据 ）)(缴费方式中趸交就是一次性缴费的意思)
|
||||
- 缴费信息子表: (采集协议单中缴费信息子表核心字段：缴费信息主表id、转账方式（wxzz - 微信转账、 zzbzz - 支付宝转账 、 yhkzz - 银行卡转账 、 xj - 现金） 、转账金额、转账时间 、转账附件 、财务确认附件、缴费状态（待缴费、缴费确认中、已缴费、退费确认中、已退费） 分期期数（如果是趸交，这个期数就为空）、分期应缴费时间（YYYYMMDD 缴费方式为分期时候，才有这个值）、备注。 如果为缴费方式为 dj - 趸交， 则只有一条记录。如果为缴费方式 为 fq - 分期，则有分期数一样数目的记录)
|
||||
- 客户信息表: （这里是采集协议单中客户信息表，跟客户信息表 customer 不一样）(客户信息表核心字段：采集协议单id、客户id，母亲姓名、母亲联系电话、母亲身份证号、母亲出生年月（YYYYMM）、母亲民族、母亲家庭住址、父亲姓名、父亲电话、父亲身份证号、新生儿分娩时间、新生儿性别（1 - 男 、0 - 女）、分娩方式（sc - 顺产、 pgc - 剖宫产）、胎次（生育第几胎的意思，生育第一胎就是1 ， 生育第二胎就是2，以此类推） 、 新生儿体重（克）、新生儿评分（1分钟）、新生儿评分（5分钟）、采集专员[用户管理，默认当前登录用户的id])
|
||||
- 审核信息表: (采集协议单有一条审核记录表，核心字段： 采集协议单id、审核人、审核备注、审核状态（shtg - 审核通过、 shth - 审核退回）)
|
||||
- 新生儿满月待办表: (生效中的采集协议单中已满月的新生儿信息， 这个满月待办表中，核心字段：采集单协议id、满月待办状态（1 - 已办报销 、 0 - 未办保险）、办理日期、办理备注、保险附件)
|
||||
- 储存证表: (生效中的，并且样本已经入库的采集协议单， 储存证表中，核心字段：制作状态（1 - 已制作 ， 0 - 未制作） 储存证图片、制作日期，备注)
|
||||
- 操作日志表: (采集协议单操作日志表：记录针对采集协议单的操作日志信息，需要我们针对协议单的所有操作都要有个编码、名称。方便记录操作日志)
|
||||
|
||||
### 2.2.6、采集协议单
|
||||
- 这个界面展示采集专员自己创建的所有的协议单。这个界面支持协议单的创建、修改、删除
|
||||
- 采集协议单新增弹窗中，要填写客户信息（客户信息可以从客户信息表customer选择，然后将信息带出到母亲信息中。 如果客户信息表customer 没有这块的数据， 在保存采集协议单的时候，会新增或者修改客户信息表customer中的客户信息数据）、采集信息、样本信息、运输信息、缴费信息、协议单信息 、备注
|
||||
|
||||
### 2.2.7、采集协议单审核
|
||||
- 这个界面可以看到所有的采集协议单，这个界面也支持协议单的创建、修改、删除
|
||||
- 增加一个审核按钮，审核弹窗中，可以填写审核备注、审核状态
|
||||
- 增加一个缴费确认发起按钮，点击后，缴费状态变成缴费确认中
|
||||
- 增加一个退费确认发起按钮，点击后，缴费状态变成退费确认中
|
||||
- 增加四个按钮：协议生效、协议过期、协议作废、协议转科研
|
||||
|
||||
### 2.2.8、采集协议单收款确认（财务确认）
|
||||
- 财务人员可以看见所有的采集协议单的所有的缴费部分的内容，可以对状态为缴费确认中的缴费信息单进行缴费确认，上传确认附件
|
||||
|
||||
### 2.2.9、采集协议单退费确认（财务确认）
|
||||
- 财务人员可以看见所有的采集协议单的所有的缴费部分的内容，可以对状态为退费确认中的缴费信息单进行退费确认，上传确认附件
|
||||
|
||||
### 2.2.5、样本编码管理
|
||||
- 此模块用于样本编码维护管理、核心字段：样本编码(32位)、是否下发（1 - 是 、 0 -否）
|
||||
|
||||
### 2.2.4、采集协议号管理
|
||||
- 此模块用于采集协议号表维护管理，核心字段：采集协议号(32位)、是否下发（1 - 是 、 0 -否）
|
||||
|
||||
### 2.2.3、采集地区及医院管理
|
||||
- 此模块用于采集地区和地区内医院的信息。
|
||||
- 采集地区医院表，核心字段：地区名称、医院名称集（医院名称逗号分隔存储）
|
||||
- 这个模块展示采集地区信息，支持采集地区的新增、修改、删除、地区医院的配置。点击【地区医院配置】的按钮弹出弹窗，弹窗中可以进行医院信息的新增、修改、删除
|
||||
- 采集地区跟医院之间是1对多的关系
|
||||
|
||||
### 2.2.2、细胞样本类型管理
|
||||
- 此模块用于维护样本类型表，核心字段包括： 样本类型编码、样本类型名称、样本存储年份、样本存储价格（元）
|
||||
- 目前样本类型有三种：wcqzxgxb - 围产期造血干细胞、qdjczgxb - 脐带间充质干细胞、 tpyqngxb - 胎盘亚全能干细胞
|
||||
- 这个模块提供细胞样本类型信息管理功能，包括新增、修改、删除等功能
|
||||
|
||||
### 2.2.1、客户管理
|
||||
- 每个客户都有个客户标签字段，这个字段存储着客户所有的标签，标签名称之间用逗号分隔。目前客户标签采取手动写标签名称，没有标准的客户标签
|
||||
- 客户信息表customer包括：客户姓名、客户性别（0 - 男 1 - 女 2 - 未知）、身份证号、年龄、联系电话、客户标签（多个标签之间用逗号分隔）。
|
||||
- 客户信息表中，客户姓名必须填写，但不要求唯一，因为存在重名的场景。如果身份证一样的，那就不要重复创建用户了，提醒用户已创建
|
||||
- 这个模块提供一个客户信息展示、新增、修改、删除的功能
|
||||
|
||||
## 2.1、系统管理
|
||||
|
||||
### 2.1.1、租户管理
|
||||
- 此模块给超级系统管理员superadmin 使用
|
||||
- 租户信息包括：id，租户编号（用户自由编排），租户名称、联系人姓名、联系电话
|
||||
- 目前系统就一个租户： 中科兴皖，租户编号 zkxw
|
||||
- 这个模块提供租户的列表展示，提供租户的增加、删除、修改功能
|
||||
|
||||
### 2.1.2、字典管理
|
||||
- 字典管理用于给中科兴皖一体化门户系统中，所有的字典项进行统一管理
|
||||
- 字典数据表 TABLE `sys_dict_data` 核心字段：
|
||||
```sql
|
||||
`dict_label` varchar(100) DEFAULT '' COMMENT '字典标签',
|
||||
`dict_value` varchar(100) DEFAULT '' COMMENT '字典键值',
|
||||
`dict_type` varchar(100) DEFAULT '' COMMENT '字典类型',
|
||||
```
|
||||
- 字典类型表 TABLE `sys_dict_type` 核心字段：
|
||||
```sql
|
||||
`dict_name` varchar(100) DEFAULT '' COMMENT '字典名称',
|
||||
`dict_type` varchar(100) DEFAULT '' COMMENT '字典类型',
|
||||
```
|
||||
- 界面中展示字典类型信息，支持字典类型的新增、修改、删除、字典数据配置的功能。点击【字典数据配置】按钮，弹出弹窗，弹窗中支持字典类型的字典数据的展示、新增、修改、删除的功能
|
||||
|
||||
- 下面是系统初始化阶段有哪些字典类型及字典数据
|
||||
- 组织类别的类型编码： zzlbbm ， 字典数据 gs - 公司 、 fgs - 分公司、 bm - 部门
|
||||
- 站点类型的类型编码： zdlx ， 字典数据 zxjd - 中心基地
|
||||
- 站点业务范围的类型编码：zdywfw, 字典数据 ybcj - 样本采集、 ybzb - 样本制备 、zljc - 质量检测 、 xbcc - 细胞存储
|
||||
- 部门状态的类型编码：bmzt , 字典数据 0 - 停用 ， 1 - 正常
|
||||
|
||||
### 2.1.3、组织管理
|
||||
- 要支持多级组织
|
||||
- 组织信息表sys_dept,核心字段包括：组织id、组织名称、父组织id、组织类别编码（数据见字典表，字典类型的编码：zzlbbm）、部门状态（ 字典类型的编码：bmzt , 0 - 停用 ， 1 - 正常）、部门负责人、部门负责人联系电话、排序号
|
||||
- 当前中科兴皖的组织：市场营销部门（下设 采集部、临床部、中试服务部、支持中心、客服部） 、技术研发部、生产部、质量安全部、财务部、综合部
|
||||
- 界面以树形表单展示组织信息，支持组织的新增、修改、删除、新增子组织等功能
|
||||
|
||||
### 2.1.4、用户管理
|
||||
- 支持对组织下的用户进行管理
|
||||
- 用户表：sys_user，核心字段
|
||||
```sql
|
||||
`dept_id` bigint(20) DEFAULT NULL COMMENT '部门ID',
|
||||
`user_no` varchar(30) NOT NULL COMMENT '用户账号',
|
||||
`nick_name` varchar(30) NOT NULL COMMENT '用户名',
|
||||
`email` varchar(50) DEFAULT '' COMMENT '用户邮箱',
|
||||
`phone_no` varchar(11) DEFAULT '' COMMENT '手机号码',
|
||||
`sex` char(1) DEFAULT '0' COMMENT '用户性别（0 - 男 1 - 女 2 - 未知）',
|
||||
`avatar` bigint(20) DEFAULT NULL COMMENT '头像地址（minio上图片的完整访问地址）',
|
||||
`password` varchar(100) DEFAULT '' COMMENT '密码',
|
||||
`status` char(1) DEFAULT '0' COMMENT '帐号状态（1- 正常， 0 -停用）',
|
||||
```
|
||||
- 界面分左右两部分、左侧用树形结构展示组织信息。点击组织信息[2.1.3、组织管理]，右侧列表中就会展示出来当前组织下的用户。在右侧区域支持组织下用户的新增、修改、删除、停用等操作
|
||||
|
||||
### 2.1.5、角色管理
|
||||
- 支持系统角色信息的维护管理。
|
||||
- 角色表 sys_role
|
||||
- ```sql
|
||||
`role_name` varchar(30) NOT NULL COMMENT '角色名称',
|
||||
`data_scope` char(1) DEFAULT '1' COMMENT '数据权限范围（1：全部数据权限 2：本部门数据权限 3：本部门及以下数据权限 4：仅本人数据权限 5：自定义数据权限 ）',
|
||||
`status` char(1) NOT NULL COMMENT '角色状态（1 正常 0 停用）',
|
||||
```
|
||||
- 在这个模块可以给角色授予用户
|
||||
- 在这个模块可以给角色授予菜单权限
|
||||
- 角色菜单关联表 sys_role_menu
|
||||
``` sql
|
||||
`role_id` VARCHAR(64) NOT NULL COMMENT '角色ID',
|
||||
`menu_id` VARCHAR(64) NOT NULL COMMENT '菜单ID',
|
||||
```
|
||||
- 在这个模块可以给角色授予数据权限,通过角色表的data_scope，但是涉及到了自定义数据权限。
|
||||
- 自定义数据权限表 sys_role_data_scope_detail
|
||||
- ```sql
|
||||
`role_id` bigint(20) NOT NULL COMMENT '角色ID',
|
||||
-- 核心字段：定义“范围”的类型和值
|
||||
`scope_type` varchar(20) NOT NULL COMMENT '范围类型：dept(部门), user(用户)',
|
||||
`scope_value` varchar(100) NOT NULL COMMENT '范围值：部门ID/用户ID',
|
||||
```
|
||||
- **特别注意：一个用户可能会存在多个角色。所以菜单权限和数据权限是要用这个用户所有角色的权限之和**
|
||||
|
||||
- 界面展示角色信息列表，支持角色的新增、修改、删除、角色菜单配置、角色数据权限配置。
|
||||
- 【角色菜单配置】按钮点击弹出弹窗，弹窗中列表树形结构方式展示菜单信息[2.1.6、菜单管理],树形结构节点前面有个多选框，支持勾选。勾选子菜单默认会将父菜单一起勾选上
|
||||
- 【角色数据权限配置】按钮点击弹出弹窗，弹窗中支持用户下拉框方式选择数据权限范围（1：全部数据权限 2：本部门数据权限 3：本部门及以下数据权限 4：仅本人数据权限 5：自定义数据权限 ），当用户选择了自定义数据权限。弹窗下方区域左侧支持勾选组织[2.1.3、组织管理](勾选子组织不会将父组织勾选上)、右侧支持勾选用户[2.1.4、用户管理]
|
||||
|
||||
#### 2.1.5.1、角色表 sys_role、角色菜单关联表 sys_role_menu、自定义数据权限表 sys_role_data_scope_detail的层级关系
|
||||
- 角色表 sys_role
|
||||
- 角色菜单关联表 sys_role_menu
|
||||
- 自定义数据权限表 sys_role_data_scope_detail
|
||||
|
||||
### 2.1.6、菜单管理
|
||||
- 在这个模块可以对web端和小程序端的菜单进行维护管理
|
||||
- 系统菜单支持多级菜单模式
|
||||
- 系统菜单表 sys_menu, 核心字段
|
||||
```sql
|
||||
`menu_name` varchar(50) NOT NULL COMMENT '菜单名称',
|
||||
`parent_id` bigint(20) DEFAULT '0' COMMENT '父菜单ID',
|
||||
`is_frame` int(1) DEFAULT '1' COMMENT '是否为外链（1 是 0 否）',
|
||||
`visible` char(1) DEFAULT '0' COMMENT '显示状态（1 显示 0 隐藏）',
|
||||
`status` char(1) DEFAULT '0' COMMENT '菜单状态（1 正常 0 停用）',
|
||||
```
|
||||
- 系统默认有两个数据，分别是 1 - web端菜单， 2 - 移动端菜单，这两个菜单数据的parent_id = 0 。其他菜单数据都在这两个节点下创建。
|
||||
- 界面以树形结构展示菜单数据，支持菜单数据的新增、修改、删除、新增子菜单。
|
||||
|
||||
### 2.1.7、站点管理
|
||||
- 此模块用于维护管理公司站点信息。
|
||||
- 目前就一个站点：中科兴皖
|
||||
- 站点信息包括：站点名称、站点编码（自定义编写）、所属租户、站点类型（字典类型编码 zdlx ）、状态（1 正常 0 停用）、详细地址、联系人、联系电话、业务范围（字典编码的类型编码为：zdywfw）
|
||||
- 这里设置了站点，为了后续细胞存储、细胞生产、质量检测都可以选择站点，目前这个功能不做，默认所有的都在一个站点：中科兴皖
|
||||
|
||||
### 2.1.8、职位管理
|
||||
- 这个模块用于职位信息的维护管理，支持职位绑定用户，一个职位可以绑定多个用户，一个用户可以绑定多个职位
|
||||
- 职位表 sys_post,核心字段包括： 职位名称、职位编码、排序号、状态（1 正常 0 停用）
|
||||
- 职位与用户关联表 sys_user_post, 核心字段： 用户id、职位id
|
||||
- 职位表和职位与用户关联表的关系
|
||||
- 职位表
|
||||
- 职位与用户关联表
|
||||
- 界面中展示职位信息，支持职位信息的新增、修改、删除、职位用户配置。点击【职位用户配置】按钮，弹出弹窗，弹窗中展示用户信息[2.1.4、用户管理]，支持勾选多个用户
|
||||
|
||||
### 2.1.9、物品单位管理
|
||||
- 记录物品单位的表，核心字段： 单位编码、单位名称 (例如：单位编码 g 、 单位名称 克)
|
||||
|
||||
### 2.1.10、快递公司管理
|
||||
- 维护快递公司信息表，核心字段：快递公司编码、快递公司名称
|
||||
|
||||
### 2.1.11、流程管理
|
||||
流程管理分为两部分：1、流程配置与启用 2、流程办理中心
|
||||
- 本次我们后端采用python语言实现一套全新的工作流系统。 实现目标类似钉钉宜搭工作流（低代码平台那种简易工作流）的配置，
|
||||
- 图形化配置审批流程。流程配置节点和连接线，节点包括但不限于开始节点、结束节点、审批人节点(支持配置用户、支持配置角色等)、条件分支（支持多分支）等节点 。节点之间用连接线进行连接。
|
||||
- 工作流还要支持流程变量：就是申请人的部门id等信息塞入到系统流程变量，也支持发起工作流时候动态塞入流程变量
|
||||
- 审批人节点要支持配置一个用户、支持配置多个用户、支持配置一个角色、支持配置多个角色、同时还要支持通过sql模式找到审批人（通过sql模式结合流程变量，就可以实现当前申请人部门的主管审批这样的场景）。
|
||||
- 审批人节点还支持配置一个人审批通过就算通过，还是所有配置审批人都审核通过了才算通过
|
||||
- 条件分支支持两个条件、也支持多个条件（例如，金额小于等于100，金额大于100，小于300， 金额大于等于300）走不同的分支。这里金额就是一个动态的流程变量
|
||||
- 流程配置支持版本号、因为有的流程通过老版本的流程发起的，还需要继续按照老版本运行。后续新增的都是按照新版本号流程
|
||||
- 工作流配置好了，下一步就是业务工单发起工作流，工作流的待办中心、已办中心。
|
||||
- 流程管理模块预计的功能模块
|
||||
- 流程配置管理
|
||||
- 待办中心
|
||||
- 已办中心
|
||||
|
||||
|
||||
# 3、技术要求
|
||||
- mysql 5.7 数据库
|
||||
- 所有表都有的公共字段
|
||||
- `id` VARCHAR(64) NOT NULL COMMENT '主键ID', 采用UUID
|
||||
- `tenant_no` VARCHAR(64) NOT NULL DEFAULT 'zkxw' COMMENT '租户编号'
|
||||
- `order_num` int NULL COMMENT '排序号'
|
||||
- `remark` varchar(512) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '备注',
|
||||
- `create_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '创建人id',
|
||||
- `create_dept_id` VARCHAR(64) NOT NULL COMMENT '创建人部门ID',
|
||||
- `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
|
||||
- `update_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '更新人id',
|
||||
- `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
|
||||
- `del_flag` tinyint(4) NOT NULL DEFAULT '0' COMMENT '删除标记：0 - 正常 1 - 已删除',
|
||||
- 创建表模型时候，业务字段放在id后面、其他的字段如tenant_no、order_num、remark、create_by、create_dept_id、create_time、update_by、update_time、del_flag放在业务字段后面
|
||||
- 所有数据都不可以直接删除，都必须要用虚拟删除（0/1， 0 表示 未删除， 1 表示 已删除）
|
||||
- 系统中附件都是支持多个附件的、用一个字段存储。存储方式：多个附件的minio地址用逗号分隔
|
||||
- API接口返回数据在没有特殊排序要求的，都是按照order_num正序排列、创建时间倒序排列
|
||||
- 后端用python语言
|
||||
- 后端API查询接口都需要带上tenant_no = 当前登录人的tenant_no进行查询。后端API查询接口都需要带上当前登录人的数据权限之和进行查询
|
||||
- 后端API操作类接口，需要表信息中的tenant_no 修改为 当前登录人的tenant_no
|
||||
- 前端用 https://github.com/Daymychen/art-design-pro 这个开源的框架，然后使用pnpm clean:dev 进行精简，在精简版本上开发
|
||||
- 小程序端使用hbuilderx创建一个空的UNI-app工程，然后在这个工程上使用vue3、vant-ui来开发业务功能
|
||||
|
||||
|
||||
# 4、术语库
|
||||
- 趸交 - 一次性缴费
|
||||
Reference in new issue
Block a user