The following explains how POS specific annotations can be applied to item data.
Think about what item specific properties your POS needs to know about that may not be present in a standard field that could be interpreted the same way for all customers. For each POS specific property that you need to know about, you can define an annotation requirement.
For example, your POS may need to flag an alcohol purchase so that the terminal operator knows that they need to ask the patron to present their ID. Some clients encode this into their level data but they don't all do it the same way. You can solve this by defining "Contains Alcohol" as an annotation requirement.
Think of each annotation requirement that you encounter as a pull down menu that can select from two or more options. You will need a name for each annotation requirement and for each option it contains. You must also decide which of these options should serve as a default when no option has been selected.
After the POS determines its item annotation requirements, it uses the POST /interfaces/thirdPartyCodes endpoint to define them at installation time in the Yellow Dog database for a specific client. The client then works with the Yellow Dog implementation team to map categories of Item data to the appropriate POS defined options for each annotation requirement.
The POS decides which of its item annotation requirements must bear an explicit value for an item to be usable and which can can infer a default value when not specified. When the integration goes live, the POS periodically checks for updates to item data. It ignores any items that don't meet explicit requirements and applies default values where optional annotations are unspecified.
See the POST /interfaces/thirdPartyCodes endpoint documentation for more information about defining POS specific annotations.