|
|
@@ -19,12 +19,18 @@
|
|
|
| 一级类别 | String | 父类别 | 是 |
|
|
|
| 名称 | String | 不可重复 | 是 |
|
|
|
| 排序 | Int | 正整数，数值越大，排序越**靠前** | 是 |
|
|
|
-| 状态 | Enum | 默认类别状态是**显示** | 是 |
|
|
|
+| 状态 | Enum | 默认类别状态：**显示** | 是 |
|
|
|
|
|
|
## 删除资讯信息
|
|
|
+
|
|
|
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
删除类别时判断该类别下是否有资讯，如果有资讯，给出提示。
|
|
|
|
|
|
+
|
|
|
+
|
|
|
## 添加资讯信息
|
|
|
|
|
|
| 第一步 | 第二步 |
|
|
|
@@ -41,41 +47,4 @@
|
|
|
| 概要 | String | 不填则自动截取正文前64个字 | 否 |
|
|
|
| 状态 | Enum | 默认资讯状态是**隐藏** | 是 |
|
|
|
|
|
|
-## 业务说明
|
|
|
-
|
|
|
-### 在线互动
|
|
|
-
|
|
|
-在线互动支持住户和物业员工互发消息，及时沟通确认问题情况。消息内容支持文字和图片（可能扩展支持语音），其中每一张图片都当做一条消息记录处理。住户端在微信服务号提交的图片为微信的mediaId（会过期），需要从微信后台通过接口下载到平台服务器永久存储。物业员工可以在Web端、微信服务号或App端进行图文回复。如果是微信服务号则需要将图片通过mediaId下载到服务器后台。
|
|
|
-
|
|
|
-在线互动内容需要单独设计数据表存储，默认在业主提交报事时将业主提交的报事内容当做在线互动沟通的第一条消息，方便对话时查看。
|
|
|
-
|
|
|
-当有新的消息时，在接收方未读的情况下，需要标识该消息对于接收方是未读的（住户发送的消息对物业方来说是未读的物业方发送的消息对于住户来说是未读的）。在主表中需要统计双方的未读消息数量，以便在前端展示。
|
|
|
-
|
|
|
-### 确认解决
|
|
|
-
|
|
|
-当处理人员完成事项处理后，可以确认该事项已经解决。确认解决成功后将推送消息告知住户其提报事项已经解决，此时住户可以对处理过程进行评价。
|
|
|
-
|
|
|
-### 评价
|
|
|
-
|
|
|
-当事项处理完成后，住户可以对服务进行评价，评价包括评分和评价内容。评分按5分制，最低1分，最高5分。评价内容为必填数据项。评价界面如下图所示。
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-### 列表排序
|
|
|
-
|
|
|
-列表排序按照数据的更新时间降序排序，方便及时查看最新动态。当有新的未读消息，业务状态变更时需要更新数据的更新时间字段。
|
|
|
-
|
|
|
-## 流程记录
|
|
|
-
|
|
|
-整个事件的状态流转需要单独记录，记录事件发生的时间，操作人，操作方（用户还是物业公司），操作行为，具体有如下状态。
|
|
|
-
|
|
|
-| 状态 | 操作方 | 行为 | 示例 |
|
|
|
-| --- | ---- | --------------- | ------------- |
|
|
|
-| 待受理 | 用户 | 用户提交报事 | xxx提交投诉 |
|
|
|
-| 已受理 | 物业公司 | 员工受理报事 | xxx受理，指派xxx处理 |
|
|
|
-| 已驳回 | 物业公司 | 员工驳回报事 | xxx驳回 |
|
|
|
-| 已解决 | 物业公司 | 员工报事已解决 | xxx完成 |
|
|
|
-| 已解决 | 用户 | 用户确认事项已解决 | xxx确认已解决 |
|
|
|
-| 已评价 | 用户 | 用户对已解决的事项进行评分评价 | xxx提交评价，评分5 |
|
|
|
|
|
|
-已解决可以是用户确认也可以是工作人员确认。注意的是同一项事务的状态不允许重复提交，已受理的如不允许重复受理，已解决的不允许重复提交解决。【】
|
mayiyuan