Cookbook examples

To help you out with some of the most commonly used recipes, we'll display them right here in our Docs.

Registering cash adjustments

Accounting for cash adjustments based on a daily store closure (CashAdjustments) via Cookbook

As employees perform their day closure, they’ll perform several actions which (might) have financial impact. All of these actions result in financial events of the type CashAdjustment, which you process via your Cookbook. Below are a few common examples of flows that need accounting for in a typical retail context:

Cash drawer count deviations

• Upon day closure, employees will count their cash drawer
• Any deviations from the expected count amount will be registered as a CashAdjustment

To account for these, include this syntax in your CashAdjustment Cookbook recipe:

when: 

- [SubType] = 'CashDifferenceCorrection' 

- [CashJournal.Device.Type] = 'CashDrawer' 

 

debit: 

- book [Amount] to 87310 'RandomCashOverShortAccount4' 

with [Remark] as [Offset1] 

 

credit: 

- book [Amount] to 11510 'RandomPettyCashAccount2' 

Cash movements

Cash drawer to safe

• Upon day closure, employees will count their cash drawer
• Any amount above the cash drawer limit (as defined on the settings of the Organization Unit) will need to be moved out of the cash drawer
• Typically you would move this amount to a Safe, from which it can later be moved into a (pending) bank deposit

To account for cash movements from a cash Drawer to a safe, include this syntax in your CashAdjustment Cookbook recipe:

when: 

- [SubType] = 'CashMovementDestination' 

- [CashJournal.Device.Type] = 'Safe' 

 

debit: 

- book [Amount] to 11520 'RandomCashMovementAccount1' 

 

credit: 

- book [Amount] to 11510 'RandomPettyCashAccount2'

From safe to bank

• After moving money from a cash drawer into a safe, employees can deposit this money into a (pending) bank deposit.
• Once the deposit is really confirmed to be moved to a bank, the money ‘leaves’ the EVA view

To account for this, please use this syntax in your CashAdjustment Cookbook recipe:

when: 

- [LedgerClassID] = 'CASH_DEPO' 

 

debit: 

- book [Amount] to 11520 'RandomCashMovementAccount1' 

 

credit: 

- book [Amount] to 11510 'RandomPettyCashAccount2' 

Safe count deviations

• Depending on settings, staff can count their store safe periodically or at a random moment

To account for any deviations amounts in which they find more than the expected amount, please use this syntax in your CashAdjustment Cookbook recipe:

when: 

- [SubType] = 'CashDifferenceCorrection' 

- [CashJournal.Device.Type] = 'Safe' 

- [Amount] > 0 

 

debit: 

- book [Amount] to 87310 'RandomCashOverShortAccount5' 

with [Remark] as [Offset1] 

 

credit: 

- book [Amount] to 11520 'RandomCashMovementAccount1' 

To account for any deviations amounts in which they find less than the expected amount, please use this syntax in your CashAdjustment Cookbook recipe:

when: 

- [SubType] = 'CashDifferenceCorrection' 

- [CashJournal.Device.Type] = 'Safe' 

- [Amount] < 0 

 

debit: 

- book [Amount] to 11520 'RandomCashMovementAccount1' 

 

credit: 

- book [Amount] to 87310 'RandomCashOverShortAccount5' 

with [Remark] as [Offset1] 

Booking income and expense

Income and expenses are specified in the dedicated Income and expenses chapter in Admin Suite.

Income

When defining your income, you will have to enter a unique value (max 8 characters) in the Ledger class ID field.

This Ledger class ID needs to be used in your CashAdjustment cookbook recipe.

when: 

- [LedgerClassID] in ['OPSUPPINC'] 

 

debit: 

- book [Amount] to 11510 'RandomPettyCashAccount2' 

 

credit:  

- book [Amount] to 75110 'RandomOperatingSuppliesAccount6' 

Expenses

The same goes when creating expenses: create a When statement using the Ledger class ID.

when: 

- [LedgerClassID] in ['OPSUPPEXP'] 

 

debit: 

- book [Amount] to 11510 'RandomPettyCashAccount2' 

 

credit:  

- book [Amount] to 75110 'RandomOperatingSuppliesAccount6' 

Stock mutations

Accounting for stock mutations (StockMutations) via Cookbook

There are several actions in a store that lead to mutations of stock. Examples include the receival of items, counting stock or deducting stock due to theft. All of these mutations in turn have financial impact.

Below are a few common scenarios, including details on how to account for these via Cookbook.

All stock mutations are visible in the Overview and mutations chapter. Looking at the Stock mutations tab, you can seen any StockMutation and its reason. These reasons can be used to filter out specific scenarios in your accounting.

Full stock counts or Cycle Counts

• Any stock mutations based on a full stock count will be registered as a StockMutation with a Reason ‘FullStockCount’
• The same goes for mutations based on Cycle Counts (in that case, replace the Reason with 'CycleCountDeviation')

To use this in Cookbook, include the following in your StockMutation Cookbook recipe:

when: 

- [StockMutation.Reason] in ['FullStockCount'] 

 

debit: 

- book [Amount] to 14220 'RandomRetailInventoryAccount1' 

 

credit: 

- book [Amount] to 47820 'RandomRetailPhysicalInventoryAdjsAccount2' 

Theft

• When doing a stock adjustment whereby a SKU stock quantity is deducted based on theft, EVA will create a StockMutation financial event with the reason ‘Theft’

To account for this, use this syntax in your StockMutation Cookbook recipe:

when: 

- [StockMutation.Reason] in ['Theft'] 

 

debit: 

- book [Amount] to 14220 'RandomRetailInventoryAccount1' 

 

credit: 

- book [Amount] to 79740 'RandomTheftAccount2' 

Interbranch transactions

• When employees send items from their store to another store, EVA generate a StockMutation with the reason Interbranch.
• This accounts for the stock leaving the shipping store

In your StockMutation recipe you can use this syntax to book these amounts:

when: 

- [StockMutation.Reason] in ['Interbranch'] 

 

debit: 

- book [Amount] to 12304 'RandomStockAccount' 

 

credit: 

- book [Amount] to 12345 'Random GR/IR' 

Receipt deficiencies

• Any time an employee receives an incoming shipment to the store, but they find less items than were originally shipped, EVA will generate a StockMutation with a reason ReceiptDeficiency

Using the below syntax you can account for this via Cookbook:

when:  

- [StockMutation.Reason] in ['ReceiptDeficiency'] 

 

debit: 

- book [Amount] to 22150 'RandomGRIRglAccount2' 

 

credit: 

- book [Amount] to 88340 'RandomReceiptDeficiencyAccount1'

PurchasePriceVariances

• Any time you buy in goods via a PurchaseOrder, on which values are different from the values on the CostPrice list, EVA generates a financial event called a PurchasePriceVariance
• These are registered as StockMutations, with a reason ‘StockMutation’

You can account for these via Cookbook:

when: 

- [Shipment.TrackingCode] has no value 

 

debit: 

- book [Amount] to 22150 'RandomGRIRglAccount2' 

 

credit: 

- book [Amount] to 88370 'RandomDifferencesStandardCostingPurchasedGoods'

Automatic stock corrections

Accounting for automatic stock corrections (StockMutationAutomaticCorrection) via Cookbook

By default EVA does not like the concept of ‘negative stock’. For this reason we introduced the concept of a Negative Auto Stock Correct (NASC). In case an items has 0 stock, but an employee still wants to sell this item (because they physically have it), EVA will ‘create’ 1 item of stock that is than instantly sold, resulting in a stock level of 0 (again).

This process is covered in a separate Financial Event called a StockMutationAutomaticCorrection.

To account for this, create a StockMutationAutomaticCorrection cookbook recipe with a syntax similar to this:

recipe 'Automatic Stock Correction' for StockMutationAutomaticCorrection 

 

debit: 

- book [Amount] to 14100 'RandomRetailInventoryAccount1' 

 

credit: 

- book [Amount] to 44040 'RandomRetailCostOfSalesAccount2' 

Settlements

EVA allows processing of Payment Service Provider (PSP) settlement files, and use the outcome of that in Cookbook.

Below we show an example of this using Adyen (PSP) settlement files.

Create a recipe:

Start by creating a recipe. It would look something like this:

recipe 'Payment Settlement' for PaymentSettlement

Breakdown your recipe

Following this you can start breaking down your recipe using the various values provided in the Settlement file. A single payment settlement can be broken down into multiple values, which Adyen would then store in various columns. Using the LedgerClassID in Cookbook you can lift these values.

• [LedgerClassID] in ['Netto'] this lifts the value from the "Net Debit" or "Net Credit Fee" column in the Adyen settlement file, based on whether the underlying transaction is a payment or a refund.

• [LedgerClassID] in ['Commission'] this lifts the value from the "Commission" column in the Adyen settlement file.

• `LedgerClassID] in ['Interchang'] this lifts the value from the "Interchange" column in the Adyen settlement file.

• [LedgerClassID] in ['Markup'] this lifts the value from the "Markup" column in the Adyen settlement file.

• [LedgerClassID] in ['SchemeFees'] this lifts the value from the "Scheme Fees" column in the Adyen settlement file.

Example: Posting the net amount of a payment transaction to a single account. The cookbook recipe syntax would look like this:

when: 

- [LedgerClassID] = 'Netto' 


debit: 

- book [Amount] to 10123 'Adyen Suspense'  


credit: 

- book [Amount] to 10124 'Trade receivables EVA' 

Example: Posting all underlying fees of a payment transaction to a separate account. The cookbook recipe syntax would look like this:

when: 

- [LedgerClassID] in ['Commission','Interchang','Markup','SchemeFees'] 


debit: 

- book [Amount] to 10125 'Credit Card Fees and Commisions'  


credit: 

- book [Amount] to 10124 'Trade receivables EVA' 

Common Offsets

Various values from an Adyen settlement file can be used as Offsets to your postings. By doing so, those details will be part of the export file to your ERP.

Common examples include:

• [Payment.FinancialPeriod.ID] the "Financial period" in which the original payment transaction took place (in EVA);
• [PaymentTransactionSettlement.MerchantReference] is the EVA Payment ID (the value in the "Merchant Reference" column of the Adyen settlement file);
• [PaymentTransactionSettlement.PaymentReference] is the Adyen Payment identifier (the value in the "PSP Reference" column of the Adyen settlement file);
• [PaymentTransactionSettlement.Offset1] is the value from the "Payment Method" column of the Adyen settlement file;
• [PaymentTransactionSettlement.Offset2] is the value from the "Type" column of the Adyen settlement file;
• [PaymentTransactionSettlement.Offset3] is the value from the "Batch Number" column of the Adyen settlement file;
• [PaymentTransactionSettlement.Offset4] is the value from the "Terminal ID" column of the Adyen settlement file;
• [Payment.RefundedPayment.Order.SoldFromOrganizationUnit.BackendID] the store number of the store in which the original payment was registered for a refund. Relevant when triggering a refund from another OU (example: when refunding an e-commerce placed order from a store).
  
  

Example: Splitting American Express payments using the 'amex' value in the "Payment Method" column as exposed in [PaymentTransactionSettlement.Offset1]. The cookbook recipe syntax would look like this:

else when: 

- [LedgerClassID] = 'Netto' 

- [PaymentTransactionSettlement.Offset1] = 'amex' 

 

debit: 

- book [Amount] to 10123 'Adyen Suspense' 

 

credit: 

- book [Amount] to 10999 ’AMEX Suspense’ 

Other types of amounts in the Settlement file

There are various types of entries in an Adyen Settlement file. Not all refer to a payment transaction since a settlement file might also contain other amounts.

All entries in the "Type" column of the Settlement file are exposed in Cookbook in Offset2 of the PaymentTransactionSettlement variable.

Examples include:

• [PaymentTransactionSettlement.Offset2] in ['Fee']

• [PaymentTransactionSettlement.Offset2] in ['InvoiceDeduction']

• [PaymentTransactionSettlement.Offset2] in ['MerchantPayout']

• [PaymentTransactionSettlement.Offset2] in ['Chargeback']

• [PaymentTransactionSettlement.Offset2] in ['ChargebackReversed']

• [PaymentTransactionSettlement.Offset2] in ['InvoiceDeduction']

• [PaymentTransactionSettlement.Offset2] in ['Balancetransfer']

Charge backs:

Using the above logic you can, for example, post charge backs as follows:

else when: 

- [PaymentTransactionSettlement.Offset2] in ['Chargeback'] 

- [LedgerClassID] = 'Netto' 

 

debit: 

- book [Amount] to 10998 'Chargeback differences' 

 

credit: 

- book [Amount] to 10123 'Adyen Suspense' 

The opposite applies for charge back reversals:

else when: 

- [PaymentTransactionSettlement.Offset2] in ['ChargebackReversed'] 

- [LedgerClassID] = 'Netto' 

 

debit: 

- book [Amount] to 10123 'Adyen Suspense' 

 

credit: 

- book [Amount] to 10998 'Chargeback differences' 

You can also account for all fees associated with a chargeback by combining two conditions:

else when: 

- [PaymentTransactionSettlement.Offset2] in ['Chargeback'] 

- [LedgerClassID] in ['Interchang','Markup','SchemeFees'] 

Discounts, Markdowns & Price Corrections

Discounts

Discount postings are triggered whenever a discount configured in EVA Promotions Engine is applied to an order (or when a push order from an external system is received for an order with a separate Discount line).

These can be automatically triggered discounts like "10% off when buying 3 or more items" or a manual discount triggered by an employee pressing a button in one of EVAs Apps.

Discounts trigger a separate financial event called SalesDiscounts.

Create a recipe:

Start by creating a recipe. It would look like this:

recipe 'Name of Recipe / Sales Discounts' for SalesDiscounts

Example: To account for discounts, you'll need to enter debit and credit postings. The cookbook recipe syntax would look like this (assumes posting is done to single account):

debit: 

- book ([Amount]) to 98760 ‘Retail Discounts' 

  

credit: 

- book ([Amount]) to 54325 'Commercial Trade Earnings' 

Booking specific discounts to a different GL.

To book specific discounts to different GL accounts, use the LedgerClass of the discount (entered when configuring your discount in the Promotion Engine. This is a string value with a max. of 8 characters).

Once set-up, use the following syntax in the SalesDiscounts recipe to make the split:

when 

- [LedgerClassID] = 'SPECIALS' 

 

debit: 

- book ([Amount]) to 98761 ‘Special Discounts' 

  

credit: 

- book ([Amount]) to 54325 'Commercial Trade Earnings' 

Using product characteristics

Naturally, you can also make a split based on the products to which the discount was applied. To do so, you can for example create a condition at the top of your SalesDiscounts recipe.

This example uses the LedgerClass as set on the products in your product master data feed:

# Licensed goods 

with [isLicensed] as: 

- [Product.LedgerClassID] in ['SUNGLASS', 'FRAGRANCE'] 

Markdowns

Besides discounts configured in the Promotion Engine, EVA also allows you to apply a "markdown discount". In this set-up you configure a Selling pricelist (containing your regular base prices) and a Sales pricelist (containing the discounted prices).

More on pricelist usage types can be found here.

Using a certain syntax in the Sales recipe you can then calculate the difference between both values to book this to a dedicated GL. To do so, use the OrderLine.OriginalUnitPrice syntax as such:

debit: 

- book ([InvoiceLine.QuantityInvoiced] * [OrderLine.OriginalUnitPrice]) - ([Amount]/[TaxRate]) to 98760 ‘Retail Discounts' 

 

credit: 

- book ([InvoiceLine.QuantityInvoiced] * [OrderLine.OriginalUnitPrice]) - ([Amount]/[TaxRate]) to 54325 'Commercial Trade Earnings' 

Price corrections

There are cases in which employees need to manually override the price of an item (for example to price match with a price of a competitor, or to adjust the price of a returned item). The difference between original and new price caused by such modifications can be accounted for in Cookbook in the Sales Recipe. The cookbook syntax for such instances would look like this:

debit 
- book (([OrderLine.UnitPriceBeforeCorrection] * [TaxRate]) - [Amount]) / [TaxRate] to 98769 ‘Price modifications' 

 

credit: 

- book [OrderLine.UnitPriceBeforeCorrection] to to 54325 'Commercial Trade Earnings' 

Taxes

Tax amounts based on a sale or return create a separate financial event called SalesTax.

Create a recipe:

Start by creating a recipe. It would look like this:

recipe 'Name of Recipe / Taxes' for SalesTax

Subsequently, you can use a syntax as follows to make your postings:

debit: 

- book [Amount] to  

- when [InvoiceLine.QuantityInvoiced] > 0 then 80200 'Total Revenue'     # Sales 

- when [InvoiceLine.QuantityInvoiced] < 0 then 80207 'Return Sales'   # Return 

  

credit: 

- book [Amount] to 17810 'VAT Liability' 

North American taxes

In North America taxes are typically calculated using a third party tax engine such as, Avatax. When using Avatax, the below syntax can be used to split between the various tax categories.

Data tax name

The Data.TaxName needs the exact syntax 'QUEBEC QST/TVQ' or 'CANADA GST/TPS' as this is how data is forwarded from Avalara.

- book [Amount] to  

- when [Data.TaxName] = 'QUEBEC QST/TVQ' then 17812 'City Sales Tax' 

- when [Data.TaxName] = 'CANADA GST/TPS' then 17811 'Provincial Sales Tax' 

- when [OrganizationUnit.CountryID] = 'CA' then 17811 'Provincial Sales Tax' 

- when [OrganizationUnit.CountryID] = 'US' then 17811 'State VAT Liability' 

Including tax details in other recipes

Each posting in your Cookbook export file contains a separate field called the Tax Code Backend ID. This corresponds to the BackendID of the TaxCode that was applied to the sold item i.e. the one applied when creating this posting.

More on tax configurations can be found here.

Here is a sample of how such export would look like:

CurrencyID: "JPY" 

AccountName: "Modified Sales Own Operated" 

AccountObject: "80101" 

TaxCodeBackendID: "High" 

Offset1: null 

Offset2: null 

Offset3: null 

Offset4: null 

Offset5: null 

Offset6: null 

Offset7: null 

Offset8: null 

Offset9: null 

Amount: -75000.0000 

Remark: null 

Reference: null 

Some users prefer to have this Tax Code Backend ID field filled with the Category value of the TaxRate that was applied. To do so, you can include this ([TaxRateCategory] as [TaxBookingCode]) on any Cookbook syntax as part of your Offsets, as follows:

with [OrganizationUnit.BackendRelationID] as [Offset1], 'Text Entry' as [Offset2], [TaxRateCategory] as [TaxBookingCode] 

Rounding

In certain setups EVA will apply rounding to get to rounded (cash) amount figures. The differences this creates will trigger what is called a PaymentEndRounding financial event.

To account for this, create a simple recipe:

recipe for PaymentEndRounding 

debit: 

- book [Amount] to 12345'Random Suspense Account' 

  

credit: 

- book [Amount] to 13556 ‘Rounding differences'

More explanation on the rounding concept can be found here.