Exchange via intermediateDB

[hasibaakterss3309]

The integration is implemented according to the standard: not in the configuration of the control system itself, but in an extension to it (as a pluggable object). This approach is justified for the following reasons:

we do not interfere with the original configuration, it is quietly updated and remains supported by the supplier. The extension can be disabled at any time;

all modifications made by the integrator luxembourg mobile database remain in place after updating the vendor code;

We do not touch the standard code, thus ensuring security.

Integrations work through the exchange of messages that are saved in the DB tables. All processes, except inventory, are initialized on the 1C side.

During the first stage of integration, mechanisms for exporting messages were developed for the following objects:

Nomenclature groups (CLASSIFIER);

Nomenclature (GOODS);

Receipt by ASN (Order to supplier - ASN, Receipt of goods and services - RECEIPT);

Shipment (Customer order - ORDERS, Sale of goods and services - DESPATCH);

Reconciliation of balances (REMAINS).

During the integration process, a number of features were taken into account:

To integrate product groups on the WMS side, there are corresponding classifiers; on the 1C side, these are groups in the product reference book.

The peculiarity of counterparty integration is that WMS does not have the concept of a partner, while 1C maintains joint records of both partners and counterparties. Counterparties can either be exported from 1C to WMS immediately, or this can be done as documents containing references to counterparties are exchanged.