This specification details our Sales Sync which is a 1-way sales processing application. If you need a 2-way integration, please look at our API.
With the Sales Sync we are able to consume transactional or daily summarized sales data, transactional data is recommended for most clients' needs.
POS Partner integrations will go under a certification process led by Yellow Dog Inventory to validate the integration.
Reach out to the Sales department, sales@yellowdogsoftware.com, to begin this process, then a Yellow Dog team member will work with your team to certify the integration. Included in the certification process is documenting data exchange mapping and testing by providing sales examples for validating data.
This supports SFTP or FTP and can be either Yellow Dog hosted or Third Party hosted.
- The file extension must be a .csv.
- The file format must be comma delimited.
- The file can be formatted with either a header or no header.
The sync can be scheduled to run at any interval but will be configured to run based on the schedule that the .csv file(s) will be made available from the Point of Sale.
It is recommended to produce one sales file after end of day to ensure all sales have been completed and closed.
The Sales Sync does not require the columns to be in a specific order nor follow any specific rules in header naming.
The sync allows for dynamic configuration and mapping of the sales columns by index or header to the equivalent field in Yellow Dog.
The POS Partner needs to provide the following detail:
- Specification on if Summary or Transaction Level detail sales information will be provided
- Sample file(s) as requested below
- Know whether the site will be using modifiers and if so, whether they should be concatenated
- The method for matching POS Items to YD Items
- The method for matching POS Store to YD Stores
- FTP location or local folder provided by the third party or Yellow Dog for POS Sales File exports
The client will be responsible for providing the matching of Revenue Centers to the correct store(s) in Yellow Dog to ensure that sales are mapped to the correct inventory locations.
The Client is also responsible for mapping recipes to the POS menu items for inventory depletion.
The POS Partner is responsible for configuring the export of the sales file and providing to the agreed upon FTP location. The schedule of the export should be provided to Yellow Dog so the sync schedule can be configured accordingly.
The POS Partner will need to work with Yellow Dog during the certification process to ensure the proper mapping of the sales data from the file to the fields in Yellow Dog.
Yellow Dog will need to configure the sync to ensure all the sales data mapping is complete and schedule the sync to run.
To determine if this sync is the best approach for an integration, a sample sales file will be requested for review as part of the certification process.
The sample sales file should contain the following sale examples:
- Return
- Void
- Comp
- Discount
- Sale
- Modifier
Consider the following options for developing the sales file as this will determine the fields required in the file:
- Is this integration for F&B, Retail, or both?
- F&B:
- Modifiers are commonly used.
- Returns are typically not supported. Instead, we recommend 100% comp discounts for refunds.
- Voids are typically supported for F&B integrations.
- Yellow Dog recipes are mapped to POS items.
- The file must include ItemNumber which is the POS systems unique identifier for items and modifiers.
- Retail:
- Returns and Voids are typically supported.
- Sales are typically matched on YD SKU.
- F&B:
- How will sales be matched?
- POS item mapping: Maps YD recipes to POS items. ItemNumber is Required. This is most commonly used for F&B integrations.
- SKU: YD SKU and the third party SKU must match. This is most commonly used for Retail integrations.
- ItemID: The YD Item ID must be provided and sales will match on ItemID.
- How will sales map to the YD Store?
- Revenue Center: If there are locations or revenue centers in the POS, the RevenueCenter should be included in the sales file which will then be mapped to a YD Store.
- YD StoreID: If the YD StoreID is provided in the file sales can map directly to the YD StoreID specified.
- Single store: In the YD sync a single store can be selected, all sales will be mapped to this store.
- To send an update to a transaction previously received by YD, the following fields must remain the same to update the transaction:
- TransactionNumber
- LineNumber
- ItemID
- ItemNumber
- SKU
- DateTime
- Voids & Returns:
- Voids:
- Voids should be sent with 0 quantity.
- If updating a previous transaction, provide the same transaction details listed in the section above, with an updated quantity of 0
- Returns:
- Returns are a negative quantity.
- Returns should be presented as a separate transaction to appropriately adjust inventory on hands.
- Voids:
The following details the required and optional fields for a Transaction Level sales file. This is the recommended method.
| Sales data | Transaction Level Detail File | Description | Additional Information |
|---|---|---|---|
| ItemNumber | Required* | ItemNumber is a unique identifier for an item in the POS System. This is required for mapping YD recipes to POS items. | |
| SKU | Required* | Required if the ItemNumber is not provided. Sales will match on SKU. POS SKU must match YD SKU. | |
| Item | Required | The description of the item sold. | |
| Quantity | Required | Quantity sold. Positive quantities = sale Negative quantities = return | |
| UnitRetail | Required | Should always be positive. This is the unit retail per 1 quantity of the item sold. | |
| DateTime | Required | This is the datetime offset of when the check was closed and paid. If a Check Closed time cannot be provided, the sync has a configuration option called “Enable Time Part Override” that will allow for a selected time to be assigned to all transactions. Other formats may be supported upon request. | Supported Formats: RFC 3339/ISO 8601 full (recommended) - Example: 2025-12-05T13:32:10-0500 ISO 8601 with Zulu - Example: 2025-12-05T18:15:10Z MM/DD/YYYY HH:MM:SS - Example: 12/05/2025 13:15:10 |
| TransactionNumber | Required | This is the transaction/check/order/receipt number for the sale. | If a check has 3 different line items, the TransactionNumber will be the same for all 3 items. |
| LineNumber | Optional | This is a string, and does not have to be a number. If able this should be the line ID or unique identifier for this line. If not provided, the file placement will be used. | If a check has 3 different line items, the LineNumber will be different for all 3 items. |
| RevenueCenter | Required | Revenue Center should always be provided. | |
| UnitDiscount | Optional | Should always be negative. This is the discount per 1 quantity of the item sold. If not included, discounts will not be supported for this integration. | Example: 2 of the same item was sold at the same time, the UnitRetail for each item is 10 and there was a 25% discount applied, the UnitDiscount would be -2.50 |
| DiscountDescription | Optional | The description of a discount. If the UnitDiscount is provided but DiscountDescription is not, discounts can still be supported by this integration. | Examples: 100% comp, 25% Discount, Employee Discount |
| RegisterName | Optional | The name of the register | |
| RegisterNumber | Optional | The register ID. This is a string and does not need to be a number. | |
| EmployeeName | Optional | The employee's name. | |
| EmployeeNumber | Optional | The employee's ID. This is a string and does not need to be a number. | |
| ItemID | Optional | This is the YD ItemID for the item. Should only be provided if itemNumber and/or SKU are not being used. | Example: 6890DD8B-F1DE-11EE-A04B-00051B5D4B1B |
| StoreID | Optional | This is the YD StoreID. Required if the Revenue Center is not provided. | Example: 18363386-B7FD-430D-9B7E-00619276068C |
| IsModifier | Required* | This is required if supporting modifiers. This is true/false to identify modifier items. Modifiers must appear in the file directly after the item they are modifying. | |
| ModifierParentProductId | Required* | This is required supporting modifiers and if the item is a modifier. This is the ItemNumber for the parent item |
F&B Example Transactional Files: See Here
Retail Example Transactional Files: See Here
The following details the required and optional fields for a Summary sales file. If possible, the recommended method is to provide transaction level data.
| Sales data | Summary File | Description | Additional information |
|---|---|---|---|
| ItemNumber | Required* | ItemNumber is a unique identifier for an item in the POS System. This is required for mapping YD recipes to POS items. | |
| SKU | Required* | Required if the ItemNumber is not provided. Sales will match on SKU. POS SKU must match YD SKU. | |
| Item | Required | The description of the item sold. | |
| Quantity | Required | Quantity sold. Positive quantities = sale Negative quantities = return | |
| UnitRetail | Required | Should always be positive. This is the unit retail per 1 quantity of the item sold. | |
| DateTime | Required | The date of the closed sale. | Example: MM/DD/YYYY |
| RevenueCenter | Required | Revenue Center should always be provided. | |
| ItemID | Optional | This is the YD ItemID for the item. Should only be provided if itemNumber and/or SKU are not being used. | |
| StoreID | Required* | This is the YD StoreID. Required if the Revenue Center is not provided. |
F&B Example Summary File: See Here
Retail Example Summary File: See Here