How it works...

This recipe is closely linked to the next two recipes, and some explanation is required as to how we know which tables to modify. To keep this information in one place, this explanation is in the There's more... section of the How to customize a document layout without an over-layer recipe.

When an extension is created, an artifact is created that contains the changes to the element being extended. This is true of all extensions. There is no copying from layer to layer; it is a reference and a list of changes.

The actual source of the table extension is shown in the following piece of code:

<?xml version="1.0" encoding="utf-8"?>
<AxTableExtension xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Name>SalesConfirmHeaderTmp.ConVMSSalesReports</Name>
  <FieldGroupExtensions />
  <FieldGroups />
  <FieldModifications />
  <Fields>
    <AxTableField xmlns=""
      i:type="AxTableFieldString">
      <Name>ConVMSSalesReportsSalesPoolName</Name>
      <ExtendedDataType>Name</ExtendedDataType>
      <Label>@SYS84547</Label>
    </AxTableField>
  </Fields>
  <Indexes />
  <Mappings />
  <PropertyModifications />
  <Relations />
</AxTableExtension>

When the project is built and the database synchronization is done, the SalesConfirmHeaderTmp physical table will have the base fields plus the fields in all of its extensions. This is why the field name needs to be prefixed. Adding VMS as part of the prefix for the project and project elements is interesting. ConSalesReports would be enough for a customer-specific implementation developed by the customer or partner. If we are delivering a vertical then we should use VMS as well to separate it from other solutions we may write. We can, therefore, have two sales order confirmations, and the decision as to which gets used will be done by configuring the print management.