商业文档处理器的制作方法

xiaoxiao2020-7-22  14

专利名称:商业文档处理器的制作方法
技术领域
本发明涉及用于对在商业文档中描述的信息执行检查处理并在数据库中注册该种文档的商业文档处理器。例如,本发明涉及通过分析该种文档的逻辑结构来注册和检查商业文档。
背景技术
随着J-SOX(其日文版,或金融产品贸易法)的实施,企业在他们的经营活动中进行的凭证(voucher)的处理已经引起了越来越多的注意。同时,特定地,对于企业使用的商业凭证,由于下面的两个原因,因此即使现在也常常使用非标准化的纸文档。这在管理上是成问题的。第一个原因是,当企业经由商业凭证与客户(例如,顾客、商业伙伴或厂商)执行商业交易时,在某些情况下企业需要创建符合由客户定义的格式的凭证。因此,即使在常规任务中也不能总是使用固定的文档,并且从而不可能完全实现文档的数字化或自动化。第二个原因是,存在某些情况,在这些情况中,根据法律系统、商业环境或公司管理政策的改变,例如向企业的管理部门提交的表格等凭证文档应该被重新创建、废除、合并或在格式上进行改变。因此,需要频繁改变文档格式,从而阻碍了文档的数字化或自动化。同时,在内部控制中,确保在凭证中描述的信息的准确性并充分保存凭证是至关重要的。为了防止凭证的描述中的任何缺陷,必需通过充分检查例如下面列出的这些示例性项目(RCM 风险控制矩阵)等项目来创建并管理凭证。示例性检查项目1 交易数量处于对特定客户设置的信用限额内?示例性检查项目2 信用限额是根据贸易时间间隔重新设置的?示例性检查项目3 以与对各个交易数量或交易类型设计的许可的货品交易量相同的等级或更高等级从被授权的决策者已经获取了任意许可?示例性检查项目4 凭证保存日期在凭证创建日期之前?示例性检查项目5 与示例性检查项目4相反,在凭证创建日期和凭证保存日期之间不存在太长的时间间隔?示例性检查项目6 下面的项目公司名称、货币数量、交付到期日期、交付条件、 接收到期日期、付款到期日期、付款条件等在与下面的文档匹配报价单、定购单、定购确认书、运货单、验收证明书、发票、收据等?示例性检查项目7 创建定购单或运货单的部门与处理付款接收过程或支付过程的部门不同?示例性检查项目8 凭证创建日期符合在工作流中定义的顺序?然而,在基于纸文档的商业运营中,用户没有选择而只能依赖于他们对文档的视觉上的检查。从而,存在某些风险,以至于在审计中,审计者可能指出凭证中的缺陷或可能断言企业在其内部控制中有问题,这可能是由人为错误或用户意识缺乏造成的管理缺陷导致的。
此外,可能出现其中应该根据各种情况不规则地处理凭证的情况。例如,对其已经发出单个报价单的定购可能被分离成多于一个的定购,或可以在进行确认之后的几天里经由FAX接收到官方凭证。在该种情况下,任何人应该准备解释该原因(为何出现该种不规则的处理)。如果没有这样做,在审计中他/她可能仅具有模糊的记忆,这可能导致增加检查步骤的数量的因素。作为管理企业中的文档的系统,已经设计出非专利文献1到4中描述的这些系统。另外,为了检查凭证的内容,必需从纸文档的被扫描的图像中分析其逻辑结构,并自动提取对应于特定项目的值。在专利文献1到3中描述了该种技术。引用列表专利文献PTLl 日本专利申请 No. 7-341983(1995)PTL2 日本专利申请 No. 10-64431 (1998)PTL3 日本专利申请 No. 2000-163784非专利文献NPLl :Documentum (EMC Japan K. K.)http//japan, emc. com/products/family/documentum-family. htmNPL2 :DocumentBroker(Hitachi,Ltd.)http://www. hitachi. co. jp/Prod/comp/softl/docbro/NPL3 :Ridoc (Ricoh Company, Ltd.)http://www. ricoh. co. jp/ridoc_ds/rds/NPL4 =FileNet (IBM Japan, Ltd.)http : //www. i bm. com / developerworksn / jp / ysl/library / db 2/ y-db2-filenetp8-l/

发明内容
技术问题然而,非专利文献1到4中揭示的各个系统仅保存文档,并且对于在文档或有含义的输入项中描述的信息的分析不执行任何处理。从而,用户应该执行与文档中描述的信息相关的所有处理,这与由用户在复杂的项目中进行的视觉检查没有什么区别。此外,由于在专利文献1到3中揭示的所有技术仅打算用于布置文档或改善检索性能,因此用户应该执行基于意义的所有处理或判断。考虑到前述情况做出本发明,本发明提供一种能够在不依赖于由用户进行的视觉检查的情况下自动检查在商业文档中描述的信息的商业文档处理器。技术方案为了解决前述问题,发明人注意了以下事实在企业内产生的凭证的类型限于某些类型;在各个凭证中描述的项目是固定的;及,企业为了内部控制目的准备的检查项目数据(例如,RCM:风险控制矩阵)布置并描述关于在企业中产生的凭证的给定关系。特定地,在RCM中提出的关于凭证的关系被大致划分为与单个凭证中描述的项目相关的那些关系(上述检查项目示例1到5)以及与通过一系列操作产生的多个凭证中描述的项目相关的那些关系(上述检查项目示例6到8)。
S卩,根据本发明的商业文档处理器包括已输入文档分析部,用于分析已输入的商业文档的结构并产生包括多个描述项目的逻辑结构数据;检查项目数据获取部,用于从保存了检查项目数据的数据库中获取用于检查在商业文档中描述的信息的检查项目数据,所述检查项目数据对应于在已输入的商业文档的逻辑结构数据中包括的文档类型数据;描述项目检查处理部,用于通过将已输入的商业文档的逻辑结构数据与由检查项目数据获取部获取的检查项目数据相比较,来检查在已输入的商业文档中描述的信息;及警告显示部,用于当描述项目检查处理部已经发现在已输入的商业文档的逻辑结构数据的描述项目中的不匹配时显示警告。这里的检查项目数据是包括用于检查在商业文档中描述的信息的项目的RCM(风险控制矩阵)数据或客户数据。描述项目检查处理部检查在已输入的商业文档的逻辑结构数据中包括的描述项目是否满足由检查项目数据定义的关系。当检查项目数据包括与已输入的商业文档相关的不同种类的文档的文档类型数据时,检查项目数据获取部从逻辑结构数据库中获取与所述不同种类的文档相对应的逻辑结构数据。然后,描述项目检查处理部检查在已输入的商业文档的逻辑结构数据中包括的描述项目和在所述不同种类的文档的逻辑结构数据中包括的描述项目是否满足由检查项目数据定义的关系。商业文档处理器进一步包括数据修改反映部,用于接受在所显示的警告中包括的不匹配的描述的修改或包括为什么发生了所述不匹配的描述的原因的附加信息的输入, 并在已输入的商业文档的逻辑结构数据中反映所述修改或所述附加信息;及数据注册部, 用于在逻辑结构数据库中注册具有所反映的修改或附加信息的逻辑结构数据。通过用于实施本发明的下面的最优模式和附图,本发明的进一步的特点将变得清林疋。本发明的有益效果根据本发明的商业文档处理器,可以在不依赖由用户进行的视觉检查的情况下自动地检查在商业文档中描述的信息。


图1是说明根据本发明实施例的商业文档处理器的示意性配置的功能框图。图2A和2B说明RCM数据的示例性数据结构。图3说明客户数据的示例性数据结构。图4说明凭证的逻辑结构数据的示例性数据结构。图5是说明商业文档处理器的整体处理的流程图。图6说明示例性检查显示屏幕。图7是说明检查在凭证中描述的项目是否满足预定关系的处理的具体内容的流程图。图8说明当在凭证中描述的项目不满足预定关系时呈现的示例性警告显示屏幕。图9说明检查在通过一系列操作产生的多个凭证中描述的项目是否满足预定关系的处理的具体内容的流程图。图10说明当在通过一系列操作产生的多个凭证中描述的项目不满足预定关系时呈现的示例性警告显示屏幕。图IlA说明另一示例性RCM数据,图IlB说明凭证的另一示例性逻辑结构数据。
具体实施例方式下文中,将参考附图具体描述用于实现本发明的商业文档处理器的最佳模式。图1 到IlB示例性地说明本发明的各实施例。应该注意,被分配了相同附图标记的部件是相同的元件。因此,假设它们的基本结构和操作是相同的。<商业文档处理器的配置>图1是示意性地说明根据本发明实施例的商业文档处理器的内部配置的功能框图。商业文档处理器包括其中保存用于各种文档的RCM(风险控制矩阵)的RCM_DB 100、保存客户数据的客户DB 101、保存凭证的逻辑结构的凭证逻辑结构DB 102、显示数据的显示设备103、执行例如对所显示的数据选择菜单等控制的键盘104、例如鼠标等点击设备105、 执行必要的算法处理、控制处理等的中央处理单元106、保存对于中央处理单元106执行的处理必需的程序的程序存储器107以及保存对于中央处理单元106执行的处理必需的数据的数据存储器108。中央处理单元106包括用于检查在单个凭证中描述的项目的第一处理单元 109(下文简称为“第一处理单元109”)和用于检查在多个凭证中描述的项目的第二处理单元110 (下文简称为“第二处理单元110”)。第一处理单元109检查在凭证中描述的项目是否满足预定关系,对用户显示警告,并接受修改和附加信息的输入。第二处理单元110检查在通过一系列操作产生的多个凭证中描述的项目是否满足预定关系,对用户显示警告,并接受修改和附加信息的输入。数据存储器108包括用于保存从RCM_DB 100获取的并将要用于读入凭证文档的 RCM数据的RCM数据(存储单元)111、保存从客户DB 101获取的目标客户数据的客户数据 (存储单元)112以及保存从凭证逻辑结构DB 102获取的凭证逻辑结构数据的凭证逻辑结构数据(存储单元)113。〈各种数据的结构〉图2A到4说明在数据存储器108中包括的RCM数据111、客户数据112及凭证逻辑结构数据113的(示例性)数据结构。图IlA和IlB分别说明另一凭证的示例性RCM数据和逻辑结构数据。图2A中说明的RCM数据包括凭证ID 200、凭证类型201、凭证检查项目202、相关凭证类型203、相关凭证检查项目204、关系205及适用条件206。在由207和208表示的 RCM适用条件条款数据的阵列中保存适用条件。在图2A和2B中示例性说明的RCM数据用于检查收据和运货单之间的关系。即,如果“收据”满足适用条件,则表示在“收据”中描述的“产品名称”和在与“收据”属于相同项目的“运货单”中描述的“产品名称”是“相同的”。 当要检查单个凭证时,将相关凭证类型203设置为空(NULL)。图2B中说明的RCM适用条件条款数据包括凭证条件项目207和条件208。图2B 说明其中“数量”应该“大于或等于10,000,000日元”的示例性条件。根据数量的该条件, 确定决策者是否是例如后面描述的被授权的决策者。在图IlA说明的示例中,相关凭证类型103指示NULL。从而,这是如后面描述(见图7)的当仅对于单个凭证执行检查处理时的RCM数据的示例。图IlA表示了关系,从而如果“合同”满足适用条件,则本文描述的“被授权的决策者”是“总经理级别或更高级别的人”。图3中说明的客户数据包括客户名称300、最近的信用检查日期301以及信用限额 302。图3说明其中用于被称为“ABC公司”的客户的信用限额是“50,000,000日元”,并且于“2008年2月11日”最后检查了该信用限额。图4中说明的凭证逻辑结构数据包括当读入凭证时分配的项目ID 400、凭证类型 401、公司名称402、被授权决策者403、数量404、交付到期日期405、交付条件406、付款到期日期407、付款条件408、描述409、凭证创建日期410、附加信息411、最近的信用检查日期412及信用限额413。区段(field)400到410中的信息表示当读入凭证时设置的值,区段411到413中的信息表示在随后的处理中设置的值。根据凭证的种类,区段402和408 中的信息可以存在或不存在。图4中的示例表示关于凭证的信息,对于该凭证,项目ID是 “2008A_01234”,凭证类型是“收据”,其中,公司名称是“ABC公司”、被授权的决策者是“采购部的总经理Mary Smith”、交付到期日期是“2009年3月31日”、描述是“一台商业文档处理器”、凭证创建日期是“2009年3月30日”。图IlB中的示例表示关于凭证的信息,对于该凭证,项目ID是“2008A_01230”, 凭证类型是“合同”,其中,公司名称是“ABC公司”、被授权的决策者是“销售部的副理John Smith”、凭证创建日期是“2009年3月30日”。<具体处理>(1)整体处理现在将描述根据具有前述配置的当前实施例的商业文档处理器执行的处理。图5 是示意性地说明商业文档处理器的整体处理流程的流程图。在图5中,中央处理单元(CPU) 106首先获取经由扫描仪等(未示出)输入的凭证的逻辑结构数据,并将其保存为凭证逻辑结构数据113(步骤S500)。应该注意,在专利文献 1到3中揭示的分析文档的逻辑结构的技术可用作从凭证的被扫描的图像获取凭证的逻辑结构数据的方法。在凭证逻辑结构数据113的值400到410中,将在凭证中没有描述的那些保存为NULL。这时,基于作为所输入的文档的逻辑结构分析的结果获得的凭证类型401, 从RCM_DB 100中获取要用于检查处理的RCM数据(见图2),并在RCM数据存储单元111中保存该RCM数据。提供了多条RCM数据。一条RCM数据被称为一个元素。因此,当存在三条RCM数据时,元素的数量是三。接着,中央处理单元106将数据改变标记设置为假(FALSE)(步骤S501)。该标记是一种初始值。对于所输入的凭证逻辑结构数据,首先将该标记设置为FALSE。然后,参考图3,中央处理单元106基于关于公司名称的信息获取关于最近的信用检查日期和信用限额的信息(步骤S502)。S卩,中央处理单元106搜索在客户客户DB 101中保存的客户数据 112中的元素以查找客户与凭证逻辑结构数据113中的公司名称402相同的客户名称300。 然后,中央处理单元106将该种元素中的最近的信用检查日期301传送到凭证逻辑结构数据113的最近的信用检查日期412的区段,并且也将信用限额302传送到凭证逻辑结构数据113的信用限额413的区段。之后,第一处理单元109参考输入的凭证数据检查在单个凭证中描述的项目是否满足预定关系(步骤S50;3)。例如,在该处理中,第一处理单元109检查上述的示例性检查项目1到5。将参考图7描述该具体内容。第二处理单元110检查在通过一系列操作产生的多个凭证中描述的项目是否满足预定关系(步骤S504)。这是检查已经产生的凭证和所输入的凭证之间存在匹配条件的处理。例如,第二处理单元110检查上述示例性检查项目6到8。将参考图9描述该具体内容。然后,中央处理单元106在显示设备103上显示凭证逻辑结构数据的检查屏幕,并从用户接受修改输入(步骤S505)。在这里显示的屏幕类似于图6中所说明的。用户可以点击按钮601以在修改之后注册值,或可以点击按钮601以在没有修改的情况下注册值。如果发生了任何修改,则基于修改将标记改变为真(TRUE)。当用户在修改值之后点击了按钮601时,中央处理单元106在凭证逻辑结构数据 113中反映该种改变,并将数据改变标记设置为TRUE (步骤S506)。此外,中央处理单元106 检查数据改变标记是否是TRUE (步骤S507),并且如果对步骤S507的回答为是(YES),则流程返回到步骤S501以重新开始处理。由于指示TRUE的标记表示某些修改已经发生,因此这是用于再次检查的目的。如果对步骤S507的回答为否(NO),则中央处理单元106将作为凭证逻辑结构数据 113保存的该内容保存到凭证逻辑结构DB 102 (步骤S508),并终止处理。(2)用于在单个凭证中描述的项目的检查处理图7是说明图5中的步骤S503的具体内容的流程图,即检查在凭证中描述的项目是否满足预定关系的处理。在图7中,除了另行指定之外,执行各个步骤的处理的主体是第一处理单元109。首先,第一处理单元109将索引变量i初始化为1 (步骤S700)。然后,第一处理单元109检查在RCM_DB 100中保存的RCM数据111的元素的数量是否小于i,并且如果确定该元素的数量小于i,则处理终止(步骤S701)。如果确定该元素的数量大于或等于i,则流程进一步前进到步骤S702,反之,如果确定该元素的数量小于i (初始地小于1),则处理终止。这是由于不再存在要被检查的RCM元素。然后,第一处理单元109检查是否满足RCM数据111的第i个元素的适用条件 206 (条件条款数据)(步骤S7(^)。如果对步骤S702的回答为N0,则流程前进到步骤S707, 如果对步骤S702的回答为YES,则流程前进到步骤S703。S卩,第一处理单元109检查RCM数据111的第i个元素的相关凭证类型203是否指示为NULL (步骤S70!3)。如果对步骤S703 的回答为N0,则表示该元素描述了凭证之间的关系。从而,由于该种凭证不是这里的检查对象,因此流程前进到步骤S707。如果对步骤S703的回答为YES,则流程前进到步骤S704。然后,第一处理单元109 检查RCM数据111的第i个元素的凭证检查项目202是否满足在关系205的区段中保存的关系(S704)。如果对步骤S704的回答为N0,则流程前进到步骤S705,如果对步骤S704的回答为YES,则流程前进到步骤S707。在步骤S705,中央处理单元106在显示设备103上显示警告并从用户接受修改和附加信息的输入(步骤S705)。例如,在步骤S705中显示的警告显示屏幕类似于图8中说明的屏幕。如图8中的800所指示的,中央处理单元106在显示设备103上通过在其中嵌入下面的信息来显示不满足在RCM数据111的第i个元素中描述的关系的效果的信息ID 1100(图8的示例中的“合同_011”)、凭证类型1101(图8的示例中的“合同”)、凭证检查项目1102(图8的示例中的“被授权的决策者”)、关系1105(图8的示例中的“总经理级别或更高级别的那些人”)以及凭证逻辑结构数据113中的对应项目的值(图8的示例中的“销售部的副理 John Smith”)。在图8的示例中,基于假设RCM数据111的第i个元素不指定“应该关于合同(凭证类型1101)来被检查”的任意凭证,相关凭证类型1103指示为NULL。这里的凭证检查项目1102是“被授权的决策者”。由于虽然被授权的决策者应该是“总经理级别或更高级别的那些人”但是图8中指示的被授权的决策者是“副经理”,因此这里显示警告显示 800。中央处理单元106如801所指示地显示逻辑结构数据1107到1117和1118到1120 中的内容,并且还显示如802所指示地用于输入附加信息的区域。用户可以在修改区域801 中的信息或将信息输入到区域802之后点击按钮803注册值,或可以在没有修改或输入任何信息的情况下点击按钮803注册值。图8示例性地说明通过在被授权的决策者的区域中显示的提示用户正在修改区域801中的信息的情况。因此,如在专利文献1到3中的分析文档的逻辑结构的技术中所描述的,即使在从凭证的被扫描的图像中获取凭证的逻辑结构数据的处理中出现错误,修改也是可以的。当用户在修改和输入信息之后点击按钮803时,将被修改的信息和新输入的信息反映在凭证逻辑结构数据113中,并也将数据改变标记设置为TRUE (步骤S706)。这里,当用户已经将信息输入到区域802中时,将该种信息保存为附加信息1118。随后,将索引变量i增加1 (步骤S707),然后流程返回到步骤S701以重新开始处理。(3)用于在多个凭证中描述的项目的检查处理图9是说明图5中的步骤S504的具体内容的流程图,即检查在通过一系列操作产生的多个凭证中描述的项目是否满足预定关系的处理。在图9中,除了另行指定之外,执行各个步骤的处理的主体是第二处理单元110。首先,第二处理单元110将索引(index)变量i初始化为1(步骤S900)。然后,第二处理单元110检查在RCM_DB 100中保存的RCM数据111的元素的数量是否小于i,并且如果确定该元素的数量小于i,则处理终止(步骤S901)。如果确定该元素的数量大于或等于i,则流程进一步前进到步骤S902,反之,如果确定该元素的数量小于i (初始地小于1), 则处理终止。这是由于不再存在要被检查的RCM元素。然后,第二处理单元110检查是否满足RCM数据111的第i个元素的适用条件 206 (步骤S902)。如果对S902的回答为N0,则流程前进到步骤S908。如果对步骤S902的回答为YES,则第二处理单元110检查RCM数据111的第i个元素的相关凭证类型203是否指示NULL (步骤S90;3)。如果对步骤S903的回答为YES,则表示该元素描述了关于单个凭证的关系。从而,由于该种凭证不是这里的检查对象,因此流程前进到步骤S908。如果对步骤S903的回答为N0,则第二处理单元110检查凭证逻辑结构DB 102是
9否保存了具有与凭证逻辑结构数据113中的项目ID 400相同的项目ID并具有与RCM数据 111的第i个元素的相关凭证类型203相同的凭证类型的凭证(步骤S904)。如果没有保存该种凭证,则流程前进到步骤S908。如果在凭证逻辑结构DB 102中保存了相关凭证,则第二处理单元110检查是否满足在RCM数据111的第i个元素中保存的关系205 (步骤S9(^)。如果对步骤S905的回答为N0,则中央处理单元106首先显示警告,然后从用户接受修改和附加信息的输入(步骤 S906)。这里显示的警告屏幕与图10中说明的屏幕类似。如由1000所指示的,显示对于不满足在RCM数据111的第i个元素中描述的关系的结果的描述。如由1000所指示的警告文本模板包括空白“ ”。通过以相关项目填写的空白,产生用于对条件不匹配进行报警的警告文本。例如,在警告文本模板中显示的空白“ ”被填入ID 200(图10的示例中的“收据 _001”)、凭证类型201(图10的示例中的“收据”)、凭证检查项目202(图10的示例中的 “公司名称”)、相关凭证类型203(图10的示例中的“运货单”)、相关凭证检查项目204(图 10的示例中的“公司名称”)、关系205(图10的示例中的“相同”)、凭证逻辑结构数据113 中的对应项目的值113(图10的示例中的“ABC公司”)以及在凭证逻辑结构DB 102中保存的凭证逻辑结构数据中的对应项目的值(图10的示例中的“XYZ公司”)。另外,如1001所指示地显示逻辑结构数据的内容,如1002所指示地也显示用于输入附加信息的区域。用户可以点击按钮1003以在修改区域1001中的信息并将信息输入到区域1002中之后注册值,或可以点击按钮1003以在没有修改或输入任何信息的情况下注册值。图10说明其中用户正在将信息输入到区域1002中以输入附加信息的示例。因此, 可以在注册凭证过程中清楚地示出不规则处理凭证的原因,并快速地在审计中对审计者解释该种原因,从而减少步骤的数量。当用户已经在修改并输入信息之后点击按钮1003时,将被修改的信息和新输入的信息反映在凭证逻辑结构数据113中,并也将数据改变标记设置为TRUE (步骤S907)。这里,当用户已经将信息输入到区域1002中时,将该种信息保存为附加信息411。随后,将索引变量i增加1 (步骤S908),然后流程返回到步骤S901以重新开始处理。< 结论 >根据当前实施例,在注册凭证的过程中自动检查凭证的内容,据此,对用户显示警告并接受附加信息的输入。从而,可以防止凭证的描述中的缺陷并确定地搜集关于不规则处理凭证的原因的信息。特定地,可以通过检查在一个凭证中描述的项目是否满足预定条件或通过检查在通过一系列操作产生的多个凭证中描述的项目是否满足预定关系来确定地执行检查。应该注意,基于为要被检查的特定凭证所获取的检查项目数据(例如,RCM数据)中包括的相关凭证的信息,识别通过一系列操作产生的多个凭证。通过使用RCM检查凭证的内容,可以根据各个企业的商业内容来检查凭证的内容。RCM是在企业中为了内部控制的目的正常创建的文档。使用RCM可以减少对于构建和操作系统所要求的步骤的数量。当使用已经基于RCM处理过的信息来检查凭证的内容时, 也可以期望相似的效果。另外,通过使用客户数据检查凭证的内容,可以根据各个交易项目来检查凭证的内容。
应该注意,还可以通过实现本实施例的功能的软件的程序代码来实现本发明。在该种情况下,对系统或设备提供记录了程序代码的存储介质,并且系统或设备中的计算机 (或CPU或MPU)读取在存储介质中存储的程序代码。在该情况下,从存储介质读取的程序代码本身实现前述实施例的功能,并且程序代码本身和记录了程序代码的存储介质构成本发明。作为用于提供该种程序代码的存储介质,例如,使用软盘、CD-ROM、DVD-ROM、硬盘、光盘、磁光盘、CD-R、磁带、非易失性存储卡、ROM等。此外,基于程序代码中的指令,在计算机上运行的OS (操作系统)等可以执行某些或所有的实际处理,并且可以通过这些处理实现前述实施例的功能。另外,在将从存储介质中读取的程序代码写入计算机中的存储器之后,计算机的CPU等可以基于程序代码的指令执行某些或所有的实际处理,并且可以通过这些处理实现前述实施例的功能。另外,可以经由网络来分配实现实施例的功能的软件的程序代码,并从而在例如系统或设备中的硬盘或存储器等存储部件或例如CD-RW或CD-R等存储介质中保存该程序, 并且在使用上,系统或设备中的计算机(或CPU或MPU)可以读取在存储部件或存储介质中保存的程序代码并执行程序代码。附图标记列表
100:RCB DB
101客户DB
102凭证逻辑结构DB
103显不设备
104键盘
105点击设备
106中央处理单元
107程序存储器
108数据存储器
权利要求
1.一种商业文档处理器,执行对于在商业文档中描述的信息的检查处理并在数据库中注册所述商业文档,所述商业文档处理器包括输入部,用于输入所述商业文档;已输入文档分析部,用于分析已输入的商业文档的结构并产生包括多个描述项目的逻辑结构数据;检查项目数据获取部,用于从保存了检查项目数据的数据库中获取用于检查在所述商业文档中描述的信息的检查项目数据,所述检查项目数据对应于已输入的商业文档的逻辑结构数据中包括的文档类型数据;描述项目检查处理部,用于通过将已输入的商业文档的逻辑结构数据与由检查项目数据获取部获取的检查项目数据相比较,来检查在已输入的商业文档中描述的信息;及警告显示部,用于当描述项目检查处理部已经发现在已输入的商业文档的逻辑结构数据的描述项目中的不匹配时显示警告。
2.根据权利要求1所述的商业文档处理器,其中检查项目数据是包括用于检查在所述商业文档中描述的信息的项目的RCM(风险控制矩阵)数据,检查项目数据获取部从RCM数据库获取与在已输入的商业文档的逻辑结构数据中包括的文档类型数据相对应的RCM数据,并且,描述项目检查处理部通过将已输入的商业文档的逻辑结构数据与由检查项目数据获取部获取的RCM数据相比较,来检查在已输入的商业文档中描述的信息。
3.根据权利要求1所述的商业文档处理器,其中检查项目数据是在所述商业文档中包括的客户数据,检查项目数据获取部从客户数据库中获取与在已输入的商业文档的逻辑结构数据中包括的文档类型数据相对应的客户数据,并且描述项目检查处理部通过将已输入的商业文档的逻辑结构数据与由检查项目数据获取部获取的客户数据相比较,来检查在已输入的商业文档中描述的信息。
4.根据权利要求1所述的商业文档处理器,其中,描述项目检查处理部检查在已输入的商业文档的逻辑结构数据中包括的描述项目是否满足由检查项目数据定义的关系。
5.根据权利要求1到4中任一项所述的商业文档处理器,其中当检查项目数据包括与已输入的商业文档相关的不同种类的文档的文档类型数据时, 检查项目数据获取部从逻辑结构数据库中获取与所述不同种类的文档相对应的逻辑结构数据,并且描述项目检查处理部检查在已输入的商业文档的逻辑结构数据中包括的描述项目和在所述不同种类的文档的逻辑结构数据中包括的描述项目是否满足由检查项目数据定义的关系。
6.根据权利要求1到5中任一项所述的商业文档处理器,进一步包括数据修改反映部,用于接受在所显示的警告中包括的不匹配的描述的修改或包括为什么已经发生了所述不匹配的描述的原因的附加信息的输入,并在已输入的商业文档的逻辑结构数据中反映所述修改或所述附加信息;及数据注册部,用于在逻辑结构数据库中注册具有所反映的修改或附加信息的逻辑结构数据。
全文摘要
通过充分检查凭证的内容来创建和管理凭证,以使得凭证将在描述中不包括任何缺陷。通过分析凭证的逻辑结构分析在凭证中描述的信息。基于为内部控制目的而准备的RCM(风险控制矩阵),检查在单个凭证中描述的项目是否满足预定关系以及在通过一系列操作产生的多个凭证中描述的项目是否满足预定关系。然后,显示警告并接受修改的输入。
文档编号G06F17/21GK102171684SQ20098013878
公开日2011年8月31日 申请日期2009年11月27日 优先权日2008年12月2日
发明者中重亮, 大峡光晴, 松本俊子, 野崎康行 申请人:日立系统解决方案有限公司

最新回复(0)