Document views decide which columns and labels the storefront shows for ERP documents. The configuration drives an ERP document card's header, on screen and in the PDF and XLSX downloads, the same way it drives the card's item table. Because this is configuration, each client can choose its own header fields, for example agent name and comments on one shop and only dates on another, without a storefront code change.

A document view controls presentation only, and the values it presents come from the ERP through a data mapping.

A column's value travels through a chain of configuration: an ERP query fetches the field, a data mapping line binds it to a destination property, and a document view column displays that property. The name a mapping line binds a field to identifies where the value lands in DigiTrade, and it is separate from the name the ERP uses for that field. A column can only show a field that a data mapping line already provides, so a field that is missing from the column choices usually means the mapping is incomplete. A mapping line can target a destination property name that the model does not already define, so adding a new document field no longer needs a development change for each field.

Once you configure a view, the card header shows only the columns you add, each placed by its position, titled by its label and formatted by its type. To reorder the header, change the columns' positions, and to drop a field from it, hide that column. Each translation applies only to its own language, so adjusting the Hebrew label leaves what English-language shoppers see unchanged. Pick each column's type for how the value should read: status values render as a chip, dates follow the shop's date format, and money amounts are shown as prices. Downloads match the screen: a shopper's PDF or XLSX file lists the header fields with the card's labels and ordering. Once a lines view is configured, the item table in each download uses that view's columns as well.

The document number and the status are not header fields; the card shows them in its own title strip. On a configured card, each appears only when the view includes a matching column and never repeats among the header fields, so leaving that column out removes the number or status from the card. The customer identifier that the standard header shows is not available to configured views, so it disappears when you switch a family to a configured layout.

Where no view is configured for a document family, the card and both downloads keep their standard layouts. A newly created view has no effect until you add columns to it, so the storefront keeps its standard layout in the meantime. The storefront switches to the configured layout only for a view that an admin configured, and a view the system derives automatically from mapping lines does not trigger the switch. This makes the change opt-in for each client and each document family, so you can configure one family without affecting the others.

Every ERP document family, including orders, invoices, deliveries and returns, uses the same header and item rendering, but each family needs its own document view. In Site Builder, the header block and the item lines block each pick their own source, so a page can read its header and its lines from different views. Reservation orders have little header data to configure, because their ERP data is organized around item lines rather than a header.

When the raw ERP value is not what shoppers should read, you can attach conditional rules to a column and put them in order. Typical uses are translating an ERP code into words a shopper understands and showing a different column's value when the one you bound has nothing in it.

Prefer column rules to value replacement in the data mapping when only this view should change, because a replacement defined on the mapping affects everything that reads from it. A mapping-level replacement also returns an empty value for any code you did not list, which makes a newly introduced ERP code vanish from the display.

You create and maintain views on the Document Views screen, and each view's record includes a Columns table that holds the view's columns. On a view's record, Source tells you whether the view came from a sync as a default or was overridden by an admin. View key names the live ERP function that the view presents, and it stays empty when the view is backed by a model.