Our Interfaces

Certified Interface to the QM-Module (Quality smanagement) for SAP® R/3

Target group:
For all analytical laboratories that work with the QM module for SAP for the purpose of quality control and who do not intend to record results directly into SAP.

Overview:
When implementing a SAP system there is often the task of reproducing the existing structure in this system. Particularly in the laboratory field it is often not desired to implement the SAP gui interface to record test results due to the SAP specific type of results recording.

This is where the capabilities of AJ blomesystem^® QDI (QDI = QM-Data-Interface) apply. It is primarily an interface between blomesystem^® applications and SAP systems by making available the tables and functions with which all the functionallities of the QM IDI interfacecan be covered.

Through the integration of AJ blomesystem^® QDI, the following can take place through different function calls:

• downloading of inspection lots from the SAP system,
• recording the results (parameter, sample of individual results) for the inspection lots,
• recording the data (parameter, sample or individual results) of the inspection lots,
• preparation of the data in a format understandable to SAP,
• transfering in direct, active communication with the attached SAP system,
• evaluation of results
  
• making usage decisions.

AJ blomesystem^® QDI consists of a COM library which can be used by any COM capable development environment completely independently of blomesystem^®. In this way it is therefore possible to automate the communication between the SAP module and any desired system.

Through their methods, the COM objects offer all funcionalities required in the laboratory operations which are required for the recording of test results for the SAP QM module. Through different functions it is possible to request inspection lots matching specific query conditions from SAP, to record the results corresponding with the transferred test planand to send these back to SAP, to evaluate and complete parameters and to make usage decisions.

In this manner, it is possible to expand the testing scope / sampling scope, to create inspection points in SAP and to change already recorded results through correction transfers as required before the making of usage decisions. Transfers to and from SAP take place completely through RFCs through the COM library.

Details:
Requierements for the implementation of AJ blomesystem^® QDI is that inspection lots are present on the SAP side. These can be created either manually or automatically (e.g. receival of goods or change of batch during production). If these requirements are fulfilled, the following functionallities become available:

• All transfers are made through direct computer to computer communications with certified Remote Function Calls (RFCs). these transfers run in the context of a CPI-C user. If the connection to SAP is lost (e.g. in the case of routered ISDN connenctions), the connection is newly made for each transfer.
  
• Local data storage, whereby inspection lots and data remain available for further evaluations even after the transferto the SAP system.
  
• Download of the available inspection lots through freely definable query conditions and a pre-selection (worklist)
  
• Download of catalogue data, whereby it is possible to query by code groups or selections amounts.
  
• Download of already available inspection points.
  
• After the downloading of the procedure head data, all required sample records are automatically generated. Depending on the identification of the head data, an expansion of the testing scope within AJ blomesystem^® QDI is possible at any time.
  
• During the processing of process data, new inspection points can be created at any time for an inspection lot with inspection points.
  
• Transfer results to SAP
  
• Canceling of already transferred results.
  
• Every sample / parameter record can contain an evaluation.
  
• Sample / parameter records can be completed.
  
• Already completed values can be overwritten (correction transfer, new completion required).
  
• A usage decision can be made for every inspection lot. This can also take place for inspection lots that still contain open parameters (canceling of testing).
  
• Acquisition of defective units (error texts) and transfer to SAP. The acquisition can thereby also take place with the following references:
  • to the inspection lot,
  • to the procedure,
  • to the parameters,
  • to a procedure for the inspection point or
    
  • to a parameter for the inspection point.
    
• An integration of all possible functionalities in existing environments with the help of an expansive function library.

Standardised Data Transfer
The topic of instrument connection and data transfer is becoming increasingly interesting for all users of instrumental analysis. The fundamental requirements are, as a rule, always the same: fast and errorless transfer of measurement data into other systems. However, the devil likes to be in the detail: how and in which format should the data be delivered, which of the available data should even be transferred?

AJ Blomesystem GmbH allows the opportunity to accomodate exactly these specific requirement profiles through their new developments. On this basis of a combination of proven blomesystem^® technology and .Net components, the daugther company of the laboratory instuments corporate Analytik Jena AG is now implementing the module LABDDI.

The abbreviation DDI stands for Data Device Interface. With the help of this software any desired instument data can be deposited in a standardized form, whereby LABDDI offers a high degree of configuratibility. The connection of instruments to LABDDI is realized through plug-ins which take over the analysis and preparation of the data delivered by the instrument.

Based on the fixed structure of LABDDI, the prepared data can be transferred to the actual target systems. Individual adaptations or evaluations of the transferred data can then take place through functionalities in these systems. Current blomesystem^® products already consider the possibilities, which are produced from LABDDI. But even evolved customer specific applications can use LABDDI, the user here can also profit from the advantages of the system.

Based on the structures created through LABDDI, an external control chart module AJ-AQC created with blomesystem^® technology has been created for analysis instruments of the Analytik Jena Group. With the free Oracle Database 10g Express Edition (Oracle Database XE) as a platform, the many years of experience of AJ Blomesystem GmbH in the field of the control charts is used.

The AJ Blomesystem GmbH has developed a new interface for their standard systemLABcua, the standard for testing authorities. Although, up until now, the ILM files produced from LIMS data could only be transferred to ILM, these files can now also be imported into LABcua.

The interface is intended to be used for, e.g. receiving sample data from the sample taking local agency and creating samples from these directly in the LIMS. Files created with Balvi or Hamlet have been tested. You can therefore save yourself the work of caoturing the sample data again manually and instead using the already captured data of the local authorities.

The files can contain any number of samples. This file content is analysed. Address datas contained therein are checked to see whether they are already present in the LIMS. If not, the user can decie whether he wants to select from similar addresses or whether a new address should be created automatically from the given file content. The sample registration results through transfer of the data into the sample registration mask. In this way, individual characteristics of the corresponding LIMS can be considered.

This interface is available for the earlierstandard system CUA I of AJ Blomesystem.

In both variations, the file contents are transferred to a list form, which the user can view after a small modification. This list is translated into field names and can be converted by the customer with the most limited programming knowledge to the posiibly different field names in their LIMS. In this way, this interface can also be implemented by all CUA I - customers.