Separating the standard code from the specific code is not an easy operation.

Take for example the interfacing methodology in SAP.

First, you need to create an additional package that contains the standard procedures and functions of the Gus³ system. This package, the PK_Int_Gus, is based on the standard tables that must be partly renamed.

You also need to create a PK_Int_SAP package for standard SAP interfaces. The specific package of the Client, the PK_Int_Client, is lightened. However, the standard function calls and procedures have been rewritten. The most complex part concerns objects that are both standard and specific. Some objects should be considered as simple extensions of the standard. As such, they should not be separated.

For example, for movements in IDOC format, there is an indicator that determines whether the type of motion should be transmitted to the server. The menu is also divided into 3 parts: one part is integrated with Gus³ (standard part of the interfaces), another part with the SAP interfaces and the third part with the specific Client.

New pre-load tables must be created (standard). They must review the trans-codifications performed by the specific interface. The goal is that iGus can load the written data directly into its format. This makes the connector available for any load.

Jobs are scheduled in the specific part of the Client. The mission of Gus³ is to detect the records that must be loaded from the standard tables.

Regarding the export part, the procedures that are not in SAP format have been fully maintained in the Customer's specific package (PK_Int_Client).

The documentation has been adapted. In particular, the connectors have been technically commented on so that users can format the data according to the pattern expected by Gus³.

Because of the invasive nature of the intervention, all interfaces are tested and validated before being activated.

We adapt this methodology to each of the editors with whom we interface.