This document covers several advanced topics concerning the Signet Analysis Codes and Rules.

Changing a Master File's Analysis Codes

When you change the analysis codes in a master file, Signet allows you to (optionally) update all historical transactions against that particular master file entry.

This functionality is useful in several cases:

  • You may be adding new analysis codes which were not previously required. By instructing Signet to update all historical transactions, these transactions can then be analysed according to your new criteria.
  • If an analysis code was originally entered incorrectly, the corrections can also be applied to historical transactions.
  • Where the master file's specifications have changed, you would instruct Signet NOT to update the historical transactions. In such a case, the history is left intact, and all future transactions are analysed correctly.

The following three sections provide more details.

Posthumously adding Analysis

Signet allows you to add analysis codes after initial implementation.

Typically, you would use this where an analysis need is identified only after the implementation.

For example if the vehicle colour was not initially captured, you can add the necessary Analysis Codes and Rules; update all Vehicles by selecting their colours; and allow Signet to update the historical transactions.

Once this has been done, you can produce a report showing which deliveries were done by Red vehicles.

Correcting incorrectly captured Analysis Codes

If an analysis code was captured incorrectly against a particular master file entry, Signet allows you to update the transactions already posted.

Changes to a Master File

Examples:

  • You change the colour of a vehicle
  • You take on a new Rep, and split 10 products which were previously handle by Rep01 into two groups of 5 each, to be handled by Rep01 and Rep14 respectively

In cases such as the above, you would want to change the master file entries (vehicles or products), but leave the history intact.

Signet allows you to do this by simply instructing it NOT to update any historical transactions.

Transactions already in the system would remain unchanged, but all future transactions would reflect the new (changed) analysis codes.

Different Rules for the Same Analysis Codes

Because the actual Analysis Codes and the Rules governing them are separate, you can implement the rules in several ways.

Typically, your rules would bind the codes together, and specify the parameters for the binding. However, it is also possible to have several rules using the same codes.

For example, you could create a set of analysis codes for your Reps. Some products may always be handled by a particular Rep, others may be handled by multiple Reps.

In a case such as this, you could:

  • Set up the Reps as Analysis Codes.
  • Create a rule binding the Reps, making it applicable to Products, and specifying it as optional (by leaving the "Must Select One" parameter switched off).
  • Create a second rule binding the same Rep Analysis Codes, making it applicable to Inventory Transactions, and specifying that it is NOT optional!

The nett result would be that Products can be added with an optional Rep (which would automatically be copied to the Transaction Entry screens), and Transactions must have a Rep selected.

Products which do not have a Rep selected would begin with no Rep selected when a transaction is added, the operator would need to manually select one of the Reps before storing the transaction record.

Return to the Analysis Screen.