K3总账数据结构分析
第1章基础资料 (3)
1．1计量单位 (3)
1．2币别(T_CURRENCY) (4)
1．3凭证字 (4)
1．4科目(T_A CCOUNT) (4)
第2章初始化 (7)
2．1初始化数据的存放 (7)
2．2启用往来业务管理科目的初始数据的存放 (7)
2．3试算平衡 (8)
2．4结束初始化 (8)
2．5案例 (8)
第3章凭证处理 (10)
3．1多项目核算 (10)
3．2凭证过账 (11)
3．3凭证反过账 (11)
3．4案例 (12)
第4章现金流量 (16)
4．1凭证录入与保存时有关现金流量的处理 (16)
4．2现金流量表的平衡关系 (16)
4．3案例 (16)
第5章往来处理 (18)
5．1往来业务核销 (18)
5．2往来对账单 (18)
5．3账龄分析 (18)
5．4注意事项 (19)
第6章期末调汇 (20)
6．1期末调汇原理 (20)
第7章结转损益 (21)
7．1结转损益过程 (21)
7．2案例 (21)
第8章自动转账 (23)
第9章期末结账 (24)
9．1期末结账 (24)
9．2反结账 (24)
9．3案例 (24)
第10章账薄 (26)
10．1总账取数原理 (26)
10．2明细账取数原理 (26)
10．3科目余额表取数原理 (26)
10．4核算项目分类总账取数原理 (27)
10．5核算项目明细账取数原理 (27)
10．6核算项目余额取数原理 (27)
10．7案例 (28)
第11章报表与总账对账 (30)
11．1资产负债表 (30)
11．2损益表 (30)
第12章附-其他案例 (31)
第1章基础资料
1．1计量单位
涉及的表为t_measureunit（计量单位表），t_unitgroup（计量单位组表），常用的字段为Fmeasureunitid（计量单位内码），Funitgroupid(计量单位组内码)，Fstandard（是否基本计量单位）。
计量单位组和计量单位信息同时也保存在t_Item表中。
在一个计量单位组内，只能有一个基本计量单位，即Funitgroupid 字段值相同的记录，只能有一条记录的Fstandard字段值为1，如果一个组内有两个Fstandard=1的计量单位，则会造成一些报表数据翻倍。
t_measureunit和t_unitgroup表中都有一条系统预置的零记录，此记录不能丢失，如果丢失，会导致数据错误在操作时出现莫名其妙的错误（一般是在做凭证时不能保存，查询凭证，账表时数据不正确）。
案例
问题描述：在打开基础资料的科目时出现“当前数据不存在”。
原因：经过检查发现出现这个问题的主要原因是由于t_UnitGroup表丢失了一条零记录处理方法：使用如下sql补上就可以了——
insert into t_UnitGroup(FUnitGroupID,FName,FDefaultUnitID) values(0,'*',0) （K3中很多表都有一条零记录，这些记录都不能删除。）
零记录
在K3中很多表都存在零记录，比如:t_currency、t_Measureunit、t_Item、t_ItemDetail 等等。这些零都是系统预置的，有特定的用途，比如：t_account.Funitgroupid =0代表不使用数量辅助核算；而t_Balance.FcurrencyID=0代表所有币别；t_Balance.FDetailID=0代表所有核算项目。
K3中有很多表引用“计量单组ID”和“计量单位ID”，比如科目，凭证，物料，物流单据，余额表、BOM等等。一旦t_UnitGroup或t_MeasureUnit丢失记录(包括零记录)，对引用表来说就产生了“孤立数据”。或者也可以说“计量单位表与XX表数据不匹配”。这种情况下可以使用 NOT IN 的子查询来判断是否存在“孤立数据”——
select * from t_account where fmeasureunitid NOT IN (select fmeasureunitid from t_measureunit)
孤立记录（数据不匹配）
上个例子中t_UnitGroup的零记录丢失，而科目表又引用了t_UnitGroup的零记录，这种情况就是“孤立记录”。“孤立数据”是一个普遍的现象，数据库经常会出现这种问题，比如：
凭证的表头存在而凭证表体丢失——
select * from t_Voucher where FvoucherID NOT IN (select FvoucherID from
t_VoucherEntry)
凭证表所引用的FaccountID在t_account中根本不存在——
select * from t_Voucher
t_Balance中的FdetailID在t_ItemDetail中不存在——
select * from t_Balance where FdetailID NOT IN (select FdetailID from
t_ItemDetail)
问题
什么样的数据是“孤立数据”？
1．2币别(t_c u r r e n c y)
涉及的表为t_currency（币别表），常用到的字段为FcurrencyID（币别内码），FFixRate （换算率），Fscale（小数位数）等等。
FcurrencyID（币别内码）：系统默认账套记账本位的FcurrencyID值为1。
Fscale（小数位数）：在中间层账套管理中，有个地方设置本位币小数点位数，就是FcurrencyID值为1的记录对应的Fscale值，可以在此改动币别对应的小数位数。
1．3凭证字
涉及的表为t_vouchgroup（凭证字表），常用的字段为FgroupID（凭证字内码），一般被t_voucher（凭证表）引用。
1．4科目(t_A c c o u n t)
涉及的表为t_account（科目表），主要字段为fAccountID(科目内码)，FfullName(科目全名)，FQuantity(是否数量金额辅助核算), FMeasureUnitID（计量单位内码），FDetailid(核算项目内码)等。
1）FAccountID（科目内码）
科目内码一旦被引用，为保证数据的完整性，此科目就不允许删除。
案例
问题描述：gl001账套中，科目103没有任何业务发生，但是删除时却提示：“已有业务发生或已被使用，不能删除”。
处理过程：
1、用Profiler跟踪删除过程，发现系统调用了存储过程sp_ObjectInUsed；
2、用“sp_helttext sp_ObjectInUsed”命令查看存储过程，发现sp_ObjectInUsed
检测t_Balance、t_VoucherEntry、t_BUDGET、t_ProfitAndLoss是否引用了103科目，但经过检查发现这个表并未引用103科目ID；
3、在sp_ObjectInUsed脚本的最后用游标调用t_ObjectRefs表中存储过程；
4、依次检查t_ObjectRefs表中存储过程，最后在sp_ObjectInUsed存储过程中发现t_Icitem表引用了103科目。
5、修改物料的存货科目，问题解决。
删除基础资料的检查
上面的例子具有一定的代表性，不仅仅是科目如此，K3中删除任何基础资料，系统都要判断该基础资料是否已被引用。因此遇到类似问题，都可以按这一思路进行来分析处理。
原理：如果础资料ID是已经被其他数据表所引用则不允许删除,这个判断过程是调用一系列存储过程来实现的:先调用sp_ObjectInUsed，在sp_ObjectInUsed又调用t_ObjectRefs 表中的存储过程。
问题
删除物料时，提示：“已有业务发生或已被使用，不能删除”，如何判断那些表引用了该物料？
问题
gl001账套处于初始化阶段，币别中设置了港币，港币没有任何业务发生。现在客户认为公司根本没有港币业务，所以想删除港币这个币别，但是删除时却提示：“已有业务发生或已被使用，不能删除”。这个问题如何处理？
2）FFullname(科目全名)
这个字段主要是在录入凭证，查看账薄时用到。如果在录入凭证，查看账薄时，系统只显示科目的最明细一级的名称，那就是因为科目全名字段中的值不正确。这个问题有个相关的补丁可以解决，补丁名叫Repare_FullName.sql。
3）Fquantity(是否数量金额辅助核算)
此字段主要是标识此科目是否需要数量金额辅助核算，一般此字段与FmeasureUnitID （计量单位内码）一起使用，当fquantity字段的值为1时，FmeasureUnitID字段中一定也要有相应的值，且FmeasureUnitID与t_measureunit表中的FmeasureUnitID字段值相对应。
4）FDetailid（核算项目使用状况内码）
这个字段的值与t_itemdetail(核算项目横表)中的Fdetailid字段值相关联，且这个值在t_itemdetail表中对应的以F开头的字段的值为“-1”。例如：113（应收账款）科目，带部门及客户两个核算项目，假设在t_account表中对应的Fdetailid字段的值为1，那么在t_itemdetail表中，一定要有Fdetailid值为1的记录，详细讲解见凭证处理这节。
核算项目
客户、部门、职员、物料等，这些都是核算项目的类别。比如客户是一个核算项目类别，部门也是一个核算项目类别，系统用t_ItemClass保存核算项目类别。
我们把核算项目类别看成一个对象，则不同的对象都有各自的属性。比如对于客户这个对象来说，它的属性是：代码、名称、银行账号、法人代表、偿债等级等等。对于部门这个对象来说，它的属性是：代码、名称、部门主管、部门电话、传真等等。系统用t_ItemPropDesc 保存核算项目类别的属性。t_ItemClass与t_ItemPropDesc用FitemClassID字段关联，一个核算项目类别可以拥有多种属性，因此是“一对多”的关系。用户新增的核算项目类别的属性也保存在t_ItemPropDesc中。
举例：新增一核算项目类别，并定义核算项目类别属性，注意其数据的存放。
不同的核算项目类别都拥有自己的数据表，在t_itemclass表中，有一个FsqlTableName 字段，它表示每个核算项目对应的数据表。比如：客户—t_Organization ；部门—
t_Department ；职员—t_Emp；物料—t_ICItem ... 。
不同的核算项目类别有相同的属性，比如：ID、父级ID、代码、名称、长代码、全称等，系统将这些相同的属性值保存在t_Item表中。
因此，所有的核算项目都实际同时保存在两个数据表中。比如：新增一个职员，则同时保存在t_Emp中和t_Item中；新增一个部门，则同时保存在t_Department中和t_Item中。
因为所有的核算项目都保存在t_Item中，系统用t_Item.FitemClassID字段区分核算项目类别。
核算项目的内码进度值保存在t_Identity表中，比如每新增一个核算项目，系统先从t_Itdentitey找到Fnext的值作为本次新增的ID。核算项目保存成功后，系统又更新
t_Itdentitey将Fnext加1。
案例
问题描述：：新增任何的核算项目都报错：“定义的应用程序或对象错误”Server Detail :违反了 PRIMARY KEY 约束 'PK_Item'。不能在对象 't_Item' 中插入重复键。
原因：t_identity记录t_Item表内码进度小于实际的内码进度。
处理方法：update t_identity set fnext=(select max(fitemid) from t_item )+1 where fname='t_item'
k3内码递增机制
K3的内码递增机制有三种：
1、用t_Itdentitey和IcMaxNum来跟踪内码进度；
2、SQL Server自动递增(种子列)。比如com_Inventory表FID字段。
3、临时计算
比如Icbal表的FbillInterID字段记录了先进/后进先出法的批次（顺序号）。当有新的批次保存到IcBal时，系统临时计算出最大内码：select Max(FBillInterID)+1 from icbal .
新增基础资料、凭证、其他模块的各种单据时，经常提示错误：“违反了 PRIMARY KEY 约束 'PK_XXX'。不能在对象 'XXX' 中插入重复键”。遇到这类问题应该考虑到是否是内码的递增出现问题。
问题
k3的内码递增机制是如何实现的？举例说明其原理。
第2章初始化
2．1初始化数据的存放
初始化时，涉及到的表主要是 t_balance（金额余额表），t_quantitybalance（数量余额表）和t_profitandloss（损益类科目实际发生额情况表）。
如果在年初进行初始化时，余额表和数量余额表中都只有第一期的数据，且没有本年累计数据和损益数据，即在两张余额表中，累计数字段的值为零和在损益类实际发生额表中没有记录。
如果在年中进行初始化时，假如在第6期进行初始化，则t_profitandloss有记录,另外两张余额表中会存在第1期和第6期两期的数据，例如t_Balance——
1期的数据中：FYtdDebit、FYtdCredit、FendBalance取用户录入的本年累计借方、本年累计
贷方、期初余额（是指6月初的余额）。FDebit、FCredit、FBeginBalance 这
三列是系统倒算出来的，过程是：FDebit= FytdDebit；FCredit= FytdCredit；
FBeginBalance= FEndBalance+ FCredit – FDebit。
6期的数据中：6期的FBeginBalance等于1期的FendBalance；6期的FcreDit和FDebit 无
数据；6期的FYtdCreDit和FytdDebit等于1期的FYtdCreDit和FytdDebit；
6期的FendBalance等于6期的FbeginBalance。
在上面所讲的三张表中，都有币别（Fcurrencyid）这个字段，假如科目带有外币核算，且外币有余额或发生额，则在这三张表中都由币别ID来识别，一个科目的余额之和是由这个科目的几个币种余额之和而得；在余额表中币别字段（Fcurrencyid）的值为零，就表示是此科目的综合本位币记录。一个科目下所有币别余额之和等于此科目币别字段为零值的记录的余额，所有币别发生额字段之和等于币别字段为零值的记录的发生额。
在上面所讲的三张表中，也都有核算项目（Fdetailid）这个字段，如果某个科目下挂核算项目，且核算项目有余额或发生额，那么在这三张表中都由Fdetailid字段的值来反映。Fdetailid字段的值为0，则是此科目所有核算项目之和的记录。
t_balance表中，借方余额保存为正数，贷方余额保存为负数。 t_Profitandloss表对不同的余额方向的处理方式也不同。例如：科目“营业外收入”的余额方向是贷方，在初始余额录入中录入“实际损益发生额”为200，则在t_ProFitandloss中FytdAmount保存为–200。科目“现金”的余额方向是借方，在初始余额录入中录入“期初余额”为300，则在t_Balance中1期的FEndBalance保存为–300。科目“现金”的余额方向是借方，在初始余额录入中录入“期初余额”为100，则在t_Balance中1期的FEndBalance保存为 100。
2．2启用往来业务管理科目的初始数据的存放
如果未启用往来业务核销,则对于起用往来业务核算的科目,初始数据按“核算项目、往来日期”进行录入,累计发生额和余额仍保存在t_balance中,往来业务日期保存在往来初始化日期表t_LastContactDate中。
如果启用往来业务核销,则对于起用往来业务核算的科目,初始数据必须按“核算项目、往来日期、业务编号”进行录入,累计发生额和余额仍保存在t_balance中,往来业务日期保存在往来初始化日期表t_TransInitBalance中。
也就是说起用往来业务核销使用t_TransInitBalance表，否则使用
t_TransInitBalance表。
2．3试算平衡
平衡的标准是：当前期间的综合本位币科目借方余额合计等于贷方余额合计，借方累计发生合计等于贷方累计发生额合计，即汇总t_Balance表中FcurrencyID=0的启用期间数据。下面这段SQL语句是检查余额表中的余额是否平衡：
select b.fdc,sum(a.fbeginbalance) from t_balance a join t_account b on
a.faccountid=
b.faccountid
where a.fyear=xxxx and a.fperiod=yy and a.fdetailid=0 and a.fcurrencyid=0 and b.fdetail=1 group by b.fdc
2．4结束初始化
由于月末处理需要，结束初始化后，系统将自动更新表t_Subsys（新增或更新一条记录），同时更新t_SystemProfile 表中 Fcategory = GL, Fkey = InitClosed对应的 Fvalue=1，初始化完成。
2．5案例
案例
问题描述：初始化试算平衡不平
原因：科目没有借贷方向
处理方法：select * from t_account where fdc=0 ，把这些科目方向在界面里双击保存即可。
案例
问题描述：在“初始资料录入”界面录入了所有的初始数据，点击工具栏中的“平衡”按钮，发现“本年累计借方”和“本年累计贷方”差额为零，期初余额的借贷方的差额也为零，但总显示“试算不平衡”。
原因: 在t_balance表中，一些金额字段的小数位数过长导致借贷方相差一个很小的小数。
处理方法：
--用下面SQL对t_balance所有金额字段进行四舍五入
update t_balance set
fbeginbalancefor=round(fbeginbalancefor,2),fbeginbalance=round(fbeginbalanc e,2),
fendbalancefor=round(fendbalancefor,2), fendbalance=round(fendbalance,2), fdebitfor=round(fdebitfor,2), fcreditfor=round(fcreditfor,2),
fdebit=round(fdebit,2),
fcredit=round(fcredit,2), fytddebitfor=round(fytddebitfor,2),
fytdcreditfor=round(fytdcreditfor,2), fytddebit=round(fytddebit,2),
fytdcredit=round(fytdcredit,2)
第3章凭证处理
3．1多项目核算
在讲凭证处理之前，先来讲一下多项目核算，即一个科目带一个核算项目或带多个核算项目时，数据是怎样形成的。
多核算项目在科目中的应用
在基础资料维护中需要下设核算项目的科目中设置核算项目类别，科目下设了核算项目类别将会在表t_Account 中FDetailID 有相应的代码，同时在t_ItemDetailt和
t_ItemDetailV 中有按FdetailID对应的记录。例如：113（应收账款）科目，带部门及客户两个核算项目，假设FDetailID的值为1，那么在t_ItemDeail中有一条记录FDetail = 1 ,FdetaiCount=2 (表示下设两个核算项目类别)，F1= -1 ，F2 = -1，F3 = 0，F4=0，F8=0 等（以“F”开头 + “数字”的字段是根据t_ItemClass 中核算项目类别代码FitemClassID 的值得来的，1和2在t_ItemClass 中分别代表客户和部门，由于此科目下设核算项目类别为“客户”和“部门”，所以只有F1，F2字段的值是–1，其他则为0表示在此类别不参与核算）。
在t_ItemDetailV 中有对应FdetailID = 1的两条记录，FitemClassID对应t_ItemClass 表中FitemClassID的值，分别为1 和2 ，FitemID = -1（表示此类别参与核算）。
多核算项目在凭证中的应用
在录入凭证时科目下设核算项目则提示输入核算项目，输入核算项目后，在表
t_VoucherEntry 中FDetailID 有相应的代码，在表t_ItemDetailt和t_ItemDetailV 中有按FdetailID对应的记录，更新的规则是在t_ItemDetail中“F”开头 + “数字”的字段值和t_ItemDetailV中FitemID字段值是录入的核算项目对应表t_Item中FitemID的值。
例如：做一张收款凭证，借：银行存款，贷：应收账款（下挂客户和部门核算），客户为A客户，部门为B部门；在t_Item个表中，A客户对应的FitemID的值假设为20，B部门对应的FitemID值为30，那么，在保存完这张凭证后，t_VoucherEntry表中FdetailID 的值假设为4，在t_ItemDetail表中相对应有一条FdetailID=4，FdetaiCount=2的记录，其F1=20，F2=30，其他以F开头的字段的值如F3=0，F4=0，F8=0等等，这里面的F1和F2的值就是A客户和B部门在t_Item表中对应的FitemID的值。在t_ItemDetailV有两条相应的记录，表现如下：FDetailID=4，FitemClassID=1，FitemID=20；FDetailID=4，FitemClassID=2，FitemID=30。
在录入模式凭证时，与录入凭证时一样，表t_VoucherEntrytemplate中FDetailID 有相应的代码，在t_ItemDetailt和t_ItemDetailV表中都有相应的记录生成。
核算项目横表和纵表:
核算项目横表为t_ItemDetailt，核算项目纵表为t_ItemDetailtV。核算项目纵表是由核算项目横表来生成的，可以用SP_CleanItemDetailV这个存储过程来生成。系统一般是在查询一些账表时用到核算项目纵表，比如查明细账，如果查出来的核算项目窜户，则可以运行EXEC SP_CleanItemDetailV 来重新生成过核算项目纵表，这样查明细账时数据就正常了。
而有时也会出现核算项目横表丢失记录，而在核算项目纵表中却保存完好，这时就可以写SQL语句从核算项目纵表中把丢失的记录插回核算项目横表中了。
3．2凭证过账
凭证过账过程
在过账前，系统会检查总账是否已完成初始化、检查当前期间是否有未过账凭证，若未完成初始化或没有未过账凭证，则退出过账过程否则进入下一步。
凭证过账时，在选定的凭证范围内按照期间、凭证字、凭证号、分录号的顺序逐条处理凭证分录：
①检查凭证是否在本会计年度、期间。
②根据账套选项的“凭证过账前必须审核”，检查凭证是否已经审核。
③检查科目、核算项目的合法性。
④检查凭证号是否连续。
⑤将分录中的借或贷方发生额登记至t_Balance，分三步完成：
A、登记科目的原币、原币折合本位币发生额。
B、登记核算项目的原币、原币折合本位币发生额。
C、若是非明细科目，则汇总其所有上级科目的发生数。
以上三步操作中数据库中数据会发生变化的有表t_Balance中的
FdebitFor,FcreditFor,FytdDebitFor,
FytdCreditFor,FEndBalanceFor,FDebit,FCredit,FytdDebit,FYtdCredit,FendBa lance十个字段。
⑥检查是否机制损益类凭证，如是结转机制凭证(FinternalInd=“TransferPL”、
“RateAdjust”)，则不更新余额表数据。
⑦若科目属于损益类科目（t_Account中FGroupID值大于500），且凭证分录中
的FinternalInd字段值为“TransferPL”(自动结转)，则将分录中的借或贷方发生额登记至表t_ProfitAndLoss中，分三步完成：
A、登记损益类科目的原币、原币折合本位币发生额。
B、登记核算项目的原币、原币折合本位币发生额。
C、若是非明细科目，则汇总其所有上级科目的发生数。
以上三步操作中数据库中数据会发生变化的有表t_ProfitAndLoss中的FamountFor, FytdAmountFor,Famount,FytdAmount四个字段。
⑧若科目或核算项目设有数量辅助核算，则更新表t_QuantityBalance，发生变
化的字段有FDebitQty ,
FCreditQty ,FYtdDebitQty ,FytdCreditQty,FEndQty五个字段。
⑨表t_Voucher的对应字段Fposted=1,FpostID=过账人，加上过账标记。
3．3凭证反过账
凭证反过账过程
①检查本期有没有已过账的凭证，若没有，则退出反过账过程。
②更新t_Balance本期发生、本年累计及期末余额字段，使其数值去除当前反过账凭证的发生额：
如反过账凭证分录为借方：
注以下：Vch.FamountFor、Vch.Famount、Vch.FQuantity为凭证分录金额及数量
FDebitFor:= FdebitFor — Vch.FAmountFor
FYtdDebitFor= FytdDebitFor — Vch.FAmountFor
FEndBalanceFor= FBeginBalanceFor + DebitFor — CreditFor
FDebit= Fdebit — Vch.FAmount
FYtdDebit= FytdDebit — Vch.FAmount
FEndBalance= FBeginBalance + Debit — Credit
③损益类科目更新t_ProfitAndLoss 本期发生及本年累计字段：
FamountFor= FamountFor —Vch.FAmountFor
FytdAmountFor= FytdAmountFor — Vch.FAmountFor
Famount= Famount — Vch. FAmount
FytdAmount= FytdAmount — Vch.Famount
④更新t_QuantityBalance本期发生、本年累计及期末余额字段，使其恢复至期初状态：
如反过账凭证分录为借方：
FdebitQty= FdebitQty — Vch.Fquantity
FytdDebitQty= FytdDebitQty — Vch.Fquantity
FendQty= FbeginQty+DebitQty — CreditQty
⑤表t_Voucher的对应字段Fposted=0,FpostID= -1 修改为未过账标记。
3．4案例
案例
问题:凭证查询界面双击一凭证，提示：下标越界。
原因：凭证分账制
处理：系统设置==》总账==》取消“凭证分账制”。
案例
问题：凭证保存提示“当前数据已存在”
处理：在总账套的系统参数中,把"凭证号按年度排列"这个选项勾去掉即可.
案例
问题描述：不能保存当前期的凭证，提示“类型不匹配”
处理：系统参数设置==》总账==》凭证==》凭证日期处理中所有日期都设置为零。
案例
问题描述：凭证在WEB模式下无法查询
原因：此问题是环境问题,把KDWEB网站加入到可信任站点中,然后把安全级别设置为最低,选项中的能启用的东西都启用,经常清理临时文件夹.
案例
问题描述:科目应付账款挂供应商核算项目,但是在新增凭证时,输入应收账款科目后回车关标定位在“供应商”处,按F7选择供应商，发现一部分供应商不能出现，比如：代码为001的供应商。
分析：
用profiler跟踪F7选折供应商过程，语句如下：
Select t1.FItemID From t_Item t1 ,t_Supplier x2
where FItemClassID = 8
AND t1.FItemID=x2.FItemID
AND t1.FDeleteD=0
And (t1.FDetail=1)
ORDER BY t1.Fnumber
逐条屏蔽where字句后面的条件，当屏蔽AND t1.FDeleteD=0子句时，供应商001能够查询出来，这说明问题就出在此，检查t_supplier发现该供应商被禁用了。
处理方法：取消供应商禁用。
F 7 问题/ 屏蔽where子句中的条件
上面的案例所本身没有什么价值，我们要说的是处理这个案例的过程。
K3中F7的使用非常多，经常会有客户反映这样的问题：“我在录入XX单据时，在YY 处按F7，但是却发现ZZ资料不能显示”。
比如：“我在录入生产领料单时，在单据头领料部门处按F7，发现一部分部门不能显示出来”；
“我在录入采购发票时，关联采购订单，但是按F7却看不到任何采购订单”；
...
在K3中，凡是按F7的过程，无论是调用基础资料还是调用单据，其SQL格式大致如下：SELECT …
FROM table1 t1
INNER JOIN table2 t2 ON …
INNER JOIN t2 ON …
…
INNER JOIN tableN tn ON …
WHERE 条件1
AND 条件2
…
AND 条件N
处理这类问题时，不要关心SELECT后面的字段和FROM后面的表，直接找到WHERE子句，逐条屏蔽条件1、条件2…条件N。当屏蔽某一个条件时，目标数据可以显示，那说明问题就出在此。
总之，K3中凡是F7问题，都可以按照这一思路来处理，这是一个已经过实践证明的“思维定式”。
案例
问题描述：该账套凭证过账后有些科目余额不准确、或者干脆没有余额，但是明细账都是正确的，比较典型的就是总分类账、科目余额表、试算平衡表也算不平，如果反过账以后，一切又都正常了，过账过程中系统也不报错。
原因：此账套的问题主要是核算项目横表丢失了0记录和其他一些记录.
解决步骤如下: 1、把总账系统反结账到第三期； 2、运行下面的SQL语句：insert into t_itemdetail values (0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0) 3、总账系统直接结账到第四期； 4、最后再在总账中把所有凭证过账,问题即可解决。
案例
问题描述：是自定义核算项目及供应商的问题，只要添加这两种项目核算，就会自动带出部门及职员核算。
原因：此账套的问题在于核算项目横表与核算项目纵表不一致导致科目的辅助核算显示错误,从而在存货核算中定义凭证模板时出现科目的核算项目增多情况.运行下面的存储过程即可解决问题: exec sp_cleanitemdetailv
案例
问题描述：e总账不能新增科目
原因：是核算项目类别资料里有回车符和换行符
select * from t_itemclass where charindex(char(13),fname)>0 select * from t_itemclass where charindex(char(10),fname)>0
处理方法：
－更新即可
update t_itemclass set fname=replace(fname,char(10),'') where
charindex(char(10),fname)>0
update t_itemclass set fname=replace(fname,char(13),'') where
charindex(char(13),fname)>0
案例
问题描述：双击凭证，分录为空。
处理过程：用Profiler跟踪，——
Select ve.FEntryID,ve.FExplanation,ve.FAccountID,ve.FDetailID,a.FNumber as FAccountNumber,
a.FName as FAccountName, a.FFullName as FAcctFullName,
ve.FCurrencyID,c.FNumber as FCurrencyNumber,c.FName as FCurrencyName, ve.FExchangeRate,ve.FDC,ve.FAmountFor,ve.FAmount,ve.FDC*ve.FAmount as FDebit,(1-ve.FDC)*ve.FAmount as FCredit,ve.FQuantity,
ve.FMeasureUnitID,u.FName as
FMeasureUnit,u.FUnitGroupID,u.FCoefficient,ve.FUnitPrice,ve.FInternalInd,ve.FAc countID2,ve.FSettleTypeID,
ve.FSettleNo,ve.FTransNo,ve.FCashFlowItem,ve.FTaskID,ve.FResourceID
From t_VoucherEntry ve,t_Account a,t_Currency c,t_MeasureUnit u
Where ve.FAccountID = a.FAccountID
and ve.FCurrencyID = c.FCurrencyID
--and ve.FMeasureUnitID = u.FMeasureUnitID 屏蔽这一句，问题消失
and ve.FVoucherID =11
问题就出在计量单位，查询t_MeasureUnit表发现零记录丢失。
处理：补回t_MeasureUnit零记录。
可以根据其他账套导入t_MeasureUnit零记录。
使用Excel
使用INSERT INTO前用sp_help 查出所有字段，copy到Excel加逗号。
还有一种情况可能会用到EXCEL——
比如：现在我们想知道所有数据表中那些表包含FKFDate字段，并且查出这些表中是否存在FKFDate<>0或不为Null的记录。
--得到所有包含FKFDate字段的表
select * from sysobjects where id in
(select id from syscolumns where name='FKFDate') and xtype='u'
--把查询结果COPY到EXCEL进行处理。
案例
问题描述：在凭证查询中序时簿里，偶尔有几张凭证只显示一条分录，但是双击时仍可见凭证全部。
原因：经过检查，客户账套中的问题主要是因为个别凭证的结算方式内码有问题，
t_voucherentry表中记录的结算方式内码不正确，出现在t_settle(结算方式表)中不存在的id值，所以叙事簿中显示不出来就是这个原因。
处理：执行下面的sql语句修改： update t_voucherentry set fsettletypeid=6 where fsettletypeid in (87,92)
案例
问题描述:保存凭证时，应收账款的核算项目无法保存。
原因:应收账款挂了两个核算项目：1和F1001，即：客户和另外一个自定义核算项目。检查t_item和客户资料表，发现基础资料本身没有问题，不存在不匹配数据。问题出现在t_itemdetailv表丢失数据。
处理：exec sp_cleanitemdetailv
第4章现金流量
4．1凭证录入与保存时有关现金流量的处理
总账系统中的现金流量表最关键的表就是t_CashFlowBal和t_VoucherEntry这两张表，在做凭证时，如果某条分录指定了现金流量项目，则在t_CashFlowBal表中插入一条记录，在t_VoucherEntry表中，现金类科目的分录记录的FcashFlowItem字段的值为1。
t_CashFlowBal表结构如下：
FvoucherID：凭证内码（与t_VoucherEntry表中的FvoucherID相对应）
FentryID：凭证分录号（与t_VoucherEntry表中的FentryID相对应）
FcashAccountID：现金流量科目内码（即凭证中对方科目的内码）
FitemID：现金流量项目内码（与t_Item表中的FitemID相对应）
FsubItemID：现金流量附表项目内码（与t_Item表中的FitemID相对应）
FcurrencyID：币别内码（与t_VoucherEntry表中的FcurrencyID相对应）
FamountFor：原币金额（与t_VoucherEntry表中的FamountFor相对应）
Famount：本位币金额（与t_VoucherEntry表中的Famount相对应）
当做凭证时，没有指定现金流量项目，而是通过T型账户来指定现金流量项目时，系统会把所有现金类科目的凭证分录（整张凭证的分录）都提取到t_CashFlowBal表中；在没有指定流量项目和附表项目之前，t_CashFlowBal表中的FitemID与FsubItemID字段的值分另为-1和0；当指定了流量表项目和附表项目时，则更新t_CashFlowBal表中相应记录的FitemID和FsubItemID字段的值。
4．2现金流量表的平衡关系
在T型账中，有一些对应关系：现金类科目的借贷发生额一定要相等，非现金类科目的借贷发生额不一定相等；借方现金类科目与非现金类科目发生额合计等于过滤期间的总账的现金类科目的借方发生额，相应的贷方现金类科目与非现金类科目发生额合计等于过滤期间的总账的现金类科目的贷方发生额。这是提取数据最关键的一步，如果在这个地方数据就与总账不对，那么以下的对应关系就没有依据了。
满足上面的对应关系后，就是现金流量表本身的平衡关系了，第一、现金流量的净增加额与补充资料项目中的现金及现金等价物的净增加额相等；第二、补充资料项目中的净利润与利表中的净利润数相等；第三、补充资料项目中的净利润加上附表二的总数等于主表中经营活动产生的现金流量净发生额。
4．3案例
案例
问题描述：有一账套V9.3升级到V9.4.1的过程中出现如下提示：“数据库升级失败！SQL文件不全或SQL语句有误! 错误描述:CREATE UNIQUE INDEX 终止，因为发现了索引 ID 1 的重复键。最重要的主键为 '3020'。 Sql文件
名:D:\WINNT\system32\Kdcom\SqlSrv\SP_K3V94GL.sql Sql内容:ALTER TABLE
dbo.t_CashFlowBal ADD CONSTRAINT pk_CashFlowBal PRIMARY KEY CLUSTERED ( FVoucherID, FEntryID, FCashAccountID, FItemID, FSubItemID, FEntryID2 ) ON [PRIMARY]”。
原因：账套在升级前t_CashFlowBal中记录已经出现主键重复的现象。
处理方法：
select FVoucherID, FEntryID, FCashAccountID, FItemID, FSubItemID, FEntryID2, Sum(FAmountFor) As FAmountFor, Sum(FAmount) As FAmount, FCurrencyID Into
t_CashFlowBalTemp from t_CashFlowBal group by FVoucherID, FEntryID, FCashAccountID, FItemID, FSubItemID, FEntryID2,FCurrencyID
truncate table t_CashFlowBal
insert into t_CashFlowBal(FVoucherID, FEntryID, FCashAccountID, FItemID, FSubItemID, FEntryID2, FAmountFor,FAmount,FCurrencyID) select FVoucherID, FEntryID, FCashAccountID, FItemID, FSubItemID, FEntryID2,
FAmountFor,FAmount ,FCurrencyID from t_CashFlowBalTemp
drop table t_CashFlowBalTemp
案例
问题描述：总账系统中的现金流量表，在T型账户中非现金科目下的流量和附表中的流量全部都指定过了，但现金流量表做出来数字却是不对的，主表中经营活动产生的现金流量净额与附表中经营活动产生的现金流量净额两个数字不相等，主表中现金及现金等价物的净增加额与附表中现金及现金等价物的净增加额两个数字不相等。
分析：碰到此种情况，先到总系统中查找一下是否存在多借多贷的现金类科目的凭证，在总账中的现金流量表中,多借多贷的现金类科目的凭证在提取数据时系统提取不出，从而显示的数据都是错误的，大多数客户存在此种问题。解决方法有下面几种：1、在做凭证时，手工指定多借多贷的现金类科目的凭证的现金流量项目；2、把所有的多借多贷现金类科目凭证拆分成一借多贷或一贷多借的凭证。
排除这种情况外，那么就要从数据着手了。首先，在假设系统提取的凭证没有错误的前提下，分析t_FlowCashBal表，系统提取的凭证数据全部都是放在此表中，在没有指定任何现金流量项目之前，所有的数据都应该是平的，如果不平，则是t_FlowCashBal表的FitemID 和FsubItemID字段的值不正常，可以先把它们清除，再重新指定过应该就会数据平衡。
最后一种情况，就是提取过来的凭证是错误的，而这个错误来源于凭证数据中的对方科目，系统为什么不能处理多借多贷的现金类科目的凭证就是因为系统不能判别每条记录的对方科目。
怎样来判定凭证中对方科目的数据是错误的呢，这就需要写很多的SQL语句来查找到，对于一借一贷的凭证，借方记录的对方科目就是贷方记录的科目，反过来贷方记录的对方科目就是借方记录的科目；对于一借多贷的凭证，借方记录的对方科目只能是贷方第一条记录的科目，；对于多借一贷的凭证，贷方对方科目只能是借方第一条记录的科目；在此排除多借多贷的凭证。
第5章往来处理
5．1往来业务核销
涉及到的主要数据表：t_Voucher，t_VoucherEntry，t_TransCheckInfo、
t_TransInitBalance。进行往来业务核的前提条件是系统参数中设定“启用往来业务核销”，往来科目一定要设置“往来业务核算”，所有的凭证全部都要过账。
以“应收账款”科目为例，系统先从t_TransInitBalance，t_VoucherEntry两个表中取出“应收账款”初始化期间没有核销或没有核销完的数据和凭证表中“应收账款”科目借方发生的没有核销或没有核销完的记录（与t_TransCheckInfo表相比较而得出没有核销或没有核销完的数据），再从t_VoucherEntry表中取出“应收账款”科目贷方发生的没有核销或没有核销完的记录（也是与t_TransCheckInfo表相比较而得出没有核销或没有核销完的数据），分别列在上下两个窗口中。窗口上半部分是需要进行核销的记录，下半部分是收款或是付款业务，如果是资产类科目，则借方行发生额在上面，贷方发生额在下面；如果是负债类科目，则是贷方发生额在上面，借方发生额在下面。在此客户可进行自动或手工核销。
核销完后，系统会在t_TransCheckInfo表中记录核销的记录，FcheckNo字段为核销日志内码。
5．2往来对账单
往来对账单是用来过滤查询某个往来科目的某个核算项目的借贷余数据情况：
当过滤条件选择“全部”时，涉及的表有下面这些：t_Balance，
t_Voucher,t_VoucherEntry, t_ItemDetailV，t_Account ，系统先从t_Balance表中取出期初余额，再从t_Voucher,t_VoucherEntry两表中取出本期借贷方发生数据，最后计算得出余额。
当过滤条件选择“未核销”时，涉及的表有下面这些：t_Balance，t_TransCheckInfo，t_Voucher,t_VoucherEntry, t_ItemDetailV，t_Account ，系统先从t_Balance，
t_TransCheckInfo两表中取出期初余额，再从t_Voucher,t_VoucherEntry两表中取出本期借贷方发生数据，最后计算得出余额。
5．3账龄分析
账龄分析主要是用来对设置为往来核算科目的往来款项余额的时间分布进行分析，系统自动把设置往来的会计科目的科目余额属性方向（如应收账款为借方）的最后一笔业务发生时间为账龄起算点，所有业务自动从凭证中提取，自动出龄分析表。在账龄分析表中，系统只提供单核算的账龄分析表，不提供组合情况的账龄分析表。目前系统的过滤项中的核算项目的选项实际上是无效的，把往来核算的科目下所设置的所有的核算项目都列示出来。
涉及的表有下面这些：t_TransInitBalance，t_Balance，t_LastContactDate，
t_VoucherEntry，t_Voucher，t_TransCheckInfo，t_itemdetail。系统分别从
t_TransInitBalance，t_Balance，t_LastContactDate，t_VoucherEntry这些表中取出期
初，本期借方发生，本期贷方发生的数据与t_TransCheckInfo表中的核销数据相减而得出未核销的数据，按时间的分布把这些数据分别归类到具体的时间中而形成账龄分析表。
5．4注意事项
如果启用了往来业务核销，那么初始数据保存在t_TransInitBalance表中，无论是否关闭初始化、无论凭证是否已经过账，只要未进行往来业务核销(t_TransCheckInfo无记录)系统允许更改总账系统参数“启用往来业务核销”。这个选项只能更改一次,否则会出错。
第6章期末调汇
6．1期末调汇原理
系统执行此功能时，是根据在会计科目中的科目属性来进行的，只有在会计科目中设定为期末调汇的科目才会进行期末调汇处理。
调汇原理：某个科目的期末原币乘以期末汇率是否与此科目调汇前余额表中的综合本位币有差异，如果有差异，就生成调汇凭证。
期末汇率：用户输入。调汇前余额表中的综合本位币：期初综合本位币（即上期期末调汇后的余额）与本期业务发生综合本位币之和。本期业务发生综合本位币：做凭证时原币乘以月初汇率或原币乘以业务发生日的汇率就得出业务发生的综合本位币
调汇计算：
①算出此科目在调汇前余额表中的期末综合本位币A（一般都是把凭证过账即可）
②算出原币余额乘以期末汇率得出期末综合本位币的余额B，B作为本期期末的综本位
币余额，也是下期期初的综合本位币余额。
③算出B与A的差C（B-A），其中C即为要调汇所产生差异。把C记入汇兑损益，是
正是负根据C的正负以及科目的借贷方决定。例如对应收账款调汇，C为正则记入
应收账款正数（借方），记入汇兑损益科目贷方正数。
涉及的表有下面这些：t_User，t_Voucher，t_VoucherEntry，t_VoucherGroup，
t_Currency，t_Account，t_Systemprofile，t_RP_SystemProfile，t_Balance，t_RateAdjust，t_ItemDetailV，t_ItemClass，t_rp_Contact，t_RP_BillNumber，t_RP_ARPBill，
t_RP_Contactbal。
处理步骤如下：
①系统首先检查有没有未过账的凭证，如果有，则退出，没有则进行下一步，检查本
期是否有调汇凭证，有则退出，没有则进行下一步；
②接着系统把期末汇率更新到t_Currency表中相应外币的汇率字段中，再取出汇兑损
益科目，如果没有，则要手工录入，并把此科目填入系统参数表中，以便下次能够
使用；再接着取出生成汇兑损益凭证的凭证字、凭证日期和摘要；
③系统从t_Balance表中取出科目的期末原币和期末本位币（调汇前的本位币），并
计算期末原币*期末汇率减去期末本位币（调汇前的本位币）而得到需要调整的差额，如果差额为零，则提示本期不需要调汇，否则生成一张调汇凭证。
④从应收系统的t_rp_Contact（往来业务列表）中取出期初客户（供应商）外币和本
位币的未核销余额与本期客户（供应商）的发生数据核销后剩余原币和本位币金额
进行汇总，得出客户（供应商）的期末原币和本位币余额，并计算期末原币*期末汇率减去期末本位币而得到需要调整的差额，然后生成一张调汇的其他应收（付）单，这张单据的凭证内码指向第三步生成的调汇凭证内码，且这张单据的状态为完全核
销状态，（向t_RP_ARPBill，t_rp_Contact插入相应的记录），并更新应收应付余额（更新t_RP_Contactbal表中的数据）。