Table of Contents
- Waiting for release
- Example use cases
The Transfer module is a generic module for exchanging transaction data. Outgoing* data is sent from xentral to the target system or made available for retrieval. Incoming* data is fetched, read in and processed further.
* The direction of this description refers to the perspective of xentral.
- Outgoing → Outgoing data is stored in the FTP directory, for example, to be retrieved from there.
- Incoming → Incoming data is copied to the folder from outside and regularly read in by xentral and interpreted or e.g. converted to jobs.
This module is especially relevant if a system is or will be connected to xentral.
The standard version of the module already provides a variety of options for connecting to shipping or fulfillment service providers. Typically, orders are sent to the fulfiller and shipping information is returned to xentral. However, the system can also be used, for example, to transfer inventory data (stock figures), to transfer products or to provide documents such as orders, delivery bills or invoices as PDFs.
The following technical transfer types (type) are available in the standard:
- FTPS (username and password, no certificates)
- Local storage on server
The following transmission formats are available in the standard:
- XML with integrated PDF (Base64-encoded)
- XML and PDF in separate files
- CSV (Comma Separated Values, simplified Excel format)
Additional transfer modules can be used to configure further interfaces and transfer formats:
- AmazonMfn (Amazon MFN - Merchant Fulfillment Network).
- AmazonVendor (Amazon Vendors)
- App4Sales (Offline order entry for field staff)
- Brickfox (Portal for connecting multiple services)
- DS (DS Logistics)
- EDI (Electronic Data Interchange)
- EDI (Sport 2000)
- GobNavConnect (Microsoft Navision in cooperation with GOB)
- OpenTrans (XML format)
- Pixi (Descartes Pixi WMS)
- Smarty (template generator for any text format)
The Monitor tab lists all successful and faulty transmissions of the module as a filterable and searchable list. You can filter according to errors or message types (e.g. stock, tracking, article, order, purchase order). In addition, the account and thus the remote station can be filtered in the list.
Waiting for release
If data is to be processed by configuration in two steps, e.g. because in the introductory phase of an interface this was set to manual release required, the messages to be transmitted appear in the Waiting for release tab and can be released there.
All created accounts are listed in the Accounts tab.
Based on an API account (see below), any number of accounts can be defined for transfer to an external system. In many cases it can be useful to distribute the transmissions to several accounts, e.g. to be able to test and monitor them better, but also if different intervals are to be used. One account can configure outgoing and incoming messages. In more complex environments it may make sense to split this into two or more accounts.
Before setting up one or more accounts, an API must be created. Even though in many cases this does not require a URL or access data for the transfer module, it is necessary in order to define the remote station. It is advisable to create at least one API account per remote station and to use it only once with regard to message type and direction.
API account management is not part of the transfer module and can be done in the Administration → Settings → System → API Account area.
In the API Account view, you can create a new API account or edit an existing one.
For example, an XML account only needs to be created and activated in context of the Transfer module; usually, no further settings are needed.
Create new account
A new transmission can be created using the "+New" button. You can specify the transmission settings in the following sections of the view:
- active → selection, if the transmission is used. If not selected, it is deactivated
- Designation → Name of the transmission, can be freely assigned
- API → Selection of an API account
- Transmission format → The transmission format refers to the format of the file content. In most cases, these are text files that contain structured data (such as CSV or XML) in order to be easily read and interpreted on the other side as well. In case of doubt and if there is flexibility on the other side, always choose the standard formats in xentral: XML (xentral standard format), PDF (non-structured data e.g. for backup purposes or for document-based further processing), XML with integrated PDF (Base64-encoded), XML and PDF in separate files, CSV (xentral standard format, Comma Separated Values, simplified Excel format) and API. Additional transfer modules can be used to configure other interfaces and transfer formats: AmazonMfn (Amazon MFN Merchant Fulfillment Network), AmazonVendor (Amazon Vendors), App4Sales (offline order entry for field staff), Brickfox (portal for connecting multiple services), DS (DS Logistics), EDI (Electronic Data Interchange), EDI (Sport 2000), Gob NavConnect, Netstock, OpenTrans (XML format), Pixi (Descartes Pixi WMS), Smarty (template generator for any text formats). The description of the formats and further notes can be found in the respective modules. Please change the transmission format of an account first and then go to the help page in the module.
- Type → The following technical transfer types (type) are available in the standard: FTP, FTPS (username and password, no certificates), SFTP, Email, Local storage on server, API.
- Encoding (send) → selection in which encoding the transmission should be sent (UTF-8, ISO-8859-1, ISO-8859-15, Windows-1252, CP1256).
- Server → Specify the server where the transmission should go.
- Port → port on the recipient server that will be addressed
- SSL → specify if the transmission should be encrypted with SSL
- Username → the user who is logged into xentral is pre-filled by xentral. However, this can be changed manually
- Password → password in xentral of the corresponding user
- OAuth Client ID → client ID from the service where the API is set up
- OAuth Client Secret → Client Secret from the service where the API is set up.
- OAuth URL → URL to which the permission to use the data from the service should be sent back to xentral
- Storage Location (Output) → Output of documents from xentral (Optional if xentral is used by fullfilment service providers. Output of "Other Actions" warehouse numbers and tracking numbers for slave xentral or ERP from customers).
- File name prefix → All file names with this prefix will be ignored.
- Response location (input) → Input for orders, warehouse, tracking, items, etc.
- Response file name prefix → All response file names with this prefix will be ignored.
- Delete from server after download → These files will be deleted from the server after download.
- Document type → Available documents for transmission are: Order, Invoice, Credit bill, Quotation, Delivery bill, Purchase order, Return, Liability, Goods receipt QA report. Alternatively, e.g. if only the transfer of stock values is desired, "no documents" can be selected.
- Document status → Indication whether the status is created, released, sent or completed.
- Project → Assignment of the transmission to a project
- Address → Address to which the document is to be sent.
- Group → Indication to which group the address belongs.
- Manual release required → Specification that documents are first released manually
- Start from ID → Select invoice ID from which the transfer is to start
- Start from date → date from which the transfer should start
- Labels → Select self-defined labels that will be assigned to the transmission. The overview can then be filtered by these labels. Please note that if several labels are assigned, all of them must be filtered so that they appear in the overview.
- Stationery in XML → Select that the stationery is stored base64encoded in XML.
- Maximum simultaneous transmissions → Number of documents that the process starter transmits simultaneously. The default value entered here is "0". Entered values <1 mean in this case that the described default of 10 is used. Therefore, the entry "0" means that a maximum of 10 documents are transmitted per interval of the process starter.
- Each document in its own XML → Selection that each document is stored in its own XML. We recommend you to enable this option
- XML addition → Specification of the XML addition.
- Tracking Mail → Specification that a tracking mail will be sent.
- Invoice Mail → Specify that the invoice email will be sent automatically when the tracking number is reported back by the fulfiller. If there are multiple tracking numbers, the invoice email will only be sent once. The requirements for this are that the check mark in the Transmissions module for "Invoice Mail" is set, the invoice already exists with the customer email addresses and customer names, and that the invoice amount is greater than 0
- Create invoice → Select that if the delivery bill or tracking number is reported back and the matching invoice is still missing, an invoice will be created automatically.
- Transfer file as attachment → Select that the file will be transferred as an attachment.
- Transfer attachment as → Select how the attachment should be transferred (as a separate file or Base64-encoded in the document).
- Receive orders/quotations → Specify that orders or quotations are to be received.
- Transfer customer number from external system → Specify that the customer number is to be transferred from the external system.
- Receive orders → Specify that orders are to be received.
- Create production instead of order → Specify that a production is to be created instead of an order.
- Own address → Selection of own address. This must have been created previously under Master data → Addresses.
- Receive stock figures → Selection that the stock figures are to be received.
- Ignore storage bin in file receipt → Specify that the storage bin in the file receipt is to be ignored.
- Warehouse → Storage bin for confirmations without storage bin specification
- Receive tracking → Indication that tracking is to be received
- Automatic feedback → Independent of delivery bills and tracking numbers, an order will be finalized after X days at the latest and possibly reported back to stores and marketplaces. Only orders that were sent by transmission module max. 14 days ago will be considered.
- Receive articles Not found articles → Indication that if articles are received but not found, an error is displayed in the transmission monitor.
- Search supplier number as well → Specify that supplier numbers should be searched as well.
- Always post order to supplier → Specify that an order is always posted to the supplier.
- Create missing articles → Specify that missing articles from order items should be created automatically.
- Mark missing items as stock items → Specify that missing items are to be marked as stock items.
With this overview it is possible in principle to import articles or to perform an update on the articles:
- Receive articles (new articles) → Indication that article data will be taken into account when receiving.
- Update article → Indication that in case of deviations of article data from the master data the deviating information should be overwritten.
These actions are possible with XML and CSV formats. However, there are some variations with these formats, as both rely on presumably pre-existing methods.
- The fields must be named like the fields in the import template (module=importtemplate&action=formats)
- number, name_en, ean must be present in the CSV file
- New articles can be created
- To be able to create new articles, the following fields must be present: number, name_en, ean
- All other possible fields correspond to those of the import template under module=importtemplate&action=formats
If you use only "Receive products (new products)":
- If you only select "Update products":
- Updates of products are possible, the product number must remain the same, the rest can be changed
- But also new products will be created, so the checkbox "Receive products (new products)" is obsolete here.
- If "Receive products (new products)" and "Update products" is executed:
- Updates and create new works
- If only "Receive products (new products)" is executed:
- New products can be created
- To be able to create new products, the following fields must be available: create (e.g. with value 1), number, name_en
- All other possible fields correspond to those of the import template under module=importtemplate&action=formats
- If only "Update product" is executed:
- Updates of products are possible, the product number must remain the same, the rest can be changed
- When "Receive product (new products)" and "Update products" is executed:
- Updates of products are possible, but no new products can be created
- Warehouse numbers from xentral to external system → Specification that the warehouse numbers are to be transferred from xentral to the external system.
- Warehouse → Selection of the warehouse
- Storage location → Selection of the storage location
- Send "saleable" quantity → specification that the saleable (existing - reserved quantity) quantity is to be sent
- Transfer at → Specification of the time when the transfer is to take place.
- Send sales report → Specify that a sales report should be sent.
- Time range → Selection of whether the sales report is to be sent daily, weekly or monthly
- Tracking from xentral to external system → Specify that tracking from xentral to the external system should take place. Note: Currently, the tracking number from xentral to the external system can only be played out for the transfer format XML, but not for CSV.
- Transfer products → With this button products can be transferred to the external system.
- Automatically transfer new products → Specify that new products are automatically transferred to the external system.
Transfer modules Brickfox and Pixi
Using Brickfox and Pixi (Descartes Pixi WMS) as additional transfer modules, additional interfaces and transfer formats can be configured in xentral. First you have to change the transfer format of an account and then go to the help page in the module.
The Warehouse Management System (WMS) Pixi can be connected to xentral. In Pixi the movements in the warehouse and the order processing is more specific than in xentral. Pixi is able to synchronize articles as well as warehouse numbers to articles. If the stock of all actively usable articles is to be summarized in a warehouse, this specification is to be made in the overview "Receive documents". In doing so, all Pixi pick locations are bundled in the previously defined standard warehouse. It is the physical stock that is imported here, not the available stock, i.e. the physical stock minus the open orders.
After the order is imported from the store, it is processed in xentral. When the order is ready to be shipped, it is forwarded to Pixi. This feedback is done via the "Transmissions" module.
First, "Pixi" must be selected as the transmission format from the drop-down menu.
After that, in the "Other actions" overview, you can specify how the transfer should take place.
It is possible to transfer the products to the third-party system. Lock products are not transferred and it is also not possible to set project filters. This means that the articles are transferred regardless of the project.
In order to transfer products correctly, import orders, send confirmations, synchronize stock figures and transfer different document types correctly, the process starter "Transfer module (Fulfillment, Transfer, EDI, XML)" is used.
In contrast to Pixi, it is not possible to synchronize stock figures from Brickfox to xentral with Brickfox. Only the order import or the order pickup works. But it is possible to transfer item data, categories, manufacturer and tracking data from xentral to Brickfox.
For a Brickfox application the transfer format "Brickfox (Beta)" has to be selected from the drop-down menu.
Certain products synchronize only if the product is completely new and the transfer has been allowed. Only at the next run of the above mentioned process starter "Transfer module" the warehouse and the time of the article export will be transferred. Only if all defaults are fulfilled in the transfer module, the process starter can run through correctly.
Note: Duplicate imports may occur if the following conditions exist:
- The file name of an already read file is renamed on the server. This causes the file to be perceived as a new file
- Cleanup of log tables for transfer files is enabled (Basic Settings → Cleanup).
- Files are not deleted from the server after processing. This setting can be changed in the Transfers module for the account. The setting can be found under Details in the "Communication" section. For deletion, a check mark is set at "Delete from server after download".
It is a Transfer module as a part of the Transfers module. The Transfers module (CSV/XML/EDI/PDF) is required for operation.
The following synchronizations are possible:
- Stock numbers can be synchronized from xentral to Brickfox
- In Pixi product stocks can be imported into xentral
Note: These operations are one-dimensional, i.e. they only work in the direction specified here. A functionality in the other direction is not given.
This tab contains a list of all files to be transferred that have to be released manually. This works by selecting the corresponding transfers and then releasing them via the "Release" button.
In this tab the documents that should be transferred can be selected and then added to the list using the "Add order to transfer" button. During the next transfer, these documents will be added and move to the "Transfer" tab. The processing of the documents collected here is done via process starter and is limited to one number per run (limitation in the interface settings). Documents can be removed from the list using the "Delete requests" button.
This tab contains a list of all documents that have already been transferred. Among other things, the date and time of the transfer can be taken from the list. The files can be deleted on the server. The transfer history is also saved and logged.
The transferred XML files are located in this tab. Even if the files are deleted on the server, the history is displayed here.
If the tracking option was selected under the "Details" tab, all tracking data will be listed here. This means that all returned tracking numbers are displayed. Transferred documents without tracking numbers can be viewed in the "Transferred" tab.
If the bearing number option has been selected under the "Details" tab, all returned bearing numbers will be listed here.
If the "Receive items Not found" option was selected under the "Details" tab, all errors will appear listed in the "Errors" tab. This therefore corresponds to an error log of all unprocessed data. If a tracking number cannot be assigned to the matching document, an entry is created here in the error log. If there is still no tracking number for a document, you can check the error log to see if there was an incorrect response. If there are no entries, the tracking number was not reported back.
If the "Send sales report" option is selected under the "Details" tab, all the created sales reports will appear listed in the "Sales report" tab.
Example use cases
Use case: Transfer of products to third-party system
If you want to transfer new products to a third party system you have to check the box "Automatically transfer new articles:" in the Transfers module.
It should be noted that this does not apply to modified products. If you want to transfer changed products, click on the button "Transfer products to external system". This way all products, including the changed products, will be transferred again.
Use case: Connection to fulfillment service provider
The connection to a fulfillment service provider enables, among other things, the transfer of XML structures or CSV files to a fulfillment service provider and, subsequently, the import of data reported back by the fulfillment service provider, e.g. tracking numbers, stock levels, best-before dates, etc. The interface also enables the import of new customer orders, e.g. from an external software/order platform (e.g. EBISS). The interface also enables the import of new customer orders, e.g. from an external software/order platform (e.g. EBISS). In general, it is possible to store data as a file on a server. This data is then fetched and processed by the Fulfiller. The Fulfiller then reports back to the server, e.g. 1x daily (at night), the tracking numbers, updated stock levels and e.g. also MHDs. This data is read in by xentral via a cronjob and updated in the system. A feedback to stores for stock updates or the tracking number to the store, as a simultaneous trigger for an invoice email, are possible in parallel.
Note: The deactivation of the automatic feedback to the online store must be used in connection with the "Transmissions" module (fulfillment connection), otherwise orders will always be reported without tracking number. If the orders are to be reported with a tracking number, the "Deactivate automatic feedback" box must be checked.
The further processing of the data and the storage of the feedback file for xentral with the necessary fields is usually defined and created by the fulfiller. The following flowchart shows the basic interaction between xentral, an online store / marketplace and a shipping service provider / fulfiller.
Use case: Connection of an external platform
The interface also enables the import of new customer orders, e.g. from an external software/order platform (e.g. e.biss or App4Sales). Required master data (products or customer names) are synchronized in both systems. Order entry can also take place offline, for example.
Use case: Connection to Netstock
xentral communicates with Netstock through two different channels. The outgoing data (especially orders and stock) is played out to Netstock via the Netstock App. The incoming data (orders or productions) is processed via the Transfer module with the Netstock transfer module. Please note that the transfer module is therefore required to use the network interface.
Setup transfer module Netstock
In order to process incoming orders in xentral, an API account is first assigned to the transfer module. The access data is provided by Netstock. Then the data exchange channel is set up.
- If the data exchange is done via FTP, the access data is entered first. These access data (server name, port, user name and password) are provided by Netstock. If necessary, a prefix for the file name (po_) has to be entered.
- Alternatively, the data can also be exchanged via a local server folder (e.g. /from_netstock). For this purpose, only the local input folder is entered in the transfer module. It may be necessary to specify a prefix for the file name (po_). Transfer via a local input folder is not possible on Xentral Cloud instances; in this case, data exchange via FTP is preferable.
Subsequently, further settings for receiving or correct processing have to be made:
Take over customer number from external system
Takes over the supplier number and thus determines the correct supplier
Please activate this option to receive purchase orders
Create production instead of purchase order
Instead of purchase orders, productions are created. For this purpose, the address specified under "Own address" is used for the created production order.
Selection of own address as address for production orders.
Note: Orders are imported in the "created" (draft) status and vendor number and item number must be known.
Transfer documents from xentral (output)
Settings of the outgoing XML or CSV data. To enable the transfer of an XML or CSV file from xentral to the outside, the process starter "api_uebertragungen" must first be created and activated under Administration → Settings → System → Process starter.
The next step is to create an API_Account. To do this, create a new account under Administration → Settings → System → API Account via "+NEW", which can be filled out as follows (it is important here that the Active check mark is set):
In the next step, a new transmission can be set up in the Appstore under Transmissions (EDI/XML/CSV/PDF). In the following example, an XML transmission for invoices via email is to be created.
Under API the set up account can be deposited. Under XML addition, the outgoing XML file can be extended with customer-specific additional specifications. Under Start from ID, the invoice ID can be selected from which the transfer is to start. In order to test whether the transmission has been set up successfully, the process starter and the transmission can be activated and the last invoice ID and the associated status can be entered and saved. After the set interval has expired, an email with the XML file should be delivered.
Connection to a fulfillment service provider
An online store is operated that is already connected to xentral. Now the entire shipping process is to be handled by a fulfillment service provider. The service provider receives the delivery bill information from xentral and reports back a tracking number and the stock deduction. To receive this feedback, a transmission must be set up. There are four ways to send the data to the service provider:
- FTPS (only with username + password, not when using certificates)
- Local directory on xentral server
In addition, the desired transfer format can be selected in the drop-down list.
The data can also be transferred via the module as a CSV file in addition to an XML file.
Under "+New" a transfer to the fulfillment service provider can now be created. The type of transfer and the data format can also be defined there.
In the Communication area, the FTP account with the incoming and outgoing folders can then be stored and a decision can be made as to whether the files stored by the reporting office (e.g. tracking) should be deleted from the server after the download. In the Send vouchers section, all settings for outgoing files can be made. In the outbox, the document type, the status and/or a document ID or a date from which the transfer should take place must be specified. In addition, it can be specified which email notifications are to be sent to the address.
If files are to be transferred to the fulfillment service provider (PDF file from the delivery bill or other attachments), the following option must also be activated: "Transfer file attachment" (Accounts tab).
In the "Receive documents" area, you can define which documents are to be received by the system. In addition, it is also possible in this area to receive warehouse figures from external systems and to map these to a specific warehouse in xentral. In addition, the receiving of tracking messages in response to the transmitted delivery bill and of articles from external systems can be activated here.
In the area Stock numbers the transfer of the stock numbers to an external system can be configured. If no warehouse or shelf has been selected here, the complete stock of the system can be transferred to the external system. If there is an entry for warehouse or storage location, the transfer will be restricted accordingly. In addition, different times can be defined at which the transfer is to take place.
Note: The API account for the "API" field is created under Administration → Settings → System → API Account.
To retrieve the fulfillment service provider's feedback from the FTP server, a new cronjob must be created via Administration → Settings → System → Process starter. This fetches the returned deliveries at a defined time interval and plays them into xentral. More information on how to set up the cronjob can be found here. If the deliveries are successfully reported back, the list of transfers fills up.