> 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/source-data.md). # Source data ## Source data - basic product data **Menu path:** `Administration -> Dictionaries -> Products` The `Source data` section is located at the top of the product card. It contains basic product identification data and information that affects further product configuration in the tabs. This is not only a product description. Data from this section can determine how the product is visible in locations, how it is searched for, how it behaves on POS, how it appears in documents and how it is handled by integrations.
### Source data fields | Field | What it means | Impact on the system | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Product index` | Technical product index in the system. | Helps uniquely identify the product record in the backend, reports and issue analysis. The user usually should not treat it as the product's sales code. | | `Product type` | Record type, for example `Article`, `Packaging`, `Service`, `Set`, `Product`, `Marketing material` or `Grouping product`. | The product type can affect available processes, sales method, stock handling, bound products and POS configuration. Before changing the type, make sure the product is not used in active processes. | | `Product name` | Full product name visible in the backend. | Affects product search, lists, documents, reports and user work. The name should be clear and compliant with the organization's standard. | | `Unit of measure` | Basic unit of measure of the product, for example `pcs`, `kg`, `box`. | Affects quantities in documents, warehouses, orders, sales and reports. An incorrect unit can cause incorrect quantities or integration problems. | | `Group` | Product's place in the product group structure. | Affects filtering, reporting, assortment classification and sometimes pricing processes, labels or permissions to work with the assortment. | | `Product source` | Product source, for example central or local product. | Determines product visibility in the location structure. A central product can be visible in all locations, while a local product is visible only in the location where it was created and in subordinate locations. Visibility does not automatically mean activity or sale availability. | | `Product symbol` | Product symbol used as an important business identifier. | For a central product, it can be defined when creating the product; for a local product, it is generated by the system. It can be used in search, integrations, reports or data exchange. | | `Name on cash register` | Product name used on POS. | Affects how the product is presented on the cash register and potentially on prints or sales screens. It should be shorter and understandable for the cashier and customer. | | `VAT rate` | VAT rate assigned to the product. | Affects sales, receipts, documents, tax reports and integrations. VAT changes should be made according to tax rules and the implementation process. | | `VAT classification` | Additional VAT classification, if used in the implementation. | Can be used in reporting, integrations or local tax requirements. If the field is not used in the implementation, it can remain empty. | ### Fields with the greatest impact `Product type` determines how the system interprets the record. A standard article, service, set, deposit packaging or grouping product can behave differently. If you are not sure which type to select, check [Product types](/aquila-store-user-manual/products-and-product-records/product-types.md) or consult the topic with the product records administrator. `Product source` and `Product symbol` are important for central and local products. A product can be visible in a given location, but still require activation, price, codes and POS configuration. Therefore, after creating a product, also check the `Availability`, `PLU codes`, `Prices` and `Configuration on cash register` tabs. `VAT rate` should be changed carefully because it affects sales documents and reporting. If a VAT change should apply from a specific date, also check [VAT changes](/aquila-store-user-manual/products-and-product-records/vat-changes.md). `Name on cash register` does not have to be identical to `Product name`. In practice, it can be shorter because it is used in the POS context. ### What to watch out for * Data from the `Source data` section can affect POS, documents, reports, prices, orders and integrations. * `Product source` affects product visibility in the location structure. * `Product symbol` has different rules for central and local products. * Before changing the product type, make sure you understand its impact on the sales and warehouse process. * Changing the unit of measure, group, VAT or POS name can require additional verification in sales, document, order or integration processes. ### Related pages * [Product types](/aquila-store-user-manual/products-and-product-records/product-types.md) * [Availability](/aquila-store-user-manual/products-and-product-records/availability.md) * [VAT changes](/aquila-store-user-manual/products-and-product-records/vat-changes.md) * [Product records overview](/aquila-store-user-manual/products-and-product-records/product-records-overview.md) * [Product card navigation](/aquila-store-user-manual/products-and-product-records/product-card-navigation.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/source-data.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.