Special price and loss treatment
The Hypersoft system can be used very flexibly with price levels. Queries and other booking methods can also influence prices. An item can therefore have more than one selling price and, depending on the situation, another "normal price" (the term is not further defined). If the item is sold at a reduced price or even sold at 0,-, there are possibilities to evaluate which purchase values are affected by accessing the DEK. However, if you want to create evaluations in comparison to a possible sale, all the conditions of the possible sales price come into play.
Prices and losses
The Hypersoft program saves the "price" in three columns in the booking journal. These columns are used for evaluations and also for journal export for accounting audits.
In the recent past, new fields have been integrated into the booking journal in order to be able to create further evaluations. Depending on the application, you can use these evaluations with booking data that has been saved since the service pack November 2017.
The Report Manager reacts specifically to this service pack and uses the now reliable original price from the bookings. Booking data created with an older program version will be used as before (see below restrictions until November 2017).
Until the service pack of November 2017, extended restrictions applied:
Price column...
This is the sales price that is ultimately billed to the customer.
Base Price column...
The sales price that is normally posted. This is the standard price or the price from the price level with which the cash register starts in the standard system. So if the cash register uses a different starting price level, the base price assumes that this is the default. The Base Price field is not supported until SP 85 (from March 2017). Bookings made before may not yet have a value in the Base Price field.
Column Original Price...
This is the price that should have been billed to the customer and is not achieved now, for example, because the item was posted as a loss.
This value is stored in this column for further evaluations.
However, this function is only supported to a limited extent:
For example, you can activate the loss reason before posting or activate a transaction accordingly. If the loss is already known when the item is posted, no value is entered in the Price field (the Price field is zero). Thus, it is assumed that the item is to be considered from the outset with 0,- as value.
Even if queries are applied, the Original Price field is not filled.
Special reports that make use of these fields...
Since the Base Price field could not have been filled earlier, the report automatically uses the CURRENT price in the item master for calculation if the fields are empty.
The Loss Report price level is the only loss report that works with the Base Price field.
Various loss reports (usually via option counters) also make it possible to use the sale values. These reports use the Original Price column and are therefore subject to the above restrictions.
Queries with and without price changes
Queries of items can change the sales price and the recipe, or the components. In the case of a journal export for auditing accounting purposes, the sales price determined is issued and, depending on the case, the value-added tax applied. However, the journal export is not intended to explain complex recipes that could explain the respective price or changes in the nature of the item.
If you therefore want to represent tax-relevant item information in the export, then this should emerge best from the item text. It is best to discuss this with your tax advisor before creating the relevant items and queries.
Independently of this, the Hypersoft program can display information about the nature of queries in certain reports with additional reports. If this is relevant for a check, you can also refer to this data, especially if you are working with a plausible stock management system such as Hypersoft CONTROLLER.
An example on the topic:
If you sell a special hamburger with different accessories and changeable components, many different variations may be possible in the end. You could decide to create this item in a single item record with corresponding queries. The queries change the price and the components and in the journal export you can see when the item was sold at what price. If information about the consumption of goods or the exact composition of the items is required, further reports are generated which are provided by the Hypersoft program.
If you were a Hamburger fast food restaurant that sells mainly hamburgers or cheeseburgers, you could decide to create these two items separately so that both can be distinguished in export. A query "as a cheeseburger" would summarize both in one item.
Since the possibilities in practice are unmanageable and this can also affect the audits, we ask you to coordinate with your tax advisor how you can optimally invest the items in your case and evaluate audit festivals.
Further documentation: Calculate purchase price
Back to the parent page: Limitations and methods