Basware XML data format reference
Data file formats for file-based integrations
Basware XML data formats
This page describes the XML structures for Basware XML data file formats. This is Basware's default file format for file based integrations. These file formats reflect the default P2P tenant configuration. The expected encoding of these files is UTF-8.
Please expand sections below to browse the XML file formats for each interface.
Importing Master Data
Accounts
Assets
Coding dimensions (profit centers, customers, etc.)
Coding dimension lists AccList1 - AccList20
Download XML | Download Schema | View full screen
Coding dimension lists AccList21 - AccList30
Download XML | Download Schema | View full screen
Coding dimension lists AccList31 - AccList35
Download XML | Download Schema | View full screen
Cost centers
Exchange rates
Header dimensions
Custom lists InvList1 - InvList10
Download XML | Download Schema | View full scre
Custom lists InvList11 - InvList20
Download XML | Download Schema | View full screen
Payment block
Payment method
Payment terms
Download XML | Download Schema | View full screen
Available values for end of month calculations in fields Due_Date_Eom, Cash_Due_Date_Eom:
- 0 = No action
- 1 = Moves the due date to the last day of the invoice date's month
- 2 = Moves the due date to the last day of the following month
- 3 = Moves the due date to the last day of the following month + 1 (and so on)
Projects
States
Suppliers
Download XML | Download Schema | View full screen
Validations
- Company Code
- Supplier with valid organization code is imported. Suppliers with invalid organization code are imported on ROOT level.
- Supplier Code
- Unique for a supplier on organization. Code can be duplicate but on different organization.
- Other Codes
- Invalid codes are skipped (currency code, payment term code, deliveryterm code, supplier address, address part)
- Bank Accounts:
- At least one Bank account should be marked as 'IsDefault' for a supplier.
- Bank Account Number / IBAN
- Can be left blank but if Bank account is mandatory then either of BBAN/IBAN should be filled.
- Bban cannot be duplicate for a supplier.
- Space is allowed in Bban.
- Bank Account Name:
- Can be left blank but if Bank name is set as mandatory then bank name is necessary.
- Can be duplicate for a supplier.
- Space is allowed in Bank name.
- Note: Bank name and bank account mandatoryness can be set in the Admin, Organization structure for each administrative site separately.
- Identifiers:
- Finland = y-tunnus, UK = Vat reg. code or Company House Number, US = DUN’s / TIN number. This is used for identifying the supplier during the Scan and Capture phase.
- If the business ID is visible in the invoice image, it is used to identify the supplier in validation phase.
- For DUNS:
- 9 digits are allowed.
- Duplicate values are not allowed for same organization.
- Space should not be allowed.
- DUNS code can be duplicate for duplicate supplier on diff organization
- For Australian Business Number:
- 11 digits are allowed.
- Duplicate values are not allowed for same organization.
- Space should not be allowed.
- DUNS code can be duplicate for duplicate supplier on diff organization.
- Language and country codes:
- IETF language tag. An IETF best practice, currently specified by RFC 5646 and RFC 4647, for language tags easy to parse by computer. The tag system is extensible to region, dialect, and private designations.
- Example: en-US – English as used in the United States (US is the ISO 3166-1 country code for the United States)
Invalid suppliers are skipped from the import process.
Tax codes
Unit of measure (UOM)
Work orders
Importing orders (matching orders)
Standard, Framework and Return purchase orders
Download XML | Download Schema | View full screen
s;
Important fields
- Header: OrderNumber, CurrencyCode, OrganizationElementCode, CompanyCode, MainSupplierCode, NetSum, SourceSystem. Use the SourceSystem field to indicate source ERP system.
- Row: OrderNumber, RowIndex, Quantity, NetPrice, NetSum, UnitCode, GoodsReceiptRequired, GoodsReceiptsBasedInvoicing
(if GoodsReceiptRequired = 1, then a goods receipt line is required for matching but many goods receipt lines are combined when matching is done. If also GoodsReceiptBasedInvoicing =1, then matching must be done against a goods receipt) - CodingRow: OrderNumber, OrderRowNumber, RowIndex
- GR: OrderNumber, OrderRowNumber, GoodsReceiptNumber, GoodsReceiptRowNumber, Quantity, NetPrice, NetSum
- ServiceEntrySheet: ServiceEntrySheetNumber, OrderNumber, OrderRowNumber Accepted, NetValue
- ServiceEntrySheet CodingRow: OrderNumber, ServiceEntrySheetNumber, OrderRowNumber, RowIndex, NetSum
Unique keys (used to identify data on updates):
- Order header <Order>: OrderNumber + POSourceSystem + OrganizationElementCode + CompanyCode -combination
- Order row <OrderRow>: OrderNumber + RowIndex combination
- GoodsReceipt <GoodsReceipt>: GoodsReceiptNumber + GoodsReceiptRowNumber combination
Validations:
- Order header:
- If ValidTo and ValidFrom have a value then ValidTo needs to be equal or greater than ValidFrom
- If MatchingMode is Return (integer value: 2) then sum needs to be 0 or a negative value
- At least one OrderRow must exist
- InvoicedNetSum and InvoicedGrossSum cannot be changed after the order has been matched in Alusta
- Order row:
- At least one CodingRow must exist
- If MatchingMode is Framework PO (integer value: 1) then GoodsReceiptRequired needs to be null or false
- If MatchingMode is Return PO (integer value: 2) then sum needs to be 0 or a negative value
- If MatchingMode is Service PO (integer value: 2) and the order has been matched without ServiceEntrySheets then the order row cannot be updated anymore
- GoodsReceiptRequired and GoodsReceiptsBasedInvoicing cannot be changed after the order has been matched in Alusta
- InvoicedNetSum, InvoicedGrossSum and InvoicedQuantity cannot be changed after the order has been matched in Alusta
- Goods Receipt:
- Quantity must be either less or greater than zero
- If ReferenceDocId and ReferenceDocItemId have a value and ReferenceDocId is not equal to GoodsReceiptNumber or ReferenceDocItemId is not equal to GoodsReceiptRowNumber then a parent GoodsReceipt needs to be found with ReferenceDocId, ReferenceDocItemId and FiscalYear values (GR return or cancel)
- InvoicedNetSum, InvoicedGrossSum and InvoicedQuantity cannot be changed after the order has been matched in Alusta
- Order size limitations can be found from OM2_MATCHING_LIMITS table
Note: Most date and datetime fields do not allow empty values if the element is sent. There are two ways to handle empty date values: 1) Not sending the element containing empty date, 2) sending value '0001-01-01' (for dates) or '0001-01-01T00:00:00' (for datetimes) - these get saved to DB as null values.
Service purchase orders
Service orders are a subtype of orders which have an additional data structure. See section "Standard, Framework and Return purchase orders" for general notes on importing orders.
Notes on using service orders:
- Before services are received, import order with <OrderRow> - this gets the order into P2P so it can wait for goods receipts. At this stage, data on <OrderRow> is visible in P2P UI.
- After services are received (<ServiceEntrySheet> is sent under <OrderRow>), the data on the order row shown in P2P is overwritten with data from the <ServiceEntrySheet>(s).
- <CodingRow>(s) on the <ServiceEntrySheet>(s) correspond to <GoodsReceipt>(s) on standard POs. <GoodsReceipt> -block is not used on service POs.
Download XML | Download Schema | View full screen
Transferring invoices
Prebook invoice (P2P -> ERP)
Transfer and prebook share the same message schema. The operation performed on the invoice is indicated in the field 'Method'.
Download XML | Download Schema | View full screen
Prebook response (P2P <- ERP)
Reverse prebook (P2P -> ERP)
Transfer invoice (P2P -> ERP)
Transfer and prebook share the same message schema. The operation performed on the invoice is indicated in the field 'Method'.
Download XML | Download Schema | View full screen
Transfer response (P2P <- ERP)
Payment response (P2P <- ERP)
Procurement integration
Budgets (import)
Contracts (import)
Purchase requisitions (import)
Purchase requisitions (export)
Purchase orders (import)
Purchase orders (export)
Purchase goods receipts (import)
Self approve permissions (import)
Importing users
Users
Advanced permissions