Answers from the Workshop
- Is VERTEX ODBC compliant?
- How flexible is coupon value?
- Will Stock/BOMs work with my Accounts System?
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 33 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.