Lesson 1, Topic 1
In Progress

1.13. State all rates and other numeric inputs and assumptions to the correct number of decimal places

ryanrori February 1, 2021

[responsivevoice_button rate=”0.9″ voice=”UK English Female” buttontext=”Listen to Post”]

A query is a request for data results, for action on data, or for both. You can use a query to answer a simple question, to perform calculations, to combine data from different tables, or even to add, change, or delete table data. Queries that you use to retrieve data from a table or to make calculations are called select queries. Queries that add, change, or delete data are called action queries.

When the results of these queries are numeric, it is important to keep it accurate. Rounding a number is when you take a number and “bump it up” or “bump it down” to a nearby and “cleaner” number. A number can be rounded to any place value you want. Rounding means reducing the digits in a number while trying to keep its value similar. The result is less accurate, but easier to use. To ensure the data is valid, state all rates and other numeric inputs and assumptions to the correct number of decimal places

Values that should not be rounded as per the document would be monetary values. It is also essential that these values show two decimals to indicate a rand and cent value. This is very important as rounding these values up or down would cause errors in the company’s accounting systems.

For the system to operate accurately, all rates, including charges, taxes, duties and tariffs must be clearly specified. 

Check calculated values for correctness when changes are made to the inputs

To check calculated values for correctness when changes are made to the inputs we use data validation.  Data validation guarantees to your application that every data value is correct and accurate. You can design data validation into your application with several differing approaches: user interface code, application code, or database constraints.

There are several types of data validation. 

  • Data type validation.
  • Range checking.
  • Code checking.
  • Complex validation.

One of the simplest forms of data validation is verifying the data type. Data type validation answers such simple questions as “Is the string alphabetic?” and “Is the number numeric?” Usually you can handle such simple validations with your application’s user interface.

As an extension of simple type validation, range checking ensures that the provided value is within allowable minimums and maximums. For example, a character data type service code may only allow the alphabetic letters A through Z. All other characters would not be valid. As with data type validation, your application’s interface can typically provide the necessary range validation, although as a design alternative you could create a business rule to handle range validations.

Code checking is a bit more complicated, typically requiring a lookup table. For example, maybe your application calculates sales tax for only certain state codes. You would need to create a validation table to hold the authorised, taxable state codes. This validation table could be part of a business rule, or it could be implemented directly in the database for query lookup.

Simple field and lookup validation is sometimes not enough. Consider a health care claim which has a billed amount of R123.57, but the allowable amount may depend on a year-to-date rolling accumulation that is capped at R1500 (not to exceed the lifetime policy maximum of R100 000). In this situation, data validation extends beyond the immediate data entry screen to one of careful evaluation of how to pay this claim based on the policy limits and both year-to-date and lifetime accruals. This kind of complex multi file data validation is often best handled with procedure-based business rules.

It is an unfortunate artefact of older file structures that the data is often corrupted (such as numeric fields that are blank or contain alphabetic characters). As you build your enterprise application, you may want to build a testing utility to verify the correctness of every single field in every record of the files your application uses. If you do not, your new application may provide unpredictable results.

Use the document to carry out data modifications and for the entering of related formulas

An input document can be text documents, spreadsheets, images or any other kind of file. An Input Document can be a hard copy (which has been printed out and stored in a filing cabinet), a digital file which is uploaded to the case, or both.  This document is used to provide information that needs to be included or changed in the Information System.

The input document will contain the information that must be used to modify the data by adding records or information, deleting records as well as corrections to records. Use the document to carry out data modifications and for the entering of related formulas. Information from the input documents could be rate or tariff changes.

The input document is used to provide the related formulas for the calculation of the data. This is essential to ensure all calculations are done consistently and accurately.

Format each document clearly and accurately

Accuracy and clarity are paramount. The reader should be able to follow your logic and your instruction, understand the results and see how these results and their implications fit into the larger context of the Information System. 

To ensure this, using documents with consistent contents and format will help the reader follow the instructions with ease. Format each document clearly and accurately.