It does appear that Minty & Pat are saying the same things in #21 & #22.
As I said in earlier posts, I am referring to Ticking systems. Therefore by definition the order number, date and order numbers will indeed appear on every line because it is necessary.
If a vehicle arrives at a quarry to collect product, it will tare on at the weighbridge, then load, then tare out. The two readings from the weighbridge are read by the program through the RS232 serial port to calculate the product tonnages collected.
The ticket will contain: Ticket Nº, Ticketdate, VehicleRegNo, PO, CustomerCode, ProductCode, ProductWeight, Rate, InvoiceNº and InvoiceDate(when added) as a very basic and simple example.
This happens all day with hundreds of wagons passing through. The same customer may return but with a different O/N. But every transaction has similar but not identical content. You simply would not have an invoice header for every transaction because every element you have both mentioned can be different from one ticket to another. Granted the O/N may be repeated here and there. At month end any single customer can have hundreds of tickets that need to be invoiced. As I have said these can be merged by OrderNº, Requistion, JobNº, or Site, or simply by client code depending upon settings in the customer table. Some of these are processing thousands of tickets a month. Although a concrete, or tarmac supplier would generally handle less tickets than a quarry.
Waste Management and Hire companies are much the same in principle. Although they will tend to have linked to the customer table, a SitesTable, and a SkipsOnSiteTable. Tickets are added from SkipsOnSite which will contain rates and other detail to reduce operator entry time. As in the Quarry, a ticket is added for each order. A skip is ordered and a ticket is added to be charged later. Following that another order may be added to empty and return the skip. That ticket will include the waste weight and rate. At month end if the skip is on-site then a rental charge may be added at a day rate. So that customer has three charges at month end. All of different dates and possibly different order numbers. Again, there will be no point in an invoice header for every ticket. Furthermore the customer may well order more skips of the same, or of different size at the same site. As well as skips at other sites of course. Some customers will have various skips at different locations on a large sites. All may be unrelated by OrderNº, waste type and skip size. At month end, all of a client’s tickets are formed into invoices in accordance with the settings in the customer and other system files. They will get an invoice, or invoices depending on settings with charges that match the tickets they were given for each skip operation. The operator will import the invoices into their accounts according to the nominal codes and cost centres preset in tables.
Ticketing systems are clearly not the same as invoicing stock items, components, or nuts and bolts with an order number having a multitude of different items all usually delivered on the same day and with the same order number and delivery note. Data entry is minimal on all systems.
If you still think that every single ticket should have an invoice header in a ticketing system, well I’ll not agree on that one.
