CN104102992A - 业务单据变更控制方法和系统 - Google Patents

Abstract

本发明提供了一种业务单据变更控制方法，包括：根据业务单据的变更范围，判断业务单据的变更请求是否在所述业务单据的所述变更范围内，当判断结果为是时，接收所述变更请求；根据接收到的所述变更请求，查找所述业务单据的历史业务变更记录；判断所述历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和所述变更请求，设置目标变更任务；根据所述目标变更任务变更所述业务单据。相应地，本发明还提出了一种业务单据变更控制装置。通过本发明的技术方案，可以实现业务单据变更的事前控制和事后复查，便于用户对业务变更进行监管和事后数据分析。

Description

业务单据变更控制方法和系统

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种业务单据变更控制方法和一种业务单据变更控制系统。

背景技术

在软件系统的应用过程中，有很多针对业务单据的变更业务，由于很多软件系统并不支持内控功能，所以此类变更业务很难通过软件系统来实现，使用户在通过软件系统变更业务单据的过程中遭遇了诸多不变，目前软件系统中对于业务单据的变更控制主要存在以下不足：

(1)变更过于随意，比如在人为数据录入发生错误后直接对数据进行修改，这样造成可以对于已完结业务随意进行可逆操作，容易发生错误，且不利于系统的安全运行；

(2)不能体现逐级申请、审批的过程与流程记录，不利于用户对系统进行监管；

(3)不能跟踪、追溯历史变更过程中的审批过程及干系人等信息，不利于事后的复查和数据分析。

因此，需要一种新的技术方案，可以实现业务单据变更的事前控制和事后复查，提升系统的安全性，便于用户对业务变更进行监管和事后数据分析。

发明内容

本发明正是基于上述问题，提出了一种新的技术方案，可以实现业务单据变更的事前控制和事后复查，提升系统的安全性，便于用户对业务变更进行监管和事后数据分析。

有鉴于此，一种业务单据变更控制方法，包括：根据业务单据的变更范围，判断业务单据的变更请求是否在所述业务单据的所述变更范围内，当判断结果为是时，接收所述变更请求；根据接收到的所述变更请求，查找所述业务单据的历史业务变更记录；判断所述历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和所述变更请求，设置目标变更任务；根据所述目标变更任务变更所述业务单据。

在该技术方案中，通过判断业务单据的变更请求是否在所述业务单据的所述变更范围内来确定该变更请求是不是可以被接收并执行，比如，在财务软件系统中，修改本月的某张采购单据的申请一般可以被接收。通过判断历史业务变更记录中是否具有未审核的历史变更任务，可以确定目标变更任务，这体现了申请和审批的过程，可以实现业务单据变更的事前控制，利于用户对业务变更进行监管。

在上述技术方案中，优选地，在判断业务单据的变更请求是否在所述业务单据的所述变更范围内之前，还包括：根据接收到的设置命令，设置所述业务单据的所述变更范围；以及判断所述业务单据的所述变更请求是否在所述业务单据的所述变更范围内，当判断结果为否时，拒绝所述业务单据的变更请求。

在该技术方案中，为业务变更设置一个变更权限范围，当变更请求在该变更权限范围内时才可以接收该变更请求，比如，修改本月的某张采购单据的申请一般可以被接收。而当变更请求超出了预设的变更权限范围的时候，应当拒绝所述业务单据的变更请求，比如已经结算的自然月的财务数据一般是不可以变更的，当得到修改已经结算的自然月的财务数据的请求时，系统判定该请求超过了权限变更范围，不予接收。这样，避免了用户在自身权限范围外对于已完结业务随意进行可逆操作，减少了发生错误的几率，有利于事后的复查和数据分析，提高了系统运行的安全性。

在上述技术方案中，优选地，还包括：存储所述接收的所述业务单据的变更请求和/或所述拒绝的所述业务单据的变更请求的标识信息；以及存储所述目标变更任务的标识信息和变更后的所述目标业务单据的标识信息。

在上述技术方案中，优选地，所述标识信息包括操作用户、操作时间、操作内容和/或操作日期。

在该技术方案中，通过存储各步骤的操作用户、操作时间、操作内容和操作日期等标识信息，可以得到用户的操作流程记录，能体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

在上述技术方案中，优选地，判断所述历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和所述变更请求，设置目标变更任务，具体包括：判断所述历史业务变更记录中是否具有所述标识信息为空的历史变更任务，当判断结果为是时，即所述历史业务变更记录中具有未完成的历史变更任务，则将所述未完成的所述历史变更任务设置为所述目标变更任务；以及当判断结果为否时，即所述历史业务变更记录中不具有未完成的历史变更任务，则根据所述接收到的所述业务单据变更请求，建立所述目标变更任务。

在该技术方案中，以标识信息作为判断历史变更任务是否已完成的标志，当历史变更任务的标识信息为空时，判定该历史变更任务为未完成。如果该历史变更任务已经经过审核，则对其进行取消审核操作，并将其设置为目标变更任务；如果该历史变更任务还未经过审核，可以直接将该历史变更任务设置为目标变更任务，对其进行修改和/删除等操作。而当历史变更任务的标识信息不为空时，判定该历史变更任务的状态为已完成，不允许进行放弃审核、修改和/删除等操作，系统应根据接收到的业务单据变更请求，建立新的目标变更任务。这样，避免了用户对于已完结业务随意进行可逆操作，减少了发生错误的几率，提高了系统运行的安全性，同时，还可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

根据本发明的另一方面，还提供了一种业务单据变更控制系统，包括：第一判断单元，根据业务单据的变更范围，判断业务单据的变更请求是否在所述业务单据的所述变更范围内，当判断结果为是时，接收所述变更请求；查找单元，用于根据接收到的所述变更请求，查找所述业务单据的历史业务变更记录；第二判断单元，用于判断所述历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和所述变更请求，设置目标变更任务；变更单元，用于根据所述目标变更任务变更所述业务单据。

在该技术方案中，通过判断业务单据的变更请求是否在所述业务单据的所述变更范围内来确定该变更请求是不是可以被接收并执行，比如，在财务软件系统中，修改本月的某张采购单据的申请一般可以被接收。通过判断历史业务变更记录中是否具有未审核的历史变更任务，可以确定目标变更任务，这体现了申请和审批的过程，可以实现业务单据变更的事前控制，利于用户对业务变更进行监管。

在上述技术方案中，优选地，还包括：初始设置单元，根据接收到的设置命令，设置所述业务单据的所述变更范围；以及所述第一判断单元还包括：当判断结果为否时，拒绝所述业务单据的变更请求。

在该技术方案中，为业务变更设置一个变更权限范围，当变更请求在该变更权限范围内时才可以接收该变更请求，比如，修改本月的某张采购单据的申请一般可以被接收。而当变更请求超出了预设的变更权限范围的时候，应当拒绝所述业务单据的变更请求，比如已经结算的自然月的财务数据一般是不可以变更的，当得到修改已经结算的自然月的财务数据的请求时，系统判定该请求超过了权限变更范围，不予接收。这样，避免了用户在自身权限范围外对于已完结业务随意进行可逆操作，减少了发生错误的几率，有利于事后的复查和数据分析，提高了系统运行的安全性。

在上述技术方案中，优选地，还包括：存储单元，用于存储所述接收的所述业务单据的变更请求和/或所述拒绝的所述业务单据的变更请求的标识信息；以及存储所述目标变更任务的标识信息和变更后的所述目标业务单据的标识信息。

在上述技术方案中，优选地，所述标识信息包括操作用户、操作时间、操作内容和/或操作日期。

在该技术方案中，通过存储各步骤的操作用户、操作时间、操作内容和操作日期等标识信息，可以得到用户的操作流程记录，能体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

在上述技术方案中，优选地，所述第二判断单元具体包括：判断所述历史业务变更记录中是否具有所述标识信息为空的历史变更任务，当判断结果为是时，即所述历史业务变更记录中具有未完成的历史变更任务，则将所述未完成的所述历史变更任务设置为所述目标变更任务；以及当判断结果为否时，即所述历史业务变更记录中不具有未完成的历史变更任务，则根据所述接收到的所述业务单据变更请求，建立所述目标变更任务。

在该技术方案中，以标识信息作为判断历史变更任务是否已完成的标志，当历史变更任务的标识信息为空时，判定该历史变更任务为未完成。如果该历史变更任务已经经过审核，则对其进行取消审核操作，并将其设置为目标变更任务；如果该历史变更任务还未经过审核，可以直接将该历史变更任务设置为目标变更任务，对其进行修改和/删除等操作。而当历史变更任务的标识信息不为空时，判定该历史变更任务的状态为已完成，不允许进行放弃审核、修改和/删除等操作，系统应根据接收到的业务单据变更请求，建立新的目标变更任务。这样，避免了用户对于已完结业务随意进行可逆操作，减少了发生错误的几率，提高了系统运行的安全性，同时，还可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

通过以上技术方案，可以避免用户对于已完结业务随意进行可逆操作或超过允许范围的操作，减少了发生错误的几率，能够提升系统的安全性，还可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

附图说明

图1示出了根据本发明的实施例的业务单据变更控制方法的流程图；

图2示出了根据本发明的实施例的业务单据变更控制系统的框图；

图3示出了根据本发明的实施例的业务单据变更控制方法的具体流程图；

图4示出了根据本发明的另一个实施例的业务单据变更控制系统的框图；

图5示出了根据本发明的再一个实施例的业务单据变更控制方法的流程图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

图1示出了根据本发明的实施例的业务单据变更控制方法的流程图。

如图1所示，根据本发明的实施例的业务单据变更控制方法，包括以下步骤：

步骤102，根据业务单据的变更范围，判断业务单据的变更请求是否在业务单据的变更范围内，当判断结果为是时，接收变更请求。

步骤104，根据接收到的变更请求，查找业务单据的历史业务变更记录。

步骤106，判断历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和变更请求，设置目标变更任务。

步骤108，根据目标变更任务变更业务单据。

在该技术方案中，通过判断业务单据的变更请求是否在业务单据的变更范围内来确定该变更请求是不是可以被接收并执行，比如，在财务软件系统中，修改本月的某张采购单据的申请一般可以被接收。通过判断历史业务变更记录中是否具有未审核的历史变更任务，可以确定目标变更任务，这体现了申请和审批的过程，可以实现业务单据变更的事前控制，利于用户对业务变更进行监管。

在上述技术方案中，优选地，步骤102之前还包括：根据接收到的设置命令，设置业务单据的变更范围；以及步骤102还包括：当判断结果为否时，拒绝业务单据的变更请求。

在该技术方案中，为业务变更设置一个变更权限范围，当变更请求在该变更权限范围内时才可以接收该变更请求，比如，修改本月的某张采购单据的申请一般可以被接收。而当变更请求超出了预设的变更权限范围的时候，应当拒绝业务单据的变更请求，比如已经结算的自然月的财务数据一般是不可以变更的，当得到修改已经结算的自然月的财务数据的请求时，系统判定该请求超过了权限变更范围，不予接收。这样，避免了用户在自身权限范围外对于已完结业务随意进行可逆操作，减少了发生错误的几率，有利于事后的复查和数据分析，提高了系统运行的安全性。

在上述技术方案中，优选地，还包括：存储接收的业务单据的变更请求和/或拒绝的业务单据的变更请求的标识信息；以及存储目标变更任务的标识信息和变更后的目标业务单据的标识信息。

在上述技术方案中，优选地，标识信息包括操作用户、操作时间、操作内容和/或操作日期。

在该技术方案中，通过存储各步骤的操作用户、操作时间、操作内容和操作日期等标识信息，可以得到用户的操作流程记录，能体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

在上述技术方案中，优选地，步骤106具体包括：判断历史业务变更记录中是否具有标识信息为空的历史变更任务，当判断结果为是时，即历史业务变更记录中具有未完成的历史变更任务，则将未完成的历史变更任务设置为目标变更任务；以及当判断结果为否时，即历史业务变更记录中不具有未完成的历史变更任务，则根据接收到的业务单据变更请求，建立目标变更任务。

在该技术方案中，以标识信息作为判断历史变更任务是否已完成的标志，当历史变更任务的标识信息为空时，判定该历史变更任务为未完成。如果该历史变更任务已经经过审核，则对其进行取消审核操作，并将其设置为目标变更任务；如果该历史变更任务还未经过审核，可以直接将该历史变更任务设置为目标变更任务，对其进行修改和/删除等操作。而当历史变更任务的标识信息不为空时，判定该历史变更任务的状态为已完成，不允许进行放弃审核、修改和/删除等操作，系统应根据接收到的业务单据变更请求，建立新的目标变更任务。这样，避免了用户对于已完结业务随意进行可逆操作，减少了发生错误的几率，提高了系统运行的安全性，同时，还可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

图2示出了根据本发明的实施例的业务单据变更控制系统的框图。

如图2所示，根据本发明的实施例的业务单据变更控制系统200，包括：第一判断单元202，根据业务单据的变更范围，判断业务单据的变更请求是否在业务单据的变更范围内，当判断结果为是时，接收变更请求；查找单元204，用于根据接收到的变更请求，查找业务单据的历史业务变更记录；第二判断单元206，用于判断历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和变更请求，设置目标变更任务；变更单元208，用于根据目标变更任务变更业务单据。

在该技术方案中，通过判断业务单据的变更请求是否在业务单据的变更范围内来确定该变更请求是不是可以被接收并执行，比如，在财务软件系统中，修改本月的某张采购单据的申请一般可以被接收。通过判断历史业务变更记录中是否具有未审核的历史变更任务，可以确定目标变更任务，这体现了申请和审批的过程，可以实现业务单据变更的事前控制，利于用户对业务变更进行监管。

在上述技术方案中，优选地，还包括：初始设置单元210，根据接收到的设置命令，设置业务单据的变更范围；以及第一判断单元202还包括：当判断结果为否时，拒绝业务单据的变更请求。

在该技术方案中，为业务变更设置一个变更权限范围，当变更请求在该变更权限范围内时才可以接收该变更请求，比如，修改本月的某张采购单据的申请一般可以被接收。而当变更请求超出了预设的变更权限范围的时候，应当拒绝业务单据的变更请求，比如已经结算的自然月的财务数据一般是不可以变更的，当得到修改已经结算的自然月的财务数据的请求时，系统判定该请求超过了权限变更范围，不予接收。这样，避免了用户在自身权限范围外对于已完结业务随意进行可逆操作，减少了发生错误的几率，有利于事后的复查和数据分析，提高了系统运行的安全性。

在上述技术方案中，优选地，还包括：存储单元212，用于存储接收的业务单据的变更请求和/或拒绝的业务单据的变更请求的标识信息；以及存储目标变更任务的标识信息和变更后的目标业务单据的标识信息。

在上述技术方案中，优选地，标识信息包括操作用户、操作时间、操作内容和/或操作日期。

在该技术方案中，通过存储各步骤的操作用户、操作时间、操作内容和操作日期等标识信息，可以得到用户的操作流程记录，能体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

在上述技术方案中，优选地，第二判断单元206具体包括：判断历史业务变更记录中是否具有标识信息为空的历史变更任务，当判断结果为是时，即历史业务变更记录中具有未完成的历史变更任务，则将未完成的历史变更任务设置为目标变更任务；以及当判断结果为否时，即历史业务变更记录中不具有未完成的历史变更任务，则根据接收到的业务单据变更请求，建立目标变更任务。

在该技术方案中，以标识信息作为判断历史变更任务是否已完成的标志，当历史变更任务的标识信息为空时，判定该历史变更任务为未完成。如果该历史变更任务已经经过审核，则对其进行取消审核操作，并将其设置为目标变更任务；如果该历史变更任务还未经过审核，可以直接将该历史变更任务设置为目标变更任务，对其进行修改和/删除等操作。而当历史变更任务的标识信息不为空时，判定该历史变更任务的状态为已完成，不允许进行放弃审核、修改和/删除等操作，系统应根据接收到的业务单据变更请求，建立新的目标变更任务。这样，避免了用户对于已完结业务随意进行可逆操作，减少了发生错误的几率，提高了系统运行的安全性，同时，还可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

图3示出了根据本发明的实施例的业务单据变更控制方法的具体流程图。

如图3所示，根据本发明的实施例的业务单据变更控制方法，具体包括以下步骤：

步骤302，根据接收到的设置命令，设置业务单据的变更范围。为业务变更设置一个变更权限范围，当变更请求在该变更权限范围内时才可以接收该变更请求，而当变更请求超出了预设的变更权限范围的时候，应当拒绝业务单据的变更请求，这样，避免了用户在自身权限范围外对于已完结业务随意进行可逆操作，减少了发生错误的几率，有利于事后的复查和数据分析，提高了系统运行的安全性。

步骤304，根据业务单据的变更范围，判断业务单据的变更请求是否在业务单据的该变更范围内，当判断结果为是时，进入步骤306，当判断结果为否时，进入步骤308。

步骤306，接收变更请求，进入步骤310。比如，修改本月的某张采购单据的申请一般可以被接收。

步骤308，拒绝变更请求，结束进程。比如,已经结算的自然月的财务数据一般是不可以变更的，当得到修改已经结算的自然月的财务数据的请求时，系统判定该请求超过了权限变更范围，不予接收。这样，可以避免用户对于已完结业务随意进行可逆操作，减少了发生错误的几率，提高了系统运行的安全性。

步骤310，根据接收到的变更请求，查找出业务单据的历史业务变更记录。

步骤312，判断历史业务变更记录中是否具有标识信息为空的历史变更任务，当判断结果为是时，历史业务变更记录中具有未完成的历史变更任务，进入步骤314，当判断结果为否时，历史业务变更记录中不具有未完成的历史变更任务，进入步骤320。

步骤314，判断该历史变更任务是否已经经过审核，当判断结果为是时，进入步骤316，当判断结果为否时，进入步骤318。

步骤316，对该历史变更任务进行取消审核操作，进入步骤318。

步骤318，将该历史变更任务设置为目标变更任务，进入步骤322。

步骤320，根据接收到的业务单据变更请求，建立新的目标变更任务，进入步骤322。这样，在判定该历史变更任务的状态为已完成时，不允许进行放弃审核、修改和/删除等操作，系统应根据接收到的业务单据变更请求，建立新的目标变更任务，这样可以避免用户对于已完结业务随意进行可逆操作，减少了发生错误的几率，提高了系统运行的安全性。

步骤322，根据目标变更任务变更业务单据。

在该技术方案中，通过多次判断逐级确定目标变更任务，能体现逐级申请、审批的过程，可以实现业务单据变更的事前控制，便于用户对系统进行监管以及事后的复查和数据分析。

图4示出了根据本发明的另一个实施例的业务单据变更控制系统的框图。

如图4所示，根据本发明的另一个实施例的业务单据变更控制系统400，具体包括：用户界面交互事件处理组件402，用于接收用户向业务单据变更控制系统400发起的变更请求，并由用户通过操作用户界面(UI)交互事件处理组件402的按钮将该变更请求发送给单据变更逻辑状态处理组件404；业务单据变更范围与配置组件406，用于从单据变更逻辑状态处理组件404中读取该变更请求，判断该变更请求是否在预设的业务单据的变更范围内，将判断结果发送至单据变更逻辑状态处理组件404；单据变更逻辑状态处理组件404，用于接收该判断结果，且当判断结果为是时，接收该变更请求，并将该变更请求发送给业务变更单据数据处理组件408，当判断结果为否时，拒绝该变更请求；业务变更单据数据处理组件408，用于处理该变更请求，进行业务变更，生成业务变更单。

其中，业务单据变更范围与配置组件406用于定义要支持变更的业务单据的相关属性，并为相关属性预置数据脚本预置数据脚本，并根据相关属性和预置的数据脚本判断是否接收变更请求，可以避免用户对于已完结业务随意进行可逆操作或超过允许范围的操作，减少了发生错误的几率，能够提升系统的安全性。其中，相关属性的类型如表1所示。

在本实施例的业务单据变更控制系统400中，还包括业务单据变更状态与回写处理组件410和单据API(应用程序编程接口)插件处理组件412，用户界面(UI)交互事件处理组件402在变更完成后，通过单据API(应用程序编程接口)插件处理组件412中的API资源调度器实现自定义插件DLL(动态链接网)的集成，以协助业务单据变更状态与回写处理组件410完成对已接收并完成的变更请求或已拒绝的变更请求的状态回写等逻辑处理，为业务变更单做出流程记录等补充说明。这样，可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

表1

在本实施例的业务单据变更控制系统400中，还包括工作流处理组件414，其主要用于支持工作流的全生命周期的实现，即从变更申请的发起、新建、审核、取消审核、修改直至删除或保存等，起到辅助软件系统完成业务变更的操作的作用。

通过上述技术方案，可以避免用户对于已完结业务随意进行可逆操作或超过允许范围的操作，减少了发生错误的几率，能够提升系统的安全性，还可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

图5示出了根据本发明的再一个实施例的业务单据变更控制方法的流程图。

如图5所示，根据本发明的再一个实施例的业务单据变更控制方法，当用户想要修改采购订单上的信息时，其变更流程具体包括：

步骤502，用户向业务单据变更控制系统发起修改采购订单请求，具体通过用户界面(UI)交互事件处理组件的交互事件的操作按钮将该修改采购订单请求转发给单据变更逻辑状态处理组件。

其中，用户界面(UI)交互事件处理组件用于通过从用户界面的交互事件中截获对应的操作按钮来实现业务单据需要变更时的申请发起动作，操作按钮包括修改、取消审核、变更、存储和审核等，其实现交互事件的方式可分为事前方式和事后方式，我们这里只用到了事前方式。针对不同的业务，用户界面(UI)交互事件处理组件所需实现的UI交互事件的功能也不同，比如，操作按钮中的修改、取消审核、变更、存储和审核对应的功能如表2所示：

表2

步骤504，业务单据变更范围与配置组件从单据变更逻辑状态处理组件中读取该修改采购订单请求，判断该修改采购订单请求是否在预设的业务单据的变更范围内，当判断结果为是时，进入步骤506，当判断结果为否时，进入步骤508。

其中，业务单据变更范围与配置组件用于定义要支持变更的业务单据的相关属性，以及为相关属性预置数据脚本预置数据脚本，并根据相关属性和预置的数据脚本判断是否接收该修改采购订单请求。这样，可以避免用户对于已完结业务随意进行可逆操作或超过允许范围的操作，减少了发生错误的几率，能够提升系统的安全性。其中，数据脚本预置如表3所示：

表3

步骤506，单据变更逻辑状态处理组件接收并处理该修改采购订单请求，得到采购订单变更任务，并将该采购订单变更任务发送给业务变更单据数据处理组件。

步骤508，单据变更逻辑状态处理组件拒绝该修改采购订单请求，进入步骤512。

步骤510，业务变更单据数据处理组件根据该采购订单变更任务对该采购订单进行处理，生成采购订单变更单。

步骤512，用户界面(UI)交互事件处理组件在在变更完成后，通过单据API(应用程序编程接口)插件处理组件中的API资源调度器实现自定义插件DLL(动态链接网)的集成，以协助业务单据变更状态与回写处理组件完成对已接收并完成的采购订单变更任务或已拒绝的修改采购订单申请的状态回写等逻辑处理，对采购订单变更单做出流程记录等补充说明。这样，可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

以上结合附图详细说明了本发明的技术方案，通过本发明的技术方案，可以避免用户对于已完结业务随意进行可逆操作或超过允许范围的操作，减少了发生错误的几率，能够提升系统的安全性，还可以体现逐级申请、审批的过程，便于用户对系统进行监管以及事后的复查和数据分析。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种业务单据变更控制方法，其特征在于，包括：

根据业务单据的变更范围，判断业务单据的变更请求是否在所述业务单据的所述变更范围内，当判断结果为是时，接收所述变更请求；

根据接收到的所述变更请求，查找所述业务单据的历史业务变更记录；

判断所述历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和所述变更请求，设置目标变更任务；

根据所述目标变更任务变更所述业务单据。

2.根据权利要求1所述的业务单据变更控制方法，其特征在于，在判断业务单据的变更请求是否在所述业务单据的所述变更范围内之前，还包括：

根据接收到的设置命令，设置所述业务单据的所述变更范围；以及

判断所述业务单据的所述变更请求是否在所述业务单据的所述变更范围内，当判断结果为否时，拒绝所述业务单据的变更请求。

3.根据权利要求2所述的业务单据变更控制方法，其特征在于，还包括：

存储所述接收的所述业务单据的变更请求和/或所述拒绝的所述业务单据的变更请求的标识信息；以及

存储所述目标变更任务的标识信息和变更后的所述目标业务单据的标识信息。

4.根据权利要求3所述的业务单据变更控制方法，其特征在于，所述标识信息包括操作用户、操作时间、操作内容和/或操作日期。

5.根据权利要求1至4中任一项所述的业务单据变更控制方法，其特征在于，判断所述历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和所述变更请求，设置目标变更任务，具体包括：

判断所述历史业务变更记录中是否具有所述标识信息为空的历史变更任务，当判断结果为是时，即所述历史业务变更记录中具有未完成的历史变更任务，则将所述未完成的所述历史变更任务设置为所述目标变更任务；以及

当判断结果为否时，即所述历史业务变更记录中不具有未完成的历史变更任务，则根据所述接收到的所述业务单据变更请求，建立所述目标变更任务。

6.一种业务单据变更控制系统，其特征在于，包括：

第一判断单元，根据业务单据的变更范围，判断业务单据的变更请求是否在所述业务单据的所述变更范围内，当判断结果为是时，接收所述变更请求；

查找单元，用于根据接收到的所述变更请求，查找所述业务单据的历史业务变更记录；

第二判断单元，用于判断所述历史业务变更记录中是否具有未审核的历史变更任务，根据判断结果和所述变更请求，设置目标变更任务；

变更单元，用于根据所述目标变更任务变更所述业务单据。

7.根据权利要求6所述的业务单据变更控制系统，其特征在于，还包括：

初始设置单元，根据接收到的设置命令，设置所述业务单据的所述变更范围；以及

所述第一判断单元还包括：

当判断结果为否时，拒绝所述业务单据的变更请求。

8.根据权利要求7所述的业务单据变更控制系统，其特征在于，还包括：

存储单元，用于存储所述接收的所述业务单据的变更请求和/或所述拒绝的所述业务单据的变更请求的标识信息；以及存储所述目标变更任务的标识信息和变更后的所述目标业务单据的标识信息。

9.根据权利要求8所述的业务单据变更控制系统，其特征在于，所述标识信息包括操作用户、操作时间、操作内容和/或操作日期。

10.根据权利要求6至9中任一项所述的业务单据变更控制系统，其特征在于，所述判断单元具体包括：

判断所述历史业务变更记录中是否具有所述标识信息为空的历史变更任务，当判断结果为是时，即所述历史业务变更记录中具有未完成的历史变更任务，则将所述未完成的所述历史变更任务设置为所述目标变更任务；以及

当判断结果为否时，即所述历史业务变更记录中不具有未完成的历史变更任务，则根据所述接收到的所述业务单据变更请求，建立所述目标变更任务。