活动
从 2020-05-29 到 2020-06-27
2020-06-24
- 18:34 错误 #43 (进行中): 销售订单WEB7348747在提交时,提示的信息,超出信用期限1天有误!
- 18:30 错误 #43 (已关闭): 销售订单WEB7348747在提交时,提示的信息,超出信用期限1天有误!
- 在提交销售订单WEB7348747时,提示的信息:“编号为:WEB7348747的销售订单已经超出信用期限[编号为:AR2020017799的应收单,应收日期为2020-06-13还未收款,已经超期:1天]”;销售订单的订单日期6月2...
- 16:56 错误 #15: 客户主档资料中财务资料,因为每次生成的销售订单会更新客户主档中的结算方式,得捷期望实现不更改客户主档资料中结算方式字段信息;只以销售订单SO中的结算方式为准。
- 补充说明:得捷客户在网站下订单选择的结算方式比如是支付宝,金蝶中生成的销售订单的结算方式是电汇,因为订单中携带的是客户主数据结算方式电汇
- 13:27 错误 #3 (已解决): 同一个销售订单能够下推生成重复的采购订单(例如销售订单WEB7259147下推生成两张一样的采购订单PO-PO2020017380/ PO2020017379)
2020-06-19
- 22:11 错误 #42 (已解决): EAS补丁部署后,得捷网站订单状态显示不正常
- 22:11 错误 #42 (已关闭): EAS补丁部署后,得捷网站订单状态显示不正常
- 提示内容:系统暂时不能刷新订单明细和发货状态。
- 22:08 错误 #41 (已解决): EAS补丁部署后,客服Lee.Li(李德伟)无法查看应收单,权限很早之前已经授权,并且一直没有做任何权限修改
- 用administrator查看客服Lee.Li(李德伟)有查看应收单权限,需转交开发排查!
- 22:07 错误 #41 (已关闭): EAS补丁部署后,客服Lee.Li(李德伟)无法查看应收单,权限很早之前已经授权,并且一直没有做任何权限修改
- EAS补丁部署后,客服Lee.Li(李德伟)无法查看应收单,权限很早之前已经授权,并且一直没有做任何权限修改
- 22:01 错误 #40 (已解决): EAS 补丁部署更新后异常问题 (收款单和应收单无法操作)
- 22:00 错误 #40 (已关闭): EAS 补丁部署更新后异常问题 (收款单和应收单无法操作)
- 1、6月19日部署完补丁后,应收单序时簿无法打开;
2、收款单做收款动作,系统出现报错 - 01:09 错误 #39 (已解决): 重启服务器后,客户端登录出现报错
- 提单号R20200608-4582
- 01:08 错误 #39 (已关闭): 重启服务器后,客户端登录出现报错
- 重启服务器后,客户端登录时出现如下报错:
下载失败的错误堆栈:
java.io.FileNotFoundException: http://10.3.3.38:7888/easWebClient/metas/sp/
处理建议... - 01:05 错误 #20: 导出多行应收单、应付单、收款单、付款单,金蝶系统导不出,会报错。
- 提单号R20200603-4144
- 01:03 错误 #38 (已解决): 通过EXCEL模板0603991导入金蝶应付单中,应付单模板是有税率13%,但是导入到金蝶后,明细分录中的税率没有带入系统,变为0
- 1、重新检查导入模板信息,将有公式的信息变为文本格式;
2、通过6条数据发现数量维护错误,已修正,重新导入,没有问题。 - 01:02 错误 #38 (已关闭): 通过EXCEL模板0603991导入金蝶应付单中,应付单模板是有税率13%,但是导入到金蝶后,明细分录中的税率没有带入系统,变为0
- 报错日志分析提示,[单据未满足算法规则,请检查数量,单价,金额及金额本位币字段是否正确Caused exception message is: 单据未满足算法规则,请检查数量,单价,金额及金额本位币字段是否正确],共639条数据,引入...
- 01:00 功能 #37 (进行中): Digi-Key会每月发给客户赛默飞世尔(上海)仪器有限公司付款通知书,但是发现有一年没有发送给客户,需要确定每月向客户发送付款通知书的逻辑是什么,收件人的邮箱是怎么取得
- 00:59 功能 #37 (已关闭): Digi-Key会每月发给客户赛默飞世尔(上海)仪器有限公司付款通知书,但是发现有一年没有发送给客户,需要确定每月向客户发送付款通知书的逻辑是什么,收件人的邮箱是怎么取得
- Digi-Key会每月发给客户赛默飞世尔(上海)仪器有限公司付款通知书,但是发现有一年没有发送给客户,需要确定每月向客户发送付款通知书的逻辑是什么,收件人的邮箱是怎么取得
- 00:50 功能 #34 (已解决): 金蝶 SO内单价值设置为“可修改”
- 1、销售订单基本信息界面含税取消勾选,显示出单价字段即可修改单价;
2、已邮件通知客户 - 00:48 功能 #34 (已关闭): 金蝶 SO内单价值设置为“可修改”
- 希望将SO内的单价设置为“可修改”,以避免由于客户订单内保留小数点位数与我们系统不同造成含税单价差异,进一步导致总价不同。
目前,SO内“数量”、“税率”、“含税单价”都是可以被修改的,但由于以上原因销售需要另外计算含税单价后更改系... - 00:46 错误 #33 (进行中): 生成的采购收货单PUI2020023301的仓库自动选择错误,目前Ship Carrier为UPS时,明细分录中的仓库是深圳商品仓库。
- 00:46 错误 #33: 生成的采购收货单PUI2020023301的仓库自动选择错误,目前Ship Carrier为UPS时,明细分录中的仓库是深圳商品仓库。
- 正确的采购收货单生成后,Ship Carrier为UPS时,仓库必为UPS上海商品仓库;Ship Carrier为Fusen时,仓库必为深圳商品仓库
- 00:43 错误 #33 (已解决): 生成的采购收货单PUI2020023301的仓库自动选择错误,目前Ship Carrier为UPS时,明细分录中的仓库是深圳商品仓库。
- 生成的采购收货单PUI2020023301的仓库自动选择错误,目前Ship Carrier为UPS时,明细分录中的仓库是深圳商品仓库。
- 00:42 支持 #32 (已解决): 销售订单序时簿里面进行过滤设置:客户名称等于东莞华秋电子有限公司,且订单类型等于正常销售,且原因代码为空,但销售发现原因代码已经设置为空了,筛选出来的报告还是有原因代码的订单。
- 更改过滤筛选条件:关闭原因为空
- 00:41 支持 #32 (已关闭): 销售订单序时簿里面进行过滤设置:客户名称等于东莞华秋电子有限公司,且订单类型等于正常销售,且原因代码为空,但销售发现原因代码已经设置为空了,筛选出来的报告还是有原因代码的订单。
- 1、销售订单序时簿里面进行过滤设置:客户名称等于东莞华秋电子有限公司,且订单类型等于正常销售,且原因代码为空,但销售发现原因代码已经设置为空了,筛选出来的报告还是有原因代码的订单。
2、选择过滤条件有误。 - 00:38 支持 #31 (已解决): 销售订单提示超出信用期限。编号为:WEB7252996的销售订单已经超出信用期限【编号为:AR2020009292的应收单,应收日期为2020-04-28还未收款,已经超期:8天】,应收单序时簿下客户ID:285662 这个ID下的有发票4/28到期,认为销售订单系统日期是2020-06-04距离应收日期不止8天,,但在SO里面显示超期时间只有8天?
- 1、原因是系统识别销售订单日期2020-05-06与应收账款的应收日期2020-04-28超出8天,不是根据系统当前日期2020-06-04与应收日期2020-04-28比较;
2、已沟通问题提出人。 - 00:37 支持 #31 (已关闭): 销售订单提示超出信用期限。编号为:WEB7252996的销售订单已经超出信用期限【编号为:AR2020009292的应收单,应收日期为2020-04-28还未收款,已经超期:8天】,应收单序时簿下客户ID:285662 这个ID下的有发票4/28到期,认为销售订单系统日期是2020-06-04距离应收日期不止8天,,但在SO里面显示超期时间只有8天?
- 销售订单提示超出信用期限。编号为:WEB7252996的销售订单已经超出信用期限【编号为:AR2020009292的应收单,应收日期为2020-04-28还未收款,已经超期:8天】,应收单序时簿下客户ID:285662 这个ID下的有...
- 00:34 错误 #13 (进行中): 已审核的发货通知单部分存在没有下顺丰运单时间和签收时间的信息,并且需要同步显示出顺丰物流具体运单信息
- 00:33 功能 #30: PO2020016186/ WEB7217767下单过程中Date Code Required月份信息归零, 销售订单SO下推采购订单PO,其中SO中的Date Code Required字段信息没有携带到PO。
- 通过单据转换规则设置DateCodeFlag和DateCodeMonths两个字段的映射关系(正式环境、测试环境已配置)
- 00:33 功能 #30 (已解决): PO2020016186/ WEB7217767下单过程中Date Code Required月份信息归零, 销售订单SO下推采购订单PO,其中SO中的Date Code Required字段信息没有携带到PO。
- 单据转换规则设置问题,没有设置映射关系
- 00:33 功能 #30 (已关闭): PO2020016186/ WEB7217767下单过程中Date Code Required月份信息归零, 销售订单SO下推采购订单PO,其中SO中的Date Code Required字段信息没有携带到PO。
- PO2020016186/ WEB7217767下单过程中Date Code Required月份信息归零,
销售订单SO下推采购订单PO,其中SO中的Date Code Required字段信息没有携带到PO。
- 00:30 错误 #29 (进行中): PO提交过程中报错,系统正常,会出现邮件报错,windecs内物料差异。PO2020017577,少2019-RK73H1JTTD1101FCT-ND
- 00:30 错误 #29 (已关闭): PO提交过程中报错,系统正常,会出现邮件报错,windecs内物料差异。PO2020017577,少2019-RK73H1JTTD1101FCT-ND
- 物料差异同行号2;邮件报错属于正常;希望能通过810文件日志更快找到哪个物料出现差异
- 00:27 功能 #28 (已解决): 得捷客户没有收到航信开好电子发票的通知。
- 开发已做了接口调整
- 00:27 功能 #28 (已关闭): 得捷客户没有收到航信开好电子发票的通知。
- 金蝶后台任务有问题,代码写在webservices接口里面在。误导其他地方有调用这个接口,导致得捷客户没有收到通知
- 00:22 错误 #25: 深圳物流操作员每隔一段时间需要重新登录一次,否则数据无法录入,原因系统太卡;经常发生。
- 日志收集方法
- 00:14 错误 #25 (进行中): 深圳物流操作员每隔一段时间需要重新登录一次,否则数据无法录入,原因系统太卡;经常发生。
- 00:14 错误 #25 (已关闭): 深圳物流操作员每隔一段时间需要重新登录一次,否则数据无法录入,原因系统太卡;经常发生。
- 1、已告知客户发现情况,立即录制现场视频;
2、已提单总部;提单号R20200612-0017 - 00:05 错误 #22: 所有通过应收单生成的凭证,再到应收账款的客户辅助明细账下查询不到
- 重新打开客户辅助明细账后,发现数据正常
- 00:04 错误 #22 (已解决): 所有通过应收单生成的凭证,再到应收账款的客户辅助明细账下查询不到
- 1、应收单生成的凭证,可能没有提交;
2、客户辅助明细账查询的时候没有包括未过账凭证 - 00:04 错误 #22 (已关闭): 所有通过应收单生成的凭证,再到应收账款的客户辅助明细账下查询不到
- 所有通过应收单生成的凭证,再到应收账款的客户辅助明细账下查询不到
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