K3迁移星空企业版--账簿未映射原创
金蝶云社区-夏天的云儿
夏天的云儿
4人赞赏了该文章 291次浏览 未经作者许可,禁止转载编辑于2024年09月02日 14:05:24
summary-icon摘要由AI智能服务提供

K3迁移至星空企业版时遇“账簿未映射”错误,可能因用户权限不足或会计日历起始期间不符。解决方案包括重新授权用户、检查并修正K3账套表数据、调整星空会计日历设置以确保覆盖所有迁移账套的会计日历期间,避免分批迁移导致的日历不一致问题。


问题描述:K3迁移星空企业版报错,提示“账簿未映射”。


image.png

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

解决办法:

a. 确认权限是否正常。如果权限不够导致的问题,对此用户重新授权;

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

image.png

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

image.png

b. 如果K3启用期间比星空会计日历开始时间晚,那就说明会计日历起始时间够,但是还是迁移报错。可能是因为K3账套t_SystemProfile表缺少FCategory=“GL” and FKey =“KJRLStartYear”的数据,可K3账套执行下列脚本后。重新恢复未迁移过的星空数据中心,重新迁移。

 select * into t_SystemProfilebak20240903 from  t_SystemProfile
if not exists (select * from  t_SystemProfile where  FCategory='GL' and FKey ='KJRLStartYear')
begin
insert into t_SystemProfile (FCategory,FKey,FValue,FReadonly)
 values ('GL','KJRLStartYear','2000','1')
declare @aa  int
select @aa=FValue from  t_SystemProfile where  FCategory='GL' and FKey='StartYear'
select @aa
  update t_SystemProfile set FValue=@aa where   FCategory='GL' and FKey ='KJRLStartYear'
end
else
begin
print 't_SystemProfile存在 FCategory=“GL” and FKey =“KJRLStartYear”数据'
end


如果运行上述脚本还是有问题,重点查看会计核算体系、会计政策、账簿、会计日历的信息是否正常,可能因为该组织带的会计日历期间不够,导致迁移异常。

迁移最好是所有K3账套一次性迁移成功,如果账套过多需要分批,K3最早使用的账套一定要放第一批次迁移。


c、如果K3启用期间比星空会计日历开始时间早那就说明星空会计日历不够,需要调整会计日历。

情况一、迁移到星空空白数据中心,且星空空白数据中心会计日历期间不够。

参考方案:直接星空前台新增一个新的会计日历,日历的起始时间要能包含需要迁移的所有账套的最小会计日历日期;查看会计核算体系、会计政策、账簿,如果引用的旧的会计日历,需要前台调整为引用新的会计日历。再迁移。(之前已迁移异常的星空数据中心不要用了,重新恢复新的星空数据中心做迁移)

情况二、迁移到已经使用的星空数据中心,且星空会计日历期间不够。

参考方案

(1)查看能否前台新增新的会计日历,日历的起始时间要能包含需要迁移的所有账套的最小会计日历日期;需要迁移的组织对应的会计核算体系、会计政策、账簿等涉及会计日历的内容需要调整为新的会计日历,且迁移时要核对带出来的会计日历是否用的新的会计日历。

(2)如果前台调整不可行,可参考下列后台调整的方法。脚本仅供参考,需按需调整。重新创建会计日历,日历的起始时间要能包含需要迁移的所有账套的最小会计日历日期;

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
4人点赞
还没有人点赞,快来当第一个点赞的人吧!
图标打赏
0人打赏
还没有人打赏,快来当第一个打赏的人吧!