Things to note about the Report Manager
Cash postings are written to the cash journal. Hypersoft adds further information from the master data or from the system to the data that you see at the cash desk when you make the booking. Therefore, evaluations can use the status of the system settings and master data at the time the information is created (in this case the posting at the cash desk) for the report.
If, for example, you were to remove the item orangejuice from the merchandise category Non-Alcoholic Beverages after you have already posted it several times, in order to add it to the new merchandise category Natural Juices, current evaluations of postings made before the changeover would still show the orange juice in the assignment Non-Alcoholic Beverages. The Report Manager therefore uses the merchandise category assignment at the time when the corresponding postings were made. However, if you had renamed the product group at that time from the designation Non-Alcoholic Beverages to Natural Juices, past and future bookings would use this product group designation.
If you always take this into account when maintaining your item data and product groups, you will also get the desired result. Sometimes it makes sense, for example, to leave product group descriptions and perhaps also the items just as they are and to create new items and product groups for the future in order to keep reports accordingly.
In any case, you should avoid rash renaming of items and merchandise categories (after they have been posted at the POS system). Assignment errors that are noticed at short notice can usually be noted for accounting purposes and later audits, possibly as an appendix to your procedure description.
Daily closing, daily change and TTA
A Hypersoft system can also perform several trades in one day (intraday trades).
The first booking after a closing is based on the system date and uses this date as the opening day. All subsequent bookings are assigned to this opening day, even if the booking continues beyond the date change at 0:00.
In addition to the opening day, the system time is stored as the booking time and the system date as the booking date for each booking, so that a booking carries two date information when working continuously beyond 0:00: the date of the opening day and the calendar date from 0:00. This special approach is necessary because the use of cash register systems is not subject to the calendar change of day.
(Special exceptions for other requirements may arise, e.g. in establishments with 24-hour opening hours, for which an automatic time for the day change can be set with a special setting. See for this Noteworthy information on firings.)
As a rule, a time can be set for each operation at which it can be assumed that the day has been completed and that a new day has not yet begun. This value is called at Hypersoft Theoretical daily closing and is abbreviated as TTA. In the standard system, this value is set to 06:00 (for bakeries, one would introduce it and for discotheques, one would possibly choose a later time).
Especially the reporting is oriented towards this /TTA
The theoretical end of day (TTA) applies the calendar day change at a time specified by you (default setting 6:00 a.m.). The programme can automatically perform closures, updates and maintenance at this time. A new sales day then begins with the first POS booking of the day. in order to separate the opening days for the evaluations. Even if you have forgotten a daily closing at the POS system, you can simply select the TTA in the Report Manager instead of the opening day for accrual. You receive the report for the opening day (selection in the calendar) up to the time stored with TTA.
The TTA is also used by other programs. For example, the MRP monitor orients itself to determine whether a new day is to be started. Other actions are also carried out at the TTA, for example the installation of pending updates or internal automatic maintenance work. Both are done in a few minutes after the TTA.
You can adjust the setting of the TTA in the section Theoretical daily closing TTA.
Automatic report output and delivery...
These options for creating and sending reports are described in connection with the automatic daily closing in the Report Manager Report Creation (Automation) section.
Invoice date and opening day different...
When a transaction is completed (by payment in the standard system), the system date at the time of payment is also saved as the invoice date and the time of payment as the invoice time. Herewith an invoice date (correct way) can be different from the opening day.
Safety system at the end of day
Especially if, for example, daily closings are automated on the basis of conditions and these conditions then do not apply, a daily closing may be missing. It is therefore advisable to establish a procedure at the beginning of the work on one day where the first user consciously checks the date used as the opening day.
If one or more day-end closings have not taken place, a warning appears after the /TTA The theoretical end of day (TTA) applies the calendar day change at a time specified by you (default setting 6:00 a.m.). The programme can automatically perform closures, updates and maintenance at this time. A new sales day then begins with the first POS booking of the day. for each operator who wants to work at the POS cashing mode:
However, there are also situations where a daily closing has been carried out and another operator does not yet know this. To warn you, you can activate a note with the switch Display new billing period after a completion. This message is displayed once per calendar day and operator if the opening day extends beyond the TTA. Operators who are only set up for time recording do not receive this message. All others need to be briefly trained on this.
If you have several POS terminals and it may happen that a POS terminal is only put into operation after 0:00 a.m. (this may also apply to mobile devices), it is usually desired that this POS terminal (as well as those already in use) starts work on the opening day (i.e. after 0:00 the previous day). However, if this is not desired, you can Calculate new opening day from TTAdeactivate the function.
Exceptions to the cost of sales in the Report Manager
If the Report Manager calculates the goods usage, the posting data of the POS system is used here, not the goods movements. The stock Stock Reporter from the controller is used for all reports on the stock.
The cost of sales based on the postings can be calculated in Report Manager using two different methods. Both are based on the /APP DEK stands for the average purchase price. The DEK results from the goods receipt postings and the purchase price of the order variant applied. A historical average value is calculated by historically including all purchases with their quantity and price. If you change the DEK manually in the item master, this history is reset and the DEK is fixed directly. The current stock is used as the historically received quantity in this move. - For your convenience, it is also possible to reset the DEK of all items to the zero position. field in the item master. You can see how the value in the APP field is calculated in the topic Calculate purchase price. With the simple method, the APP is currently determined from the item master. This is practical if you did not maintain the APP everywhere when you posted but now need a report with the current APPs from the item master.
However, if you want to create a report of bookings that were made a long time ago, the current APP may not be suitable. You can therefore activatea switch for the PP specifications that uses the values for the APP from the POS system's posting journal. This means that the respective APP at that time of the postings is applied, which was determined from the item master when the POS system posted the item and stored in the journal.
Recipes and other things that are maintained in ingredient lists also have a APP resulting from the ingredients. This can also be evaluated currently or in the past. The POS system determines the recipe components during posting and enters them as APP during posting. You can also use the other PP specification to evaluate the current APP of the recipe from the item master.
However, there are also queries for recipe items that only determine the composition of the item when it is booked. This part of the item posting is determined by the POS system during posting and the APP is entered in the journal (also /CPP CPP is the abbreviation for calculatet purchase price. This can be used for markup calculation instead of the automatically calculated purchase price of the base items. The KEK is therefore entered manually., /LPP Last purchase price. This results from the last goods receipt posting and the purchase price of the order variant used. This value is entered automatically., /VEK). However, the selection of the query(s) is also entered for later evaluations (which item was selected and booked). If you evaluate the current PP specifications from the item master for such items, consider the following:
- The fixed recipe components (without queries) result in this part of the item purchase price based on the APP of the item master.
- The selection of the query stored in the journal at that time results in this part of the EC on the basis of the APP of the item master and thus supplements the EC from a).
- If the recipe has changed in terms of quantities or ingredients, the calculated EC will change accordingly. The same applies to changes to the queries involved. If the ingredients in the recipe are completely different items, the calculation based on the current recipe cannot be carried out in relation to the query at that time or the recipe contents. This information is then neither calculated nor added.
Settings for EK in the Report Manager
For most reports with purchase price calculation you can choose whether to use APP, CPP, LPP or VEK. Optionally, a fallback to APP can be applied if no value is available. If PP (CPP, LPP or VEK) is empty, the value from the APP field is used.
Settings for the evaluation of the turnover distribution
The settings for the distribution of turnover affect all reports that take the distribution of turnover into account.
Turnover distribution is applied in Report Manager to the following reports, among others:
- Booking overview
- DATEV and FIBU reports
- subgroup reports
- commodity group reports
Distribution of turnover on the basis of the booking journal (delivery status)...
The distribution of turnover is evaluated on the basis of the data in the item master that was valid at the time of the bookings.
If the distribution of turnover is determined on the basis of the accounting journal, a net statement in the accounting overview is not possible.
Sales distribution based on the current setting in the item master...
With this variant, the turnover distribution is used based on the current data in the item master and calculated at the time of report generation. The historical data on turnover distribution stored in the journal are not taken into account.
This allows you to make changes to the item master and apply them to past accounting periods.
This setting has no influence on the reports for front office reports, there the data from the respective bookings are always evaluated.
Do not apply turnover distribution...
The turnover distribution is evaluated neither from the booking journal nor from the current settings of the item master.
Exception Financial Accounting Export
An exception to this is Financial Accounting Export, which assigns merchandise categories based on the current settings in the item master and merchandise categories.
Front Office Reports
For the front office reports, you should also observe a few rules, as these are also the basis for the Report Manager. If you have not already done so, please refer to the chapter Noteworthy aspects of Front-Office Reportsat the end. This gives you an all-round feeling of security when handling your POS system.
Back to the parent page: Report Manager