注意事项及问题
<h5>1.开发时需要考虑异步还是同步</h5>
<p><strong>项目案例</strong>：优远项目，中台订单派单功能，之前使用的是同步处理，单据量大时处理时间很长
<strong>建议</strong>：改用异步方案，点击派单按钮时将数据提交到后台请求运行</p>
<hr />
<h5>2.功能要合理拆分，不要将多个功能揉在一起</h5>
<p><strong>项目案例</strong>：优远项目，中台订单列表界面，集成了太多的功能，有运营人员常用的订单管理功能，也有财务人员需要的计算、汇总、导出功能，导致该界面性能很低。应该要将运营人员常用的功能跟财务的需求分开，财务人员一般月底跟月初才使用该功能，若将他们合并在一起，会导致不必要的性能跟资源开销
<strong>建议</strong>：重新梳理财务人员的需求，从现有逻辑中剥离出来，做成报表或单独做成界面</p>
<hr />
<h5>3.遇到代码冲突时，要拉上对应的技术一起沟通</h5>
<p><strong>项目案例</strong>：优远、方太项目，有时会发生因为代码合并冲突导致的问题
<strong>建议</strong>：1.一个功能最好一个人去改，不要多人同时进行，在任务分配时就尽量避免冲突的发生。2.遇见代码冲突需要拉上开发人员一起确认</p>
<hr />
<h5>4.为了测试修改了代码要记得改回去</h5>
<p><strong>项目案例</strong>：方太项目，原逻辑是调用WMS接口判断状态为D才认为是确认送达。UAT阶段，为了测试方便，将OMS判断WMS状态的代码注释了，3月1日第二批上线时一起发布至正式环境，导致12个发货单WMS还没发货，OMS的状态已变成【已出库】状态
<strong>建议</strong>：尽量不要为了测试去修改代码，而是通过正常业务流程去造满足测试条件的数据。一定要改代码时，需要自己记起来改了哪里，及时改回去</p>
<hr />
<h5>5.外部系统没有测试环境时需要特别注意</h5>
<p><strong>项目案例</strong>：方太项目，WMS系统只有一套正式环境没有测试环境，OMS的测试跟正式环境都是对接的WMS系统正式环境，后面出现了一个问题：OMS测试环境跟正式环境都会推送发货单给WMS系统，OMS发货单编号作为WMS的参考编号，WMS对于参考编号有唯一性判断，导致正式环境推送发货单时报错“参考编号已存在”
<strong>建议</strong>：1.尽量要求外围系统提供测试环境；2.我们测试环境若对接的是对方正式环境，需要特别注意，不要发送数据过去了，除非是已经沟通好了可以发送数据过去测试，测完在删掉。3.我们的测试跟正式对接对方同一套系统时，注意编号重复的问题</p>
<hr />
<h5>6.使用异步处理方案时注意中间处理状态</h5>
<p><strong>项目案例</strong>：方太项目，发货单推送给WMS是异步队列进行处理，用户在界面点按钮，发货单进入队列中待处理，此时用户立即点了取消按钮，OMS误判还未推送给WMS,因此未调用WMS的取消接口。之后队列又执行了发货单推送WMS逻辑
<strong>建议</strong>：异步处理数据时，加上中间处理状态PROCESSING，避免因为状态判断导致的数据不一致问题</p>
<hr />
<h5>7.Excel导入时注意日期格式的选择</h5>
<p><strong>项目案例</strong>：方太项目，销售订单导入时，日期格式明明是对的，但导入后却不对了。原因是使用Excel日期格式化时，选的是“*MM/DD/YYYY”，注意带了星号*，带*号的格式会随操作系统的格式变
<strong>建议</strong>：选不带星号的</p>
<hr />
<h5>8.跟易仓WMS对接时注意shipping_date字段</h5>
<p><strong>项目案例</strong>：方太项目，oms发货单的状态变为了已发运，但“wms发货时间”为空，发现问题后用postman去调接口查看日期是有值的。原因：易仓的接口问题，状态变为已发运时，发运时间可能不会立即有值，此时还是0000-00-00 00:00:00，有一定时间的延迟
<strong>建议</strong>：除了判断状态还需要判断日期不为0000-00-00 00:00:00才处理</p>
<hr />
<h5>9.错误提示不够友好</h5>
<p><strong>项目案例</strong>：方太项目，很多报错提示不友好，类似：请检查配置、货品现有量不足。用户看到这类错误其实不知道后续怎么处理，没有更具体的提示
<strong>建议</strong>：文字描述更具体。涉及到具体数据时带出数据，比如：请检查货品映射表xxx货品的配置，xxx货品现有量不足</p>
<hr />
<h5>10.上线时漏迁了脚本</h5>
<p><strong>项目案例</strong>：天普项目，上线时漏迁了一个工作流脚本A，顾问在配置工作流时误将付款的工作流脚本当做A脚本配置上去了，导致提前触发了付款逻辑
<strong>建议</strong>：1.列好上线检查清单；2.付款逻辑中需要加上校验；3.顾问在配置工作流脚本时发现问题需要沟通而不是根据自己的猜测去配置</p>
<hr />
<h5>11.财务月结相关MR程序需要考虑性能，数据量</h5>
<p><strong>项目案例</strong>：福建扬腾，3W+的sku，每月产生的事务处理数据也有几万+，成本结构报表是以子公司+SKU维度，按月计算期初，本期，期末各项指标的单价，数量，费用。原来程序是在getInputData阶段获取数据，在map阶段
查询不同的搜索取值验证，然后插入单个自定义记录，上线后顾问反馈程序运行接近两天数据确只取出来部分。
<strong>建议</strong>：搜索导出csv在getInputData阶段验证全量数据，同时生成记录可以通过批量插入实现，并不是所有程序适合在map阶段单个处理</p>
<h5>12.日期范围查找问题</h5>
<p><strong>项目案例</strong>：方太项目，订单查询界面，日期自日期至的查询字段为日期。例如界面录入日期自为2023-4-1，日期至为2023-4-5。后台转为dto后，日期自为2023-4-1 00:00:00，日期至为2023-4-5 00:00:00。mapper中的查询条件为2023-4-1 00:00:00<=order_date<=2023-4-5 00:00:00。但本意其实是要查2023-4-1至2023-4-5之间的的数据（包括2023-4-5的），实际逻辑却查不到2023-4-5的数据。
<strong>建议</strong>：可以将日期至加一天，然后mapper中的条件改为<日期至</p>
<h5>13.问题：工作流配置的【提交记录前】的【返回用户错误】操作，导致程序回写单据逻辑失败</h5>
<p><strong>项目案例</strong>：徐工项目，回款分配单界面控制的工作流操作【返回用户错误】，校验条件：回款分配单的【发车资料表】的销售合同非空，回款分配单的【销售合同】非空，发车资料表的销售合同等于销售合同，否则报错返回错。MR脚本回写回款分配单时用record.submitFields，触发工作流时无法获取到以上字段，返回报错导致程序回写失败，但是程序已经成功并生成了相应单据。去除掉此操作上下文中Map/Reduce的选择即可
<strong>建议</strong>：要求顾问部署影响单据保存的工作流操作时，和技术商量一下此操作上下文的选择，不要影响到代码单据的回写</p>