Skip to main content
Jump to
    Fourth Customer Success Portal
    • Updated

    Release Note: Recipe and Menu Engineering: Catch Weight (Variable Weighted) Ingredient Validation and Import API: Ingredient Identifier Logic

    What’s Changing?

    Catch Weight Ingredients – new validation has been added

    Import API Ingredient Identifier Logic – the logic to identify an existing ingredient (for update) has been aligned across several endpoints

    Release date: 4th June 2020

    Reason for the Change

    General system enhancements.

    Customers Affected

    Catch Weight Ingredients:  Inventory customers using ‘catch weight’ functionality in the Recipe and Menu Engineering module.

    Import API Ingredient Identifier Logic:  All customers using these import API endpoints to update existing ingredients:

    /ingredients
    /ingredientintolerance
    /ingredientnutrient
    /ingredientcost
    /ingredientalternateswitch

     

    Release Notes

     

    Catch Weight Ingredients (aka ‘variable weighted’ ingredient)

    New validation has been introduced that requires a ‘catch weight ingredient’ to have the same ‘supply quantity UoM’ (base UoM or a conversion) as the ‘unit size UoM’.  This validation relies on a configuration that is specific to Inventory customers. 

    This change will ensure that sales are correctly attributed to recipe ingredients when POS data is processed in Inventory. 

     

    Import API, Ingredient Identifier Logic

    The logic to identify an existing ingredient (for update) has been aligned across several endpoints.

    The reason for this change is to have consistent behaviour for all of the import API endpoints in regard to 'ingredient identification' values.  These changes will allow the use of StarChef key as an 'ingredient identifier' as well as 'supplier name + supplier code' combination for all of the endpoints except /ingredientpriceband.  For some of the endpoints the StarChef key can already be used as an identifier but the logic will be changed slightly for these endpoints as well.

     

    There are three notable changes regarding ingredient updates.

     

    1. For /ingredientintolerance and /ingredientnutrient endpoints, if both identifying values of StarChef key and 'supplier name + supplier code' combination are included in the payload, only the StarChef key will be used as an ingredient identifier.  If the StarChef key is invalid, an error will be generated and the update for the specified ingredient will fail.

      - The logic will no longer try to identify the ingredient using 'supplier name + supplier code' if the StarChef key is present in the payload and is invalid
      - The 'supplier name + supplier code' combination can still be used as identifying values for an ingredient update if the StarChef key is not included in the payload

    2. For the /ingredientcost endpoint, the logic will match the behaviour described above. The current logic (which is changing) is that if both StarChef key and 'supplier name + supplier code' combination are in the payload, they must all match the same ingredient for the update to be successful. This logic is changing to improve performance.

    3. For /ingredients endpoint, logic is being introduced which will allow:

      - Update of ingredient using StarChef key as 'ingredient identifier' without supplier name and supplier code in payload.  In this scenario, the supplier name and supplier code values will not be changed to null if they already exist in the database
      -       To update supplier name and supplier code, see details below of how this can be accomplished

     

     

    Values included in payload

    		  

    Update operation

     

    Endpoint  /ingredient

    StarChef key

    Supplier name

    Supplier code

    What should happen?
             
     

    Y

    N

    N

    Update ingredient without changing supplier name + supplier code
     

    Y

    Y

    N

    Update ingredient > change supplier name, supplier code is not impacted
     

    Y

    N

    Y

    Update ingredient > change supplier code, supplier name is not impacted
     

    Y

    Y

    Y

    When all 3 values are provided, update supplier name + supplier code if StarChef key is valid

    In brief, the ingredient identification logic will follow these rules:  

        1. If the StarChef key is present in the payload, use this as the identifying value
        2. If the StarChef key is invalid (does not exist), generate an error
        3. If StarChef key and supplier name + supplier code combination are included in the payload, match on StarChef key and ignore supplier name + supplier code as identifying values
        4. If supplier name + supplier code are in the payload and StarChef key is not in the payload, use supplier name + supplier code as the identifying value.

     

    Regarding ingredient creation using the endpoint /ingredients:

    1. If global database setting Restrict Ingredient Access by Vendor = true, ingredient can be created without supplier name + supplier code
    • Supplier name + supplier code are optional values in this scenario
    • This allows the creation of parent ingredients without the need for 'dummy' supplier name + supplier code values
  • If Restrict Ingredient Access by Vendor = false, ingredient must be created with supplier name + supplier code combination.
    • Supplier name + supplier code are mandatory in this scenario
    • The above scenario is relevant to the majority of RME customers that use the import API

     

     

    Related articles

    Comments

    Please sign in to leave a comment.