T3总账与明细账对账不平数据库分析

问题现象：

查看余额表的时候2203（预收账款）科目年初数和明细账的年初数还有期初余额不一致（明细账和期初余额一致）

适用版本：

T3用友通系列

原因分析：

1、期初余额对账检查，对账结果正确无误

2、1月凭证全部记账后对账检查，对账结果正确

3、2月凭证未审核、未记账，对账检查。检查结果有错误

4、从上图中可以看出，科目‘2203001001001’的总账数值是240119，明细账数值是323373.27，以此为例，在查询分析其中执行如下脚本时可以看出：科目‘2203001001001’的期初值是240119，这个科目的明细合计是323373.27。科目‘2203001001001’在2月的期初与1月的期末数相等，说明是明细科目有问题，按正常情况修改明细科目的期初值就可以解决问题了。

5、就在准备修改明细科目的时候发现，有一行明细科目不应该出现在这个查询结果集中，因为查询条件是：ccod like ‘2203001001001%’ and iperiod = 2，这样的条件不应该出现科目‘220300100500251’并且会计期间是1月的记录。为了再进一步确认问题，再次使用如下脚本得到一个结果集：select * fron gl_accsum where ccode=’ 220300100500251’，比较两次的查询结果发现，同样的i_id 3289，却有两条不同的记录，问题看到这里已经很明显了，是数据库的索引出现了问题，这已经不是通过直接修改某条记录的期初就可以解决的。因此，使用“数据库检测修复工具”检测一下，看能否修复数据库中的错误。

6、在“数据库检测修复工具”中执行‘检测数据库（仅检测）’时发现如下图的错误提示

7、使用脚本在数据库中增加缺少的表以后再次检测，又会出现如下图的错误提示

8、继续在数据库中增加缺少的表，然后再次检测，又会出现如下图的错误提示

9、还是在数据库中增加缺少的表，然后再次检测，终于提示有分配性错误和一致性错误，如下图

10、这个步骤一直到没有错误出现为止，然后再执行下一项“检查修复磁盘空间分配结构一致性”，如下图。开始也会报错，同样需要执行到没有报错为止

11、在执行“（仅支持SQL2000）检查修复页和记录标题物理错误”时仍然会遇到2个一致性错误，执行了N多遍以后仍然是这样的提示，只能先执行下一项操作。一般来说遇到这种情况，如果工具能修复，每次执行完毕以后的提示错误数目都会比上一次少。如果执行很多次一直是相同数目的错误提示，说明暂时无法修复，可以先执行别的项，然后再返回来执行这一项，如果返回执行后仍是同样的错误，就说明数据库使用这个工具已经无法修复，只能请专业的数据修复公司来处理

12、在执行“修复sys*****表”这3项功能时没有报任何错误。但是在继续执行“修复数据库”时出现如下图的208个一致性错误。同样，如果这个功能项在执行N多遍以后仍有相同的提示，如上所描述：这样就可以认为“数据库检测修复工具”已经不能修复这个错误，先尝试执行执行下一项

13、执行“修复当前数据库所有用户表”的没有任何错误，因此继续执行下一个操作“重建当前数据库所有用户表已有索引”，结果出现了错误提示“内部SQL Server错误”，这之后无论执行多少遍都是这样的提示。从上面出现的错误一直到现在出现的错误，都是反复执行仍旧报相同的错误，至此已经可以判断这个数据库使用“数据库检测修复工具”已经无法修复。

解决方案：

因为这个客户只启用了总账管理模块，因此解决这个问题比较容易实现的办法是：首先新建一套帐，其次在旧账套中把所有会计期间的凭证反记账、取消审核，然后通过“用友通系统工具”把基础设置、凭证、科目期初从旧账套中分别导入新建账套，最后在新建账套中对所有会计期间的凭证审核、记账，月末结帐以后就可以继续使用了。

相反，如果尝试在客户的原始数据上修复，所花的时间和精力很大，并且还不能保证修复后数据的完整性。如果找专业的数据库修复公司来处理，肯定要再额外支出不小的费用，因此，采用上面的解决方案对于客户来说是最经济又实用的。

知识拓展：

总账模块的对账不平，按照文中开始的那种方法来处理，一般都可以找到问题，然后写出脚本来修正就可以了。像上述这样由于系统表缺失而导致索引混乱的情况毕竟是少之又少，只要在处理问题的过程中多注意观察，就一定能找到原因，最终找到处理的解决方案。