Deactivate 52ViKING Emergency POS and recover from emergency

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

You deactivate 52ViKING Emergency POS individually on each of the relevant stores' 52ViKING store services, where you mark them as recovered as they gradually become able to enter regular production again. That means that you don't deactivate Emergency POS on the activation site that you used when you activated Emergency POS.

Depending on the nature of the emergency, your store services 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.

To be able to mark a store service as recovered, you must:

Reestablish the store service 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 service, 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 service 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 service.
On the store service, reestablish the mobile POS instances with IDs that match the MPOS IDs used before and during the emergency. That way, when you connect the store service to the Fiftytwo cloud repository again, it'll be possible to download accumulated sales data from the emergency period to the store service for each mobile POS that has run Emergency POS during the emergency period.
The store service can now connect to the mobile POSs in the Fiftytwo cloud repository, from where it'll automatically begin to download the sales data that's been accumulated during the emergency period.
Verify that the store service has downloaded all of the store's sales data that was accumulated during the emergency period from the Emergency POS solution.

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

epos.sh -r

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

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

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

During the short period from when you mark the store service as recovered, it stops using Emergency POS, you restart it, and until it begins to use MPOS, 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 service. 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