Answers from the Workshop
- Is VERTEX ODBC compliant?
- How flexible is coupon value?
- Will Stock/BOMs work with my Accounts System?
- Help - I've lost my Bundle Data!
- I can't print from my NT or XP Workstation
- HASP Driver on Windows 2000 Workstations
- Barcode Printing using Dot-Matrix Printers
Is VERTEX ODBC compliant?
We've had this question about ODBC compliance several times before. Just thinking aloud........
ODBC stands for Open Data Base Connectivity. What does this mean? It isn't DDE - Dynamic Data Exchange or OLE - Object Linking and Embedding.
These two allow things like Excel spreadsheets to be incorporated into Word letters and so forth - convenient, but not what we would call data
manipulation in the full sense of the word. No, ODBC means that the data is structured in such a way that any user with another ODBC system can use it.
For example, if VERTEX data was ODBC compliant then someone with a FoxPro relational database could call in a VERTEX Plus file and display it as a FoxPro
table - similarly Access tables and so on. This would allow the data to be used or amended, outside Vertex itself.
All this is fine, and if all that was wanted was to re-format special reports and so on, everyone would be very happy. But VERTEX is not just a wordprocessor
or spreadsheet or relational database where it is easy to spot and manually change wrong or incomplete data. If we allowed that level of access to Vertex data we
could not guarantee its integrity. For example, once an operation on a bundle has been paid, the system will never pay for it again. Similarly, a style with active
orders in production cannot be erased, neither can its operations be deleted. The slightest change to data introduces flags which will not let you update and leave
the period until the appropriate re-calculation has been done, reports revised and data integrity validated. With unrestricted ODBC, these safeguards could be
over-ridden with impunity and in the wrong hands could be disastrous. (Bear in mind VERTEX is used in 26 countries and hundreds of factories, the vast majority
of which have no IT department!)
On the other hand, some of the advantages of ODBC have been built in to VERTEX. Any database such as FoxPro can import the CSV formatted data created by Vertex
from its report generators, which themselves permit selective report creation and as such meet a significant need. For example, each country using VERTEX has differing
requirements for Gross-to-Nett payroll. Hence there can be no standard facility within Vertex for a Gross-to-Nett function. However, in UK the Pegasus Opera suite includes
a Gross-to-Nett program which, being written in FoxPro, can import a CSV file from Vertex containing just Clock No. / Name / Total Gross Pay - problem solved. Exactly the
same potential is available in USA where I believe Oak Tree can do it.
In this way we get over the problem of ensuring data integrity while permitting further manipulation outside the system, which is fine for those who wish to do so.
The example I always quote is the UK headquarters of a company which has four factories making lingerie in Morocco. Each one exports a daily production report in CSV
format from the VERTEX report generator and sends it down the internet to HQ in UK where a Paradox database consolidates the information into a report of overall Morocco
production. This is data connectivity at its best.
Nevertheless, what about getting data into VERTEX without typing it in? At present the only import feature is the direct link with GSD for operations, standard minutes
and so on. What if I wanted to add production orders from my Customer Order Processing System? Again, data integrity has to be paramount and the user has to be very much aware
of the way VERTEX Plus safeguards it. Having said that, however, while we have effectively prevented general access by denying full ODBC features, there is no reason at all why
specific connectivity cannot be achieved. WISCO Manufacturing in Australia is doing exactly that. We have made available all the appropriate data input file structures and the
interface which allows order data to be transferred is being constructed as a relatively simple function. (See Australia)
One feature highlighted by the WISCO initiative has been the capability of ODBC drivers to control multi-user access. For example, larger users can connect up to six CCD barcode
scanners and use them simultaneously to update the file of barcodes read. This requires that an individual's record within the file is locked while being accessed with one scanner.
Another scanner trying to read a second sheet for that individual would get a "wait" message. The file as a whole must be accessible to all. ODBC drivers tend to use full file
locking in multi-user environments, which would restrict the barcoding function and probably rule out VERTEX Plus being used by anyone with more than about 50 employees.
So, we do not use universal ODBC device drivers and hence, perhaps rather selfishly, can say we guarantee data integrity. Nevertheless we recognise the need to go some way
towards providing the more useful features of the ODBC concept.
How flexible is coupon value?
By far the best way to calculate pay and bundle values is to use standard minutes and operator pay bands with "yield rates" expressed in dollars / pounds / pesetas etc.,
per 60 S/Mins collected. Because the system caters for new timings and updated standard minutes to be immediately effective it is better management and more accurately
reflects the work done, performances and efficiency.
The alternative is to use money values for each operation, which is fine, but mixing the two can cause misunderstandings because the system will always give priority to
standard minutes if it finds any. The logic of this is that there must only be one way of calculating a coupon's value and performance figures are based on SMs. If both SMs and
money values are used for a particular operation then "calculated money" will be zero, whereas "calculated SMs" will be shown. We get questions about the pay being zero and so
forth because of this override.
There is another simple point which can be misconstrued. The accuracy with which S/Mins and money values are expressed is set within the system. Choose Settings - then Ticket
Parameters and towards the bottom right of the screen you will see the accuracy settings. If the money values are not expressed to enough decimal places the system will simply
round the values entered and calculated when printing them on the ticket. When anybody tells you that the system is calculating something "wrong" just mention that computers
and especially VERTEX computers simply cannot do that! Tell them to look elsewhere for the solution, like how they have set it up, or the way they are using it!
It is worthwhile for users to take time to reflect when seemingly senseless tasks arise. An understanding of how coupon value works is fundamental.
It is of course dependent on the latest value in the style definition and not necessarily what has been printed on the ticket. A simple concept, but important.
We had one case in Scotland where each time a value changed on the database someone went out to the factory floor and laboriously changed all the appropriate coupons,
for each different bundle quantity, to show the new calculated value. This was in the mistaken idea that by some magic the change had to be made this way to work.
Will Stock/BOMs work with my Accounts System?
There are several features built in to the new Stock/Bills of Material module which will help to align it with standard accounting systems. In particular, the accounting period
for stock movements can be set to match the period your accounting system uses, be it monthly, weekly etc. In addition, while prices, purchase orders etc, can use a mixture of
currencies, the stock valuation routines can convert and report in your own currency.
Most standard accounting systems use "Start Stock" and "Finished Stock" figures to complete monthly Trading or Profit & Loss accounts. The ability to report on these figures through
a stock system tailored to your industry is a significant advantage when compared to the accounting system "going it alone" on a more general basis.
The full extent of integration with any accounting system will depend on how easily that system can import data, either in plain text or database (CSV) format. Certainly any systems written
using relational databases such as FoxPro can import VERTEX data. If so, then the user has available another powerful and labour-saving tool.
Help - I've lost my Bundle Data!
Loss of data is rare, but in some circumstances can happen to even the best regulated system. For example, if your PC or file server has no UPS
(uninterruptable power supply) and the mains supply fails for some reason then you will probably lose any data you were inputting at the time. In addition you might well
find that the parts of the system being used when the power went off are now "locked". Both circumstances are only minor irritations, because you can quickly clear locks
and retype new data.
It is another matter, however, if data was actually being written to the hard disk at the time the power failed. Either the data or its index might well be corrupted or
no longer match as they should and you will quickly notice that the latest information is no longer available. This is the time you give thanks for having taken regular
An even worse circumstance can arise in which corruption of a particular index is such that none of its associated data can be found. It is still there, but no longer accessible.
You may be able to find all your Products, Orders, Employees and such, but no Bundle information at all! Again, this is the time to restore your latest back-up.
Ah, I hear you say, the person who should have taken regular data back-ups was "off sick" and I don't have a set I can use. (There is usually a hint of panic in the voice at this stage!)
Fear not, here in the VERTEX Workshop we've anticipated even this circumstance and can download a rebuild utility for you, which will scan your data and restructure the indexes to match.
Just contact us and we will help out straight away.
Bear in mind that it isn't just power failures which can cause data corruptions. Switching a machine off before everyone has finished can do it. So can running a disk-intensive routine such as Defrag.
We can help, but by far the best defence is to ensure your routines for data back-up are in place and used. The aim must be to keep the factory going!
I can't print from my NT or XP Workstation!
For users familiar with Windows '95 or '98 the apparent inability of NT and XP to capture or reassign
printer ports can be bewildering! The "capture printer port" function on the "details" window of a
printer's "properties" just doesn't seem to be there any more. The advantage of VERTEX being
able to print to selected ports and therefore to network as well as to local printers by choice appears
All is not lost, however, because the same functionality is available, albeit better hidden! With NT
and XP a command line can be created to assign a port to a network printer path and ensure it is
reconnected at logon. A typical sequence to do this follows, courtesy of Fiona Bond and Simon
Gillespie of Coats-Viyella and validated by Tony Bird of Shadowline.......
From the start bar, go to Run and type cmd - this will bring up the command line.......
Note that the command line syntax must be followed exactly - each "space" is needed.
Then type: net use lpt2 \\Servername\Printername /persistent:yes
Similarly, lpt3 can be assigned and local report printing activated "on the fly" by choosing an
emulation and port at the time. Note that the lpt1 port could also be re-assigned in
this way, but as Tony established, to do so the user must have ADMINISTRATOR privileges.
This works and restores the desired printing flexibility.
HASP Driver on Windows 2000 Workstations
The latest version of the HASP driver is fully compatible with Windows 2000. So if you are thinking of upgrading your hardware or have had problems getting Vertex ticket printing
routines to recognise the "dongle" with Windows 2000 workstations, you should contact us for the latest download. It is quite easy to install on your
Barcode Printing using Dot-Matrix Printers
We are now supplying Unitech MS265 CCD barcode scanners, which are extremely fast at reading laser barcodes, but less efficient with the older pattern barcodes printed on
SC170 or SC330 Leetec pattern worktickets using dot-matrix printers. If you are experiencing read problems with dot-matrix barcodes, you will find it an advantage to upgrade your
Vertex Plus module to the latest issue of Version 2.80. A slight change in the print pattern makes it easier for the new scanners to recognise the barcode structure. Only dot-matrix
barcodes experience this problem; tickets printed on continuous-feed bubble-jet printers do not suffer from it. Please contact us if you need an interim upgrade. The next full issue - Version 2.90 - will incorporate all advances to date.