这些方案提供了一些示例来说明数据验证如何帮助实现业务策略。
方案 1
Acme,Inc. 公司聘请 John 作为顾问,负责设计表单并实施数据验证规则来强制执行公司的某些策略。公司要求他实施这样一项验证规则:如果“Total Cost(总成本)”的实际金额超出了预算金额,则该规则将实际金额标记为红色。在应用程序中,必须对每个年份和每个期间重复执行此检测。John 设计了该表单,并使用交叉维成员在单元格级别添加了数据验证规则,如下图所示。
设计时的表单布局:
设计时的数据验证规则:
输入数据时的表单(应用了数据验证):
提示:
John 可以将总成本拆分为其自身的段,并针对该段应用数据验证规则以便小幅提高性能。但是,这样做将增加维护难度,因为这向表单中添加了新帐户和方案。
如果要求有所更改(例如只要求将“Actual(实际)”方案的年度合计期间标记为红色),则 John 有两种选择。最佳选择是添加一条 IF 条目来检查期间成员是否为年度合计。另一种选择是将年度合计成员拆分为单独的列来提高性能。但是,这样做可能会破坏扩散逻辑,还会重复“年”列标题,而且表单将更难维护,因为添加了新的年份。
方案 2
在审查了方案 1 中由 John 设计的表单后,Acme 公司决定用列(而不是行)来显示预算。为实现该要求,John 可在轴之间移动成员来更改表单的布局。但是,他无需更新数据验证规则。John 更新了表单,如下图所示。
设计时的表单布局:
输入数据时的表单(应用了数据验证):
方案 3
成功部署这些表单后,公司要求 John 执行下一项政策,即确保本年度的预算金额不要明显超出上一年度的实际金额。如果此二者之间的差值大于 5%,则将差值标记为红色。
John 决定使用包含成员公式的成员来计算本年度的预算与上年度的实际金额之间的差异。他添加了以下成员公式:
@varper(@Prior("Actual", 1, @Relative("Year", 0)), budget)/100;
如下图所示,John 设计了表单,并在单元格级别添加了一条数据验证规则。他使用成员名称来确保仅对“Total Cost(总成本)”进行验证。
设计时的表单布局:
设计时的数据验证规则:
输入数据时的表单(应用了数据验证):
提示:
如果公司不允许 John 更改大纲,或者他遇到了与成员公式相关的性能问题,则可以使用公式列。请参阅“设计具有公式行和公式列的表单”。
出于以下原因,John 在 "Variance Percent" 列上定义了规则。
这样能改进性能。只对 "Variance Percent" 列中的单元格评估规则。如果将规则分配给年度合计,则必须为当前年度预算的所有期间评估该规则。
这样能帮助用户解决数据验证消息。John 可在 "Variance Percent" 列(而不是年度合计)中添加消息来说明差值比较高。这样,用户无需搜索 "Variance Percent" 即可确定差值。
如果公司有相关要求,John 可将年度合计和 "Variance Percent" 都标记为红色。
方案 4
除了要将单元格标记为红色外,还要求该规则在本年度的预算过高于(大于 5%)上年度的实际金额时阻止任何人提升审批单元。要实现该要求,John 只需编辑数据验证规则的处理说明,然后选择 Do Not Promote(不提升),如下图所示。
设计时的数据验证规则:
方案 5
最后,公司要求 John 设计一个数据验证规则来验证特定部门对员工的总报酬是否在允许范围之内。该规则对运营部门内的现有员工进行评估。该规则验证的是:如果总报酬高于最小允许值,且低于或等于员工等级的报酬范围的四分之三,则无需执行任何操作。
如果“报酬总计”高于报酬范围的四分之三,则会提供一条验证消息,同时,审批单元必须由人力资源经理批准。如果值低于最小值或大于最大值,则会生成错误,而且用户无法提升其审批单元。
John 在“表单管理”对话框中打开了“员工费用摘要”表单。该表单在页中显示员工和部门,在行中显示帐户(例如“总报酬”),在列中显示期间。为了方便构建验证规则,John 添加了一个计算行来计算报酬范围的四分之三,然后将“最小报酬”成员和“最大报酬”成员添加到表单,如下图所示。员工等级的最小报酬和最大报酬是使用成员公式计算的。
设计时的表单布局:
用于阻止审批单元提升的数据验证规则:
用于将人力资源经理添加为审核者的数据验证规则:
输入数据时的表单(应用了数据验证且显示有验证消息):