> For the complete documentation index, see [llms.txt](https://docs.aquiladynamics.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aquiladynamics.com/aquila-store-user-manual/products-and-product-records/prices.md). # Prices ## Prices **Menu path:** `Administration -> Dictionaries -> Products` The `Prices` tab shows product price data. On POS, one final selling price applies to the product, but the way it is determined depends on the price management model adopted by the organization. Aquila Flex allows prices to be managed very flexibly. Prices can be defined centrally, overwritten locally, set as regular or promotional prices, passed through integrations, maintained in price lists or calculated based on margin added to the purchase price. Price management is also controlled by permissions, which allows the work model to be adapted to a specific customer and implementation.
### When to check Check this tab when the problem concerns product price, margin, local price, promotional price or a difference between price data in the backend and the final selling price on POS. ### Global and local values If the user is logged in to a subordinate location, meaning a location other than central, the `Prices` tab usually shows two fields for a given value: a global value and a local value. The global value shows the price or margin coming from the parent level. The local value applies to the current location. When working in a location, the user can overwrite local values if they have the appropriate permissions. The local value can have priority over the global value according to the price hierarchy. ### Price sections on the screen | Section | Meaning | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | `Selling prices (user)` | Selling price entered manually by the user. | | `Product margin` | Product margin. It can be used for analysis or price calculation if the organization's pricing process uses margin. | | `Selling prices` | Regular selling price coming from a price list. | | `Promotional sales prices (user)` | Promotional selling price entered manually by the user. | | `Promotion selling prices` | Promotional selling price coming from a price list. | | `Declared net purchase price` | Declared net purchase price. It can be used as a basis for margin analysis or price calculations. | | `First selling prices` | First selling price of the product, if the implementation process maintains it. | ### Where a price can come from | Price source | Meaning | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Manual user price | Price set directly by the user in the relevant price area. It can be a regular or promotional price. | | Price list | Price coming from a sales price list. Price lists are used to maintain regular or promotional prices according to the organization's pricing process. | | Local price | Price assigned to a specific location or shop. | | Inherited price | Price coming from a parent location if no price with higher priority has been set for the given location. | | Margin from purchase price | Price calculated based on purchase price and margin, if this model is used in the process. | | Integration / API | Price passed through integration. If location-specific prices are defined for a location, they take precedence over prices passed through API. | ### Price selection hierarchy for a location If more than one price exists for a product, the system selects the price according to the hierarchy. The order below shows which price has priority when determining the price for a location. | Priority | Price | | -------- | ---------------------------------------------------------------- | | 1 | Promotional manual price in the shop. | | 2 | Regular manual price in the shop. | | 3 | Promotional price list price in the shop. | | 4 | Regular price list price in the shop. | | 5 | Promotional manual price inherited from the parent location. | | 6 | Regular manual price inherited from the parent location. | | 7 | Promotional price list price inherited from the parent location. | | 8 | Regular price list price inherited from the parent location. | {% hint style="info" %} If location-specific prices are defined for a location, they take precedence over prices set through API. Other dependencies between API prices and the full price hierarchy should be confirmed before integration procedures are described. {% endhint %} ### What to watch out for * The scope of price editing depends on configuration and the pricing process. * If the organization manages prices through price lists, changes should be made in the pricing module according to implementation rules. * A price change may require synchronization with POS. * Local prices can differ from the global price. * A price visible in one tab does not have to be the price finally used in the shop if a price with higher priority exists. * Location-specific prices take precedence over prices passed through API. ### Related pages * [VAT changes](/aquila-store-user-manual/products-and-product-records/vat-changes.md) * [Prices on shops](/aquila-store-user-manual/products-and-product-records/prices-on-shops.md) * [Prices history](/aquila-store-user-manual/products-and-product-records/prices-history.md) --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.aquiladynamics.com/aquila-store-user-manual/products-and-product-records/prices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.