...
Each validation type generates a validation report on completion. The layout of each report will be different depending on the validation type. Each report is sorted with failures at the top of the document, each row is an actionable data point.
Configure Sanity Threshold Configurations
Navigate to the CTG Configs → Sanity Configs document inside the Sanity Desk tool. You will see the different validation types that are available:
The values that you set for a given validation type are the minimum threshold percentage values. For example, if restaurant availability → Sicom is set to a value of 10, the Sicom PLU in the offer being validated will need to be available in at least 10% of restaurants for the offer to pass validation. Note, if any of the posVendors from vendorConfigs do not meet the thresholds, the entire document will not pass validation.
| Info |
|---|
You will need to set values for at least one of the validation types in order for the service to run validations. If you do not, the service will throw an error. Temporary values have been put in place as placeholders. |
Callouts and Edge Cases
Pricing Distribution Validations
...
Note on availability - there are several steps to make an offer available/visible in our application. Our script strictly looks at the POS availability from the menu service response (this endpoint is cached for ~60 seconds). In order for something to be available, POS vendors must add the PLU systemwide, but individual restaurants must refresh their POS/mark the PLU as available in order for the menu service response to come back as available for that restaurant.
| Info |
|---|
The price available in the restaurant availability validation file is the price in the menu service, for example, in case of NCR integration that is the price sent via the POS to the Menu Service. In case where the DOP is the source of truth for P&A, it is the price set in the DOP. |
| Info |
|---|
Additional technical context for CSM: /wiki/spaces/FEP/pages/3675193369 |