一、需求背景
为支持补偿类型在医院维度上的精细化控制，本次在原有“经销商 / 产品 / 省市补偿类型”基础上，新增“医院补偿类型”能力，并同步打通总部维护侧与 DMS/SOI 应用侧逻辑。
本次改造目标为：
•    总部可维护医院补偿类型关系
•    支持医院补偿类型导入、导出
•    补偿申请选择补偿类型时，按医院规则进行过滤
•    补偿申请新增列表与补偿类型选择逻辑保持一致
---
二、提测范围
1. 总部侧-补偿类型维护
新增“医院”维度的补偿类型维护能力，支持：
•    新增
•    修改
•    查看
•    删除
•    导入
•    导出
2. DMS / SOI 应用侧
在补偿申请相关场景中增加医院维度筛选逻辑，涉及：
•    补偿类型选择弹窗
•    补偿申请新增可选数据列表
•    DMS 端
•    SOI 端
---
三、本次开发内容
1. 总部侧开发内容
1.1 医院补偿类型 CRUD
在补偿类型主档下新增“医院”页签，支持维护医院明细关系。
功能点
•    可选择医院
•    可维护“是否纳入补偿”
•    可查看医院补偿类型明细
•    同一补偿类型下支持多医院维护
•    增加重复校验
业务规则
是否纳入补偿 分两种模式：
•    是：表示当前补偿类型仅对配置的医院生效
•    否：表示当前补偿类型对配置的医院不生效
---
1.2 医院补偿类型一致性控制
同一个补偿类型下，所有医院记录的 是否纳入补偿 必须保持一致，不允许同一补偿类型同时出现“是”和“否”。
已实现
•    前端联动同步
•    后端保存前统一规范化处理
•    导入时一致性校验
---
1.3 医院补偿类型导入
新增医院补偿类型导入能力。
导入规则
•    医院代码必填，且必须存在
•    补偿类型代码必填，且必须存在
•    是否纳入补偿 必填，仅允许填写“是/否”
•    标识必填，仅允许填写“新增/覆盖”
•    同一补偿类型下，是否纳入补偿 必须一致
•    任意一条校验失败，则整批导入失败
标识说明
•    新增：保留原有医院关系，新增本次导入数据
•    覆盖：先清除该补偿类型历史医院数据，再导入本次数据
---
1.4 医院补偿类型导出
新增医院补偿类型导出能力，支持导出以下字段：
•    补偿名称
•    补偿代码
•    医院代码
•    医院名称
•    是否纳入补偿
•    创建时间/创建人
•    修改时间/修改人
---
2. DMS / SOI 应用侧开发内容
2.1 补偿类型选择增加医院筛选逻辑
在补偿申请中选择“补偿类型”时，除原有经销商、产品、省市规则外，新增医院规则过滤。
规则说明
医院条件与原有规则关系为 AND。
即在满足经销商 / 产品 / 省市逻辑的基础上，还需满足医院逻辑。
医院筛选规则
•    若补偿类型未配置医院关系：不限制医院
•    若补偿类型配置为 IsInclude = 1
•    当前医院必须存在于医院补偿配置中
•    若补偿类型配置为 IsInclude = 0
•    当前医院必须不存在于医院补偿配置中
---
2.2 补偿申请新增列表增加同样医院逻辑
为保证补偿申请入口行为一致，补偿申请新增列表同步增加同样的医院筛选逻辑。
已同步场景
•    DMS：CompensateApplicationADD
•    SOI：CompensateApplicationADD_SOI
目标
避免出现以下不一致问题：
•    列表中数据可选，但补偿类型不可选
•    补偿类型可选，但实际列表不应出现
---
四、影响模块
总部维护侧
•    补偿类型主档
•    医院补偿类型子表
•    医院补偿类型导入
•    医院补偿类型导出
应用侧
•    DMS 补偿申请
•    SOI 补偿申请
•    补偿类型选择弹窗
•    补偿申请新增列表
---
五、重点测试场景
1. 总部侧 CRUD 测试
场景 1：新增医院补偿类型
•    新增一个补偿类型
•    关联多个医院
•    是否纳入补偿 = 是
•    保存成功
场景 2：修改医院补偿类型
•    修改已有补偿类型的医院列表
•    修改后保存成功
•    查看明细正常
场景 3：一致性校验
•    同一补偿类型下尝试同时保存“是”和“否”
•    预期：不允许保存 / 系统统一规范化
场景 4：重复医院校验
•    同一补偿类型下重复选择同一家医院
•    预期：不允许重复
---
2. 导入测试
场景 5：正常导入-纳入补偿
•    同一补偿类型导入多个医院
•    是否纳入补偿 均为“是”
•    预期：导入成功
场景 6：正常导入-不纳入补偿
•    同一补偿类型导入多个医院
•    是否纳入补偿 均为“否”
•    预期：导入成功
场景 7：混合导入
•    同一补偿类型下同时导入“是”和“否”
•    预期：导入失败
场景 8：医院代码不存在
•    预期：导入失败
场景 9：补偿类型代码不存在
•    预期：导入失败
场景 10：覆盖导入
•    原有医院关系存在
•    使用“覆盖”重新导入
•    预期：旧数据被替换
---
3. 导出测试
场景 11：医院补偿类型导出
•    从补偿类型列表点击“医院导出”
•    预期：
•    成功下载
•    数据字段完整
•    内容与维护数据一致
---
4. DMS / SOI 应用侧测试
场景 12：未配置医院关系
•    某补偿类型只配置经销商/产品/省市，未配置医院
•    预期：该补偿类型不受医院限制
场景 13：医院纳入补偿
•    配置 IsInclude = 1
•    当前医院在配置内
•    预期：补偿类型可见 / 列表可查
场景 14：医院纳入补偿但不匹配
•    配置 IsInclude = 1
•    当前医院不在配置内
•    预期：补偿类型不可见 / 列表不可查
场景 15：医院不纳入补偿
•    配置 IsInclude = 0
•    当前医院在配置内
•    预期：补偿类型不可见 / 列表不可查
场景 16：医院不纳入补偿且不匹配
•    配置 IsInclude = 0
•    当前医院不在配置内
•    预期：补偿类型可见 / 列表可查
---
5. 联合规则测试
场景 17：省市通过，医院通过
•    预期：可选
场景 18：省市通过，医院不通过
•    预期：不可选
场景 19：省市不通过，医院通过
•    预期：不可选
场景 20：省市与医院都通过
•    预期：最终可用
说明：省市与医院关系为 AND
---
六、注意事项
1.    同一补偿类型下医院关系采用统一模式，不支持部分医院纳入、部分医院排除混用
2.    本次改造不影响现有补偿金额计算公式
3.    本次改造主要影响“补偿类型是否可选”和“申请数据是否可见”
4.    DMS 与 SOI 两侧已同步处理，需分别验证

1) 在模型层新增属性（ViewItem）
在 ..\Wicresoft\BusinessObject\ObjectView\BusinessObjectView.cs 的 ViewItem 中新增了 EndTimeInclude（并提供了对应构造函数），用于标记某个日期查询项是否要“按日期（yyyy-MM-dd）比较”。
---
2) 在查询控件生成阶段把属性下发到 UI 节点
在 ..\SOI\CustomControls\QueryProvider.ascx.cs 的 GenerateQueryItem(ViewItem vi, int rowIndex) 里，增加了：
•    queryItem.Attributes["EndTimeInclude"] = vi.EndTimeInclude.ToString().ToLower();
这样每一行查询项（__queryitem_x）都带上了这个标记。
GridView 的作用是通过 ucQueryProvider.InitQueryProvider(this.BusinessObjectView) 把 BusinessObjectView 传给 QueryProvider，因此 vi.EndTimeInclude 能被拿到并写入 queryItem.Attributes。
---
3) 在过滤拼接阶段按该属性走不同 SQL 逻辑
在 QueryProvider.GetBusinessFilter(...) 的 DateTime 分支中，读取：
•    queryItem.Attributes["EndTimeInclude"]
并做条件拼接分支：
•    非 true：沿用原逻辑（field <= endTime）。
•    true：对字段加 CONVERT(varchar(10), field, 23)，确保按 yyyy-MM-dd 比较后再和结束日期拼接。

ADD DMS  经销商基准价功能：

1.列表及查询及导出去掉有效日期、失效日期、修改创建时间为创建日期、新增修改日期。

2.当前年份字段改成使用年份，列表、查询、导出都改掉。

3.价格字段放到产品编码后面。

4.查询条件增加经销商名称查询

5.导出都按照最新列表内容进行导出。

6.货号升级功能看下代码逻辑，做修改的时候，需要更新modifytime字段

一、当前已改的代码
1. 去掉了 Page_Load 的重复绑定
文件：DMS\OrderInfoMnangerment\OrderInfo\UT_ProductListSelect.aspx.cs
你现在的 InitializeComponent() 里已经把这句注释掉了：
•    this.Load += new System.EventHandler(this.Page_Load);
作用：
•    避免首次打开弹窗时 Page_Load 被重复触发
•    避免 !IsPostBack 里的 ucCustomPaging.LoadData(...) 被多执行一次
---
2. 去掉了 btnQuery 的重复绑定
文件：DMS\OrderInfoMnangerment\OrderInfo\UT_ProductListSelect.aspx.cs
AppendServerEvents() 里原来有两次：
•    this.btnQuery.ButtonClick += ...
现在保留了一次，另一处已注释。
作用：
•    点击“查询”按钮时，避免 btnQuery_ButtonClick() 触发两次
•    避免 GetMyProductInfoList() 被重复调用
---
3. 优化了 GetFilter() 的 SQL 条件拼接
文件：DMS\OrderInfoMnangerment\OrderInfo\UT_ProductListSelect.aspx.cs
这部分是本次真正落地的主要 SQL 优化。
3.1 SSO_SameLotInfo
从：
•    FK_SSO_ProductCategoryID in (...)
改成：
•    exists(select 1 ...)
作用：
•    减少大表 in 子查询带来的额外代价
3.2 UT_OrderDetailInfo
从：
•    ut_product.pkid not in (...)
改成：
•    not exists(select 1 ...)
作用：
•    避免 not in 的执行问题和 NULL 风险
•    更利于索引使用
3.3 SOI_ProductStockAdjust
从：
•    对 StartTime / EndTime 做 CONVERT(...)
改成：
•    StartTime < tomorrowStart
•    EndTime >= todayStart
并且整体改成：
•    not exists(...)
作用：
•    去掉对列的函数转换
•    提升日期范围条件走索引的概率
3.4 FCN_Product
从：
•    CONVERT(nvarchar(10), BuyStartTime, 120) > ...
改成：
•    BuyStartTime >= tomorrowStart
作用：
•    日期字段可走索引
3.5 OPF_ProductSettingRecord + AllowOrderChoose
从：
•    月份比较 CONVERT(nvarchar(7), ...)
•    日期比较 CONVERT(varchar(100), ...)
改成：
•    BeginDate < nextMonthStart
•    EndDate >= monthStart
•    AllowOrderChoose 也改成日期范围比较
作用：
•    去掉月份/日期字符串转换
•    更适合索引
3.6 SOI_ShipToProductPurchase
从：
•    先调用 getShiptoIDCount() 额外查一次
•    再决定是否拼 in (...)
改成：
•    直接一条相关条件：
•    not exists(...) or exists(...)
作用：
•    少一次额外预查询
•    逻辑合并到主 SQL 中
---
二、你当前代码里“虽然没改，但已确认的问题”
1. 弹窗初次打开时多次查询的原因
已确认来源有两个：
•    Page_Load 重复绑定
•    btnQuery 重复绑定
你现在这两个点都已经处理掉了。
2. ucCustomPaging.LoadData(this.GetLastPageNumber(...))
这个仍然保留。
它可能导致：
•    首次打开恢复到旧页码
•    如果旧页码大于总页数，分页控件内部可能再补查一次
这个点还没改。
---
三、已给出但还没正式落地到代码的改动
1. BusinessRule.UT_OrderInfo.GetMyProductInfoList()
文件：..\BusinessRule\OrderInfo\UT_OrderInfo.cs
建议方案已给出，但你还没正式应用到代码里。
核心思路是：
•    删除 subfilter 里重复加的 UT_DealerNetPrice 相关条件
•    把 UT_DealerNetPrice 从“where 过滤”改成“带条件的 inner join”
•    删掉无用的 DOH_ProductLimit join
目的：
•    避免价格表重复过滤
•    尽早缩小结果集
•    让执行计划更清晰
---
四、数据库侧已给出的优化建议
1. 已给出索引创建 SQL
已给出这些表的索引脚本：
•    UT_DealerNetPrice
•    SOI_SDDealerDetails
•    SSO_SameLotInfo
•    UT_OrderDetailInfo
•    SOI_ProductStockAdjust
•    SOI_ProductStockAdjustDetail
•    FCN_Product
•    OPF_ProductSettingRecord
•    AllowOrderChoose
•    SOI_ShipToProductPurchase
•    UT_Product
2. 已给出索引删除 SQL
用于回滚测试。
---
五、目前结论
这次优化的结果可以概括成：
已落地
•    去掉重复事件绑定
•    优化 GetFilter() 里的 in/not in
•    去掉日期字段上的 CONVERT
•    减少一次额外 ShipTo 预查询
未落地但已准备好
•    GetMyProductInfoList() 的 join 改造
•    数据库索引落库执行

https://conyss.uk

1) CC4 修改 order form 的核心逻辑
入口在 ServicesBll.cs 的 case "DMS_RProductFamily"：
•    SpecialParameter == "CC4IsInApproval"：先校验该 CC4 是否在审批流中（CT_CC4IsInApproval）。
•    SpecialParameter == "UpdateProductSalesteam" 且 EDITE：进入
ServicesBll.DMS_Product.cs -> UpdateProductSalesteam(...)。
UpdateProductSalesteam(...) 会把前端传入的 a_OrderFormName_id 写入参数 OrderFormName_Id，然后执行两段 SQL：
1.    CT_UpdateProductSalesteamEdite
批量更新该 CC4 下所有产品：
•    DMS_Product.FK_EDMS_OrderForm_ID = @OrderFormName_Id
2.    CT_UpdateDMS_RProductFamily（编辑）或 CT_ADDDMS_RProductFamily（新增）
更新/新增 CC4 主档：
•    DMS_RProductFamily.FK_EDMS_OrderForm_ID = @OrderFormName_Id
---
2) CC4 改 order form 后会更新哪些表
直接更新：
•    DMS_Product（批量更新该 CC4 下产品的 FK_EDMS_OrderForm_ID）
•    DMS_RProductFamily（更新该 CC4 自身的 FK_EDMS_OrderForm_ID）
同一次逻辑里还会维护（但非 orderform 字段）：
•    DMS_RProductFamilyPMUserRelation（培训人员关系增删）
结论：CC4 改 order form 时，不会改 EDMS_OrderForm 主数据本身，而是改“引用关系”。
---
3) 全量排查：哪些功能使用了 orderform 相关表
A. order form 主数据维护
•    功能：DMS_ProductCategroy（名称虽叫 ProductCategroy，实际映射 EDMS_OrderForm）
•    证据：
•    FC_DMS_ProductCategroy.xml -> TableMapping tableName="EDMS_OrderForm"
•    VC_DMS_ProductCategroy.xml -> TableMapping tableName="EDMS_OrderForm"
•    明细配置使用 EDMS_OrderFormDetail（FC/VC_DMS_ProductCategroyDetail.xml）
B. CC4 维护时选择并同步 order form
•    功能：DMS_RProductFamily 编辑（UpdateProductSalesteam）
•    涉及表：
•    DMS_RProductFamily.FK_EDMS_OrderForm_ID
•    DMS_Product.FK_EDMS_OrderForm_ID
C. 经销商“最小采购金额”配置（按经销商 + order form）
•    功能：
•    DMS_DistributorPurchaseOrderSum
•    DMS_DistributorPurchaseOrderSumTimeCtrl
•    对应放大镜：VC_DMS_DistributorPurchaseOrderSum_EDMS_OrderForm、VC_OrderSumTimeCtrl_EDMS_OrderForm
•    涉及表：
•    DMS_DistributorPurchaseOrderSum(FK_EDMS_OrderForm_ID, FK_DMS_DistributorInfo_ID, PurchaseOrderSum)
•    DMS_DistributorPurchaseOrderSumTimeCtrl(FK_EDMS_OrderForm_ID, FK_DMS_DistributorInfo_ID, StartTime, EndTime)
D. 下单金额校验/补偿计算对 order form 的使用
•    功能：
•    EDMS_OrderInfo.queryOrderSum(...)
•    DMSEDMS_OrderInfo.queryDMSOrderSum(...)
•    逻辑：
•    使用订单里的 a_FK_OrderForm_ID 去查 DMS_DistributorPurchaseOrderSum / ...TimeCtrl
•    用于最小采购金额门槛判断
E. 订单与 order form 关系
•    表字段：
•    EDMS_OrderInfo.FK_OrderForm_ID
•    代码：
•    CT_EDMS_OrderInfoUp 更新该字段
•    CT_getOrderFormIDByID / QueryOrderFormID(...) 按订单取 OrderForm
---

今天更新医院销售代表

经销商授权申请审批流程优化需求，见如下详细说明。

2.1 经销商申请授权单时，下拉框选择的客户区域由现在的东南西北四项，在增加一个CL区域选项。

2.2 CE审批时，客户区域下拉框选择项也增加一个CL区域。允许CE做客户区域的内容修改。默认根据经销商提交订单的区域进行内容显示。审批条件修改，单据中的经销商所属类型+客户区域与CE审批人员负责的经销商类型+授权区域相同，才展示带CE审批的数据允许CE审批。

2.3 CMD审批调整，客户区域下拉框选择项也增加一个CL区域，默认根据经销商提交订单的区域进行内容显示。不允许修改。审批条件修改，单据中的经销商所属类型+客户区域与CMD审批人员负责的经销商类型+授权区域相同，才展示对应待审批数据允许CMD人员审批。

2.4 RMD审批调整，客户区域下拉框选择项也增加一个CL区域，默认根据经销商提交订单的区域进行内容显示。不允许修改。审批条件修改，单据中的经销商所属类型+客户区域与RMD审批人员负责的经销商类型+授权区域相同，才展示对应待审批数据允许RMD人员审批。

2.5 总裁办审批调整，客户区域下拉框选择项也增加一个CL区域，默认根据经销商提交订单的区域进行内容显示。不允许修改。审批条件修改，单据中的经销商所属类型+客户区域与总裁办审批人员负责的经销商类型+授权区域相同，才展示对应待审批数据允许总裁办人员审批。

PS

审批流的那个审批状态  CE待审批、CERutrn 等把CXE换成ComEx

把总裁办审批更改成全国渠道审批

一：DMS根据BPCS推送的价格数据做经销商基准价的增补，
  1）根据BPCS推送的经销商+产品+价格数据，如果经销商在基准价功能存在，产品在基准价功能不存在的，需要把此价格数据新增到经销商基准价功能（时间都是当前年份的1月1号到12月31号）。
  2）第一步新增好数据后，把新增数据的经销商+产品+价格数据拿出来，在循环增加数据，从2024年开始截止到当前时间的上一年，每年一条记录。
二：货号升级功能调整
  1）系统需要选择新货号、老货号、年份（年份从2024年开始，到当前年）,同时要根据老货号，老货号有的年份才有年份,数据选择完成点击数据同步按钮，系统判断，如果新货号+年份在经销商基准价功能无数据，系统自动按照老货号+年份查询出所有记录复制一份给到新货号。
  2）如果选择的新货号+年份在经销商基准价中已存在数据，系统则按照老货号+经销商+年份更新新货号的价格。
三：功能List列表显示、查询、导出功能增加【创建时间】、【年份】字段、年份取值如下：a. 手工上传：取上传字段。b. BPCS 推送：取生效日的“年份”
四：手工上传数据逻辑调整。保证相同经销商，相同货号，相同年份只有一条记录。如果本次上传的数据经销商+产品+年份在当前功能已存在相同数据，系统直接做价格更新。