General

This documentation describes the format and content of customer master data that can be sent to the shop.

Transfer of import files

The import files described below can be transferred in 3 ways.

Transfer via SFTP/REST

Step 1: Transferring the import files via SFTP
Step 2: Starting the import of the data via REST trigger

Since the trigger procedure is used in a similar way for different interfaces, it is described in the separate documentation "SFTP-REST-to-Shop (EN)".

Transfer via SFTP/SOAP

Step 1: Transferring the import files using SFTP
Step 2: Starting the import of the data using SOAP trigger

Since the trigger procedure is used in a similar way for different interfaces, it is described in the separate documentation "SFTP-SOAP-to-Shop (EN)".

Alternative transfer via WSPManager (previous version)

Data can also be transferred to and imported from the shop server using the Windows tool "WSPManager" provided by WEBSALE. This method should be used if, for example, no SFTP transfer or no REST/SOAP trigger can be implemented on the merchant's system.

The transfer via WSPManager is described in the separate documentation "WSPManager-to-Shop (EN)".

Format and character set of the files

The import files must be delivered in CSV format (character separated values).

The character used as field separator must be the tab character (ASCII 9). Other field separators are not allowed.

By using the tab separator, additional wrapping of text fields, e.g. by double quotes ("), is not necessary and also not allowed. All types of quotation marks are regular, permissible characters in the fields and may therefore be included directly in the data without any further marking.

The character set in which the data is encoded depends on the language of the country for which the shop is operated. The country ISO codes standardized on the Internet (e.g. ISO 8859-1) must be used. The use of UTF-8 is not allowed with WEBSALE V8, because otherwise many interfaces and services internally and to third party providers would deliver incorrect results.

Addressing of data records

In order to be able to access the master data of a customer specifically, key fields are required in the data. There are various key fields whose content is managed either by the shop, the ERP system or the customer.

To each customer data record belong only once occurring data such as the customer name or its address, but also multiple occurring data sets (multiple customer additional data) such as several deviating delivery addresses.

IDs with key function

Email

The primary identification of a customer in the shop is always via his email address.

From the shop's point of view, a new customer is therefore a customer who creates a new account in the shop with a new email address, i.e. one that has not yet been assigned to an account.

UserIndex of the customer master data (managed by the shop)

The UserIndex is a unique, numeric ID that is assigned exclusively by the shop when a new customer record is created in the shop database.

Possible cases of new creation in the shop

1. A new customer registers in the shop

2. An ERP system transfers to the shop a customer record previously unknown in the shop system.

To update existing records in the shop, an ERP system addresses a customer record using UserIndex.

CustomerID of the customer master data (managed by the ERP)

From the shop's point of view, the CustomerID is simply a string assigned by the shop operator. usually, the CustomerID is the unique customer number generated by the ERP system and used to reference the customer in the ERP system.

If an ERP system imports a new customer record from the shop system and then assigns a new customer number (CustomerID), the ERP system must inform the shop of this new customer number. In this case, the value that was transferred to the ERP together with the order or the customer data record (when collecting customer data changes) must be transferred as the user index. If the same customer number already exists in the shop, the import will be rejected as a duplicate.

TableIndex and ExternalID of the Multiple Customer Additional Data

These two IDs are used for addressing in tables of so-called "multiple additional customer data", i.e. for data records that can occur not only once but also several times. Such multiple, also several times per customer occurring data records can occur with 2 data types

• Delivery addresses

• Bank details

For each of these two data types there is a separate table in the shop.

TableIndex

The TableIndex is assigned exclusively by the shop when a new data record is created in one of the customer additional data tables.

The TableIndex is a unique numeric ID within the table.

Since there are three different customer additional data tables, the TableIndex values for the data records in each table can and do have the same values.

Example
A record in the table of delivery addresses can have the TableIndex "123", just as a record of a completely different customer in the table of bank details can also have the TableIndex "123".

ExternalID

From the shop's point of view, the ExternalID is simply a string that the shop operator has assigned. Usually, this is an index generated by the ERP system and used in the ERP system to reference one of several (multiple) delivery addresses of a customer, for example.

Rules of data transfer from ERP to the shop

New creation of a customer master data record

An ERP system transfers to the shop system a data record with a new CustomerID assigned by the ERP and a mail address not yet known in the shop.

The characteristic of a new creation is that the "UserIndex" field in the customer master data is empty.

In the course of importing the new customer master data into the shop database, the UserIndex is reassigned and then communicated from the shop to the ERP system via an export interface (see the documentation for the "SOAP-from-shop (EN)" interface).

The import of a customer record duplicate is rejected as an error and the record is discarded. A duplicate is recognized if the CustomerID or the mail address already exists in the shop database. Both CustomerID and mail address must therefore not exist in the shop. The remaining data, such as name or address, is irrelevant for the duplicate check of the shop during the customer data import!

Note:
In the case of a B2B shop, there may be an exception to the rule "New creation only if mail address does not exist". This is the case when using so-called "multiple accounts" (see the chapter "Multiple accounts" below). In this documentation, however, the standard case "a mail address may only exist once" is always treated in connection with the mail address.

Updating a customer master data record

An ERP system updates a data record that already exists in the shop by transferring all fields of the desired customer master data record.

The characteristic of an update is that the field "UserIndex" contains a UserIndex existing in the shop.

New creation of a multiple customer record

In a new creation, the same email addresses for different accounts can be passed to the shop. However, the CustomerID must be unique and must not already exist in the shop. If the CustomerID already exists, the record will be discarded.

Update of a multiple customer additional data record

An update of a multiple customer record is done via the UserIndex, as described in section above “Update of a customer master record.”

Examples of addressing

Assigning the IDs of new customers who register themselves in the shop

A new UserIndex, e.g. "123456", is generated in the shop database when a new customer master data record is created.

After the new creation, the shop transfers this UserIndex together with the other customer master data to the ERP system.

The transfer of the customer master data of the new customer takes place after his registration. Two cases are distinguished:

1. transfer together with the order data
   if the customer has placed an order after the new creation of the account

2. transfer by change of address data
   if the customer has not placed an order after the account was created

When transferring the customer master data, the CustomerID field (customer number) remains empty, since the shop does not yet know an ERP customer number (see the documentation for the "SOAP-from-Shop (EN)" interface).

The ERP system must now check the CustomerID field when reading in the order or change of address data and recognize that it is a new shop customer due to the non-existent customer number. It must then assign a new ERP customer number, e.g. "777888". This is immediately replicated back to the shop by the ERP system addressing the customer in the import file with the shop user index "123456" and passing the newly assigned ERP customer number "777888".

Assigning the IDs of new customers created in the ERP system

A new customer is created in the ERP system (e.g. by employees in the dealer's call center).
At least 2 fields are required to import a new customer into the shop:

1. a new customer number

2. a new email address

Both fields are required. The UserIndex, however, must be empty or 0 in this case.

Due to the missing UserIndex, the shop recognizes that this is a new creation and checks whether CustomerID or email already exist. If not, a new record with a new UserIndex is created in the shop database. The user indices of the created new customers can be queried via the SOAP function "GetAddedCustomers" (see the documentation "SFTP-SOAP-to-Shop (EN)").

Exceptions and options

eMarketingManager attachments

In addition to the shop, the WEBSALE-eMarketingManager (eMM), a newsletter system with extended functionality, also creates data records. These are

• Mail address

• optional address data

Since a newsletter usually only requires the specification of a mail address, the customer records created by the eMarketingManager (eMM) are usually without a password.

As a consequence, an ERP system usually discards a customer record from the shop that consists of a mail address alone, so the record also has no customer number in the customer database.

Here it is to be considered, if later a data record is to be imported from the ERP system with one of the same mail address:

• Many ERP systems do not know the UserIndex of these records because they either do not read address data changes from the shop or have discarded the incomplete address data that eMarketingManager creates.

• If these systems then try to create a new record with the same mail address, it will be rejected with an error message during import, because a mail address must not occur twice in the database.

For this reason, the mail address is also used for addressing under the following condition:

• No UserIndex is specified in the import data from the ERP (i.e. from the ERP's point of view, it is the creation of a new customer)

• A customer exists in the shop customer database with the mail address in the import data and without a password created and without a customer number in the shop database.

If these conditions are met, then the customer data from the import data will be written to the shop record that has the specified mail address.

Note:
This is also tolerable from the shop's point of view from a data security point of view, because the owner of the mail address had to undergo a double opt-in procedure when registering for the newsletter, thus clearly proving authorization to use the mail address.

Multiple accounts (eMail)

Multiple accounts are a feature that may be desired by the mail order company for a B2B shop.

By default, only one account can be created per mail address in a WEBSALE shop. However, if multiple accounts are allowed in a shop, it is possible to create multiple customer accounts with the same mail address, in deviation from the standard. Each of these multiple accounts then has its own password for login.

Multiple accounts should only be used in a shop in absolutely exceptional cases, as mail duplicates restrict some functions in the shop or even make them impossible.

Example of an application
A purchasing department with several buyers does not handle all purchase-related communication with individual mail addresses for each buyer, but with a single central purchasing mail address (e.g. einkaufsteam@firma.de). Nevertheless, each order in the shop should be traceably assigned to the individual purchaser. In this case, the login to the shop takes place with the same mail address, but each buyer has his own password. The combination mail / password ensures the assignment to the correct master data record of the respective buyer.

In the case of multiple accounts, there are thus several customer master data records with the same mail address in the shop.

Prerequisite for use
To use this feature, the shop must be specially configured. Please contact WEBSALE AG if multiple accounts are required.

Multiple accounts (CustomerID)

Normally it is not possible to create multiple customer records with the same customer number (CustomerID) via import, because they will be rejected as duplicates.

When using the "Multiple Accounts (CustomerID)" feature, this restriction is removed.

Compared to the feature "Multiple accounts (eMail)" there is the additional complication that the records in the individual import files (e.g. custupdate.csv and billcomplete.csv) are linked via UserIndex or CustomerID. In case of a new creation, however, the UserIndex must now have the value "0", so that in case of ambiguous CustomerIDs, an unambiguous assignment of the rows in the individual import files is no longer possible.

For this reason, when using "Multiple Accounts (CustomerID)", the "Email" field must be specified in each import file.

A combination of "Multiple accounts (CustomerID)" with "Multiple accounts (eMail)" is not possible for the same reason.

Prerequisite for use
To use this feature, the shop must be specially configured. Please contact WEBSALE AG if multiple accounts are required.

Mail addressing

Normally an import record with an empty user index (or user index = 0) is rejected as a duplicate if the mail address specified there is already used for a customer record in the shop.

If "Mail Addressing" is activated, the record with the specified mail address will be overwritten instead in this case.
The same is done if the user index specified in the import data does not exist in the shop database, i.e. a record with matching mail is searched for and overwritten.

Advantages

A certain "error tolerance" is achieved. If a customer is created in the ERP system who has already registered himself in the shop, then the import normally fails, because the import data record is marked as "new creation" and the mail is already assigned.

This case may occur if the ERP has not (yet) read the customer created in the shop. This can happen if the customer was created in the shop and in the ERP at the same time or if the ERP has explicitly refused to read in the customer data record (e.g. because of an incomplete address).

Furthermore, a customer record can still be imported if there is an incorrect user index in the ERP database, e.g. because the customer has deleted himself in the shop and registered again and this process has not arrived in the ERP.

Disadvantages

The "error tolerance" is also a disadvantage at the same time, because it disguises discrepancies between the ERP database and the shop database.

For example, by creating a new customer in the ERP, a clerk can overwrite an existing customer record in the shop without being notified in any way.

Something similar can happen if the user index in the ERP is no longer correct; this can also unknowingly overwrite data for a shop customer for whom the changes were not intended.

Furthermore, "Multiple accounts (eMail)" can of course not be used in combination with "Email addressing".

Prerequisite for use
To use this feature, the shop must be specially configured. Please contact WEBSALE AG if email addressing is required.

Import files

Limitation of field lengths

The default and at the same time maximum allowed length of all customer data fields is 256 characters.

In the section "AddressMaxInputLen" of the shop configuration "shop.config" the maximum length of the individual fields for which the customer can enter content in the shop can be reduced if required. You should make use of this option if the respective field length in your system is smaller than 256 characters.

Limitation of file size

• Import via SFTP: 4 GB per file

• Import via WSPManager: 1 GB per file

Overview of import files

Import order

The files are imported in the following order:

1. *delete files

2. custupdate.csv

3. All other *update files

4. *complete files

So, within an import, records of a customer could be deleted first and inserted again afterwards, if this makes sense from the point of view of the exporting system.

Because of the processing as last, a complete import of all records always has "the upper hand". If with an update file and in the associated complete file thus data records for the same customer are transferred, then the data of the complete file overwrite the previously imported data of the update file.

Structure and contents of the file “custupdate.csv”

This file can be used to create new records in the shop and set various options for customers. So that for a customer invoice addresses, delivery addresses etc. can be imported always also first a data record must be created with the help of the custupdate.csv.

If required fields are not supplied in the file (i.e. the column is missing completely), the values originally shop for these fields in the customer record are retained.

The file contains the following fields:

Structure and content of the file “custdelete.csv”

This file can be used to delete records from the shop. If a record is deleted using custdelete.csv, all of the customer's data is deleted, i.e. their billing addresses, shipping addresses, etc.

The file contains the following fields:

Structure and content of the file “billupdate.csv/billcomplete.csv”

These files contain the invoice addresses to be inserted or updated. The structure of the two files is identical. However, the contained data are handled differently during import:
records of a customer that are not contained in the billupdate.csv remain in the shop's customer database, while they are deleted during import of the identical data in a billcomplete.csv.

Example

The customer database of the shop contains two customers with the customer numbers "123" and "ABC". For customer "123" there are 5 billing addresses stored in the customer database. In the billupdate.csv/billcomplete.csv there are 3 billing addresses for the same customer. The customer "ABC" does not appear in the import files.

When importing the data as "billcomplete.csv", the 5 invoice addresses of customer "123" from the database would be replaced by the 3 invoice addresses from the import file.

When importing the data as "billupdate.csv", the 3 addresses from the import data would be added to the addresses already in the customer database or the existing addresses would be updated.

The data of the customer "ABC" remain unchanged in the customer database in both cases.

Please note that the shop supports only one billing address per customer so far.

The files contain the following fields:

Structure and content of the file “billdelete.csv”

this file can be used to delete individual invoice addresses from the shop. If all data of a customer should be deleted, it is sufficient to delete the data record with custdelete.csv, a deletion of the individual invoice addresses with billdelete.csv is not necessary in this case.

The file contains the following fields:

Structure and content of the file “delivupdate.csv/delivcomplete.csv”

These files contain the delivery addresses to be inserted or updated. They are handled analogously to the files billupdate.csv or billcomplete.csv. Delivery addresses only need to be imported for a customer if they differ from the billing addresses.

The files contain the following fields:

Structure and content of the file “delivdelete.csv”

This file can be used to delete individual delivery addresses from the shop. It is handled in the same way as the billdelete.csv file.

The file contains the following fields:

Structure and content of the file “bankupdate.csv/bankcomplete.csv”

These files contain the bank details data to be inserted or updated, they are treated analogously to the billupdate.csv or billcomplete.csv files.

The files contain the following fields:

Structure and content of the file “bankdelete.csv”

This file can be used to delete individual bank details from the shop, it is handled in the same way as the “billdelete.csv” file.

The file contains the following fields:

Character set conversion

If the address data cannot be supplied in the character set used by the shop, the character set can be converted during import. There are two ways to do this:

1. Using the fields "CharsetImport" and "CharsetShop".

These two fields must be specified in the custupdate.csv file for each imported data set and contain the character set of the data set in the import data and the character set to be used in the shop.

2. Configuration of the conversion in the file global.config

Here in the file "global.config" in the directory "configuration" is set in which character set the customer data are supplied. The file "global.config" is optional in the shop and must be created therefore possibly first.

The character set of the shop is read from the "shop.config". In order for the subshop (and thus the shop.config to be used) to be determined, the "MainSubhop" field must be filled for each record in this method.

Example for the configuration in global.config

The only required parameter is "ConvertCharset", because only if this parameter has the value "yes" the charset will be converted at all. "ImportCharset" specifies the character set of the import file. If the parameter is missing or empty, the character set "UTF-8" will be used.
"UnknownCharacters" controls the behavior if the import file contains characters that are not available in the shop's character set. The default value is "ignore". Characters that cannot be converted are completely omitted. With "stdreplace" it is tried to replace unknown characters with one or more similar looking characters. The value "mapreplace" causes configurable replacements to be made before the actual conversion. If characters cannot be converted even after these replacements, they are omitted (as with "ignore").

Which characters are replaced by what is defined in the "<+ImportCharsetConvertMap>" sections.

In the global.config file there can be several of these sections. One for each required character set. The parameter "Charset" specifies the charset for which the section should be used, all other parameters represent replacement rules. To the left of the "=" is a character or character string from the import file, to the right of it is the desired replacement. Since the character set of the import file generally differs from the character set of global.config, the characters can be specified URL-encoded. With this encoding, a character is essentially replaced by its hexadecimal code and the code is preceded by a "%".

The fields "CustomerID", "Mail", "Subshop" and "MainSubshop" are excluded from the character set conversion.

Welcome emails for new customers

It is possible to send a "welcome mail" to each new customer whose data has been imported via the "custupdate.csv" file. A customer in the "custupdate.csv" is considered a new customer if one of the following two conditions is met:

• The customer was not in the database before the import

• The customer did not have a customer number before and a new one is assigned to him via the "custupdate.csv"

The text of the mail that is sent to the customer is formed from a template that is configured in shop.config:

The template file is located in the directory ".../used/templates/<subshop>/"

So the template used for sending the welcome mail depends on the content of the "MainSubshop" field in the import file. If this field is missing or empty, no welcome mail can be sent.

The sender name, sender address and subject of the welcome mail are also set in shop.config:

If sending a welcome mail is not desired, this can be prevented by setting the "Allow" parameter to "no":

Alternatively or additionally, the template can be deleted or renamed.

The following placeholders are available in the mail template:

All address data (A-CompleteSalutation, A-Salutation, A-FirstName, A-LastName) will be read from the customer's first billing address.

Forced change password

This feature can be used to force a customer created via import to change his password after the first login. To do this, set the "NewUserPWChangeRequired" parameter in the "UserData" section of shop.config to "yes"

Handling of deleted accesses

Customers have the option to delete or deactivate their accesses to the shop. These "deleted" records will initially remain in the database and will only be flagged as deleted there.

If you try to import data for deleted records, the changes will be ignored. However, deleting the data via custdelete.csv is possible or even necessary to actually remove the data from the database.

The reason for this behavior is that ERP systems normally cannot delete customer data. If the customer data were to be completely deleted from the shop database, there would be a risk that the ERP system would import the data deleted in the shop back into the shop. The customer who deleted his account in the shop would then rightly wonder why his deleted account is suddenly active again.

Sample files

Part of this documentation are the following example files, which you can download on the subordinate page:

Error codes

Error mails during import via WSPManager

When transferring customer import files with the WSPManager, the list of occurred errors and warnings is shortened if it exceeds a certain length.

The complete list of occurred errors and warnings can be sent to you by mail, configure the following sections in the shop.config of the first subshop:

Other import files

Overview of "other import files”

Import of product customer groups

Product customer groups can be used to show or hide categories in the shop, depending on which customer has logged into the shop.

The assignment of customers to product customer groups is done via two additional files in the "customerimport" directory: "groupproductupdate.csv" and "groupproductdelete.csv".

With the file "groupproductupdate.csv" customers can be assigned to product customer groups, with the file "groupproductdelete.csv" these assignments can be deleted again.

Structure of the file "groupproductupdate.csv"

For example, to assign the product customer groups 1 and 2 to the customer with the customer number "1234" you could use the following file:

CustomerID<TAB>GroupIdx

1234<TAB>1

1234<TAB>2

("<TAB>" in this example stands for the tab character/ASCII code 9. If other product customer groups were already assigned to the customer before the import, these will be retained)

Structure of the file "groupproductdelete.csv"

The following file would remove the customer with customer number "1234" from the product customer group "Pianos", as well as delete the complete product customer group "Monitors":

CustomerID<TAB>GroupID

1234<TAB>1

*<TAB>2

Import of data for customer accounts, bonus points, grants

Customer accounts, bonus points and allowances are intended for the realization of bonus systems and credits that can be redeemed in the shop.

Bonus points:
For example, a customer is credited with a number of bonus points for purchasing a product. If he has collected enough bonus points, he can redeem them in the shop.

If you do not offer bonus points, then you can omit the "BonusPoints" column in the import file.

Customer account:
Here you can credit customers with any amount of credits. When purchasing, the customer then selects the payment method "customer account" and pays with his credit. WEBSALE automatically reduces the credit after a purchase.

If you do not offer a customer account, then you can omit the "Credit" column in the import file.

Allowance:
Here you can credit customers with any allowance. The granted allowance will be deducted from the total amount in the shopping cart. When the order is placed, the granted allowance will be automatically deducted from the allowance account of the shop. Any remaining amount will be taken into account for subsequent orders until the allowance has been used up.

The import of the customer account data is done via an additional file named "accountupdate.csv" in the "customerimport" directory.

Structure of the file "accountupdate.csv"

Remarks:

• The UserIndex is used to address the records, so this indirectly means that customer account data can only be imported for customers who already exist in the database, because otherwise the UserIndex is not known.

• For bonus points, credits and allowances, differences can be specified in addition to absolute values. For this purpose, the value is preceded by a "+" or a "-".
  For example, if a customer has 100 bonus points on his account and you import the value "10" in the "BonusPoints" column, the value in the database will be set to 10. If you specify the value "+10" instead, the value will be increased to 110; if you specify "-10", the value will be decreased to 90.
  If possible, differences should be specified during the import, because in this way it can never happen that the import undoes changes that were made by the online shop. Ex: You want to reduce the number of bonus points of a customer from 150 to 100 because he redeemed 50 points via a telephone order. The same customer was in the shop shortly before you started the import and sent an order that credited him with an additional 77 points. If you now import "100", you will delete the credit of 77 points. If you import "-50", the number of bonus points will be set to the correct value (177).

• An explicit deletion of entries from the customer account table is not possible, entries are deleted when (by transferring the file "custdelete.csv") the general customer data are deleted. Of course, you can set the values to "0".

• During an import, several files with customer accounts, bonus points and allowances can be imported. In this case the names must be provided with a "suffix", the name of an import file could then be e.g. "accountupdate_1.csv".
  The suffix starts with an underscore followed by one or more digits.
  Import files are sorted alphanumerically before import, i.e. "accountupdate_10.csv" is imported before "accountupdate_2.csv".

Quotation data

This function allows you to transfer a quotation that you have made to a specific customer to the online shop, the customer can then order the corresponding products online.

For the import of offer data you have to create two files, the file "offerheadupd.dat" and the file "offerprodupd.dat". The first file contains data related to the whole offer, e.g. shipping costs. The second file contains the individual products of the offer.

You can delete offers with the file "offerdel.dat".

All three files must be stored in the "data-exchange" directory. Alternatively, the files can be named "offerheadupd.csv", "offerprodupd.csv" and "offerdel.csv", in which case they must be stored in the customer-import files ("customerimport") directory.

When importing via the SFTP-SOAP interface the *.csv files must be used, when transferring with the WSPManager the *.dat or the *.csv files can be used.

Structure of the file “offerheadupd.dat/offerheadupd.csv”

Structure of the file “offerprodupd.dat/offerprodupd.csv”

Structure of the file “offerdel.dat/offerdel.csv”

Import of customer dependent order quantities

For each product and customer a maximum and/or a minimum order quantity can be imported.

Order quantities are created and modified using the "orderquantityupdate.csv" import file, and deleted using the "orderquantitydelete.csv" file. Both files must not exceed a maximum size of 1 GB and both must be created (like the other customer import files) in the "customerimport" directory.

The file "orderquantitydelete.csv" is read in before the file "orderquantityupdate.csv", so that it is possible to delete entries and create new ones during an import.

Structure and content of the file “orderquantityupdate.csv”

The file is used to create and modify entries and contains the following fields:

Remarks:

• The "-" value in the "MaxOrderQuantity" and "MinOrderQuantity" fields has the effect of not changing the value set in the shop. Leaving the field completely empty has the same effect.

• The "$NoLimit$" value in the "MaxOrderQuantity" or "MinOrderQuantity" fields causes a limit set for the product/customer to be removed. I.e. the customer can then order as much or as little of the product as he wants.

• If a value for MinOrderQuantity or MaxOrderQuantity has never been explicitly set for a product/customer, then the value corresponds to "$NoLimit$".
  "$NoLimit$" is therefore the value with which the "MaxOrderQuantity" and "MinOrderQuantity" fields are initialized.

• If no maximum/minimum order quantity is to be set for any product/customer, the MaxOrderQuantity/MinOrderQuantity column can be omitted completely. The effect is the same as if the column was filled with the value "-".

• When deleting products or customers, the associated order quantities are not automatically deleted. An automatism is problematic, if products or customers are deleted and afterwards created again, because afterwards also the order quantities would have to be imported again.

• There is no check whether a customer or a product in the import file actually exists in the shop. This has the advantage that order quantities can be imported before products or customers.

• For products with dependent variations, it is not sufficient to specify an order quantity for the master item. Instead, the order quantity must be specified for each individual dependent variation.

• When a customer orders in the shop, the value of MaxOrderQuantity is decreased by the ordered quantity.

Structure and content of the file “orderquantitydelete.csv”

The file is used to delete entries and contains the following fields:

Remarks:

The special value "*" can be specified for each column. This causes that the value in this column is not considered when deleting. For example, if the "ProdIndex" column contains the value "123", the "Subshop" column contains the value "German" and the CustomerID column contains the value "*", the order quantities of product "123" would be deleted for all customers

Import of prime packages

The prime packages assigned to a customer are imported via the primeupdate.csv and primedelete.csv files.

Structure of the file “primeupdate.csv”

The primeupdate.csv file is used to create and update the prime packages assigned to a customer. A maximum of 10 different prime packages can be assigned to each customer.

If a prime package is imported for a customer that is already assigned to him, the data of the existing prime package will be updated. If the prime package is not yet assigned to him, it will be added.

Prime packages that are assigned to the customer but are not imported will remain unchanged.

Each line of the import file corresponds to one prime package, i.e. if 10 prime packages are to be assigned to a customer, then the file must contain 10 lines for this customer.

The primeupdate.csv file contains the following fields:

Structure of the file “primedelete.csv”

The primedelete.csv file is used to delete prime packages assigned to a customer. It contains the following fields:

Sample files

Part of this documentation are the following sample files, which you can find on the subordinate page for download: