Some Products have no physkey?
The retailer is running the disaster recovery tool and it reports a product has been sold that has no physkey. It wont transfer sales involving that product.
This is a good question to explain how some of this works, as well as how it can be resolved of course
What is a "physkey"? This is an internal globally unique value (same as GUID or UUID but with characteristics to aid indexing). Every product, customer, sale gets allocated physkey internally. You never set or edit physkeys in general operation, doing so is very dangerous. Physkey values are unique over all retailers.
Background
The retailer has the following situation
- A store suffered a disaster and was unable to use the POS computer. In order to get moving quickly, a new PC was purchased and installed as if it was a new store. This is fine, and gets the store trading again quickly
- The store is part of a franchise, so all products are centrally pushed to them. When they installed the new PC, all the products were pushed into them.
- When sales are completed, they are transmitted to several other independant Fieldpine Systems (they are using a Large, multiple independent stores model )
Where did the products come from?
When the new store is installed, this retailer deploys a prebuilt database (which is typical and normal). This database has 2 or 3 products pre defined. This ensures that when the POS is started, there is something available to sell, while the full product database is downloaded.
Those products do not have a physkey value.
When the main set of products is retrieved from the data-master, these are loaded but, every product there must have a physkey. See first step in the "Per Product Loop" on the Product Distribution Internals page. This means these original products are never claimed or overwritten by the data-master versions.
To verify this, open the products table in the store database and look at the "physkey" and "rmsystem" values. These are blank which identify a per store product.
Disaster Recovery? What's that?
The disaster recovery tool lets you take two related Fieldpine databases and merge transactional data from one to the other.
In this case the retailer managed to recover the original PC after a short period. They are using the disaster recovery tool to merge the two databases together. As the store is sending sales to external Fieldpine systems, you cannot simply rekey these sales as they would get transmitted to the downstream reporting systems and double up everything. And anyway, nobody wants to rekey sales.
How do I fix it?
New Stores installed in the Future
The blank database issued as part of new installations needs to be corrected. The fields physkey and rmsystem should be populated with the values from "data-master". This will ensure that when a master product file is loaded, it will correctly update these initial products. Once this is done, all future installs will not have any issues.
You could remove the products from the install database, but that means that a new install will block if the data master is offline or unreachable when the store is installed.
Existing installed stores
The existing stores have this sort of database structure
| Pid | Description | Physkey | RmSystem |
|---|---|---|---|
| 1 | Cash Item | ||
| 2 | Account Payment | ||
| 3 | Misc Item | KEPUJSJRKJVHEJRJB | 1,2,3,4 |
| 4 | Drink | KEPUJSJRKJVHEJRQ | 1,2,3,4 |
| 5 | Tiffen Box | KEPUJSJRKJVHEJR9W | 1,2,3,4 |
| 6 | Payment of Account | KEPUJSJRKJVHLL23ER | 1,2,3,4 |
What we need to do for existing stores is safely remove Pid# 1 and 2.