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.Company is not enabled because nothing follows the equals sign. The field cannot be placed in the template.
Name and salutation
Address
Contact details
Other fields
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.
You do not define fields that the buyer may not change here, but in the
AddressFields-ReadOnly section.DeliveryAddressFields-Txt
The same for the alternative delivery address. The fields correspond to those of the billing address, with three exceptions.
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.AddressFields-Txt. The default is 45 characters, and 12 for postal codes.
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.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.
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.D-Suffix1 to D-Suffix50
The same for the suffix fields of the delivery address. Structure and parameters are identical.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.AddressFields-Standards and DeliveryAddressFields-Standards
Defines which entry a selection list is preset to when the buyer sees the page for the first time.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.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.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 fromAddressFields-InputVisibility and AddressFields-AlternativeText only take effect on the next page change, not immediately after the input.
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.
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.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.
The parameters within
+Condition are the same as for AddressFields-InputVisibility and are described in the Conditions section further below.
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.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.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.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 filledConditions in +Condition
The+Condition subsections have the same structure in AddressFields-AlternativeText, AddressFields-InputVisibility, and InputCheck.
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.ErrorMessages
Each error message gets a freely assigned identifier. You assign this identifier to a check rule usingErrorMessageID.
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.
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
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
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.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
regex, passportcheck, and agecheckpassport are not included in the previous documentation, but the shop system evaluates them.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
Two abbreviations are available for
Signs: $ALPHA for all letters of the ASCII character set and $NUM for all digits.
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
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.GenericInputChecks
The same principle asInputCheck, 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.
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.The previous documentation once writes
notinlinst among the values for Type. The correct value is notinlist.DeliveryAddressSelection
Contains the texts for the delivery address selection list in the checkout process.Separator only appears if the parameter is filled. Without it, all entries are listed one below the other without visual separation.