> For the complete documentation index, see [llms.txt](https://kb.bevica.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.bevica.com/documentation/integration/bevica_website_integration/web_integration_-_sales_orders.md). # Web Integration - Sales Orders Import website orders and post them in Business Central. ### Web Orders The design of the integration of Sales Orders is through staging tables, rather than the website placing orders directly into the standard Sales tables. Primarily this is for performance and flexibility as writing directly to standard tables can be technically challenging. The broad process is: 1. Web Order Staging Table 2. Data Validation 3. Process Web Order into a Bevica Sales Order There is flexibility on the setup to allow for bespoke validation and processing. The Validation and Processing functions are usually run on a **Job Queue** as frequently as required. ### Web Order Staging Table This is broadly structured as: * Web Order Header * Web Order Lines Many of the standard order fields are present, as are specific ones to manage the integration. There is minimal data validation when this table is written to, except for data type and field length, to minimise errors. You can review web orders from the **Web Orders List.** ### Currencies If the ‘Default Currency Code’ has been set on the **Web Orders Setup** then this will apply to orders. A blank value in here means it will be in the system LCY. The Currency Code applied to Sales Orders comes from the **Web Order** ‘Currency Code’ value and *not* from the Customer default. As an example, if the Customer ‘Currency Code’ was set to USD but the Web Order has no ‘Currency Code’ value, the order will be in LCY. For the order to be in USD the Web Order must provide the ‘Currency Code’ on the Web Order. All prices or amount values should then be in the currency value. ### Data Validation Broadly the following occurs: * Data Types are checked * Records are matched (e.g. items, customers, location etc.) * Decode Web Items if required * Item Units of Measure are checked * Create Customers (dependent on setup) Any errors at validation are captured and updated on the Web Order Header, and also the Lines. ### Manual Edits By design the Web Order Card is editable, where appropriate permissions are given to the user. This allows for errors to be corrected by a user in Business Central and a Sales Order to be created from the Web Order. For example, if a unit of measure had been submitted incorrectly a user can correct the value on the Web Order to allow it to be converted. This should only ever be for expedience and data should be corrected in the web site as required. ### Line Actions On the **Web Order Lines** a user can set a line to be ‘skipped’ if it is preventing the order from being completed. This will set the validation and processing of this line to be ignored. ![Image](https://2932934759-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfUgpGDVvyqBWVvwVIy9a%2Fuploads%2Fgit-blob-1ce38a30d3231976ff1629a3d17860977f54b469%2FstzKY_8wB0JrPkEz24DHS7vJ1p8VTlgfrg.png?alt=media) Again, this is for expedience and data should be corrected between the website and Business Central. ### Process Web Order This creates the Sales Orders. If there are errors on creation then these are flagged on the Web Order. ### Customer Addresses Where ‘Sell-to’ Address fields have been submitted on the Web Order then if the following fields are different to the Customer address the Web Order address will be used on the Sales Order. * Sell-to Name * Sell-to Address (i.e. line 1) Note that Customer addresses, whether Sell-to, Bill-to or Ship-to do not get updated on the Customer or Ship-to record. Addresses are treated as one-off addresses (refer also to the setup section). ### Customer Requested Delivery Date Where ‘Requested Delivery Date' field has been submitted on the Web Order, this will populate into the 'Requested Delivery Date' on the Sales Order Header. ### Comment Lines Bevica will use the description field on the Web Order Line to consume Comment lines for the Sales Order. If the line type is blank, and a value exists in the Description field Bevica will convert this to a Comment line on the Sales Order. ### Unpaid Reserves The Web Order Line contains an Unpaid Reserve tickbox to indicate if the line is to be drawn from a customers Unpaid Reserve. If this line is ticked, Bevica will deplete from the Unpaid Reserve, if it cannot find one a Free Stock line will be created. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://kb.bevica.com/documentation/integration/bevica_website_integration/web_integration_-_sales_orders.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.