Calculate purchase price
Best practice: Utilise purchase prices consistently
Companies that work with stored purchase prices are on average significantly more successful than companies that have to make decisions without this basis. The reason is simple: if you know your costs, you make safer - and faster - decisions.
As Hypersoft has a vested interest in the economic success of its users, the maintenance of purchase prices has always been a standard feature of the POS system at no extra charge. Purchase prices can be stored not only for articles, but also for recipes. This results in numerous, directly usable advantages in day-to-day business and controlling.
Many analyses - especially in the Report Manager - include purchase prices directly and thus provide reliable key figures on the cost of goods sold. Integrated loss management only becomes truly meaningful with stored equity, as losses can be assessed not only in terms of quantity, but also economically.
Valid comparative values such as purchase prices, last purchase price and other information or the purchase price of lost goods(loss management) are also available to you in supplier discussions.
In addition, purchase prices form the basis for further tools such as the profile analysis, with which you can regularly check which items actually support your offer - and which ones are a financial burden. In combination with budget planning, it is even possible to calculate a theoretical EBIT in real time.
Purchase prices for recipes - two tried and tested methods
Two tried-and-tested methods are available for taking purchase prices into account in recipes:
You can either calculate in detail using the purchase prices of the individual basic items and build up your recipes from this. Changes to prices or compositions then automatically affect the purchase price of the recipe.
Or you can work with a simplified calculation: In this case, you store a base article as a placeholder (e.g. "Recipe purchase price") with a variable unit. This article is added to the recipe and enables the purchase price to be maintained directly as a multiplier - also as an approximate value.
Both methods can of course be combined: critical or high-margin products are calculated precisely, while less relevant components are mapped using placeholders.
Important note on the Report Manager
Please note the special features for handling purchase prices in the Report Manager. In particular, exceptions to the cost of goods sold and specific purchasing settings can have an impact on analyses. These are described in the chapter Important rules of the Report Manager:
Things to note about the Report Manager
Exceptions to the cost of sales in the Report Manager
Settings for EK in the Report Manager
Further topics: Directory: Best Practice
The Average Purchase Price - DEK
The average purchase price (APP) is always used when the cost of goods sold is evaluated or analysed. It represents a net price (excluding VAT) and is based on all historical purchases of an item.
The DEK answers a central question:
What did this item actually cost me on average - across all previous purchases?
How is the DEK calculated?
The calculation follows a simple principle:
**Sum of all purchase prices
÷
Total of all base units purchased
DEK of the base unit**
All values are saved cumulatively over time. The DEK therefore grows with each additional goods receipt and forms a stable mean value in the long term.
Sample calculation
Base unit: 1 piece
Purchase 1: 100 pieces at € 10.00 → Total € 1,000
Purchase 2: 10 pieces at € 20.00 → Total € 200
Total:
Quantity: 110 pieces
Value: 1,200 €
DEK = € 1,200 ÷ 110 units = € 10.909
(Rounded in the report: € 10.91)
This DEK now applies to all further valuations, regardless of which individual purchase an item physically originates from.
Historical logic of the DEK
The DEK is always based on all purchases since the first goods receipt of an item. This results in a robust average price over time.
Business analyses (e.g. cost of goods sold, losses, profile analyses) are deliberately based on this value - even if the actual gross profit was different at certain times in the past.
In addition, Hypersoft saves the last purchase price (LEK) separately for each item in order to visualise short-term price developments.
DEK in the Report Manager
The Report Manager can work flexibly with purchase prices:
-
either with the current DEK from the article master
-
or with the DEK that was valid at the time of booking
You control which method is used via a corresponding switch in the Report Manager.
See also: Exceptions to the cost of sales in the Report Manager
DEK in Stock Management (Controller)
In the controller, the DEK is deliberately designed as a statistical mean value. In the long term, it provides the correct business valuation, even if reports change retrospectively.
A central understanding is important here:
There is no fixed connection between a specific stock on a key date and a specific purchasing transaction.
Typical misinterpretation - example
Purchase 01.04.: 10 pieces at 10 €
Purchase 10.04.: 10 pieces at 20 €
→ DEK = 15 €
On 20.04. there are still 15 left in stock.
Question:
Are these 15 pieces worth €15 × 10?
Or 15 × 20 €?
Response from Hypersoft:
→ 15 × 15 € (DEK)
This rating was chosen deliberately because it:
is consistent
provides long-term comparable key figures
and avoids misinterpretations by "mentally tracing individual purchases"
In short
DEK = long-term average price
LEK = last purchase price
Controller deliberately calculates with DEK
Reports remain stable, comparable and make business sense
Further topics:
Exceptions to the cost of sales in the Report Manager
Query purchase price adjustment when posting for item option
If you change the APP manually in the item master, the historically stored values are discarded. Instead of the historical quantity, the current stock is now stored and the APP is retained. Since it is discarded with this, the weighting is removed from the existing value, so that the future goods receipt only calculates a APP together with the current stock.
This action also leads to the rejection of the historical number which is set against the new goods receipts, since the APP, if the item is already very old, is hardly changed by individual goods receipt postings in the value APP. The Historical Number is set to the number of the current inventory.
With the zeroing program you can reset all APPs with one command. However, the historical number is set to 0 regardless of the position.
| Historical number | APP | LPP | continuance |
| 4563 | 10,- | 12,- | 10 (before provision) |
| 10 | 12,- | 12,- | 10 (after provision in the item master) |
| 0 | 12,- | 12,- | 10 (after reset with zero position) |
When editing the items in the item master, the APP is calculated within the queries. As it cannot be determined until the actual booking which APP will result from the selection of the queries, the program calculates an average value on the basis of the possible items. Later, when you post at the POS system, the cost of goods sold is determined exactly on the basis of the selection and used in the reports.
The APP for products is managed automatically. If a basic item that is involved in the product via a recipe is changed in the APP, the APP of the higher-level recipe is recalculated immediately. If this recipe is the basis of a product, the APP is also recalculated here. The same happens when recipes are changed. If the PP for products is to be synchronized, this recalculation also takes place across clients.
Further topics: Purchase prices in the hypersoft system
Back to the overarching topic: Limitations and methods