> ## Documentation Index
> Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Addresses and input checks

> Which address fields the shop requests, how long the inputs may be, how fields show, hide, or rename each other, and how the inputs are checked.

The address entry is the part of the shop where the most can go wrong. A field that is not displayed cannot be filled in. A field that is checked even though it is not visible blocks the order. And a field that the merchandise management system only accepts up to 35 characters long causes trouble only after the purchase.

The sections on this page therefore build on each other. First, you define which fields exist at all. Then, how long the inputs may be and which selection lists are behind them. After that, when a field is visible or has a different name. Finally, how the input is checked.

Reference: Shop configuration shop.config, overview of all sections

## AddressFields-Txt

Defines which data is requested for the **billing address**. A field is considered enabled as soon as a value follows the equals sign. This value is also the label that can be output in the template.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AddressFields-Txt>
   Salutation = Anrede
   FirstName  = Vorname
   LastName   = Name
   Street1    = Straße
   Street2    = Hausnummer
   Zip        = PLZ
   City       = Ort
   Country    = Land
   E-Mail     = E-Mail-Adresse
   Company    =
</AddressFields-Txt>
```

In the example, `Company` is **not** enabled because nothing follows the equals sign. The field cannot be placed in the template.

### Name and salutation

| Parameter | Field |
| - | - |
| `Salutation` | Selection list for the salutation, filled from the salutation configuration |
| `SalutationCode` | Salutation code, filled from salutation.dat |
| `Title` | Selection list for the title, filled from title.dat |
| `FirstName` | First name |
| `LastName` | Last name |
| `Company` | Company name |
| `Number` | Customer number |
| `DateOfBirth` | Date of birth. The shop system automatically generates three selection lists from it for day, month, and year |

### Address

| Parameter | Field |
| - | - |
| `Street1` | Street |
| `Street2` | House number |
| `Zip` | Postal code |
| `City` | City |
| `Department` | Department |
| `PostOfficeBox` | PO box |
| `PostOfficeBoxZip` | Postal code of the PO box |
| `State` | Federal state or state |
| `Country` | Selection list for the country, filled from country.dat |

### Contact details

| Parameter | Field |
| - | - |
| `Phone` | Phone |
| `BusinessPhone` | Business phone |
| `MobilePhone` | Mobile phone |
| `Fax` | Fax |
| `BusinessFax` | Business fax |
| `E-Mail` | Email address |
| `E-Mail2` | second email address, for example for sending invoices |

### Other fields

| Parameter | Field |
| - | - |
| `TaxID` | VAT identification number |
| `Suffix1` to `Suffix50` | freely usable fields. They can also be used as selection lists |
| `IdentityCard1` to `IdentityCard5` | ID card number |
| `PassportNumber1` | Passport number |
| `UserDefList-1` to `UserDefList-3` | freely definable selection lists. Deprecated |

> [!WARNING]
>
> `UserDefList-1` to `UserDefList-3` are deprecated and no longer supported. Use the suffix fields with `A-Suffix` selection lists instead. The selection in a UserDef list is passed to the order data, but it is not saved in the customer data.

> [!NOTE]
>
> Enabling a field alone is not enough; it must also be placed in the template. Conversely, a field that has no value here cannot be used in the template, and visibility rules and input checks do not apply to it either.

> [!NOTE]
>
> You do not define fields that the buyer may not change here, but in the `AddressFields-ReadOnly` section.

Guide: Requesting the billing address, Defining checks for address data, Requesting, checking, and evaluating the VAT ID

## DeliveryAddressFields-Txt

The same for the **alternative delivery address**. The fields correspond to those of the billing address, with three exceptions.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<DeliveryAddressFields-Txt>
   Salutation = Anrede
   Company    = Firma / Institution
   FirstName  = Vorname
   LastName   = Name
   Street1    = Straße, Nr.
   Zip        = PLZ
   City       = Ort
   Country    = Land
</DeliveryAddressFields-Txt>
```

| Billing address field | In the delivery address |
| - | - |
| `Number` | not available |
| `E-Mail2` | not available |
| `TaxID` | not available |
| `IdentityCard1` to `5`, `PassportNumber1` | not available |
| `UserDefList-1` to `3` | not available |

All other fields, including `Suffix1` to `Suffix50`, exist in both addresses.

Guide: Requesting an alternative delivery address, Defining checks for address data

## AddressMaxInputLen

Limits the input length per field. This is especially important when the order data is passed to a merchandise management system that has its own length limits.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AddressMaxInputLen>
   Company          = 45
   FirstName        = 45
   LastName         = 45
   Street1          = 45
   Street2          = 45
   Zip              = 12
   City             = 45
   PostOfficeBoxZip = 12
   IdentityCard1    = 11
   IdentityCard2    = 7
   IdentityCard3    = 8
   IdentityCard4    = 1
   PassportNumber1  = 27
</AddressMaxInputLen>
```

The parameter names are the same technical field names as in `AddressFields-Txt`. The default is 45 characters, and 12 for postal codes.

> [!WARNING]
>
> The maximum input length may be no more than 256 characters.

> [!NOTE]
>
> `IdentityCard4` is set to 1 by default because only the check digit is expected there. If buyers with new ID cards should also enter the four-digit version number, set the value to 5.

Guide: Defining basic settings for billing and delivery addresses

## A-Suffix1 to A-Suffix50

Turns a suffix field of the billing address into a selection list. This lets you ask the buyer questions that they answer from predefined answers.

Each section belongs to exactly one suffix field: `A-Suffix1` fills the list for `Suffix1`, `A-Suffix2` the one for `Suffix2`, and so on.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<A-Suffix1>
   <+Entry>
      Name  = Privatkunde
      Value = private
   </+Entry>
   <+Entry>
      Name  = Geschäftskunde
      Value = business
   </+Entry>
</A-Suffix1>
```

| Parameter | Purpose | Values |
| - | - | - |
| `+Entry` | An entry in the selection list. Up to 500 entries per list. | |
| `Name` | Description of the entry. Appears in the display and in the readable format of the order. | any text |
| `Value` | Optional. Identifier of the entry. Used in the technical format of the order and saved in the customer data. | any string |

> [!NOTE]
>
> Keep `Name` and `Value` deliberately separate. `Name` is the text the buyer reads, and it may change. `Value` is the value your merchandise management system works with, and it should remain stable. Without `Value`, the display text ends up in the technical order data, and every text change carries over there.

> [!WARNING]
>
> When using Paymorrow and a selection list for the legal form: Paymorrow does not accept values that consist only of digits. So `01` does not work. Paymorrow can tell you which values are permitted.

Guide: Selection lists for address data, Paymorrow

## D-Suffix1 to D-Suffix50

The same for the suffix fields of the **delivery address**. Structure and parameters are identical.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<D-Suffix1>
   <+Entry>
      Name  = Postalische Lieferadresse
      Value = postal
   </+Entry>
   <+Entry>
      Name  = DHL-Packstation
      Value = packstation
   </+Entry>
</D-Suffix1>
```

> [!NOTE]
>
> The lists for the billing address and the delivery address are independent of each other. `A-Suffix1` and `D-Suffix1` can have completely different entries, even though both fill the `Suffix1` field.

Guide: Selection lists for address data

## AddressFields-Standards and DeliveryAddressFields-Standards

Defines which entry a selection list is preset to when the buyer sees the page for the first time.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AddressFields-Standards>
   Suffix1 = Privatkunde
</AddressFields-Standards>

<DeliveryAddressFields-Standards>
   Suffix1 = Postalische Lieferadresse
</DeliveryAddressFields-Standards>
```

The technical field name goes on the left, and the entry the list should start with goes on the right.

> [!WARNING]
>
> The right side contains the **name** of the entry, not its `Value`. If you have an entry in `A-Suffix1` with `Name = Privatkunde` and `Value = private`, then `Privatkunde` belongs here. If you later change the display text of the list, you must change the preset as well, otherwise it has no effect.

Guide: Choosing between a postal delivery address and a Packstation

## AddressFields-ReadOnly

Defines which fields the buyer may see but not change. A typical case is the customer number that comes from the merchandise management system.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AddressFields-ReadOnly>
   <+Fields>
      AddressField = Number
      AddressType  = bill
   </+Fields>
   <+Fields>
      AddressField = Suffix1,Suffix2,Suffix3
      AddressType  = both
   </+Fields>
</AddressFields-ReadOnly>
```

| Parameter | Purpose | Values |
| - | - | - |
| `AddressField` | Comma-separated list of technical field names. Required. | technical field names |
| `AddressType` | Which address the lock applies to. | `both`, `bill`, `delivery`. Default `both` |

> [!NOTE]
>
> In the parameter table of the previous documentation, the names appear as `Adressfield` and `Adresstype`. The correct names are `AddressField` and `AddressType`, as in the examples on the same page.

Guide: Defining customer data that the buyer cannot change

## AddressFields-Actions

Names the fields whose input requires the template to be reloaded because other fields change as a result.

Without this section, the rules from `AddressFields-InputVisibility` and `AddressFields-AlternativeText` only take effect on the next page change, not immediately after the input.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AddressFields-Actions>
   <+FieldAction>
      AddressField = Company
      AddressType  = bill
   </+FieldAction>
</AddressFields-Actions>
```

| Parameter | Purpose | Values |
| - | - | - |
| `AddressField` | Comma-separated list of technical field names that trigger an action. | technical field names |
| `AddressType` | Which address this applies to. | `both`, `bill`, `delivery`. Default `both` |

In the example, the `TaxID` field should be shown as soon as `Company` is filled. For this, **`Company`** must be entered here, because this field triggers the action. `TaxID` does not belong in this section.

> [!WARNING]
>
> The most common mistake is entering the field that should be shown or hidden here. The field that belongs here is the one whose input triggers the reaction.

> [!NOTE]
>
> The shop system itself adds to this list all fields that appear in a condition of `AddressFields-AlternativeText`, `AddressFields-InputVisibility`, or in a minimum length check. So a lot works even without your own entry. Do not rely on this, though; enter the triggering fields.

Guide: Choosing between a private and a business address

## AddressFields-AlternativeText

Renames a field depending on the input in another field. The classic case: "Street" becomes "Packstation no." as soon as the buyer chooses the Packstation as the delivery type.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AddressFields-AlternativeText>
   <+Alternative>
      AddressField = Street1
      AddressType  = delivery
      Text         = Packstation Nr.
      <+Condition>
         Field = Suffix1
         Type  = value
         Value = DHL-Packstation
      </+Condition>
   </+Alternative>
</AddressFields-AlternativeText>
```

| Parameter | Purpose | Values |
| - | - | - |
| `AddressField` | Comma-separated list of the fields to be renamed. | technical field names |
| `AddressType` | Which address this applies to. | `both`, `bill`, `delivery`. Default `both` |
| `Text` | The new label. | any text |
| `+Condition` | Condition under which the renaming takes effect. Multiple conditions are combined with AND. | |

The parameters within `+Condition` are the same as for `AddressFields-InputVisibility` and are described in the [Conditions](#conditions-in-condition) section further below.

> [!NOTE]
>
> Multiple `+Condition` blocks within a `+Alternative` are combined with **AND**. For an OR combination, create multiple `+Alternative` blocks with the same `AddressField` and the same `Text`.

Guide: Choosing between a private and a business address

## AddressFields-InputVisibility

Shows or hides a field depending on the input in another field. The most commonly used example is the VAT identification number, which only business customers should see.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<AddressFields-InputVisibility>
   <+FieldVisibility>
      AddressField  = TaxID
      AddressType   = bill
      Visible       = yes
      ResetIfHidden = yes
      <+Condition>
         Field = Company
         Type  = filled
      </+Condition>
   </+FieldVisibility>
</AddressFields-InputVisibility>
```

| Parameter | Purpose | Values |
| - | - | - |
| `AddressField` | Comma-separated list of the affected fields. Required. | technical field names |
| `AddressType` | Which address this applies to. | `both`, `bill`, `delivery`. Default `both` |
| `Visible` | Whether the field is visible or not when the condition is met. | `yes`, `no`. Default `no` |
| `ResetIfHidden` | Clears the input as soon as the field is hidden. | `yes`, `no`. Default `yes` |
| `+Condition` | Condition. Multiple conditions are combined with AND. | |
| `BasketConditions` | Subsection with conditions that refer to the basket instead of address fields. | |

> [!WARNING]
>
> A field is considered **hidden** if either of the following two combinations applies:
>
> * `Visible = no` and the conditions are **met**
> * `Visible = yes` and the conditions are **not met**
>
> The second combination is the one that surprises people in practice. A rule with `Visible = yes` therefore does not just show the field; it also hides it in all other cases.

> [!WARNING]
>
> With `ResetIfHidden = yes`, the default, the buyer loses their input as soon as the field is hidden. When resetting a field, the shop system also clears its corresponding counterpart: for `Salutation` also `SalutationCode`, for `Title` also the title code, for `Country` also the country code, and vice versa in each case.

> [!NOTE]
>
> The rule only affects fields that are enabled in `AddressFields-Txt` or `DeliveryAddressFields-Txt`. A visibility rule for a field without a label has no effect, and no message appears. Likewise, a `+FieldVisibility` block without `AddressField` is silently skipped.

> [!NOTE]
>
> The `BasketConditions` subsection is not included in the previous documentation. It lets you make the visibility of an address field depend on the contents of the basket instead of on another address input.

### Four typical cases

**VAT ID only when the company is filled**

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<+FieldVisibility>
   AddressField  = TaxID
   AddressType   = bill
   Visible       = yes
   ResetIfHidden = yes
   <+Condition>
      Field = Company
      Type  = filled
   </+Condition>
</+FieldVisibility>
```

**VAT ID only when the company is filled and the salutation is "Firma"**

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<+FieldVisibility>
   AddressField  = TaxID
   AddressType   = bill
   Visible       = yes
   ResetIfHidden = yes
   <+Condition>
      Field = Company
      Type  = filled
   </+Condition>
   <+Condition>
      Field = Salutation
      Type  = value
      Value = Firma
   </+Condition>
</+FieldVisibility>
```

**Hide the VAT ID if the company is empty and the country is not the United Kingdom**

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<+FieldVisibility>
   AddressField  = TaxID
   AddressType   = bill
   Visible       = no
   ResetIfHidden = yes
   <+Condition>
      Field = Company
      Type  = empty
   </+Condition>
   <+Condition>
      Field = Country
      Type  = notvalue
      Value = United Kingdom
   </+Condition>
</+FieldVisibility>
```

**No registration number for certain legal forms**

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<+FieldVisibility>
   AddressField  = Suffix27
   AddressType   = bill
   Visible       = no
   ResetIfHidden = yes
   <+Condition>
      Field = Suffix25
      Type  = inlist
      Value = Einzelfirma,Freiberufler,GbR,Sonstige Personengesellschaft
   </+Condition>
</+FieldVisibility>
```

Guide: Choosing between a postal delivery address and a Packstation, Choosing between a private and a business address

## Conditions in +Condition

The `+Condition` subsections have the same structure in `AddressFields-AlternativeText`, `AddressFields-InputVisibility`, and `InputCheck`.

| Parameter | Purpose | Values |
| - | - | - |
| `Field` | Technical field name of the checked field. | technical field name |
| `Type` | Type of check, see the table below. | Default `filled` |
| `Value` | Comparison value or list, depending on `Type`. | |
| `BasketBehavior` | Whether one product in the basket must meet the condition or all of them. | `match-all`, `match-once`. Default `match-all` |

| `Type` | The condition applies if |
| - | - |
| `filled` | the field is filled |
| `empty` | the field is empty |
| `value` | the field's value equals `Value` |
| `notvalue` | the field's value does not equal `Value` |
| `inlist` | the field's value is in the `Value` list |
| `notinlist` | the field's value is not in the `Value` list |
| `prefix` | the field's value starts with `Value` |
| `notprefix` | the field's value does not start with `Value` |
| `includedinlist` | the value from `Value` is in the value list of the product data field |
| `notincludedinlist` | the value from `Value` is not in this value list |
| `matchsimplewildcard` | the field's value matches `Value` with wildcards |
| `notmatchsimplewildcard` | it does not match |

For the two wildcard types, `?` stands for exactly one character in any position and `*` for any number of characters, but only at the end.

## InputCheck

Defines how the inputs in the address fields are checked. The section has three parts: the error messages, a default handling, and any number of check rules.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<InputCheck>
   <ErrorMessages>
      Default    = Bitte überprüfen Sie Ihre Eingabe in ~FieldName~ und versuchen Sie es erneut.
      emptyerror = Bitte füllen Sie das Feld ~FieldName~ aus.
   </ErrorMessages>

   <InputCheckDefaults>
      RemoveSigns = "$"
   </InputCheckDefaults>

   <+InputCheck>
      AddressField   = FirstName,LastName,Street1
      AddressType    = bill
      Type           = minlen
      Len            = 1
      ErrorMessageID = emptyerror
   </+InputCheck>
</InputCheck>
```

> [!WARNING]
>
> The parameter is called `AddressType`, with two d's and a capital T. The examples in the previous documentation consistently write it as `Adresstype`. This is not a case difference but a different name, and the shop system does not find it. A check with `Adresstype = bill` therefore applies to **both** addresses instead of only the billing address. The same applies to `Adressfield` in the parameter table of the old documentation; the correct name is `AddressField`.

### ErrorMessages

Each error message gets a freely assigned identifier. You assign this identifier to a check rule using `ErrorMessageID`.

The `Default` entry is the message used when a rule has no identifier or the specified identifier does not exist. In the message text, the local tag `FieldName` is replaced by the label of the affected field.

> [!NOTE]
>
> The section must be present exactly once. Always create `Default`, because an identifier that is not found silently falls back to it, and without `Default` the message stays empty.

### InputCheckDefaults

| Parameter | Purpose | Values |
| - | - | - |
| `RemoveSigns` | Characters that are removed from the input before each check. | string, optionally in quotation marks |

> [!NOTE]
>
> The default handling only applies to fields for which at least one check rule exists. If a field should only get the default handling without its content being checked, create a rule with `Type = nocheck` for it.

### The check rules

| Parameter | Purpose | Values |
| - | - | - |
| `AddressField` | Comma-separated list of fields. `*` applies to all fields. Required. | field names or `*` |
| `AddressType` | Which address the rule applies to. | `both`, `bill`, `delivery`, `inquiryCommonInput`. Default `both` |
| `Type` | Type of check. Required. | see the table below |
| `ErrorMessageID` | Identifier of the error message. | identifier. Default `Default` |
| `RemoveSigns` | Characters that are removed from the input for this check. | string |
| `Condition-UserType` | Restricts the rule to certain customer types. | comma-separated list of customer types |
| `InquiryOnly` | Restricts the rule to inquiry forms. | `yes`, `no`. Default `no` |
| `+Condition` | Condition under which the check takes place at all. Multiple conditions are combined with AND. | |

> [!NOTE]
>
> `inquiryCommonInput` as `AddressType`, `Condition-UserType`, and `InquiryOnly` are not included in the previous documentation. With `Condition-UserType`, you tie a check to the customer type, for example stricter required fields for business customers.

> [!WARNING]
>
> A `+InputCheck` block without `AddressField` and a block with an unknown `Type` are **silently skipped**. There is neither an error message nor a log entry. So always test a new rule in the shop, and do not assume that an error-free configuration file also contains an effective rule.

> [!NOTE]
>
> Up to 500 `+InputCheck` blocks are possible. The shop system stops at the first failed check for a field, so the buyer only ever sees one error per field.

### Values for Type

| Value | Checks |
| - | - |
| `num` | only digits from 0 to 9 |
| `alpha` | only letters a to z and A to Z |
| `alphanum` | only letters and digits |
| `phone` | a phone number. A leading `+` becomes `00`, and all characters except digits are removed. `+49-(0)911/2013 63 221-0` becomes `004909112013632210` |
| `date` | a valid date, including leap years. Requires `DateFormat`, `Delimiter`, and `FormatLeadingZero` |
| `email` | a valid email address |
| `zip` | a valid postal code, depending on the country |
| `taxid` | a valid VAT identification number, depending on the country |
| `regex` | a regular expression |
| `legalsigns` | only the characters specified in `Signs` |
| `illegalsigns` | none of the characters specified in `Signs` |
| `minlen` | at least the length specified in `Len` |
| `maxlen` | at most the length specified in `Len` |
| `idcheck` | a valid ID card number |
| `agecheck` | an ID card number of a person of legal age |
| `passportcheck` | a valid passport number |
| `agecheckpassport` | a passport number of a person of legal age |
| `nocheck` | nothing. The characters from `RemoveSigns` are still removed |

> [!NOTE]
>
> `regex`, `passportcheck`, and `agecheckpassport` are not included in the previous documentation, but the shop system evaluates them.

> [!NOTE]
>
> The `zip` and `taxid` checks depend on the country of the respective address. If no country is selected, the shop system checks against Germany.

### Additional parameters per check type

| Parameter | Required for | Purpose |
| - | - | - |
| `Len` | `minlen`, `maxlen` | the checked length |
| `Signs` | `legalsigns`, `illegalsigns` | the affected characters |
| `RegEx` | `regex` | the regular expression |
| `DateFormat` | `date` | Order as a three-character string of `D`, `M`, and `Y`. Default `DMY` |
| `Delimiter` | `date` | Separator between day, month, and year. Default `.` |
| `FormatLeadingZero` | `date` | Converts `02.4.1996` to `02.04.1996` instead of `2.4.1996`. Default `no` |

Two abbreviations are available for `Signs`: `$ALPHA` for all letters of the ASCII character set and `$NUM` for all digits.

> [!WARNING]
>
> `$ALPHA` does **not** include umlauts or the hyphen. A check with `Signs = "$ALPHA"` on a name field therefore rejects every Müller and every Meier-Schmidt. Explicitly allow the characters you need, for example with `"$ALPHAß- äÄüÜöÖ"`.

> [!NOTE]
>
> In `RemoveSigns` and `Signs`, you can specify characters outside ISO-8859-1 using their hex value, written as `0x` followed by two characters. The bullet point, for example, becomes `0x95`.

### A complete example

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<InputCheck>
   <ErrorMessages>
      Default      = ~FieldName~: Ungültige Eingabe
      emptyerror   = Bitte füllen Sie das Feld ~FieldName~ aus.
      toolongerror = Ihre Eingabe im Feld ~FieldName~ ist zu lang. Bitte kürzen Sie sie.
      street2error = ~FieldName~: Bitte geben Sie eine korrekte Hausnummer an
   </ErrorMessages>

   <InputCheckDefaults>
      RemoveSigns = "$"
   </InputCheckDefaults>

   <+InputCheck>
      AddressField   = Street2
      Type           = minlen
      Len            = 1
      ErrorMessageID = emptyerror
   </+InputCheck>

   <+InputCheck>
      AddressField   = Street2
      Type           = maxlen
      Len            = 10
      ErrorMessageID = toolongerror
   </+InputCheck>

   <+InputCheck>
      AddressField   = Street2
      Type           = legalsigns
      Signs          = "$ALPHA$NUM"
      RemoveSigns    = " "
      ErrorMessageID = street2error
   </+InputCheck>

   <+InputCheck>
      AddressField   = TaxID
      AddressType    = bill
      Type           = minlen
      Len            = 1
      ErrorMessageID = emptyerror
      <+Condition>
         Field = Company
         Type  = filled
      </+Condition>
   </+InputCheck>
</InputCheck>
```

> [!NOTE]
>
> You give a field multiple rules by creating multiple `+InputCheck` blocks for it. In the example, `Street2` is checked three times: for presence, for length, and for permitted characters, each with its own message.

Guide: Defining checks for address data

## GenericInputChecks

The same principle as `InputCheck`, but for the free fields at split item level instead of address fields. Each check gets an identifier that is used to assign it in `BasketProductOptions`.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<GenericInputChecks>
   <GenericInputCheckDefaults>
      RemoveSigns = "$§%"
   </GenericInputCheckDefaults>

   <+GenericInputCheck>
      ID           = kommission
      Type         = maxlen
      Len          = 20
      ErrorMessage = Die Kommission darf höchstens 20 Zeichen lang sein.
   </+GenericInputCheck>
</GenericInputChecks>
```

| Parameter | Purpose | Values |
| - | - | - |
| `ID` | Freely assigned identifier for the assignment in `BasketProductOptions` via `+UseGenericInputCheck`. | alphanumeric characters |
| `Type` | Type of check. | `alpha`, `alphanum`, `num`, `regex`, `legalsigns`, `illegalsigns`, `minlen`, `maxlen`, `nocheck`, `inlist`, `notinlist` |
| `ErrorMessage` | Error message for this check. | text |
| `RemoveSigns` | Characters that are removed before the check. | string in quotation marks |
| `Len` | Length, only for `minlen` and `maxlen`. | number |
| `List` | Value list, only for `inlist` and `notinlist`. | comma-separated list |
| `RegEx` | Regular expression, only for `regex`. | |
| `Signs` | Characters, only for `legalsigns` and `illegalsigns`. | |

> [!NOTE]
>
> Unlike `InputCheck`, the error message is part of the check itself and not in a separate message section. So there are no message identifiers here and no fallback to a default message.

> [!NOTE]
>
> The previous documentation once writes `notinlinst` among the values for `Type`. The correct value is `notinlist`.

Guide: Free fields at split item level. Reference: BasketProductOptions section

## DeliveryAddressSelection

Contains the texts for the delivery address selection list in the checkout process.

```ini theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<DeliveryAddressSelection>
   NoDeliveryAddress             = Keine abweichende Lieferadresse verwenden
   WishlistDeliveryAddressPrefix = Wunschlistenadresse verwenden: Lieferung an
   DeliveryAddressPrefix         = Gespeicherte Lieferadresse:
   Separator                     = -----------
</DeliveryAddressSelection>
```

| Parameter | Appears |
| - | - |
| `NoDeliveryAddress` | as the entry for "no alternative delivery address" |
| `WishlistDeliveryAddressPrefix` | before a wish list address, if available |
| `DeliveryAddressPrefix` | before a saved delivery address, if available |
| `Separator` | as a separator line between the first two entries and the saved addresses |

> [!NOTE]
>
> `Separator` only appears if the parameter is filled. Without it, all entries are listed one below the other without visual separation.

Reference: Tags for multiple addresses


## Related topics

- [Order process, addresses and checks](https://dokumentation.websale.de/en/v8s/referenz/tags/ws/bestellprozess-adressen-und-pruefungen.md)
- [Validation and checking services](https://dokumentation.websale.de/en/konfiguration/validierungs-und-prufservices.md)
- [A- (Billing address)](https://dokumentation.websale.de/en/v8s/referenz/tags/a-rechnungsadresse.md)
- [D- (Delivery address)](https://dokumentation.websale.de/en/v8s/referenz/tags/d-lieferadresse.md)
- [CHECK- (URL and cookie data)](https://dokumentation.websale.de/en/v8s/referenz/tags/check.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.