Answers from the Workshop

1. Is VERTEX ODBC compliant?
2. How flexible is coupon value?
3. 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.

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.