wise迁移星空企业版常见问题

wise迁移星空企业版常见问题原创

金蝶云·星空

金蝶云·星空专项服务

夏天的云儿

10人赞赏了该文章 380次浏览未经作者许可，禁止转载编辑于2024年05月13日 11:25:44

一、迁移准备常见问题

1、‘检测完毕，不符合一键迁移条件’的报错提示

报错原因:先对星空系统做了源链接，在打的迁移补丁；

解决办法：将源链接删除，在重新创建源链接；若无法删除源链接，则可使用以下脚本进行更改

update T_BAS_DBConnection set FSUPPORTONEKEY=1

2、报表转化时卡住不动

卡住原因：电脑操作系统用户权限可能不够；

解决办法：退出检查工具，找到检查工具的安装目录，选中检查工具，右键，以管理员身份运行，在次进行报表转化；

3、报表转化时一直弹出保存表格的提示

报错原因：Excel版本可能不支持；

解决办法：自行检查此台电脑上安装的Excel版本，检查工具只支持office的Excel，不支持WPS或者office365，

office版本建议安装2010版本；

4、登录星空系统，没有WISE升级按钮

出现原因：（1）有可能没有打迁移补丁；（2）使用的administrator账户登录系统

解决办法：（1）打迁移补丁

（2）使用有权限的普通用户登录系统，以H5的方式登录系统；

登录网址示例(XXXX表示需迁移的星空账套所在的应用服务器电脑名称或IP地址)：

http://XXXX/k3cloud/html5/index.aspx

5、出现两个wise财务迁移按钮的问题

出现原因：迁移补丁没有打成功，或者补丁中的源数据没有打上；

解决办法：重新打迁移补丁，打补丁时，按照下图进行勾选

6、方案未启动

出现原因：有可能在使用检查工具时未正确配置数据库连接，导致未触发对某些表添加字段，建议使用检查工具的批量新增功能进行创建数据库连接；

解决办法：对以下所有包含onekey编码的迁移方案进行手工启用，在根据启用情况进行处理详细的问题；具体问题具体分析；

7、迁移时，长时间卡住不动

现象：进度卡住不动，并且查看日志无明显报错。

解决步骤：

（1）查询T_BAS_OneKeyUpdate表（select * from T_BAS_OneKeyUpdate where FDOCUMENTSTATUS='A'）

状态为A的这一行则是有问题的数据

（2）更新FComputeId字段为空或者删除这一行都可以

update T_BAS_OneKeyUpdate set FComputeId=null where FDOCUMENTSTATUS='A'

二、未映射问题

1、制单字段使用的‘用户’未映射

出现报错原因：用来迁移的普通用户账号权限不够，缺少administrator权限；

解决方法：对用来迁移的用户账号授权，授予administrator权限，在重新迁移，重新迁移后会解决很多因缺少用户而带来的其他迁移方案的报错；

注：用来迁移的账号只需要全功能和administrator权限，不需要授予其他系统预置权限！！

2、汇率类型字段使用的‘汇率类型’内码1未映射；

出现报错的可能原因：wise中的汇率类型与星空预置的汇率类型无法匹配，标准的迁移方案，不提供汇率类型的迁移方案，只做名称映射；

解决方法：在星空系统中手工将wise中有的汇率类型而不存在星空预置汇率类型中的数据，添加到星空系统中，添加的汇率类型名称要与wise一模一样，然后在进行迁移。

3、账簿未映射

报错原因：可能存在两种原因，a.用来迁移的普通用户权限不够导致；b.会计日历的起始期间不够；

解决办法：a.对此用户重新授权；

1)对全功能角色重新授权一次

2)此用户需要有administrator和全功能角色的权限；注：不需要其他角色权限

b.重新创建会计日历，日历的起始时间要能包含需要迁移的所有账套的最小会计日历日期；

1）手工在前端创建新的会计日历；

会计政策和已存在的账簿会计日历字段需要从后台更新为新建的会计日历内码；

--先查询出前端手工新增的会计日历的内码,将新增会计日历编码字样替换成自己新增的会计日历编码

select fid '新增会计日历的内码',* from t_bd_accountcalendar where FNUMBER='新增会计日历编码'

update t_bd_accountcalendar set FNUMBER='新增会计日历编码' where FNUMBER='KJRL01_WISE'

update t_bd_accountcalendar set FNUMBER='KJRL01_WISE' where fid='新增会计日历的内码'

--备份

select * into T_BD_ACCOUNTBOOKcc_0608 from T_BD_ACCOUNTBOOK

--将查询出来的新会计日历内码,替换新增会计日历的内码字样

update T_BD_ACCOUNTBOOK set FPERIODID='新增会计日历的内码'

--备份

select * into T_FA_ACCTPOLICYcc_bak from T_FA_ACCTPOLICY

--将查询出来的新会计日历内码,替换新增会计日历的内码字样

update T_FA_ACCTPOLICY set FACCTCALENDARID='新增会计日历的内码'

2）在映射关系查询里将会计日历的映射删除，再在wise基础资料映射里面找到对应组织的会计日历重新进行映射；

3）在再wise基础资料同步中找到对应组织的账簿迁移方案，在进行手工执行，账簿迁移成功后，请在前端手工审核此账簿

4）以上步骤操作完成，可在次执行wise财务迁移；

5）出现此种情况的原因是由于在迁移时，出现了分批迁移；

举个例子，本来需要迁移60个wise账套，却在第一次迁移时只迁移了20个，对这20个wise账套进行了检查，剩余40个隔了一段时间在进行检查并迁移，这就会导致如果第一批迁移的20个wise账套里面，最小的会计日历是2010年1月1号，则检查工具会自动创建一个起始日期是2010年的会计日历，第二批迁移时，40个wise账套里面，最小的会计日历是1998年1月1号，则检查工具不会在重新创建一个会计日历了，就会出现上诉账簿内码为1未映射的情况，所以在迁移时，建议所有账套一起检查迁移，不要分批。

4、凭证迁移失败，提示核算维度未映射

解决思路：查看【基础资料同步查询】当前迁移时间的方案中是否有出现相应基础资料方案迁移失败，根据失败提示，处理基础资料的迁移，

例如：查看基础资料同步查询，辅助资料同步失败，报错提示如图所示：

根据提示进行修改迁移方案，星空已有的编码若是无法修改，则修改迁移方案，在源字段规则表达式中加上后缀做编码去重处理。

基础资料迁移报错解决完之后，在重新执行一次一键迁移。

注：若是出现员工编码重复，则需注意，在调整迁移方案时需调整员工编码和编码两个字段，其他基础资料若是也有提示编码或者名称重复，也可根据上述方式进行修改，若不修改方案，也可直接在wise数据库用SQL语句进行修改相应资料，此方法需要熟悉wise数据库后台表。

5、迁移员工报错，提示部门和岗位信息未映射

报错如图所示

解决方法：经过查询wise账套，确认wise账套中没有任何的部门和岗位或者wise账套中确实不存在报错截图中的岗位信息和部门内码。然后在将wise基础资料同步中员工的的迁移方案上的岗位信息单据体的源系统资料清空，如图所示

处理原理：星空中允许员工可以不添加岗位和部门。

三、卡片，固定资产余额表迁移失败，无任何报错提示【此提示是指【基础资料同步查询】中卡片关联关系，固定资产余额表，资产卡片历史数据的表体的报错提示】

出现场景：此问题多数存在于，客户的cloud账套已经使用过一段时间，并且原组织已经有卡片了，

解决方案：

查看wise业务单据同步方案（卡片关联关系，固定资产余额表，资产卡片历史数据），这三个方案中的FASSETID字段源字段规则表达式的数值是不是特别的大，如果是，则修改卡片关联关系，固定资产余额表，资产卡片历史数据中的FASSETID字段的源字段规则表达式（如图所示），这三个单据的FASSETID字段表达式要相同，修改的数值要比迁移自动生成的要来的小。方案修改完之后，在重新进行迁移；

注：修改的数字要比已经存在的卡片内码数字大。不可与星空系统中卡片已存在的内码相同；

已存在的卡片包含原cloud账套组织存在的卡片和已迁移上来的卡片

四、星空8.0版本，授权后还出现迁移按钮找不到

现象：打完补丁之后，迁移按钮找不到；

解决方案：方案一：在管理中心，将此数据中心的名称缩短，建议改成两个汉字，还原到客户正式环境时在将名称改成客户需要的名称；

方案二：如果使用了方案一的方法还是无法解决，可使用以下方法处理：

（1）打开bos

(2)按照图片步骤操作；

五、其他案例分享

1、迁移后凭证的“审核状态”是“创建”？

请检查是否K/3对应凭证没有审核人。

2、会计日历报错“执行失败”，实际会计日历已迁移过来？

建议检查下会计日历相关数据是否正常，总账、固定资产、报表数据、后续结账等业务是否正常，如果正常该报错可不用管。

3、损益表同步失败20条数据，如何处理？

经查看，迁移失败的1916核算维度在K/3账套中的核算维度数据异常，t_itemdetail 中存在 fdetailid=1916的记录，1916记录对应的F1为256，但T_ITEM中没有fitemid=256的记录，且T_profitandloss中fdetailid=1916的20条记录金额均为0。

故K/3这20条数据本身异常，迁移失败不用管。