...
/wiki/spaces/TRX/pages/5037850633
Item | Oracle explanation |
---|
Modifiers / Condiments | Separate PLUs for: for every modifier. No “extra” category. |
Combos | Same PLU for different sizes of the same combo. For example, the “Whopper Combo Large” and “Whopper Combo Medium” have the same PLU. To calculate the combo price: To get the price from Oracle’s /menus payload: For the combo: Retrieve the menuItemRef in the ComboMeals object Using the menuItemRef , find the menu item that defines the combo and get its price for the applicable definitionSequence . That is the combo price.
For main item and sides: In the ComboMeals object, use the prices defined at comboGroup level. If the price is not defined ("prices":[ ] ), the price is 0. The comboGroup with "isMainGroup":true contains the main item. The comboGroup with "isMainGroup":false contains the sides.
|
Service mode | Same PLU for both in-restaurant and delivery service modes. Different pricing is managed through definitionSequence . Not all items have both definitions (e.g. some items aren’t sold in delivery). |
Availability | To check availability, the following endpoints must be checked: |
Sugar tax | Can we add it as a surcharge to the product? E.g. Classic Coca-cola should already have the sugar tax included in the priceSequence . |
Bottle deposit (Pfand) | |
Delivery fees (bag fee, service fee, etc) | |
Pre-ordering | |
Fiscal | Is this standard across markets? E.g. in BK MZ in the commit call we need to send the following information: Code Block |
---|
"extensions": [
{
"displayName": "DocumentId",
"appName": "Harmonized",
"dataName": "DocumentId",
"dataType": "strings",
"data": "1",
"options": []
},
{
"displayName": "DocumentType",
"appName": "Harmony",
"dataName": "DocumentType",
"dataType": "strings",
"data": "01",
"options": []
} |
This information always stays the same as it’s needed for the fiscal integration to work. |