Printing of SAP forms and labels at interfaces to a conveyor system
In many cases, SAP users develop their forms and labels exclusively in SAP. Forms for laser printers, e.g. Delivery notes and invoices, are developed with Adobe Forms, while the label printing on themotransfer printer is implemented via a label management integrated into SAP.
Although the print processing is exclusively done in SAP, printing is often triggered by its own control software or the PLC in warehouse management or production. As a rule, a scanner is installed in front of the printer that identifies the item and reports this event to SAP via an interface. The requested print jobs can be: delivery note, invoice, packing list, product or shipping labels. Forms of laser printers fall out of the printer into the opened package, while labels are applied to the package via special applicators and printing units.
There are generally two alternatives to how the print job from SAP is sent to the printer.
Alternative 1) Print from spool
After the package has passed the scanner and the request for printing from the subsystem has been sent to SAP, the print job is generated in SAP and placed in the spool. When the package arrives at the printer, the first (the oldest) print job is printed from the spool on the printer.
Since usually only a single print job is in the spool, the printing via spool also works in most cases. However, there are situations where there is not only one print job in the spool, but several print jobs. Interferences in the process between the scanner and the printer can accumulate several print jobs in the spool, and the wrong print job is retrieved on the printer. Faults can be:
- A short dump in SAP through a program error
- A network error
- Interrupt the interface
- A print job from the SAP test system is sent to the printer
The result is that the wrong print job is called on the printer. In consequence, false delivery notes or invoices fall into the package or the package is incorrectly labeled. If such an offset occurs too late, thousands of packs may have been mislabeled in the meantime. If the packages are fed into a high-rack warehouse, large parts of the warehouse management are inconsistent. This can lead to several days of delivery stoppage and considerable financial losses.
Such a dangerous offset occurs again and again during printing from the spool and can not be ruled out as a result of the system.
For this reason I am basically against printing from the spool with SAP interfaces to subsystems (warehouse management, packaging machines, etc.).
Alternative 2) Print from the hard disk or another permanent storage medium
In this alternative, the request for printing to SAP is also transmitted by the subsystem after the package has passed the first scanner. However, printing from SAP is not placed in the spool, but the print job is stored on a hard disk. In this case, both the printer and a connected computer form a unit. Both SAP and the printer have access to the directory on the hard disk. The hard disk is often located directly on the computer-printer unit. For clear identification of the print job, the file name is usually the number of the package.
If the package passes the printer, the package is scanned again by a second scanner. This scanner now retrieves the print job from the hard disk to the package number. The print job is frequently sent directly to the printer for output with COPY LPT1.
Although the technical realization of the printing via hard disk is more complex than alternative 1 – after all, instead of a simple printer, a printer-computer unit and a second scanner are needed – however, an offset in the printing is excluded here. Alternative 2 thus offers the desired process reliability in the printing, delivery failures and incorrect deliveries are practically excluded.
Therefore, I recommend only the second alternative.
Many possibilities of printer-computer units, printers and applicators can be found at www.bluhmsysteme.com.
Further information
