活动
从 2020-05-20 到 2020-06-18
2020-06-18
-
23:48 错误 #20: 导出多行应收单、应付单、收款单、付款单,金蝶系统导不出,会报错。
- 1、减少数据量导出;
2、增加客户端虚拟机内存,因32位jdk最大虚拟机内存是1024;如果这个还不行,建议可以尝试安装64位jdk,参考文档:
3、如果还不行,那可以部署我们提供的私包。(但你这边补丁太旧了还是2014年的,不知... -
23:46 错误 #20 (已解决): 导出多行应收单、应付单、收款单、付款单,金蝶系统导不出,会报错。
- 1、判断此功能是否有开发;
2、总部提单解决; -
23:45 错误 #20 (已关闭): 导出多行应收单、应付单、收款单、付款单,金蝶系统导不出,会报错。
- 导出多行应收单、应付单、收款单、付款单,金蝶系统导不出,会报错。
-
23:40 功能 #18 (进行中): 销售订单中结算方式为Account时,希望销售类型同时自动变为业务赊销。
- 1、weborder调用接口同步生成销售订单时,判断结算方式是Account时,销售类型自动变为业务赊销,其他结算方式,销售类型都自动变为业务现销;
2、需要触发模式监视销售订单结算方式... -
23:39 功能 #18 (已解决): 销售订单中结算方式为Account时,希望销售类型同时自动变为业务赊销。
- 销售订单中结算方式为Account时,希望销售类型同时自动变为业务赊销。
-
23:37 功能 #17 (进行中): 打开信用额度分析报表时,占用金额为负数;做余额重算时,占用金额才正确。 做赊销下单时,超出信用额度的销售订单也能成功。
-
23:37 功能 #17 (已关闭): 打开信用额度分析报表时,占用金额为负数;做余额重算时,占用金额才正确。 做赊销下单时,超出信用额度的销售订单也能成功。
- 打开信用额度分析表让系统自动做余额重算
-
23:30 错误 #15 (进行中): 客户主档资料中财务资料,因为每次生成的销售订单会更新客户主档中的结算方式,得捷期望实现不更改客户主档资料中结算方式字段信息;只以销售订单SO中的结算方式为准。
- 取消更新客户资料中的结算方式信息
-
23:30 错误 #15 (已解决): 客户主档资料中财务资料,因为每次生成的销售订单会更新客户主档中的结算方式,得捷期望实现不更改客户主档资料中结算方式字段信息;只以销售订单SO中的结算方式为准。
- 客户主档资料中财务资料,因为每次生成的销售订单会更新客户主档中的结算方式,得捷期望实现不更改客户主档资料中结算方式字段信息;只以销售订单SO中的结算方式为准。
-
23:29 错误 #14 (已解决): 信用额度生效书:反馈给客户的邮件中抄送的公共邮件不要再自己发送给自己一遍,如抄送人service.sh@ digikey.com需要删除
-
23:28 错误 #14: 信用额度生效书:反馈给客户的邮件中抄送的公共邮件不要再自己发送给自己一遍,如抄送人service.sh@ digikey.com需要删除
- 1、信用额度生效后会通知客户并发送邮件,但是邮件抄送人中有ervice.sh@ digikey.com属于多余内容。
2、需要到邮件接口设置修改抄送人信息。 -
23:27 错误 #14 (已关闭): 信用额度生效书:反馈给客户的邮件中抄送的公共邮件不要再自己发送给自己一遍,如抄送人service.sh@ digikey.com需要删除
- 信用额度生效书:反馈给客户的邮件中抄送的公共邮件不要再自己发送给自己一遍,如抄送人service.sh@ digikey.com需要删除
remove service.sh@digikey.com in the Credit Noete -
23:25 错误 #13: 已审核的发货通知单部分存在没有下顺丰运单时间和签收时间的信息,并且需要同步显示出顺丰物流具体运单信息
- 初步通过发货通知单菜单中顺丰速运做提交订单,无法操作,提交订单按钮为灰色,由开发从代码层面进一步分析原因。
-
23:25 错误 #13 (已关闭): 已审核的发货通知单部分存在没有下顺丰运单时间和签收时间的信息,并且需要同步显示出顺丰物流具体运单信息
- 已审核的发货通知单部分存在没有下顺丰运单时间和签收时间的信息,比如编号为SHP2020212854 、SHP2020212854、SHP2020214353的发货通知单,并且顺丰物流跟踪信息不全,需要显示出顺丰物流具体运单信息
-
23:16 功能 #11 (进行中): 采购收货单上的客户名称可以复制和粘贴
-
23:15 功能 #11 (已关闭): 采购收货单上的客户名称可以复制和粘贴
- 采购收货单上的客户名称可以复制和粘贴
Customer name in receiving note is required to support copy and paste function. -
22:57 功能 #9: 补货的销售订单SO-A下推采购订单PO-A后,采购订单明细中CCC、HKEL没有携带过来,内容缺失。
- 打开动态扩展平台高级版DIGIKEY供应链定制方案-销售订单、采购订单-实体-分录,放出CCC、HKEL字段后,在销售订单下推采购订单单据转换规则设置映射关系。(正式环境、测试环境已配置)
-
22:57 功能 #9 (已解决): 补货的销售订单SO-A下推采购订单PO-A后,采购订单明细中CCC、HKEL没有携带过来,内容缺失。
- 初步分析单据转换规则的问题;通过单据转换设置无法解决问题,需要转开发处理
-
22:56 功能 #9 (已关闭): 补货的销售订单SO-A下推采购订单PO-A后,采购订单明细中CCC、HKEL没有携带过来,内容缺失。
- 补货的销售订单SO-A下推采购订单PO-A后,采购订单明细中CCC、HKEL没有携带过来,内容缺失。
-
22:53 功能 #8 (已解决): 补货的销售订单:通过销售订单SO再下推补货销售订单SO-A出口信息等信息没有,但是原销售订单SO出口信息等信息是完整的。
-
22:52 功能 #8: 补货的销售订单:通过销售订单SO再下推补货销售订单SO-A出口信息等信息没有,但是原销售订单SO出口信息等信息是完整的。
- (正式环境、测试环境已配置)
-
22:51 功能 #8 (已关闭): 补货的销售订单:通过销售订单SO再下推补货销售订单SO-A出口信息等信息没有,但是原销售订单SO出口信息等信息是完整的。
- 1、初步分析单据转换规则的问题;
2、设置单据转换映射关系 -
22:48 功能 #7: 补货的销售订单SO-A下推生成的采购订单单据编码必须携带-A
- 打二开补丁包
-
22:47 功能 #7 (已解决): 补货的销售订单SO-A下推生成的采购订单单据编码必须携带-A
-
22:47 功能 #7: 补货的销售订单SO-A下推生成的采购订单单据编码必须携带-A
- 1、初步分析编码规则设置的问题;检查单据编码规则不是编码规则设置问题,需要转开发处理;
2、开发处理:采购订单上增加原采购订单号字段,用来补货的采购订单PO-A做编码规则为单据编号公式结果 = 采购订单.单据编号 + "_A"... -
22:46 功能 #7 (已关闭): 补货的销售订单SO-A下推生成的采购订单单据编码必须携带-A
- 销售订单SO下推生成采购订单PO,PO有一定的编码规则;但是再次补订单的时候,需要销售订单SO下推生成补货销售订单SO-A,补货的销售订单SO-A下推生成PO-A,而实际上采购订单编码没有携带-A。
-
22:42 错误 #6 (已解决): 销售订单,更换客户,直接提交时。客户的相关信息如地址还是以前信息
- 二开补丁包
-
22:41 错误 #6 (已关闭): 销售订单,更换客户,直接提交时。客户的相关信息如地址还是以前信息
- 下销售订单,做客户变更时,例如客户A 收货地址为上海,客户B收货地址为北京,当修改客户为B时,直接提交销售订单的时候,收货地址还是上海。
-
22:34 功能 #5 (进行中): Compliance Profile
-
22:33 功能 #5 (已关闭): Compliance Profile
- Kingdee will need to Add the Compliance Profile flag to:
1.Customer Profile
2.Customer Profile Sync (Vijay will pro... -
22:23 错误 #4 (已解决): PO审核后,客户公司名称更新主档失败,例如订单编码PO2020018195 更新客户编码为317164 客户失败
- 临时解决方法:更新客户主档的True customer ID;
长期解决方法:排查BUG找出Truecustomerid和... -
21:48 错误 #4 (已关闭): PO审核后,客户公司名称更新主档失败,例如订单编码PO2020018195 更新客户编码为317164 客户失败
- 审核PO后更新的客户数据(firstname,lastname,en addrss)为317164,排查代码在找客户的时候逻辑为通过客户主导上的一个自定义字段CFCUSTOMERTRUEID的304486,然后查找客户304486 的...
-
21:44 错误 #2: 采购订单PO审核后采购订单明细中物料的分录行次跟美国接收的订单信息中物料分录行次不一样,有缺失。
- 物料号不同导致整票收货单无法正常导入
-
18:06 错误 #2 (进行中): 采购订单PO审核后采购订单明细中物料的分录行次跟美国接收的订单信息中物料分录行次不一样,有缺失。
-
18:03 错误 #2 (已关闭): 采购订单PO审核后采购订单明细中物料的分录行次跟美国接收的订单信息中物料分录行次不一样,有缺失。
- 采购订单PO审核后采购订单明细中物料的分录行次跟美国接收的订单信息中物料分录行次不一样,有缺失。也就是商品物料上传3个,但是少2个情况。得捷美国那边的存在相同物料会存放在不同的仓库并且物料号不相同,所以得捷上海传过去一个物料号,从美国...
-
20:43 错误 #3 (进行中): 同一个销售订单能够下推生成重复的采购订单(例如销售订单WEB7259147下推生成两张一样的采购订单PO-PO2020017380/ PO2020017379)
-
18:20 错误 #3: 同一个销售订单能够下推生成重复的采购订单(例如销售订单WEB7259147下推生成两张一样的采购订单PO-PO2020017380/ PO2020017379)
- 需要开发补丁,通过二开补丁包实现控制不允许同时生成2张PO
-
18:19 错误 #3 (已关闭): 同一个销售订单能够下推生成重复的采购订单(例如销售订单WEB7259147下推生成两张一样的采购订单PO-PO2020017380/ PO2020017379)
- 同一个销售订单能够下推生成重复的采购订单(例如销售订单WEB7259147下推生成两张一样的采购订单PO-PO2020017380/ PO2020017379)
2020-06-12
-
09:38 错误 #1 (进行中): 采购订单PO做审核时金蝶每天下午卡顿10分钟,希望找出卡顿原因,是网络问题,还是接口传输问题?
- 此问题正在和US沟通,确定技术方案
2020-06-11
-
23:05 错误 #1 (已关闭): 采购订单PO做审核时金蝶每天下午卡顿10分钟,希望找出卡顿原因,是网络问题,还是接口传输问题?
- 采购订单PO做审核时金蝶每天下午卡顿10分钟,希望找出卡顿原因,是网络问题,还是接口传输问题?
PO approval poor response issue often in daily afternnon
1、首先卡顿需要排除...
导出 Atom