Cookbook events

Cookbook events

Reset, process, or view cookbook events

The Cookbook events chapter is used to reset, process, or view cookbook events pertaining to a specific financial period, organization unit, order ID, and more.

Authorization

In order to be able to access this chapter, you need the FinancialEvents functionality.

Overview

The initial chapter overview provides a birds eye view of all cookbook events regardless any filters so, make use of those filters on the right sidebar to narrow down your results if needed.

Order hyperlink

Each cookbook event is hyperlinked to the corresponding order (if applicable). Clicking the order will navigate you to that orders Order detail page.

filters

The filter fields are quite self-explanatory on what to expect if used (combining filter fields is possible for additional fine-tuning of your overview results).

Event status

A Financial event has one of these possible statuses:

Status	Description
Unprocessed	The event was recently created and hasn't gone through cookbook yet.
Processed	The event was successfully booked into one or more general ledger entries.
Ignored	The event was intentionally ignored.
No processing required	The event doesn't require processing, for example when the event was created for an OrganizationUnit that does not create financial bookings.
No matching recipe	There is no matching recipe for this financial event type, so it's currently falling through the cracks or maybe not. It should either be explicitly ignored, or a recipe has to be created for this type of event.

Event types

All financial events have a certain type for which a recipe can be created. The following are all possible event types:

Sales

A Sales event is generated when a sales order, or part of a sales order, is invoiced. The amount of the event is the gross amount invoiced, so including any sales tax. So if a sales order with a total amount of €100,- after taxes is invoiced, a Sales event with an Amount of 100 is created.

SalesTax

A SalesTax event is generated at the same time as a Sales event, but contains only the sales tax portion of the invoice.

SalesDiscount

A SalesDiscount event is generated at the same time a Sales event is generated, but only contains the gross discount invoiced amount. So if there's an order with a sub total amount of €100,- (before discount), and a €10,- discount, would in turn render a total due invoiced amount of €90 as a SalesEvent,- and a SalesDiscount event with an amount of 10.

Purchase

A Purchase event is generated when a purchase order, or part of a purchase order, is invoiced. The amount of the event is the gross amount invoiced, thus including any sales tax. Therefore, if a purchase order with a total amount of €100,- after taxes is invoiced, a Purchase event with an amount of 100 is created.

PurchaseTax

A PurchaseTax event is generated at the same time of a Purchase event, but would only contain the sales tax portion of the invoice.

PurchasePriceVariance

A PurchasePriceVariance event is generated when a purchase order is received, whereby there is a difference between the cost prices of the goods, and the purchase price for which they were bought in that purchase order.

PurchaseInvoiceDispute

A PurchaseInvoiceDispute event is generated when an invoice exists. When disputes surface on a created invoice, it will be booked on invoice(line) level with an amount that is the dispute amount.

PurchaseInvoiceDisputeResolved

A PurchaseInvoiceDisputeResolved event is generated whenever disputes on invoices are resolved. This can happen both when the invoice is booked or afterwards. The amount equals the dispute amount.

PurchaseDiscounts

A PurchaseDiscounts event is generated whenever purchase orders with discounts are invoiced. The amount equals the discount amount.

CostOfGoods

A CostOfGoods event is generated when an order, or part of an order is invoiced. The amount of the event is the cost price of the products that were invoiced.

Payment

A Payment event is generated when a payment has been successfully completed. The amount on the event is equal to the paid amount. A payment is not necessarily associated with an order and can exist on its own.

PaymentEndRounding

A PaymentEndRounding event is generated in the case that the order amount has more than two decimals. For example, the order total due amount is 18.4050, but the amount that a customer pays is always rounded to two decimals, so the customer will be paying 18.41. The difference is then registered as a PaymentEndRounding event.

PaymentSettlement

A PaymentSettlement event is generated when payments are settled using a settlement file from the PSP. The amount equals the settlement amount.

PaymentCapture

A PaymentCapture event is generated when payments that involve capture at a later moment (e.g. creditcard/klarna/paypal) are captured. The amount equeals the captured amount.

CashAdjustment

A CashAdjustment event is generated when a financial period is closed. The following things occur: - Expense: an expense was registered, for example, someone's lunch was reimbursed. - Cash deposit: a cash deposit to a bank was made. - Cash difference correction: when the cash register contains a different amount than what is expected, according to how many cash payments were handled for the period, a correction can be made which results in a CashAdjustment event.

StockSold

A StockSold event is created when stock is sold on an order. The amount is equal to the value of the stock that was sold, according to the unit cost of the product, multiplied by the number of products sold.

StockReceived

A StockReceived event is created when stock has been received. The amount is equal to the value of the stock that was received, according to the unit cost of the product, multiplied by the number of products received.

Shipment

In the case of Endless Aisle and e-commerce sales, there has been no delivery made yet and therefore, recognizing revenue with a Sales event at this stage will eventually lead to inaccurate financial reporting. According to the revenue recognition principle under both GAAP and IFRS, revenue should only be recognized when it is earned and realizable. In the context of endless aisle, this typically means that revenue should be recognized only when the goods have been shipped to the customer. Here is where a Shipment event comes into action. The event ensures that the revenue is recognized at the appropriate time.

StockMutation

A Stock Mutation event is generated when stock is mutated in EVA. The amount of a Stock Mutation in such event is equal to the value of the moved stock, according to the unit cost of the product, multiplied by the number of products mutated.

Stock Mutation Reasons

Stock Mutations are a special kind of event, caused by a mutation of the stock on a particular organization unit. Each mutation bears a reason, on which additional bookings can be made.

List of reasons

• Unknown
• ChangeOrganizationUnit
• Correction
• Damage
• Theft
• Movement
• CycleCountDeviation
• Sold
• Received
• Returned
• DOA
• Scrap
• InternalUse
• Demo
• SentToVendor
• InitialInventory
• UndoOrderReservation
• CreateOrderReservation
• CreateReturnRequestStock
• ReceiptDeficiency
• Revaluation
• InventoryReset
• CancelReturnRequestLine
• ReservationSurplus
• ShopClosingReturns
• SentBySupplier
• ExternalModification
• Interbranch
• ReturnToSupplier
• ReceiptSurplus
• ShipmentCancelled
• PurchasePriceVariance
• FullStockCount

StockMutationAutomaticCorrection

Creation of a stock mutation results in a negative stock balance (for example: an item was sold that according to EVA has no stock), thus an additional stock mutation event is created to adjust the stock back to zero. The financial result of this is registered as a Stock Mutation Automatic Correction event.

(Re)processing financial events

Filters impact

The filters set at the time of (re)processing will be applied in the request payload.

Processing financial events is as simple as clicking the 'Gears' icon on the top right of the Cookbook events card.

On other hand, reprocessing requires a few steps:

Step 1: Specify the events you wish to reprocess events for by using the fields available in the filter sidebar

Step 2: Click the Reset button located on the top right.

Once the reset is complete, you can now refresh the window. You'll notice that the status is now shown as Unprocessed instead of a Processed status prior to the reset.

Step 3: Click the 'Gears' icon on the top right to process the filtered events. By doing this, you'll reprocess the financial events once again, but this time against a possible updated Cookbook setup or recipe. A new export file is now also available for your middleware i.e. for your ERP system.

Processing time

Using the Reset or Process functionality might take a few minutes to conclude. You'll be notified via email once the reset is done.

Event status resetting

Clicking the 'Reset' icon on the top right of the Cookbook events card will reset the financial event(s) status to Unprocessed and will clear the associated ledgers.