One of the StoreHouse main functions is to process r_keeper sales in order to get reports on sales self-cost and the resulting markup.
Connection between r_keeper and StoreHouse is accomplished by importing references from r_keeper using the QushMan.exe application.
One part of the goods dictionary  the Restaurant Menu group — is also formed based on the r_keeper data. The goods of this group already have some preset values, which can later be changed if necessary.
All settings and import rules are set in the QushMan.exe application. In this application, a separate dictionary branch for r_keeper goods is formed. By default, it is called the Restaurant Menu.

Inside the main Restaurant Menu branch, the list of groups and dishes has the same hierarchy as in the r_keeper program.
In addition to the r_keeper menu tree, three groups are automatically added to the Restaurant Menu group:

  • Undistributable markups — a group for uploading r_keeper undistributable markups. This r_keeper notion is similar to a dish, but it is created in a separate r_keeper reference — Discounts/Markups. For more details, see the r_keeper 7 documentation.
    Since r_keeper 7.6.0, dishes linked with markups are used for configuring undistributable markups

    When importing from r_keeper, dishes linked with markups and for which the price is not set will be placed to the Undistributable markups group in StoreHouse, regardless of the group in r_keeper.

  • Rates — a group for unloading r_keeper tariffs. This r_keeper reference contains a list of charged services, the sale of which is also uploaded to StoreHouse

  • Deleted — a group for unloading dishes stored in the r_keeper Recycle Bin, i.e. for unloading deleted dishes. Deleted dishes are stored to enable generating reports for large periods in which these dishes could have been sold.
    When this group is created, the Deleted goods flag is automatically set for it. In the list of goods, this group and the goods included in it will be displayed in gray font.
    When searching for goods, the In the Deleted group filter will be applied to this group goods.

    Do not delete these automatically added groups — Undistributable markups, Rates and Deleted — even if you do not plan to use them. They are needed for keeping the reference structure consistency when importing data from r_keeper.

When importing goods (dishes) from r_keeper, the Serving UOM is automatically created for the goods card. It is a base one. You can change it if necessary.
When importing goods (dishes) from r_keeper, the Category and Accounting category will be automatically filled in with the Default Goods categories pre-installed in StoreHouse. You can later change the categories manually through group operations.
You can configure the filling of the goods category with values ​​​​from r_keeper. To do this, make the corresponding settings in QushMan.exe.

If you enable the import of the r_keeper categories into StoreHouse, then you cannot change the value in the Category field manually, because upon new import of references, the value of the "Category" field will be redefined according to the r_keeper data.

Also, when importing, the fields of sale prices and tax rates are filled in on the goods card. If several restaurants are maintained in r_keeper and different types of prices and tax groups are created for them, then, when importing goods from r_keeper, exceptions by enterprises will be added automatically.

The r_keeper prices are imported as a unit of measure for requests. But the price in StoreHouse is always stored in a base unit of measure. If, after importing the menu, new units of measurement were added for the r_keeper goods and the base units were redefined, then the next time the menu is imported, prices will be recalculated with regard to the coefficient for converting the For requests UOM to the base one.

If barcodes were defined for dishes in r_keeper, then the list of r_keeper barcodes will be uploaded to the Goods barcodes reference for the Serving unit of measurement.
After importing goods from r_keeper, in order to write off the sales correctly, do the following:

  1. Create/assign a set, if the product must be written off according to the recipe. You can use the automatic creation of "dummy" sets, which are then filled in according to the technological map.
  2. Select departments for the write-off
  3. If it is supposed to write off sales for several enterprises in the same StoreHouse database, and for these enterprises the recipe of the same dish is different, then it is necessary to determine the version of the set for each enterprise.
    This procedure can be performed as a preliminary preparation for the processing of the expense, and to be carried out during processing the expense.
  • No labels