应用启用与停用：开通状态、设置权限与关联业务检查｜云上订货系统
云上订货 · 更新于 2026-10-08
应用启停要分别回答“本企业是否具备这个应用”“谁能改变状态”和“改变后哪些业务受到影响”。应用中心能看到介绍，不能直接认定已经开通；我的应用有卡片，也不能认定每个员工都能设置。启用后的状态、具体配置和实际使用结果各自回验；停用前先核活动、商品库存和资金关联，遇到限制沿原对象处理。不能用反复切换开关、删除原单据或放开全部权限证明功能正常。
从PC应用页确认企业和目标应用
管理员登录正确企业，在PC管理端进入“应用”。页面区分“我的应用”和“应用中心”：前者用于查企业应用及状态，后者展示平台应用介绍、分类及价格等信息。先用应用名称辨认目标，再核当前页签与分类；分类筛选可能隐藏卡片，清除筛选后再判断缺失。不能因同名业务菜单存在，就把菜单节点当作应用已经开启的依据。
图1：历史PC应用页的两个页签可帮助辨认入口；本企业的开通与启停结果仍须查询目标应用。
“我的应用”的可见范围还与员工角色有关。普通员工没有看到卡片时，先让有权限的管理员在同一企业核目标应用，再检查该员工角色，而不是立即重复申请开通。应用中心的免费、专业版免费、价格或开发中提示属于平台展示信息，应结合本企业当前版本及实际开通记录判断；开发中的卡片不能当作已经可以使用的功能。
固定本次企业、应用名称、原状态、操作账号和变更目的。原状态未知时先查询，不凭截图颜色猜测；缺少开通资格或操作权限时先处理对应条件。开通、启用、员工授权是不同动作，完成记录应说清当前完成了哪一个。旧截图只帮助辨认界面，本次使用是否生效仍要回到当前应用和具体业务。
图2：按企业开通、应用状态、设置权限和实际配置逐层核对，某一层满足不能代替其余层。
开通、角色、设置权限和数据范围分别核
找到卡片后，核当前员工是否具有该应用的设置权限。“我的应用”卡片的设置区域和状态开关并非无条件展示；没有设置区域时先核角色及按钮授权。停用应用的“设置”可能呈灰置，不能把灰置直接解释为配置丢失。应用启用后能进入详情，也不等于能保存全部业务参数，实际可执行操作还要核对应按钮权限。
管理员沿原员工编号核角色、菜单、按钮及字段范围，不以职位名称代替授权。给应用设置权限时，确认本次是允许查看介绍、进入配置还是改变状态；不要为了出现一个开关就授予所有菜单。不同员工看到的应用状态结果可能包含各自角色范围，应在同一企业、同一目标应用下比较，不能混用管理员与普通员工画面推断故障。
图3：历史员工权限页的客户、仓库、时间、角色及按钮字段分层；这些字段不等于应用开关，需分别回读。
应用已启用而原客户、商品或单据不可见时，再核客户区域、负责客户、仓库、自提点、供应商及时间数据范围。指定范围还需选中实际对象。某员工看不到旧单据，可能是时间或对象范围限制，不应直接重新建单。按批准范围核一个应当可见的原对象及一个无权对象，业务授权结果不能只靠应用页卡片证明。
配置人员与使用人员可以不同。管理员完成开关和参数保存后，由实际员工登录正确企业检查原业务入口、应有数据和岗位操作；设置成功的提示只是本次请求结果。若当前页面还保持旧状态，先刷新并重新查询目标应用与权限，保留前后结果，不承诺所有PC或手机终端会在同一时刻自动更新。
启用后按原应用回读配置和使用结果
启用前确认原状态确为停用，并检查该应用的前置资料和业务安排。执行目标卡片的状态操作后，失败先保留原提示和原状态；成功则刷新查询同一应用。页面会刷新权限和应用状态，但仍需核具体设置。不要一次开启多项应用，再把后续变化统称为某一个开关的效果，否则发生失败时无法对应首次变更。
部分应用首次启用会初始化自身设置或默认资料，具体规则各不相同。启用后进入该应用的设置页核实际内容，再补齐本次业务需要的对象、规则和接收人员。已有设置要回读，不能认为再次启用必然恢复原参数，也不能把默认值视为企业已经批准的业务条件。涉及客户或资金口径时，应由对应负责人确认后续承接。
图4：状态请求、配置保存、员工权限和原业务使用分开验收；失败先固定首次提示，不重复切换试成功。
多币种启用是需要额外确认的分支：页面先提示开启后不能关闭，并要求选择本位币。确认币种与现有资金业务一致后再执行。该页面的启用状态请求与企业本位币保存先后进行，任一步失败都要分别查询应用状态及币种资料，不能只凭“设置成功”认定两项已经一致。不要把改本位币当作恢复其他应用入口的方法。
启用某项应用可能涉及相关应用或集团商店同步，不能默认只影响当前一张卡片。集团场景先确认变更范围、商店和使用人员，再逐个回读实际结果。总企业可见不证明每个商店已一致，原订单、库存及资金记录也不会因为开关变化就自动完成。需要验证时沿原编号查询结果，不为了验证重复提交真实业务。
停用先核活动、商品库存和不可逆限制
停用前清点目标应用正在承接的业务，并安排后续处理人员。不同应用不能共用“没有在途订单就能关闭”的条件。商品预售关闭时，如果存在正在预售的商品，页面会提示关闭将结束预售活动；取消确认应保持原状态。确认前核活动及原商品，接受结束影响后才处理，不把关闭应用当作暂停后可无损恢复原活动。
商品串号的停用需要核商品资料和库存关联。存在启用序列号的有效商品，或存在在库商品序列号，会出现不可关闭提示；这不是单纯的设置权限问题。回到对应商品和原序列号库存，查明实际关联及未完成业务。不得为了通过停用校验删除真实库存、改空商品标记或作废原单据，必要处理仍走正常库存业务。
图5：历史商品串号卡片显示设置入口及状态开关；能否关闭需核原商品、在库序列号和实际返回。
图6：预售结束活动、串号商品库存拦截和已开启不可关闭限制分别处理，不套统一停用条件。
商城装修在应用页存在不允许关闭的提示；多币种和凭证汇集也有已开启不可关闭限制。遇到明确限制就保留当前状态及提示，不连续点击或寻找旧入口绕过。重新登录、更换员工、清浏览器缓存不能替代业务规则处理。是否提供其他调整方式，应回到该应用具体配置，不擅自承诺可以关闭、删除或恢复开通前全部数据。
资金相关应用还有独立的启用依赖和互斥条件。例如自动分账结算需要核销售设置中的支付方式，且与订单资金分账存在互斥。出现此类提示先查原支付配置和另一应用状态，由业务负责人判断调整安排；不要为了开通一项应用临时关闭另一项资金功能。已有资金结果和原订单应继续按原链路核对，应用状态不能替代账款核验。
回验原业务，不用再次启停掩盖首次失败
变更后先刷新同一企业的应用卡片，记录状态与设置入口，再查询实际配置。原状态未改变、参数保存失败、员工没有权限、原业务对象不可见是不同结果，应分别说明。回验时使用原应用及原业务编号，不能换到另一个企业或新建一个空对象来证明原问题已解决。取消、明确失败及未完成的结果都要保留，不写成已生效。
图7：沿开通、状态、权限、参数和关联业务保留首个差异，最终结果分别回读原对象。
停用后的核验还包括原活动是否结束、原商品与序列号库存是否仍按正常记录存在、原单据能否继续由指定人员处理。开关关闭不代表欠款清零、订单完成或历史记录消失。原流程设置的审核、出入库、确认节点属于另一类设置，不能据此推断应用状态。需要调整业务流程时另按对应设置与原下游单据处理。
实际员工在变更后重新查业务范围和必要操作。能看到应用而不能保存，继续核按钮或参数；能保存配置但没有预期业务结果，查对应原记录与后续处理。企业与集团商店分别记录结果，不能只用总企业一张画面验收。需要通知承接人员时说明应用名称、状态变化、影响对象和待处理事项，不把开关操作本身当作交接完成。
留证包含企业、应用名称、变更前后状态、操作时间、使用员工、首次提示、实际参数及关联业务编号；不记录密码或登录凭据。完成记录分别列明状态已回读、配置已核、使用权限已核、原业务结果已确认，尚未核实的部分明确保留。历史界面帮助辨认入口，应用状态、具体配置及原业务结果仍须在本企业分别回读。