Integration & Administration

Integration and administration

Make best use of your data with ERP integration


Business System Integration
The AutoCoding Enterprise Server interfaces seamlessly with Enterprise Resource and Warehouse Management systems and with the consequential business benefits from an integrated data structure the customer will benefit from security and integration of business information systems.

The integration into ERP and planning systems allows for product and order data to be transferred dynamically into the AutoCoding system. In this way double entering of data and the resulting integrity issues are completely
avoided. In this way the AutoCoding Enterprise solution is designed to sit comfortably below any standard ERP system and facilitating a secure two-way link to the production facility.

The AutoCoding Enterprise Server software is integrated into SAP, System21, Great Plains, Irenaissance, AS400, etc.

Integration case study
As one of the UK's largest juice manufacturers, Gerber Foods Soft Drinks (now known as Gerber Juice Company Limited) is a perfect example of a highly integrated factory. The implementation of Autocoding within the new ambient juice facility at Express Park encompasses many extended modules of the AutoCoding system, making it one of the most advanced implementations from an integration perspective.

The overall architecture of the system is as follows: - A central server houses the SQL database. This server also runs the external integration routines, as well as the Data Exchange Server (DES). Connected to this server are the line terminals (each servicing a single filling line) and the palletlabelling terminals.

The overall data flow is as follows:
1. Products and Orders are created on the ERP system.
2. ERP data is transferred via external integration from the ERP system to the central AutoCoding SQLServer.
3. Each terminal is updated with all the latest data from the AutoCoding server.
4. As a job is initiated at a line terminal, each line device is setup with the corresponding coding data, and the AutoCoding SQLServer updated with the job status.
5. When the palletiser system is setup with the coding data (including the SKU and job number), these parameters are then transferred via the conveyor control PLC to each pallet stop position along the remaining conveyor.
6. As a pallet reaches a pallet-labelling position, the data previously passed to the conveyor control PLC is passed back to the AutoCoding pallet-labelling terminal. This data is then used to access the job and product data from the AutoCoding SQLServer.
7. Once the AutoCoding pallet labelling controller have the correct product/job data, the AutoCoding Server post a request to the WMS system for an SSCC.
8. Once an SSCC is received and the pallet correctly labelled, we confirm this back to the WMS system via the AutoCoding Server and also to the conveyor system via the AutoCoding Pallet Labelling Controller.
9. The pallet is put away automatically by the WMS.

Each filling lines coding, verifying and line control equipment is controlled by a dedicated terminal, holding a complete copy of the server data, and therefore fully interchangeable with other lines to increase redundancy and fault tolerance.

The equipment being controlled by the line terminal is as follows:
1. Imaje S8 inkjet carton coder (BBE date, line ID, Julian date and real-time clock)
2. Carton top air-knife (only enabled during a job to reduce site air consumption)
3. PACKLAB labelling unit
4. Sick multi-pack barcode scanner (fixed scanner to read pre-printed labels as they are
applied)
5. Imaje IJ2000 print & apply tray labeller (applying product specific labels)
6. Sick tray barcode scanner (fixed scanner to read tray label barcodes as they are applied)
7. Elettric80 Palletiser Robot (setup stacking pattern, pallet type, binder program)
8. Octopus stretch wrapper (foil tension/program)

Communication between all coding/verifying devices is via RS-232, with the palletiser being controlled via Ethernet.

The filling lines at Express Park are serviced by two pallet-labelling islands, each with a single Imaje MP6000 pallet labeller, controlled by an AutoCoding Pallet Labelling Controller. These terminals manage the data transfer between the conveyor PLC, the WMS, The AutoCoding SQLServer and the labeller itself. The terminal application provides Gerber with visual confirmation of the labeller's status and current labelling data, as well as touch-screen access to common functions.

Gerber has granted AutoCoding Systems remote access via VPN, which allows interrogation of the server as well as all of the terminals, checking files, settings, or taking full control and seeing exactly what an operator can see at the terminal screen. Thanks to the technology used for the handscanners, the support engineer can even scan barcodes remotely, allowing the engineer to fully emulate being at the terminal in person. This is invaluable when it comes to diagnosing a perceived operator issue.


Business data and process management
thumbnail image
Product Management
The data for the product will be contained centrally within the AutoCoding system database. The system will initially be entered and maintained via the product interface of the database administrator application. Alternatively an ERP system may contain the data and in this case the relevant data will be entered and maintained via the ERP system with a live link forcing any changes made inside the ERP system through to the AutoCoding central database. The data contained within this element of the AutoCoding system would be: Product code, product name, shelf life offsets, customer data, and expiry type [days/weeks/months/years], ranges, and additional coding format data.

thumbnail image
Order Data/Management
Order data can be entered directly into the AutoCoding system production order interface along with customer, product, planned production date and product quantity information. Alternatively an external source like a planning, ERP or other system can provide the production order data. Through the AutoCoding system the orders can be adjusted with respect to planned production date, quantity etc. This module allows a user to Create/Amend/Delete Works orders from the back-office, as well as printing a works order schedule by date and/or production line number. These orders will define a product / production number / date / quantity association in a works order record. Instead of scanning a product barcode, the line operator will scan a works order barcode printed on a works order schedule thus providing external validation of the job-start process.

thumbnail image
QA and Audit Trail Data
The QA data will contrary to basic data like customer, order and product data be entered into the system from QA staff carrying out mandatory checks on product and packaging exclusively. This functionality will normally make a number of manual check-sheets redundant when the data and the forms are moved inside the AutoCoding system. The benefit is that electronic systems provide for easier retrieval, filtering and reporting of QA and audit information. Whereas QA information is entered by a QA auditor manually at a QA terminal, some audit information will be collected by the AutoCoding system automatically. This is data like job-start/end, equipment faults, wrong barcode scanned, check-weigher/metal-detector accept/reject of set-up command, produced quantity etc.

thumbnail image
Advanced Line Equipment Feedback Module
An example would be to trap the paper low error of a print and apply applicator and prompt the user to change the roll using beacons and on-screen prompt. Allows the system to send SMS message alerts and email to mobile phones or PC's based on specified criteria. The module allows multiple mobile numbers to be added to the system, along with times during which messages may be sent to each number, and the type of event which should trigger a message. An example is where the status of each inkjet printer is monitored, when the printer develops a warning then appropriate action can be taken before the printer stops due to a fault appearing The type of fault (fault code) can in most cases be obtained from the faulty device and through the alert module this information can be made available as an email to the supplier helpdesk. This functionality makes fault diagnostics easier and will significantly increase uptime and efficiency.

Concession Management (process Concession)
A concession procedure is used to identify and manage where material or process management MAY have affected the material quality of the product or where the absence of process control mechanisms have weakened the audit trail.

Typical concessions:
1. A barcode scanner on a production line is unavailable
2. Check-weigher/Metal-detector unavailable
3. Raw/WIP material quality is inferior, within set limits for a slight reduction in life
4. Chilling equipment has failed and warehouse temperature is higher than allowed.
It is an operational management decision for the business to define the exact list of events, which may initiate the concession request procedure.
There are three types of concessions, order specific concessions, which expire when the order is completed, product specific concessions, which are applied, to the product until expiry and line specific concessions (line device failure), which are applied until capability has been restored.

Exception and Avoidance Date Management
This module is intended to manage scenarios where a customer will not allow certain shelf life offsets to result when applied to certain specific dates. The example is where a 10-day shelf-life product is produced on DEC15, and consequently lands on DEC25, which in the case of Tesco is an avoidance date.
The DEC15 date is known as an exception date, where an exception to the standard date rules will be applied. There can be as many exception rules as required. Please click on the screenshot icon for a closer look at the screen.

Business reporting
The audit viewer collects information from both the production line terminal and the QA and database administrator applications. The data collected is dependent on the additional modules installed, but may include:
  • Equipment fault
  • Bad barcode read
  • Non-readable inkjet code
  • Production start/stop
  • Product launch (active)
  • And other data management inside the administrator package

The viewer provides a quick way of identifying by filtering by date, line, code, event type etc. In this case all instances of wrong barcode being read are displayed within a date range (>1/1-2005). Further filtering could be by line, by customer or SKU (R-code). The reporting interface can provide a wide range of reporting options from simple status through KPI/efficiency and order/pack-lists reports. Reports can be tailored to specific requirements.