Deactivate 52ViKING Emergency POS and recover from emergency

This topic is primarily for administrators and other people who manage a Fiftytwo solution

Even though you activate 52ViKING Emergency POS per chain, you deactivate Emergency POS individually on your stores' 52ViKING store controllers by marking them as recovered as they gradually become able to enter regular production again.

Depending on the nature of the emergency, your store controllers may need to be reinstalled, have their network connections and integrations to other systems reestablished, etc. before you can use them in regular production again. Contact your Fiftytwo consultant, so that you can together assess what you need to do on your 52ViKING solution. The consultant can also help you quickly get any new server packages that you may need.

Generally, to be able to mark a store controller as recovered, you must:

Reestablish the store controller as necessary after the emergency. Ask your Fiftytwo consultant if you're in doubt.

If you need to reinstall the ability to use MPOS and Emergency POS on the store controller, see Set up 52ViKING to run MPOS and Set up 52ViKING to run Emergency POS respectively.

If you need to reinstall MPOS, you'll need a new mposonpremsc-[YOUR_ORGANIZATION_NAME].[YOUR CHAIN ID].tar package from Fiftytwo because the credentials used by the package will have changed. Ask your Fiftytwo consultant if you're in doubt.
Make sure that the store controller is in a condition where it's safe to use it, and that it'll be safe to download sales data from the emergency period to the store controller.
Reestablish the mobile POSs on the store controller with IDs that match the MPOS IDs used before and during the emergency, so that it'll be possible to download the sales data accumulated for each mobile POS that has run Emergency POS during the emergency period to the store controller when you connect the store controller to the Fiftytwo cloud repository again.
The store controller can now connect to the mobile POSs in the Fiftytwo cloud repository, from where it'll automatically begin to download sales data accumulated during the emergency period.
Verify that the store controller has downloaded all of the store's sales data accumulated during the emergency period from the Emergency POS solution.

When you're ready to mark a store controller as recovered, run the following script on the store controller in question:

epos.sh -r

The script is part of the epos-on-sc package that you installed when you set up the store controller to use Emergency POS.

Once you've marked the store controller as recovered, it'll stop using Emergency POS.

When you restart the store controller, it'll use regular 52ViKING MPOS again.

During the short period from when you mark the store controller as recovered, it stops using Emergency POS, you restart it, and until it begins to use mobile POS, the store's shop assistants will not be able to sell articles, neither with Emergency POS, nor with MPOS. We recommend that you inform affected shop assistants at the beginning and end of that period.

Possible need to update sales data post-recovery

52ViKING session and receipt numbers may in some cases overlap after you've used Emergency POS

Fortunately, because you've used 52ViKING Emergency POS, your stores have been able to keep selling articles during the emergency. That means that you'll have sales data from the emergency period.

Data from the emergency period will be timestamped, tied to MPOS IDs, etc. as usual, so there'll be no doubt about when and how sales were completed. However, when data from the emergency period is merged with sales data from outside the emergency period, your organization may need to manually correct session numbers and receipt numbers from the emergency period to avoid overlaps with data from outside the emergency period. Here's why:

While your Emergency POS solution was active, it used uncompromised master data from a backup of each store's store controller. For each store, that backed-up data came from the session (that is the day) when the backup was taken, and consequently it came with a session number and a receipt sequence start number from when the backup was taken.

To avoid conflicts, Emergency POS automatically changes those numbers to 1 when it receives the backups, so that sales data that the Emergency POS solution accumulates for a store during the emergency period will start on session 1 (and continue with session 2, 3, etc. if the emergency period lasts for several days). Likewise, receipts issued during the emergency period's sessions will start with receipt number 1 on each session.

That fact can potentially cause overlaps in a store's sales data when sales data from the emergency period is merged with sales data from outside the emergency. For example, you may then have two overlapping sessions number 2, and receipts from the overlapping sessions may then also have overlapping numbers.

That's why your organization may need to correct such overlapping session and receipt numbers manually, perhaps with help from your Fiftytwo consultant. It's important that you inform relevant people in your organization, typically your organization's accounting department, about the risk of such potential overlaps in sales data from stores that have used the Emergency POS solution.

Sales data is used for fiscalization, the mandatory reporting of transactions to the authorities. Therefore, manual correction of sales data is typically not allowed. It may, however, be permitted to correct sales data in situations that involve force majeure or acts of God. Before your organization corrects sales data manually after having used Emergency POS, make sure to consult local fiscalization legislation in your area to make sure that you comply with it. If you're in doubt, seek legal advice before your organization corrects sales data manually.

Related: 52ViKING Emergency POS