金蝶软件结账常见问题汇总
金蝶软件结账常见问题有哪些你知道吗?你对金蝶软件结账常见问题了解吗?下面是我为大家带来的金蝶软件结账常见问题汇总，欢迎阅读。
金蝶KIS迷你版结账时提示“结账过程中发生错误，操作失败”
产生原因：检查其他账套无此错误，账套数据库出错。
解决办法：打开账套，使用账套“工具”中的“账套数据检查工具”检查数据库表的索引是否出错。检测结果“检查数据表:GLBal出现索引问题,与正常模板DataCheck.dat账套素引不一致。
1.将Glbal表中的所有数据复制粘贴到Excel中;
2.删除Glbal表(需要删除连带的关系);
3.在软件中新建一个空白帐套,什么也不做,直接结束初始化,作为标准帐套备用;
4.打开CHECK3000工具,用上一步中新建的帐套作为标准帐套,有问题的帐套作为目标帐套,点击自动执行，添加Glbal表,以及对应的索引和关系;
5.把Excel表中的数据粘贴回Glbal即可.
金蝶kis迷你版年结操作流程
1 进入金蝶kis迷你版账套--账务处理--凭证过账--结转损益(系统自动生成一张转账凭证)得出本年利润的余额。
2 凭证录入--手动输入一张把本年利润结转到未分配利润的凭证。
3 把系统生成的转账凭证和结转本年利润的凭证进行过账。
4 期末结账。
5 年末结账完成后，系统还会在原账套的存放目录下产生一个当前年度账套的副本。(例如：2016年度账套名称为“公司名2016.AIS”，则副本为“公司名2016.A16”)。
备注：迷你版、标准版年结后系统会自动生成一个新的账套，因为迷你版、标准版是一年一个账套，当2016年结后，账套日期会显示2017年，如果想要查看2016年的账套，则上述第5点里的.副本***.A16的账套便是2016年的账套。
资产负债表不平衡原因分析
1.重算报表
2.所有业务是否处理完成，例如：是否结转损益、凭证是否过账
3. 本期是否存在新增的一级科目
4. 检查比较容易出现错误的项目公式是否正确，例如：应收应付项目、预收预付、存货、未分配利润
5.与科目余额表对比检查
拓展内容： 金蝶财务软件介绍
一、金蝶优势
1.全球领先的中间件技术
金蝶Apusic通过JavaEE5.0认证，这是全球第4家获得JavaEE5.0认证授权的软件公司，标志着中国中间件技术已真正与世界先进水平同步。
2.全球成长最快的企业社交平台
云之家发布8个月用户达20万;来自Alexa的监控数据显示，截至2012年年底，云之家的日均PV值和IP值，超过其他国内企业微博产品的总和。
3.亚太最大在线会计应用平台
友商网付费用户数超过4万，连续四年成为中国在线会计软件领域的第一品牌，是亚太地区在线会计应用平台领导者。
二、版本介绍
1、金蝶EAS
金蝶EAS是集团企业的一体化全面管控解决方案，适用于资本管控型、战略管控型及运营管控型的集团企业。金蝶EAS为资本管控型的多元化企业集团提供财务、预算、资金和高级人才的管控体系，为战略管控型的集团企业提供集团财务、企业绩效管理、战略人力资源、内控与风险的全面战略管控，为运营管控型的集团提供战略采购、集中库存、集中销售与分销、协同计划及其复杂的内部交易和协同供应链的集成管理。
2、金蝶K/3
金蝶K/3是为中小型企业量身定制的企业管理软件。金蝶K/3集财务管理、供应链管理、生产制造管理、人力资源管理、客户关系管理、企业绩效、移动商务、集成引擎及行业插件等业务管理组件为一体，以成本管理为目标，计划与流程控制为主线，通过对目标责任的明确落实、有效的执行过程管理和激励，帮助企业建立人、财、物、产、供、销科学完整的管理体系。
3、金蝶KIS
金蝶KIS是面向小微企业的日常经营管理信息化研发的一系列软件的总称。软件种类齐全，能够全面满足小微企业的不同阶段、不同功能需求。帮助企业建立规范的业务流程，提升管理能力，降低管理、经营成本，增强企业竞争力生存力。2012年金蝶KIS产品采用最新的云计算、社交网络、移动技术，增加云管理服务功能应用，在原有软件的基础上开发了手机、ipad等移动应用。新一代金蝶KIS软件实现了所有客户端的全覆盖，可以随时、随地处理业务并及时了解自己的企业经营、库存等数据。同时很多管理流程也可以在手机上直接完成。[3]
金蝶KIS产品系列包括[3] ：
(1)金蝶KIS财务系列：包含金蝶KIS记账王、金蝶KIS迷你版、金蝶KIS标准版、金蝶KIS行政事业版
(2)金蝶KIS商贸系列：包含金蝶KIS店铺版、金蝶KIS商贸版、金蝶KIS国际版、金蝶KIS零售版
(3)专业系列：包含金蝶KIS专业版
(4)金蝶KIS旗舰系列[3] ：包含金蝶KIS旗舰版
4、金蝶K/3 Cloud
金蝶K/3 Cloud是互联网时代的新型ERP，是基于WEB2.0与云技术的新时代企业管理服务平台。整个产品采用SOA架构，完全基于BOS平台组建而成，业务架构上贯穿流程驱动与角色驱动思想，结合中国管理模式与中国管理实践积累，精细化支持企业财务管理、供应链管理、生产管理、HR管理、供应链协同管理等核心应用。技术架构上该产品采用平台化构建，支持跨数据应用，支持本地部署、私有云部署与公有云部署三种部署方式，同时还在公有云上开放中国第一款基于ERP的云协同开发平台。任何一家使用K/3 Cloud产品的企业，其拥有的是包含金蝶在内的众多基于同一个平台提供服务的服务伙伴。
金蝶 K/3 Cloud 除了具备纯 Web 应用、跨数据库应用、云应用等新兴特性外，该产品在多组织协同应用、多核算体系应用、多账薄应用、多会计政策应用、多组织结算应用、业务流程设计、弹性域与辅助属性应用等多个当代制造业管理焦点与难点应用上都做出了高价值创新，可深度且超预期支撑企业管理创新、技术创新、服务转型、内外部协同、核心竞争力再造等核心需求。
K/3Cloud以其独特的“标准、开放、社交”三大特性为企业提供开放的ERP云平台，支撑企业全生命周期管理需求，是中国“智”造“引擎”。并荣获首届中国电子信息博览会创新奖。
5、金蝶产品体验平台
为了让客户更好的体验金蝶ERP带来的便利，提供金蝶ERP产品免费在线体验。包括以下部分：
· 在线分角色体验金蝶ERP：帮助您轻松从企业管理的角色困惑出发，通过业务场景的模拟，让您轻松体验金蝶ERP提供的解决方案和为您带来的真正价值[4] 。
· 在线产品体验——金蝶K/3 Cloud：基于WEB2.0与云技术的一个开放式、社会化的新时代企业管理服务平台[5] 。
· 在线产品体验——金蝶KBI：系统包含管理驾驶舱、分析中心、功能中心和个人中心四大功能模块[6] 。
· 在线产品体验——云管理产品：利用移动互联网技术充分利用碎片时间，创新企业管理和经营模式[7] 。
6、金蝶ERP云服务(云ERP)
金蝶ERP云服务(云ERP)是金蝶基于划时代的ERP产品K/3 Cloud以及金蝶社交化产品云之家而发展起来的云服务解决方案，主要包括K/3 Cloud公有云服务以及云之家私有云服务两部分内容。
金蝶K/3 Cloud云服务(云ERP)作为金蝶ERP云服务(云ERP)的重要组成部分，是金蝶基于SaaS模式的全面业务管理解决方案，主要包括财务云、供应链云、电商云等标准模块及可根据企业具体情况定制开发，帮助企业超越传统IT架构界限，推动企业转型与发展。借助K/3 Cloud云服务(云ERP)，企业能够以一种全新互联网的方式使用ERP软件，让企业以低成本和高效率实现企业信息化[8] 。
金蝶K/3 Cloud云服务(云ERP)特征：
——软件租赁服务
——用户按年付费
——金蝶提供IT设备与IT运维服务
——用户拥有数据所有权
三、软件功能介绍
金蝶财务软件功能齐全，包括总账、报表、现金管理、网上银行、固定资产管理、应收款管理、应付款管理、实际成本、财务分析、人事/薪资管理。
四、应用范围
金蝶总公司已经是一家上市公司。金蝶软件被广泛的应用于各个领域。如it，教育，金融，服装，等。金蝶KIS系列是适合中小企业的基础版，主要功能有工资管理、固定资产管理、出纳管理、往来管理、财务处理、报表与分析;采购管理、销售管理、采购管理、资金管理、财务管理、初始信息及远程设置。适合很多正在发展中的企业。可以用于各地多用户管理。
;C# 常见错误处理 1 ArgumentException 在向方法提供的其中一个参数无效时引发的异常
2 AppDomainUnloadedException 在尝试访问已卸载的应用程序域时引发的异常
3 ArithmeticException 因算术运算、类型转换或转换操作中的错误而引发的异常
4 ArrayTypeMismatchException 当试图在数组中存储类型不正确的元素时引发的异常
5 BadImageFormatException 当 DLL 或可执行程序的文件图像无效时引发的异常
6 CannotUnloadAppDomainException 卸载应用程序域的尝试失败时引发的异常
7 CodeDomSerializerException 当行号信息可用于序列化错误时引发的异常
8 LicenseException 表示当组件不能被授予许可证时引发的异常
9 WarningException 指定按警告（而不是错误）处理的异常
10 ConfigurationException 配置设置中发生错误时引发的异常
11 InstallException 在安装的提交、回滚或卸载阶段发生错误时引发的异常
12 ContextMarshalException 在尝试将对象封送过上下文边界失败时引发的异常
13 DataException 表示使用 ADO.NET 组件发生错误时引发的异常
14 DBConcurrencyException 在更新操作过程中受影响的行数等于零时，由 DataAdapter 所引发的异常
15 SqlException 当 SQL Server 返回警告或错误时引发的异常。无法继承此类
16 InvalidPrinterException 表示当试图用无效的打印机设置来访问打印机时所引发的异常
17 RegistrationException 检测到注册错误时引发的异常
18 FormatException 当参数格式不符合调用的方法的参数规范时引发的异常
19 IndexOutOfRangeException 试图访问索引超出数组界限的数组元素时引发的异常
20 InvalidCastException 因无效类型转换或显式转换引发的异常
21 InvalidOperationException 当方法调用对于对象的当前状态无效时引发的异常
22 InternalBufferOverflowException 内部缓冲区溢出时引发的异常
23 IOException 发生 I/O 错误时引发的异常
24 ManagementException 表示管理异常
25 NotImplementedException 在无法实现请求的方法或操作时引发的异常
26 NotSupportedException 当调用的方法不受支持，或试图读取、查找或写入不支持调用功能的流时引发的异常
27 NullReferenceException 尝试取消引用空对象引用时引发的异常。
28 OutOfMemoryException 没有足够的内存继续执行程序时引发的异常
29 RankException 将维数错误的数组传递给方法时引发的异常
30 AmbiguousMatchException 当绑定到方法的操作导致一个以上的方法匹配绑定判据时引发的异常
31 ReflectionTypeLoadException 当模块中的任何类无法加载时由 Module.GetTypes 方法引发的异常
32 ServerException 当客户端连接无法引发异常的非 .NET 框架应用程序时，为向客户端传达错误而引发的异常
33 PolicyException 当策略禁止代码运行时引发的异常
34 SecurityException 检测到安全性错误时引发的异常
35 XmlSyntaxException 在 XML 语法分析中出现语法错误时引发的异常
36 TimeoutException 当已达到指定的超时时间时引发的异常
37 SynchronizationLockException 在从非同步的代码块中调用同步方法时引发的异常
38 ThreadAbortException 在对 Abort 方法进行调用时引发的异常
39 TypeInitializationException 作为由类初始值设定项引发的异常周围的包装引发的异常
40 TypeLoadException 类型加载失败发生时引发的异常
41 TypeUnloadedException 试图访问已卸载的类时引发的异常
42 UnauthorizedAccessException 当操作系统因 I/O 错误或指定类型的安全错误而拒绝访问时所引发的异常
43 SoapException 当通过 SOAP 调用 XML Web services 方法且出现异常时引发的异常
44 XmlSchemaException 返回关于架构异常的详细信息
45 XmlException 返回有关最后一个异常的详细信息
46 XsltException 由于在处理“可扩展样式表语言”(XSL) 转换时发生错误而引发的异常
47 XPathException 处理 XPath 表达式而发生错误时引发的异常
本文通过一个案例来看看MySQL优化器如何选择索引和JOIN顺序。表结构和数据准备参考本文最后部分"测试环境"。这里主要介绍MySQL优化器的主要执行流程，而不是介绍一个优化器的各个组件(这是另一个话题)。 我们知道，MySQL优化器只有两个自由度：顺序选择；单
本文通过一个案例来看看MySQL优化器如何选择索引和JOIN顺序。表结构和数据准备参考本文最后部分"测试环境"。这里主要介绍MySQL优化器的主要执行流程，而不是介绍一个优化器的各个组件(这是另一个话题)。
我们知道，MySQL优化器只有两个自由度：顺序选择；单表访问方式；这里将详细剖析下面的SQL，看看MySQL优化器如何做出每一步的选择。
explain
select *
from
employee as A,department as B
where
A.LastName = 'zhou'
and B.DepartmentID = A.DepartmentID
and B.DepartmentName = 'TBX';
1. 可能的选择
这里看到JOIN的顺序可以是A|B或者B|A，单表访问方式也有多种，对于A表可以选择：全表扫描和索引`IND_L_D`(A.LastName = 'zhou')或者`IND_DID`(B.DepartmentID = A.DepartmentID)。对于B也有三个选择：全表扫描、索引IND_D、IND_DN。
2. MySQL优化器如何做
2.1 概述
MySQL优化器主要工作包括以下几部分：Query Rewrite(包括Outer Join转换等)、const table detection、range analysis、JOIN optimization(顺序和访问方式选择)、plan refinement。这个案例从range analysis开始。
2.2 range analysis
这部分包括所有Range和index merge成本评估(参考1 参考2)。这里，等值表达式也是一个range，所以这里会评估其成本，计算出found records(表示对应的等值表达式，大概会选择出多少条记录)。
本案例中，range analysis会针对A表的条件A.LastName = 'zhou'和B表的B.DepartmentName = 'TBX'分别做分析。其中：
表A A.LastName = 'zhou' found records: 51
表B B.DepartmentName = 'TBX' found records: 1
这两个条件都不是range，但是这里计算的值仍然会存储，在后面的ref访问方式评估的时候使用。这里的值是根据records_in_range接口返回，而对于InnoDB每次调用这个函数都会进行一次索引页的采样，这是一个很消耗性能的操作，对于很多其他的关系数据库是使用"直方图"的统计数据来避免这次操作(相信MariaDB后续版本也将实现直方图统计信息)。
2.3 顺序和访问方式的选择：穷举
MySQL通过枚举所有的left-deep树(也可以说所有的left-deep树就是整个MySQL优化器的搜索空间)，来找到最优的执行顺序和访问方式。
2.3.1 排序
优化器先根据found records对所有表进行一个排序，记录少的放前面。所以，这里顺序是B、A。
2.3.2 greedy search
当表的数量较少(少于search_depth，默认是63)的时候，这里直接蜕化为一个穷举搜索，优化器将穷举所有的left-deep树找到最优的执行计划。另外，优化器为了减少因为搜索空间庞大带来巨大的穷举消耗，所以使用了一个"偷懒"的参数prune_level(默认打开)，具体如何"偷懒"，可以参考JOIN顺序选择的复杂度。不过至少需要有三个表以上的关联才会有"偷懒"，所以本案例不适用。
2.3.3 穷举
JOIN的第一个表可以是：A或者B；如果第一个表选择了A，第二个表可以选择B；如果第一个表选择了B，第二个表可以选择A；
因为前面的排序，B表的found records更少，所以JOIN顺序穷举时的第一个表先选择B(这个是有讲究的)。
(*) 选择第一个JOIN的表为B
(**) 确定B表的访问方式
因为B表为第一个表，所以无法使用索引IND_D(B.DepartmentID = A.DepartmentID)，而只能使用IND_DN(B.DepartmentName = 'TBX')
使用IND_DN索引的成本计算：1.2；其中IO成本为1。
是否使用全表扫描：这里会比较使用索引的IO成本和全表扫描的IO成本，前者为1，后者为2；所以忽略全表扫描
所以，B表的访问方式ref，使用索引IND_D
(**) 从剩余的表中穷举选出第二个JOIN的表，这里剩余的表为：A
(**) 将A表加入JOIN，并确定其访问方式
可以使用的索引为：`IND_L_D`(A.LastName = 'zhou')或者`IND_DID`(B.DepartmentID = A.DepartmentID)
依次计算使用索引IND_L_D、IND_DID的成本：
(***) IND_L_D A.LastName = 'zhou'
在range analysis阶段给出了A.LastName = 'zhou'对应的记录约为：51。
所以，计算IO成本为：51；ref做IO成本计算时会做一次修正，将其修正为worst_seek(参考)
修正后IO成本为：15，总成本为：25.2
(***) IND_DID B.DepartmentID = A.DepartmentID
这是一个需要知道前面表的结果，才能计算的成本。所以range analysis是无法分析的
这里，我们看到前面表为B，found_record是1，所以A.DepartmentID只需要对应一条记录就可以了
因为具体取值不知道，也没有直方图，所以只能简单依据索引统计信息来计算：
索引IND_DID的列A.DepartmentID的Cardinality为1349，全表记录数为1349
所以，每一个值对应一条记录，而前面表B只有一条记录，所以这里的found_record计算为1*1 = 1
所以IO成本为：1，总成本为1.2
(***) IND_L_D成本为25.2；IND_DID成本为1.2，所以选择后者为当前表的访问方式
(**) 确定A使用索引IND_DID，访问方式为ref
(**) JOIN顺序B|A，总成本为：1.2+1.2 = 2.4
(*) 选择第一个JOIN的表为A
(**) 确定A表的访问方式
因为A表是第一个表，所以无法使用索引`IND_DID`(B.DepartmentID = A.DepartmentID)
那么只能使用索引`IND_L_D`(A.LastName = 'zhou')
使用IND_L_D索引的成本计算，总成本为25.2；参考前面计算；
(**) 这里访问A表的成本已经是25.2，比之前的最优成本2.4要大，忽略该顺序
所以，这次穷举搜索到此结束
把上面的过程简化如下：
(*) 选择第一个JOIN的表为B
(**) 确定B表的访问方式
(**) 从剩余的表中穷举选出第二个JOIN的表，这里剩余的表为：A
(**) 将A表加入JOIN，并确定其访问方式
(***) IND_L_D A.LastName = 'zhou'
(***) IND_DID B.DepartmentID = A.DepartmentID
(***) IND_L_D成本为25.2；IND_DID成本为1.2，所以选择后者为当前表的访问方式
(**) 确定A使用索引IND_DID，访问方式为ref
(**) JOIN顺序B|A，总成本为：1.2+1.2 = 2.4
(*) 选择第一个JOIN的表为A
(**) 确定A表的访问方式
(**) 这里访问A表的成本已经是25.2，比之前的最优成本2.4要大，忽略该顺序
至此，MySQL优化器就确定了所有表的最佳JOIN顺序和访问方式。
3. 测试环境
MySQL: 5.1.48-debug-log innodb plugin 1.0.9
CREATE TABLE `department` (
`DepartmentID` int(11) DEFAULT NULL,
`DepartmentName` varchar(20) DEFAULT NULL,
KEY `IND_D` (`DepartmentID`),
KEY `IND_DN` (`DepartmentName`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk;
CREATE TABLE `employee` (
`LastName` varchar(20) DEFAULT NULL,
`DepartmentID` int(11) DEFAULT NULL,
KEY `IND_L_D` (`LastName`),
KEY `IND_DID` (`DepartmentID`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk;
for i in `seq 1 1000` ; do mysql -vvv -uroot test -e 'insert into department values (600000*rand(),repeat(char(65+rand()*58),rand()*20))'; done
for i in `seq 1 1000` ; do mysql -vvv -uroot test -e 'insert into employee values (repeat(char(65+rand()*58),rand()*20),600000*rand())'; done
for i in `seq 1 50` ; do mysql -vvv -uroot test -e 'insert into employee values ("zhou",27760)'; done
for i in `seq 1 200` ; do mysql -vvv -uroot test -e 'insert into employee values (repeat(char(65+rand()*58),rand()*20),27760)'; done
for i in `seq 1 1` ; do mysql -vvv -uroot test -e 'insert into department values (27760,"TBX")'; done
show index from employee;
+----------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+----------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+
| employee | 1 | IND_L_D | 1 | LastName | A | 1349 | NULL | NULL | YES | BTREE | |
| employee | 1 | IND_DID | 1 | DepartmentID | A | 1349 | NULL | NULL | YES | BTREE | |
+----------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+
show index from department;
+------------+------------+----------+--------------+----------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------+------------+----------+--------------+----------------+-----------+-------------+----------+--------+------+------------+---------+
| department | 1 | IND_D | 1 | DepartmentID | A | 1001 | NULL | NULL | YES | BTREE | |
| department | 1 | IND_DN | 1 | DepartmentName | A | 1001 | NULL | NULL | YES | BTREE | |
+------------+------------+----------+--------------+----------------+-----------+-------------+----------+--------+------+------------+---------+
4. 构造一个Bad case
因为关联条件中MySQL使用索引统计信息做成本预估，所以数据分布不均匀的时候，就容易做出错误的判断。简单的我们构造下面的案例：
表和索引结构不变，按照下面的方式构造数据：
for i in `seq 1 10000` ; do mysql -uroot test -e 'insert into department values (600000*rand(),repeat(char(65+rand()*58),rand()*20))'; done
for i in `seq 1 10000` ; do mysql -uroot test -e 'insert into employee values (repeat(char(65+rand()*58),rand()*20),600000*rand())'; done
for i in `seq 1 1` ; do mysql -uroot test -e 'insert into employee values ("zhou",27760)'; done
for i in `seq 1 10` ; do mysql -uroot test -e 'insert into department values (27760,"TBX")'; done
for i in `seq 1 1000` ; do mysql -uroot test -e 'insert into department values (27760,repeat(char(65+rand()*58),rand()*20))';
done
explain
select *
from
employee as A,department as B
where
A.LastName = 'zhou'
and B.DepartmentID = A.DepartmentID
and B.DepartmentName = 'TBX';
+----+-------------+-------+------+-----------------+---------+---------+---------------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+-----------------+---------+---------+---------------------+------+-------------+
| 1 | SIMPLE | A | ref | IND_L_D,IND_DID | IND_L_D | 43 | const | 1 | Using where |
| 1 | SIMPLE | B | ref | IND_D,IND_DN | IND_D | 5 | test.A.DepartmentID | 1 | Using where |
+----+-------------+-------+------+-----------------+---------+---------+---------------------+------+-------------+
可以看到这里，MySQL执行计划对表department使用了索引IND_D，那么A表命中一条记录为(zhou,27760)；根据B.DepartmentID=27760将返回1010条记录，然后根据条件DepartmentName = 'TBX'进行过滤。
这里可以看到如果B表选择索引IND_DN，效果要更好，因为DepartmentName = 'TBX'仅仅返回10条记录，再根据条件A.DepartmentID=B.DepartmentID过滤之。
这个案例中因为数据量很小，性能还相差不大，但如果生产环境中数据是千万或者亿级别的时候性能就会差非常非常非常大。通过简单的Hint可以解决这个问题。
原文地址：案例：MySQL优化器如何选择索引和JOIN顺序, 感谢原作者分享。
