update

dev-apply/src/main/java/com/tykj/dev/device/apply/controller/DeviceApplyController.java

@@ -119,7 +119,7 @@ public class DeviceApplyController {
     @PostMapping("/addDeviceApplyBill")
     @Transactional(rollbackFor = Exception.class)
     public ResponseEntity addDeviceApplyBill(@RequestBody @Validated DeviceApplySaveVo deviceApplySaveVo) {
-        //装备申请
+        //不是装备申请
         if (deviceApplySaveVo.getApplyType()!=1) {
             for (ApplyBillDetailVo applyBillDetailVo : GetTreeUtils.splitTree2(deviceApplySaveVo.getStorageBillDetailVoList(),ApplyBillDetailVo::getChilds)) {
                 //判断该装备是否存在装备库
@@ -423,6 +423,7 @@ public class DeviceApplyController {
     public ResponseEntity uploadFile(@RequestBody @Validated UploadApplyFile uploadApplyFile) {
         TaskBto taskBto = taskService.get(uploadApplyFile.getTaskId());
         taskService.addInvolveUser(taskBto, userUtils.getCurrentUserId());
+        //不同意
         if (uploadApplyFile.getStatus()==0){
             taskService.moveToEnd(taskBto);
             List<Integer> userIds = userPublicService.findOtherUser(userUtils.getCurrentUserId());

dev-repair/src/main/java/com/tykj/dev/device/repair/controller/RepairController.java

@@ -532,6 +532,7 @@ public class RepairController {
         repairBill.setRepairStatus(4);
         if (repairReceiveVo.getReceiveUserbId()!=null) {
             repairBill.setRepairUserB(userPublicService.getOne(repairReceiveVo.getReceiveUserbId()).getName());
+            repairSendBill.setRepairUserbId(repairReceiveVo.getReceiveUserbId());
         }
         if (repairReceiveVo.getStartUserbId()!=null){
             repairSendBill.setStartUserbId(repairReceiveVo.getStartUserbId());
@@ -743,12 +744,10 @@ public class RepairController {
             messageService.add(messageBto1);
         }
         //收件方经办人
-//        if (fileUploadVo.getRepairUserbId()!=null){
-//            repairSendBill.setRepairUserbId(fileUploadVo.getRepairUserbId());
-//            repairBill.setRepairUserB(userPublicService.getOne(fileUploadVo.getRepairUserbId()).getName());
-//            MessageBto messageBto2 = new MessageBto(taskBto.getId(), taskBto.getBusinessType(), "被选为经办人", Collections.singletonList(fileUploadVo.getRepairUserbId()), 1);
-//            messageService.add(messageBto2);
-//        }
+        if (fileUploadVo.getRepairUserbId()!=null){
+            repairSendBill.setRepairUserbId(fileUploadVo.getRepairUserbId());
+            repairBill.setRepairUserB(userPublicService.getOne(fileUploadVo.getRepairUserbId()).getName());
+        }
         if (fileUploadVo.getRepairUseraId()!=null){
             repairSendBill.setRepairUseraId(fileUploadVo.getRepairUseraId());
             repairBill.setRepairUserA(userPublicService.getOne(fileUploadVo.getRepairUseraId()).getName());

docs/交接文档(完整).md

-## 交接文档
-
-#### 列装流程：
-
-###### 库表设计
-
-PackingLibrary:设备列装库，通过partParentId来绑定父子列装，最大一级为列装目录（isRoot=1，partParentId=null，	  isPart=null）,列装目录下一级为列装装备（isRoot=0，partParentId=父目录id，isPart=0(代表是装备)），列装装备下都是配件（isRoot=0，partParentId=父装备id，isPart=1(代表是配件)）
-
-父子结构合并或拆分方法：GetTreeUtils工具类
-
-PackingLog:存放该列装的操作日志
-
-###### 流程运转
-
-- 第一级添加列装型号（/packing/add/model），不允许相同型号存在
-- 列装型号下添加列装装备，（/packing/add），不允许当前型号下有配用范围相同且名称相同的装备
-- 发起退装（/retired/form），只能退装型号下装备正常状态数量为0的
-- 删除列装进入回收站（/packing/delete/{id}），递归删除当前列装和子列装（修改列装状态为删除），若当前列装或子列装存在装备抛出异常。
-- 恢复列装（[packing/remove），恢复当前列装和子列装为列装状态为正常
-
-#### 申请流程：
-
-申请分为二类，一类是使省级装备增加的申请，例如装备申请（申请后接着入库）。一类是使省级装备减少的申请，例如退役、报废、销毁申请（申请后接着退役、报废或销毁）。
-
-###### 		库表设计
-
-DeviceApplyBill:存放所有申请账单，applyType确定申请类型，applyStat存放申请的列装信息ApplyBillDetailVo集合的json，记录了申请的序列号区间、申请数量和已入库数量。replyVos只存放报废、退役、销毁申请的不同型号的已完成数量。
-
-###### 流程运转
-
-1.发起申请（/apply/addDeviceApplyBill）
-
-省向上级发起申请，申请文号单据等同于申请单，装备申请填写数量，其他申请填写装备数量以及相应装备的序列号。
-
-2.申请批复（/apply/replay）
-
-上级批复后省录入批复文号单据等同于批复单，可以修改之前填写的数量和序列号，装备申请可以不用填序列号。
-
-3.申请任务待执行
-
-装备申请：点击入库跳转入库界面，相当于导入了该申请任务。导入装备申请任务后完成入库会增加对应列装型号的已入库数量，当所有型号已入库数量等于申请数量，该申请任务办结。其他申请任务出库后退役、报废、销毁会增加对应的已完成数量，当剩余数量为0或剩余装备的状态为丢失等非正常状态时，任务办结。如果所有装备的状态清退完成，直接点击就可以出库，否则提示请完成相应的清退任务。判断是否清退完成接口：/apply/sendBackOver/{id}
-
-#### 入库流程：
-
-可以导入申请任务，分为直接入库（不绑定rfidCardId，入库后可在标签管理打印标签）和打印标签入库（将装备与rfid标签绑定，rfidCardId为24位字符串，末位为装备id，入库后只能在标签管理替换标签）。
-
-- 选择列装型号，填写数量、序列号（可用雪花算法自动生成连续序列号/storage/autoCreate/{num}）并提交
-- 判断入库的序列号是否存在申请任务当中，不存在进行提醒，存在的话入库成功后将对应申请任务的已入库数量增加（/storage/existApplyTask）
-- 将合并的序列号拆分成一件件装备（/storage/addStorageDetail）,同时将同一装备的配件进行绑定，绑定的配件默认排在装备下面
-- 生成装备完成入库（/storage/addStorageBill）
-- 入库办结后补充单据（/storage/addOtherFiles/{taskId}）
-
-#### 配发/退回（出入库）流程：
-
-###### 统一的出入库逻辑
-
-发件方选择装备和收件单位，选择签字或签章进行配发。
-
-###### 		签字配发：
-
-- 发起方默认为A岗（发件方经办人），不用选签发人直接出库，装备生命状态变成配发。此时主配发任务为接收单位的接收装备的待办，同时还有一个子配发任务是发件单位上传回执单的待办。
-- 若发件方在子任务上传回执单并选好其他三个人，子任务和父任务同时办结。装备所属所在改变，生命状态改为在库。
-- 若收件方主动接收装备，装备所属所在生命状态改变，分为上传单据和没上传单据二种情况。若上传了单据并填写了其他二个人，则该任务和子任务办结。若没上传单据，需要在下一个状态的待办里上传单据，下一个状态上传后该任务和子任务办结。
-
-###### 		签章配发：
-
-- 发起方默认为A岗（发件方经办人），申请签章选择签发人提交后，被选的人有一条盖章等待审核的待办，审核通过后才算是签发人。
-- 电子签章审核通过后，二个人都会有等待盖章的待办，任何一方都能盖章出库。若审核不通过，任务退回到草稿的状态。
-- 盖章出库后，接收方也可以申请盖章入库。流程同盖章出库一样，只是审核不通过应该退到待接收装备的状态。盖章完成后业务办结，二方都盖章了不用上传单据，默认保存盖章了的电子单据。
-
-###### 横向/纵向配发
-
-配发给省直属单位（没有专管员和系统）为横向配发，配发给市为纵向配发。对应装备的配用范围为省以下横向和省以下纵向。如果选择的装备的配用范围与实际配发的方向不对，需要判断有没有同级相同名字的列装配用范围正确的，如果有直接将装备的列装绑定改变，否则提示不让配发。
-
-横向配发：省发起后还是省级的待办，需要上传签字单结束。
-
-#### 维修流程：
-
-###### 		库表设计
-
-RepairBill:Task表billId直接关联的维修账单表，存放送修的一些数据
-
-RepairSendBill:deviceRepairBillId与RepairBill绑定，是repairBill的延伸表，存放送修的大部分数据（由于早期设计导致送修存在二张表，可以考虑放在一张表里，这样只需维护一张表）
-
-RepairDetail:维修记录表，每件装备每往上级送修一次产生一条送修记录，对应同一件装备一直往上送的维修记录直接通过父子关系pid来绑定，deviceId绑定装备id，deviceRepairBillId与送修账单RepairBill绑定，repairBackBillId与领取单RepairBackBill绑定。维修管理列表通过维修状态RepairStatus以及所属所在筛选查询出来（对应查询接口：/repair/repairList），所有维修状态存放在RepairStatusEnum里面。
-
-RepairBackBill:维修退回/领取单表，与repairSendBill设计相同，存放领取单的数据
-
-###### 		流程运转
-
-1. 下级送修
-
-   存在本级设备和下级设备是否一起送修的情况。
-
-   从工作台本级管理发起：判断当前单位有没有待维修装备（下级送来的或手动报修的），如果没有直接跳单据页面出库，有的话先添加到待维修装备（对应接口：/repair/add），等待一起送修出库
-
-   维修管理待维修列表发起：勾选维修设备直接跳单据出库（/repair/form）
-
-   注：如果是省发起送修，上级无需签收，发起后任务直接推到上传签收单的状态
-
-2. 上级维修
-
-   分为维修完成和继续送修二种情况。
-
-   维修完成：在待维修列表直接点维修完成（repair/change），改变维修状态，设备跳到待领取列表，等待下级前来领取。若是省级送往上级的装备，省级自己在送修设备中进行操作，可以选择维修完成或装备换新。点击维修完成会直接跳领取单的单据，发起后生成一条办结的维修退回任务（/repair/back/receive）。点击装备换新跳转装备详情页面，修改序列号为新装备的序列号（/repair/changeNew），旧装备状态直接变为已报废，新装备继承所有父装备信息，如果该装备为省级的，状态直接变为在库。旧维修记录状态也变为已报废，在已报废设备列表中显示，新装备维修记录继承旧的，若为省级装备，状态改为已领取入库，否则改为待领取。
-
-   继续维修：从待维修列表点击送修出库（/repair/form），旧维修记录（对应旧的送修单）状态变为等待上级维修装备送回，产生一条新的子维修记录（新的送修单），状态为等待维修。
-
-3. 下级领取
-
-   在上级的待领取列表点击归还出库，判断是否是同一送修单位的装备（/repair/judge)，跳转领取单直接出库（/repair/back）。
-
-#### 自查流程：
-
-工作台或检查管理点击手动自查或终端自查发起。若发起后关闭，产生待自查的待办（/selfCheck/create/{type}）。若发起成功完成（/selfCheck/addBill），业务办结。
-
-###### 周期自查
-
-省设定一个自查周期（可以是1-12个月，/selfCheck/set/cycle/{type}），通过修改生成自查待办的定时任务的corn表达式来周期生成自查待办。
-
-###### 手动自查
-
-上传签字单据后，选好审核人，业务办结。给审核人发阅知。
-
-###### 终端自查
-
-扫手持机生成的二维码，前端将标签epc集合传过来（/selfCheck/compare），后台将校对结果返回。上传签字单据后，选好审核人，业务办结。给审核人发阅知。
-
-#### 业务模块设计：
-
-###### 库表设计
-
-Task:业务表，对于复杂的业务流程使用树形结构（父子）创建task。billStatus表示当前业务状态（StatusEnum存放所有状态），parentTaskId存放父任务id，businessType表示当前业务类型（BusinessTypeEnum存放所有业务状态），billId绑定该业务类型对应账单的主键id,involveUsers存放该业务的参与人员id，currentPoint为当前待办人对应的指针，指向involveUsers中某个用户（一般是最后一个），若指针指的id为0，则表示为ownUnit单位的待办，该单位所有专管员都能看到这个待办。若指的是-1，则只有跟踪，没有人是待办。customInfo存放一些自定义信息，例如"country"代表中央到省业务，自查中会设置这个字段为"手动"，"扫码"来区分是手动还是终端。通过改变task的业务状态来推动业务。
-
-TaskLog:业务日志表，taskId绑定task表。通过Aop加反射实现自动存储业务日志。createUserId代表操作人。
-
-###### Aop设计
-
-LogAspect:通过定义自定义主键@Log，在有该注解的方法上，该方法运行前切入一次获得task旧状态，运行后再切入一次获取新状态后，从日志模板LogType中查询相应日志内容，对于内容中包含的账单字段，通过反射拿到重新组合。单据也会根据新旧状态去对应单据取出来放到日志中（目前版本日志不显示文件了）。
-
-
-