# Transactions Records that increment or decrement inventory based on customer interactions with a store ## Getting all Transactions - [GET /transactions](https://developer.yellowdogsoftware.com/rest/fetch/api/transactions/get-transactions.md): This endpoint allows for pulling of raw transaction information that is stored in the Yellow Dog Database. As this data is considered to be raw and not processed there is not a way to determine directly with certainty what items or recipes had inventory adjustments from this endpoint. Due to the various Point of Sale integrations that may be connected with the database instance, there is not a guarentee that all transactions will match using the criteria represented in the POST /transactions Endpoint documentation. ## Creates or Updates Transactions - [POST /transactions](https://developer.yellowdogsoftware.com/rest/fetch/api/transactions/post-transactions.md): ##### Matching and Processing This endpoint is all about submitting sales transactions to Yellow Dog. Identifying sales transactions. Three properties in the request payload identify the transaction and its parts. - transactionNumber - thirdPartyId - thirdPartyLineId See Submit Sales via API for guidance in using these properties correctly. Match transaction lines to Yellow Dog Items via id, sku, or itemNumber. This endpoint matches transaction lines to Yellow Dog Items by either the __id__, __sku__, or __itemNumber__ field. - line[].item.id - This will match a transaction line immediately to the Yellow Dog Item with the same id. - This is the preferred method for matching Transaction Lines to the appropriate Yellow Dog Item. - line[].sku - This will match a transaction line to the Yellow Dog Item with the same SKU. - line[].itemNumber - This will match a transaction line to the Yellow Dog Item using a Third Party ItemNumber. - This can be performed by using the POS Item Map feature in Yellow Dog. Only one of the three fields are required to have a non-null or non-whitespace value. Processing depends on checkClosed and closeout dates. Only transactions with a __checkClosed__ date later than the current closeout date will be processed. This setting can be found in the Stores Tab of YDInv. Periodic processing of transactions Transactions are added to the specified Yellow Dog database in real time as they are received but the impact of these sales on inventory is calculated by a separate periodic process. This process can be configured to run at least daily and as often as multiple times per hour depending on database complexity. ##### Examples For the examples that follow, select the corresponding sample payload from the pull-down menu in the request pane. Example A: Sending a transaction with multiple lines In ___Example A___, there was a sale of a Burger and a bottle of water. The expected total for the transaction with all the lines will have a retail of $17.00. Example B: A transaction with item modifier lines In ___Example B___, there was a sale of a Burger with the additional modifiers for adding cheese and bacon. As part of the inventory processing the use of the modifiers will allow for the processing of the transactions to deduct the 2 cheese and 2 bacon appropriately. In this example the expected total for the transaction with all the lines will have a retail of $23.00. Example C: A transaction with a Check-Wide Discount In ___Example C___, there was a sale of a Burger with the additional modifiers for adding cheese and bacon. There was also a discount set for 20% off the entire check. Notice how the itemDiscount is set for each line of the transaction. This allows for proper setting of the item price. In this example the expected total for the transaction with all the lines will have a retail of $18.40. Examples D&E: Handling of Refunded Return In this example, there was a sale of a Tee Shirt that was then returned with refund the following day. To properly handle the deduction and then increment of inventory for the two actions, there should be two separate transactions sent to the api. Here, ___Example D___ shows the initial sale and ___Example E___ shows the return. Ideally, the transactions should be marked for the appropriate times that they happened at. Notice that in this example the __thirdPartyId__ and __thirdPartyLineId__ are different values between the sale and the refund. Examples F&G: Handling of a Void or a Cancellation In this example, there was a sale of a Tee Shirt that was canceled or voided without a decrement of inventory. This could have been an accidential addition of an item for the transaction. Here, ___Example F___ shows the initial sale and ___Example G___ shows the cancellation. Since this this event is not supposed to impact the inventory onhand, it is appropriate to set the quantity of the existing line to 0 as an update to the original transaction. Notice that in this example the __thirdPartyId__ and __thirdPartyLineId__ are the same values between the sale and the voided line. ## Gets Transactions by Store - [GET /transactions/store/{storeId}](https://developer.yellowdogsoftware.com/rest/fetch/api/transactions/get-transactions-store.md) ## Gets Transaction by ThirdPartyId - [GET /transactions/{thirdPartyId}](https://developer.yellowdogsoftware.com/rest/fetch/api/transactions/get-transactions-byid.md): This endpoint is intended to be used for looking up a specific Transaction record.