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

A new customer registers in the shop
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:

transfer together with the order data
if the customer has placed an order after the new creation of the account
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:

a new customer number
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

File name	Comment

File name	Comment
custupdate.csv	Records to be updated and inserted/ access data and customer options
custdelete.csv	Records to be deleted
billupdate.csv	Billing addresses to be updated and inserted.
billcomplete.csv	Billing addresses to be updated and inserted. In contrast to the file "billupdate.csv", this file must contain all billing addresses of a customer. Billing addresses that are not included will be deleted. This file is intended as an alternative to billupdate.csv, a simultaneous import will generally not be useful.
billdelete.csv	Billing addresses to be deleted. This file is intended for deleting individual addresses of specific customers. When deleting the complete customer using the file "custdelete.csv", all billing addresses will be automatically deleted as well.
delivupdate.csv	Delivery addresses to be updated and inserted
delivcomplete.csv	Shipping addresses to be updated and inserted. (analogous to billcomplete.csv).
delivdelete.csv	Delivery addresses to be deleted (analogous to billdelete.csv).
bankupdate.csv	Bank details to be updated and inserted
bankcomplete.csv	Bank details to update and insert (analogous to billcomplete.csv).
bankdelete.csv	Bank details to be deleted (analogous to billdelete.csv).

Import order

The files are imported in the following order:

*delete files
custupdate.csv
All other *update files
*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:

Field name	Field content	Required field yes/no

Field name	Field content	Required field yes/no
UserIndex	The table key in the shop database (see section Addressing the records)	yes when changing a record, forbidden when creating a new record (see Addressing records section)
CustomerID	The customer number	yes when a new record is created, otherwise: see Addressing of records
Password	The password with which the customer can log in to the shop. Note that you can only set the password when creating new customers. Since the customer can change his password in the shop at any time, there would otherwise be a risk that you overwrite the password chosen by the customer.	no
EMail	The customer's mail address	yes
MainSubshop	If a subshop ID is entered here, the customer can only log in to this subshop (and any subshops specified in the Subshop field). If a customer tries to log in to a subshop for which he has no access authorization, he will be redirected to the subshop specified under "MainSubshop". If this field is empty, the customer can log in to all subshops.	yes, if the "Subshop" field is used
Subshop	If a subshop is entered in the "MainSubshop" field, the "Subshop" field can be used to specify a comma-separated list of additional subshops that the customer can log into. As an alternative to a list of subshops, the value "*" can also be entered here, in which case the customer can log in to all subshops.	no
CharsetImport	If the customer data cannot be delivered in the character set used in the shop, the character set can be converted with these two fields	no
CharsetShop		no
AddressSharingLastChangeDate	Consent to share addresses for advertising purposes: Date of the last change of state in the format DD.MM.YYYY	no
AddressSharingLastChangeIP	Consent to share addresses for advertising purposes: IP address at last change	no
AddressSharingLastChangeTime	Consent to share addresses for advertising purposes: Time of last change of state in SS:MM:SS format (hours/minutes/seconds)	no
AddressSharingState	Consent to share addresses for advertising purposes: state, possible values are: 0: Not set 1: Consent rejected by phone 2: Consent given by phone 3: Consent refused in the shop 4: Consent given in the shop	no
AgeResMail	A mail address where the "AgeResPasswd" can be sent to	no
AgeRestricted	The age of the customer. If this field is filled with a value greater than 0, the logged in customer will only be shown products whose "AgeRestricted" is less than or equal to the customer's age	no
AgeResPasswd	The password (for the guardian) that can be used to change the "AgeRestricted" field	no
BillieDuration	Time in days within which the customer has to pay the invoice (only for payment type Billie) Valid values: 7 - 120 (overwrites the default value of 30 days from the shop configuration)	no
CreditCheckDate	Date on which an (automatic, renewed) credit check should be performed. The field can be used if a positive credit check by the shop should not be valid indefinitely, but e.g. after one year should be checked again whether a customer may continue to pay by invoice. Format: YYYY-MM-DD Example: 2022-03-17	no
CreditPassState	0/empty: not checked 1: checked positive 2: negative checked	no
Currency	The currency in which the prices are displayed to the customer by default after login.	no
CustomerDiscountOnly	"X": The customer will only be given the customer discount specified in "Discount", no other discounts. If no customer discount is assigned to the customer and this flag is set, the customer will not receive any discounts at all.	no
DelCostDiscRate	Discount in % that the customer will receive on the shipping cost.	no
DeliveryCostReduction	"X": Reduced delivery costs apply to the customer	no
DeliveryDays	Comma separated list of weekdays on which the customer can be delivered. 1=Monday ... 7=Sunday	no
DeliveryGroup	DeliveryGroup, allows to make article dependent delivery costs additionally customer dependent.	no
Discount	Discount in %, which the customer receives when purchasing discountable items	no
DiscountGroupID	Suffix for Discount.dat, allows customer dependent discount groups. Example: If DiscountGroupID="abc", then the file "discount_abc.dat" will be loaded from the shop. If DiscountGroupID="", then the file "discount.dat" will be loaded from the shop. The format of the "discount_*.dat" files is described in the "Products PRO (EN)" documentation.	no
DiscountList	Definition of the possible grouping of discountable products for the customer. If this field is used, the shop will ignore the general discount rate. This field can be used to supply discounts for products or categories that match the specified search mask. Structure of the field: <g>(Type):(discount rate)[:(search mask)][:(fromQuantity-toQuantity)]</g>... Type can have the following values: 1: Product number with optional wildcard characters 2: Product index with optional wildcard characters 3: UserDiscountCategory (reserved for internal use) "Wildcard characters" are: ?: Any character : Any number of arbitrary characters Example: <g>1:12.00:123?R</g> <g>2:12.00:10-123?R</g> <g>3:3.00:UserDiscountCategory</g> Data with and without quantities can also be combined. In this case, the first rule that applies from the left is used. Example: In the "flyer" category, a 3% discount is granted up to 1000 units, 2% up to 10000 and 1% from 10000: <g>3:3.00:flyer:-999</g><g>3:2.00:flyer:1000-9999</g><g>3:1.00:flyer:10000-*</g>	no
FreeDelivery	"X": The customer does not pay shipping costs	no
FreePayCost	"X": The customer does not pay any payment method costs	no
FreightCostsValue	Amount of a freight cost surcharge/deduction, e.g. 23.50	no
FreightCostsType	Type of freight cost surcharge/deduction, possible values: A+=Absolute markup A-=Absolute markdown P+=Percentage markup P-=Percentage markdown	no
GroupLogin	"X": The login data is used by multiple users ("group login"). In this case, neither the login data nor the address data can be changed by the logged-in user in the shop.	no
InfoScoreState	0/empty: not checked 1: positively checked 2: negative checked	no
LastOrderDate	Date of the last order in the format YYYY-MM-DD This field is intended for orders that were not placed in the online shop, e.g. by telephone. It can then be used to recognise new customers and to control the logic when retrieving address data changes.	no
MaxOrderForUserAccount	If this field contains a value > 0, this value will be used instead of the "MaxOrder-Value" entered for the payment types in shop.config.	no
OrderGenerator	"X": If a link to the "OrderGenerator" should be offered to the logged in customer.	no
PayCostDiscRate	Discount in % that the customer receives on the payment method costs
PaymentMethods	A comma-separated list of payment type codes of the payment methods available to the customer. Examples for payment type codes: 1=Credit card 3=Cash on delivery 4=Direct debit 5=Prepayment 6=Invoice … You find all payment type codes in the documentation for designers: Zahlungsarten Codes	no
ProductDiscount	"X": The customer discount is displayed at the product Any other value: The customer discount is displayed in the shopping cart	no
PriceGroup	A price group, if different prices have been specified for this price group during the article import, these will be displayed to the customer instead of the default prices. Even if customer-dependent prices are assigned via the customer number, this field must contain a non-empty entry. This "dummy entry" does not have to correspond to any existing price group and only serves as a flag so that the online shop activates the "customer-dependent prices" function.	no
RegistrationCode	"Unlock code", the shop can be set up so that only customers who know an unlock code can register. This activation code is stored by the shop with the customer data, a change of the value over the import is not meaningful therefore however a deletion of the code.	no
Releaser	"X": The customer can release the orders of other customers	no
ReleaseID	An ID for the release procedure	no
ReleaseRequired	"X": The customer's orders must be released before they are executed.	no
Reseller	"X": The customer can enter a "reseller markup" (commission), which will then be added to the total amount of the order	no
StartPage	A "start page" that is displayed after the customer logs in	no
SuperUserID	ID of a "Super-User" with special rights. This user can e.g. log in as another user and order for this user. Every customer with a filled SuperUserID is considered a "SuperUser", the ID entered here is returned in the order data. It is therefore recommended to use a different ID for each SuperUser, so that it is clear in the order data who has carried out the order.	no
SuperUserRestricted	"X": The "SuperUser" is only allowed to access the customer records where his SuperUserID is entered in the SuperUserIDList field.	no
SuperUserIDList	A comma-separated list of the SuperUserIDs of the SuperUsers that are allowed to access this customer record.	no
Surcharge	In addition to the global surcharge, it is possible to define an amount (SurchargeLimit) per customer, up to which a surcharge will be charged per order (SurchargeBase), if the surcharge falls below this amount. Furthermore, the amount of the surcharge can be defined individually for each customer.	no
SurchargeLimit		no
TeleMarketingLastChangeDate	Consent for telephone advertising: Date of last change of state in the format DD.MM.YYYY	no
TeleMarketingLastChangeIP	Consent for telephone advertising: IP address at the last change of state	no
TeleMarketingLastChangeTime	Consent for telephone advertising: time of last change of state in format SS:MM:SS	no
TeleMarketingState	Consent for phone advertising: state, possible values are: 0: Not set 1: Consent rejected by phone 2: Consent given by phone 3: Consent declined in shop 4: Consent given in the shop	no
UnitFactorGroupID	If customer-dependent denominations are to be used, the group ID must be entered here, which is then also used in the "UnitFactorGroups" field in the product data.	no
Warranty	Comma-separated list of the customer's authorization codes. An authorization code is an alphanumeric string whose content determines whether or not certain areas in the shop are displayed to the customer. Example list: 1,2,abc The customer belongs to the authorization groups "1", "2" and "abc". Example brackets in a template: `{ST-Warranty(1,abc)} This area is only displayed to the customer if he belongs to group "1" or "abc". {/ST-Warranty(1,abc)} {!ST-Warranty(1,abc)} This area is displayed to the customer, if he belongs neither to group "1" nor "abc". {/!ST-Warranty(1,abc)}`	no
WebsaleIni	Deprecated: The name of an alternative shop.config to use for the customer.	no

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:

Field name	Field content	Required field yes/no

Field name

Field content

Required field yes/no

UserIndex

The table key in the shop database (see section "Addressing the records")

Yes, if the CustomerID field is missing or empty (see Addressing the records section)

CustomerID

The customer number

Yes, if the UserIndex field is missing, empty or 0 (see Addressing the records)

If the UserIndex field is missing, empty or 0 and a customer number is specified, then all records matching this customer number are deleted.

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:

Field name	Field content	Required field yes/no

Field name	Field content	Required field yes/no
UserIndex	The table key in the shop database (see section Addressing records)	yes when changing a record, prohibited when creating a new record (see section Addressing of data records)
CustomerID	The customer number	yes when creating a new data record, otherwise: see Addressing of data records
TableIndex	The table key in the shop database	This field is currently optional, because the shop supports only one billing address per customer
ExternalID	The ID of the record for the customer.	ExternalID: yes when creating a new record. Optional when updating a billing address. (see Addressing records
BCCEMail	Comma-separated list of mail addresses to which the order confirmations should be sent as a "blind carbon copy".	no
BusinessFax	Fax (business)	no
BusinessPhone	Phone (business)	no
CCEMail	Comma-separated list of mail addresses to which the order confirmations should be sent as "carbon copy".	no
City	City of residence	no
Company	Company	no
CompleteSalutation	Complete salutation, e.g. "Dear Mr. Miller". This field can be used if a welcome email is to be sent to new customers when importing the data. It has no meaning for the shop.	no
CostCenter	CostCenter	no
CountryISO	Three-digit ISO code of the country	no
DateOfBirth	Date of birth in the format DD.MM.YYYY	no
Department	Department	no
EMail2	Mail address for invoice	no
Fax	Fax	no
FirstName	FirstName	no
LastName	LastName	no
MobilePhone	Mobile Phone	no
Phone	Phone	no
PostOfficeBox	P.O. Box	no
PostOfficeBoxZip	Post office box zip code	no
Salutation	Salutation, e.g. "Mr.". This field is used by the shop only if the "SalutationCode" is not filled. It is recommended to import the "SalutationCode" field instead of "Salutation" and to enter the text of the salutation (e.g. "Mr.") in the "salutation.dat" configuration.	no
SalutationCode	Code of the salutation, e.g. "11". The codes and the associated settings are configured in the configuration "salutation.dat". Access is via the "Configuration" service in the online service area.	no
State	Country, e.g. "Bavaria	no
Street1	Street / House number	no
Street2	Street / house number	no
Suffix1-50	Freely usable address data fields	no
TaxId	Sales ID	no
TaxIds	Sales IDs for chain transactions. Format: <g>{3ISO country}:{Check status}:{Sales-ID}</g> Example: <g>DEU:ok:DE123456789</g><g>BEL:unchecked:BE0999999999</g><g>AUT:failed:AT0999999999</g>	no
Title	Title, e.g. "Dr.".

Dokumentation

Format and content - WS-SFTP-Kunden PRO (EN)