Recalculate Stock
Background
Stock Recalculation
At a previous ISTUG Meeting,
DSIG breakout session, someone raised the topic of Stock Recalculation. I think
the question was something like "Why don't Sage fix the problems causing
Stock Recalculation errors, rather than supplying the program to correct
them?".
A show of hands confirmed that
virtually everyone in the meeting suffered from the problem. The Sage
representative at the meeting expressed astonishment at this and claimed to be
unaware of the problem. However he promised to investigate and get back to us.
To the best of my knowledge this never happened. I know from talking to other
people at ISTUG that this problem still affects a lot of users.
Could Sage give us a status
report on this?
Perhaps answering the original
question?
Informing us if there is any
likelihood of the problem being fixed?
·
The
data errors may arise for a number of reasons :-
·
System
crashes - particularly in C-ISAM environments where RBRF is not possible
·
User
aborts - incorrect exit or reboots
· User interfaces, data imports, 3rd party software, bespoke programs etc. which do not correctly update the required tables and fields in the Sage database
·
Programming
errors and errors in defining commit statements
·
These
are all fairly self explanatory, if a FIFO system a stock movement will update
stock records, order records and batch records plus some cross reference files,
if some but not all of these are done an imbalance is the end result.
·
Invariably,
the problems occur in 'live environments' which make detailed fault finding
difficult due to:-
·
the
need to continue working
·
impossibility
of running tests and trials in a live environment
·
time
and effort involved in trying to mimic all live actions in a safe demo
environment
·
In
addition diagnostic work that has been done in the product in the past also has
to be 100% correct and would not cover any third party applications (including
the ADS modules as these were independent at the time the diagnostics were
added). On sites investigated in detail this has not been entirely successful,
one of the issues of replicating these problems has also been replicating the
volume and multi-user activity both of which may play a part in these problems.
·
The
R&D approach to this is to want to find the issues and fix the problems,
the Stock Recalculation program was designed to check the consistency of the
fields held on the stock master file (stockm) with
the sum of the corresponding order lines, batches, allocations etc. The program
was not developed as a response to problems of imbalances being reported, it
was in fact developed as part of the original Chameleon In Manufacturing
release. At the time was an essential part of recovery from a program crash as
the product was ISAM only and therefore failed multi-record updates caused by a
crash was a specific issue and this program was developed in response to this
issue. In addition it was viewed that a way to validate your stock figures was
a useful part of the module.
·
Where
an error is found, the program can reset the stock master fields after a Sage
supplied password has been entered. Password protection was ironically
introduced in an effort to gauge the scale of problem in the field after anecdotal
evidence of problems in the field. As a result of the requirement to raise a
log to get a password a number of issues were then logged and many were traced
and fixed. In addition some on-site investigation was carried out on at least
two sites in 91/92. Over the years passwords were just made freely available
and in advance and therefore the visibility of issues to R&D has been lost.
·
Until
this update R&D are sheltered from the issues that seem to exist in the
field. A search of the SLX database has turned up only a single call relating
to this issue in the last 2½ months. In the last two years about 8 issues have
been fixed that would fall into this category. It is accepted that
investigating these issues is quite difficult because they often occur in high
volume/multi-user environments. However the size of the product and the nature
of these issues is such that they are
unlikely to just be spotted in the code and they are difficult to replicate in
a test/demo environment.
·
Narrowing
down of the problem is really required for the issues are investigated at Sage,
the following steps would assist
1)
Record
keeping – maintaining a list of the products that are out of balance and by how
much. Investigation of the transactions carried out on the products can begin
to narrow down the search in the source code. Are the items sold, manufactured,
purchased or a combination of all three.
2)
Use
of the generic auditing module to record the transactions taking place e.g. all
changes to the allocated_qty, this in conjunction
with 1) can allow a pattern of events to be seen.
3)
The
provision of a debug binary from Sage. Sage has installed Debug binaries on
some sites, this has not always been successful when investigating the whole
product, it has however been successful in some cases where the search area has
been narrowed for a limited part of the product and a limited number of stock
items.