The latest version of this document is here: DEAR for CFOs: Notes on Xero Accounting integration with Dear Inventory
DEAR for CFOs: Notes on Xero Accounting integration with Dear Inventory
This is a GrowthPath knowledge-base article. You may share this link as you wish.
This document is for CFO, controllers, bookkeepers and accountants who want to know how Xero works with Dear.
Essential things to review
Do you want to use the powerful feature Tracking Categories for profit-centre accounting in Xero? See Tracking Categories
Do you need to add some accounts? See Required Accounts
Are you using account codes in Xero? They are needed for Dear. Any account in Xero without an account code will not be visible in Dear.
- Dear acts like a traditional ERP. A traditional ERP is financially split into subledgers, such as Sales, Inventory, which post to the GL. The difference is that instead of posting to the GL, Dear ‘posts’ to Xero via the integration..
- Dear is the owner of the stock subledger.
- Xero is the source of truth for all other ledgers, even those where Dear provides most of the source transactions (such as AR).
- The steps you would go through in a traditional ERP are still valid in Dear. That is, good financial controller practice of reconciling ledgers each month is just as valid with Dear.
- The integration is partially two-way: under some circumstances, you can enter customer and supplier payments in Xero and have them import to Dear.
- The integration works well, but has some important practical weaknesses, and you must keep on top of sync errors. The weaknesses relate mostly to documents changing in Dear after they have synced to Xero.
- Dear is not a standard costing system. It is a FIFO system based on actual stock costs, which is like average costing in the long run, but actual cost differs from average costing for any given transaction. Costs on purchased stock come from FOB supplier pricing and can be supplemented by expenses absorbed into stock (“landed costing”).
- However, average costs are used to estimate margins at some places, for example at order entry. The true margin of a sale can only be known when particular items are picked for the order, as this locks in the actual cost.
- The default costing, FIFO, is an algorithmic or “logical” actual cost: it assumes the oldest stock is the next to be shipped. To track real-world stock movements, use batch or serial number costing methods.
- We do not import transactional history into Dear from the prior system.
- It deals well with multiple currencies.
This means Dear has ownership of Inventory, Inventory Adjustments, COGS, the Purchase Accrual accounts and WIP process accounts associated with assembly & manufacturing.
For those accounts, the only transactions in Xero are those which originate from Dear, in proper usage. It is a mistake to manually journal to them.
Unfortunately, though, we do not have formal control accounts in the Dear/Xero combination. That is, we cannot stop someone journaling to the inventory account.
If there is a need to make adjustments to any of those accounts, create a new Xero account (a contra or variances account) and book manual adjustments to that.
This discipline makes the reconciliation process much easier.
- Xero’s Tracked Inventory feature is not used when we have Dear.
Dear has a full trial balance, but to the user of Xero, it is mostly irrelevant. That is, Dear has a GL backend. But it is not very good and it should largely be ignored.
It goes almost without saying that Dear is a perpetual inventory system, like any modern ERP. Stock is capitalised on acquisition, and expensed when shipped. The value of stock can be increased by absorbing acquisition costs such as inbound freight, or costs when moving stock between locations; these are known as “landed costs”. If stock value is changed after it has been shipped, Dear will still generate additional COGS journals.
Transaction dates/effective dates
Dear has some limitations about stock movements with retrospective effect. Each transaction which affects stock value has a transaction date, which is aligned with Xero. So you can always control the financial effective date of movements. However, you can not always insert physical stock movements into a prior date. I will not explain this further here; it is hard to explain, but you will know it when you see it.
COGS vs Revenue timing, Revenue Recognition Issues
As is typical with perpetual inventory systems, revenue is recognised with the invoice is authorised, and the associated COGS is generated when the shipment is authorised. This leaves us open to timing differences: a sale on the last day of the month without a shipment will be a 100% gross margin sale.
Unfortunately it is hard to use Dear’s reporting to reliably report on this. However, GrowthPath’s Dear Analytics module provides this reporting, as well as many other advanced reporting options.
Documents/Transactions sent to Xero by Dear
There are many events in Dear which do not cause financial events in Xero.
For example, authorising a sale or PO does not cause any financial event in Xero.
Dear sends the following documents to Xero.; that is, the list below are events which do have financial consequences.
This is the “maximal” list, if all features are activated, which is typical for a GrowthPath configuration.
Dear is the sole source of truth for stock value.
Xero is the sole source of truth for all other subledgers.
Mapping of Dear to Xero
AP Invoices, when authorised in Dear. Trigger is invoice authorisation. Note: Purchase orders can be sent to Xero too but this has no financial effect, it is just for information.
AR Invoices, when authorised in Dear. Revenue/Receivables booking is triggered by invoice authorisation.
MJ (Manual Journal)
Journals to change stock, when a shipment is authorised
Journals to change stock, when a PO receipt is authorised (some special rules for partial receipts in the Simple Purchases module)
Stock adjustments and stock takes can affect stock too, via journals
Manufacturing processes will consume stock for components, and add finished goods. Manufacturing processes also allow for overheads, which are absorbed into stock, the necessary journals are sent to Xero
Payments and Refunds on Invoices
Customer and supplier payments, deposits and refunds create entries in Xero.
Paying with Dear Customer Credit
This is treated like a standard payment
Conversion of CN to Customer Credit
Payment of Xero CN
This step pays the Xero CN!
Paying document with CN in Xero
Paying bills and invoices with CN in Xero does not sycn to Dear
Dear generates accrual transactions for stock receipts before the supplier invoice is booked, and for when the invoice is authorised before the receipt has happened
Dear will move inventory into WIP or GIT in some manufacturing steps, and in some stock transfers (depending on user choice)
Landed costs/capitalised expenses
Landed costs: Dear allows non-stock invoices to be capitalised into stock. Both the supplier invoice with FOB or ex-works pricing is booked (the traditional source of product cost) and then service invoices (such as freight, duties and clearing costs) are booked in Dear, creating DR entries to expense accounts. Dear has an interface to apply service invoices to stock receipts. Dear updates its product costs, and creates a journal in Xero to CR the expense entry and DR stock.
Landed costs/capitalised expenses
Capitalisation of expenses (‘Landed costs’) can also apply to production orders and stock transfers
Dear can also send Purchase Orders to Xero when they are authorised in Dear. This has no financial effect, but gives extra visibility in Xero of upcoming financial commitments.
When does sync happen?
The Golden Rule
Once there is a payment applied on a Xero document, Xero will accept no modifications. This generates sync errors on the Dear side.
Bulk updates of Xero payments are possible via the Xero API, but there is no GUI way of doing it easily.
By default, the synchronisation is triggered manually. It typically takes one to two minutes.
It can be scheduled to run automatically.
Documents are triggered for sync when
- the document is authorised
- an authorised document changes
BUT NOTE! Not all changes will successfully sync. Xero has rules
- Lock date (remove or change lock date)
- Payment on document locks the document (remove and undo payment)
Undoing documents in Dear does nothing in Xero.
Voiding a document in Dear voids it in Xero as long as no payment exists on the Xero document.
Two-way Payment Sync
Dear has two-way payment sync.
Payments created in Dear are sent to Xero. Payments entered in Xero are pulled into Dear.
For each payment, the interface remembers which side authored the payment, and it only considers changes made from the authoring side.
There are circumstances which stop successful synchronisation. GrowthPath has a knowledge base article on fixing sync problems, including those related to sync errors.
Lock-dates, Audit Trail and Business Control
Xero has two lock-dates: ordinary user and advisor users.
Dear has lock date features too. It accepts and deploys the ordinary user lock date in Xero, so both systems have the same lock-date. You can override the Xero lock date in Dear’s settings, but it will always refresh with the Xero lock date when you next do a Xero sync, so the effect of changing the lock date in Dear is only temporary.
Dear has an excellent audit trail, and it clearly shows the accounting entries created by each transaction.
Dear has a much more refined user permission module than Xero, and Dear will not be the weak link for business control.
Accounting Transaction Reconciliation
Dear has a good reconciliation tool to verify transactions in Xero vs the Dear record of the transaction. Every month, stock and cost of sales should be reconciled.
Dear and Xero work well with foreign currency. Xero maintains AR and AP in the customer or supplier currency, translating to base currency when a trial balance is run. Dear sends invoices and payments to Xero in the currency of the supplier, customer or payment method, it does not translate them to base currency. Therefore, Xero linked to Dear performs unrealised and realised gain/loss calculations the same as it does normally.
If you want to regularly create invoices for a customer in multiple currencies, you need multiple customers, although you can also change the customer currency before creating a sale. The Dear user interface does not support setting the currency when creating a sale.
Stock is valued in the base currency.
Assuming you are using purchase accruals, Dear can receive stock before the supplier invoice is booked. Therefore, it uses the PO prices and exrate. At this point there is no AP. Later the invoice is booked. The invoice prices may be different, so an adjustment is made to stock so that the final valuation agrees with the invoice, according to the invoice exrate. At this point, the invoice ex-rate is locked in as far as stock goes. If the invoice is not booked, the value of stock is offset by the accrual account “Goods Received but not yet invoiced”, and there is no gain/loss accounting, since both these accounts are in base currency.
After the invoice is booked, we have an AP amount is in a foreign currency created at the exrate active in Dear at the time, which was also used to value the stock,
The invoice is paid, once, or more than once, and whenever it is paid, and exchange rate is finalised. While Xero keeps track of foreign currency AP balances, every time you make a trial balance, the AP is converted to base currency. This means that the value of stock, the value of the payable and the value of the payment all need to be the same. Because the exrate changes, this is very unlikely to be true. A gain/loss account is used to bring them back into alignment. The part that can’t be revalued is the part that was converted into base currency at some point in the base. For purchasing, this step is the stock receipt. For sales, it is the revenue amount on the invoice.
Gain/loss accounts make the accounts balance.
Before there is a payment, the difference on any day is the difference between the value of the foreign currency document and the value of the associated “frozen” conversion to base currency. In reality, it is simply the difference between the historical exrate and the exrate when the trial balance is made. These are the two exrates that Xero needs to know for its calculations, and it gets them from Dear.
This varying difference changes from day to day, depending on when you run the trial balance. It’s called an unrealised gain/loss/
At the same point, a payment is made or received. At this point, the AP or AR balance disappears. The exchange rate is no longer varying, and the gain or loss at that point becomes “realised”.
Tax: you should seek advice from a tax accountant, but in general, realised gain/losses are part of your taxable income, and unrealised gains and losses are not.
Consolidation of multiple Dears in different base currencies
GrowthPath’s Dear Analytics Connector takes transaction data from multiple Dear instances into one data warehouse, and it can convert to a reporting currency.
Revenue, COGS, Stock Valuation and Perpetual Inventory
Dear is a perpetual inventory system. Stock is an asset, and shipments generate cost of goods sold bookings. Revenue is booked when an invoice is authorised.
Dear values stock in the base currency. Supplier invoices are the main basis for stock valuation, and Dear has a good landed cost system. Landed costs are allocated weighted by value be default, but can be allocated with other methods, such as physical volume, qty or user choice.
Products can be costed in bulk: FIFO is used. The stock value is distinct per warehouse.
Landed costs can be pushed onto stock receipts (from suppliers), onto production and assembly orders, and stock transfers between warehouses.
Products be costed by batch (which is also the solution for warehouse-specific costing), and by serial number (individually).
It does not do standard costing (except to overhead costs added to a BOM)
FIFO is not exactly the same as average costing, although it is the same eventually. Dear does not do average costing, but it uses average cost for margin estimates when a sales order is being prepared. The actual cost is not known until particular stock is allocated to the order, when happens during fulfilment.
Stock can be revalued by writing it down and re-receiving it.
Stock Reconciliation and Stock Value
Dear should be viewed as the source of truth for the stock ledger. That is, Dear substantiates the value of stock in the Xero Balance Sheet.
It is possible for Dear to use multiple inventory accounts: they are assigned at the product level. If left blank, a product falls back to the default stock account. I will assume there is only one stock account in use, to keep these notes simpler.
I also assume that Purchase Accruals mode is activated.
Dear usually has two different stock values at any time for technical reasons
Dear has a value it assigns to every item in stock. You can see this value in the Inventory Movement Summary report, which serves as the “As On” stock report, since you can run it for any date. Therefore, this report will generate a value for all stock on hand.
THere is also a value on Dear’s balance sheet, which can be different to the stock on hand valuation. The difference is due to temporary timing issues, and incomplete document processing. So the difference should be periodically reviewed and understood.
Not every item in stock is booked to the inventory account due to timing effects and some other technical reasons. Dear has a report in the Finance section to report on source documents which have caused differences between stock on hand value and balance sheet valuation.
The Dear Balance Sheet stock value should agree with Xero, not necessarily the value of stock according to the Inventory Movement Summary report.
Manufacturing Costs: Overheads in BOMs
Non-inventory items can be added to an assembly BOM in Dear. A typical example is an estimated labour cost. You may say that there is 0.5 hours of labour per assembly.
You need to have a service item defined, which has an “expense” account associated.
The assembly process will actually create a CR entry to this account.
This is a “manufacturing variance” accounting entry, if you are familiar with traditional cost accounting. It is a type of contra account.
The full accounting entries are:
At the time of auto-assembly or completion of a Finished Goods (manual assembly), inventory on hand is increased for the parent BOM (what you just assembled) and the components are taken out of stock. This has a $0 net effect on stock. But if you have a service item in the BOM, this will be included in the value of the assembled item. For instance, if you assemble one Tank, and it has $25 labour, the booking is
DR Inventory $25
CR Service Item Expense Account $25
Accounting reporting effect: $25 favourable effect to profit, as expense is transferred to the balance sheet (inventory)
And then later, when the item is shipped:
CR Inventory $25 more than otherwise*
DR Cost of Goods Sold $25 more than otherwise
* “more than otherwise” means without adding the labour cost to the BOM
Accounting reporting effect: return of the labour cost to the P&L as a higher COGS
You have removed $25 from your expenses, and put it into stock. Your profit is higher. This is only a temporary effect because the $25 of capitalised labour will cause a higher cost of goods sold (COGS) when the item is shipped. In highly seasonal businesses which build up stock over months, the timing effect must be considered, as the months of producing stock builds will be highly profitable as labour costs “disappear” into the balance sheet.
The CR booking to the service item’s expense account is a “variance” account if you can compare this amount to an actual expense. For example, if you recorded your wage bill so that manufacturing labour cost went to an expense account separate for non-manufacturing wages,, then the CR entry should exactly equal the DR expense for manufacturing labour, in the perfect world where your estimates of labour per BOM assembly were entirely correct. Any difference between the wage expense and the CR account indicates a “variance” which is an inaccuracy in the BOM estimates. It could mean that your estimate of labour overhead on the BOM is inaccurate, which means that your cost price of the item is inaccurate. This ability to compare estimated costs taken in to the cost price against actual real-world expenses is a valued feature of variance accounting. But you don’t have to use it. If you are happy with your estimates and can’t realistically make use of a variance figure, there is no need to do anything.
Sales Invoices and Goods Movements
Dear is a perpetual inventory system so the shipment is a separate transaction to the sale.
The invoice and the shipment can be on different dates: watch for this at month end. It is possible to have the COGS and the Revenue in different months.
One order can have any number of shipments, and any number of invoices. There is not necessarily a one-to-one relationship between a shipment and an invoice.
Shipment in Dear
Dr Cost of Goods Sold (there is account mapping logic to determine the account)
Cr Dear Inventory
Invoice in Dear
Dr Accounts Receivable
(with tax entries as well)
Settings for timing of revenue and COGS
The shipment date is most often set to default to the date the shipment is created. The alternative is to choose invoice date, but this only makes sense for flows where the invoice is created before dispatch (B2C for instance).
The invoice date
The invoice date is a bit more confusing. Dear has a setting to determine when the invoice date is created if the user did not manually choose a date., and what that date is. The “when” is more important. You can choose it to default to when the order is authorised, or when the invoice is authorised.
If your flow is Shipment then Invoice, I suggest
- Subscribe to the Automation module, and build a rule to create and authorise the invoice when the shipment is authorised.
- Get the invoice to use the current date.
So, in General Settings, choose “Fill the invoice date” = “When invoice authorised” and “Fill the invoice date” = ”With the current date”.
Suggested settings for Ship-then-Invoice workflow
Chart of accounts: basic settings
- Xero makes account codes optional, but Dear will only recognise accounts which have an account code set.
- ‘Allow payments’ will allow Dear to use an account as a payment method, even if it is not a real bank
Opening balances for conversion
Not covered in this document. Items to pay attention to when converting are
- Inventory value & GIT stock
- Customer and supplier deposits/pre-payments allocated to open orders
Consider using tracking categories
This is one of the most powerful features in the Dear/Xero integration.
Xero has tracking categories, identical to what older systems call sub-accounts. You can activate one or two, therefore enabling up to three dimensions in the chart. Often these are used as a "division" and a "cost centre" (if both are used).
When tracking categories are used, each accounting entry choose the account (of course), and now a value for each of the sub-accounts.
So, a sale can now be classified into a revenue account ('Online Sales') and a division ('Export').
The division code can be used for expenses too; you may allocate freight, rent or marketing to "Export" when those invoices are booked.
This means that you can run a P&L just for "Export".
So, they are powerful.
Dear can automatically map certain things to a tracking category. The two most common are
a) using the shipping warehouse as a tracking category (for geographic analysis)
b) using the sales channel as a tracking category (export vs b2b vs in-store retail vs b2c)
It can map other fields, including custom fields.
When using Location as the tracking category, the value on the Order Header is used, not the location of the actual pick.
How does Dear choose which account to use?
Inventory accounts (Stock account, COGS account, value adjustments account, revenue account and expenses account for non-stock items) have global defaults.
They can be changed per SKU.
Users can specify particular accounts on invoices, stock adjustments, BOMs and basically everywhere an account is needed, overriding defaults selected by the system.
Dear requires some specific accounts
For official Dear notes:, which are copied into this section of the document are reading now:
with suggested account numbers based on the standard Xero chart of accounts
Inventory Control 
Current Asset: See note below
None. Can not use the existing Xero Inventory account.
Doesn't accept payments
Inventory Discrepancy [305: put this in the margin as a Direct Cost]
Doesn't accept payments
Cost of Goods Sold [310: this account may already be in Xero]
Direct Cost (DEAR standalone/Xero)
Cost of Goods Sold (QBO)
Doesn't accept payments
Supplier Deposits/Prepayments* 
Customer Credits 
*may already be created by Xero.
Special notes: Inventory
NOTE: Xero pre-loads a default Inventory account for use with its “Tracked Inventory” feature; however, it does not have the correct settings for DEAR to function correctly. You will have to create a new one with the settings listed above.
I recommend only one inventory account. Dear cannot use Xero's build in stock account, so a dedicated current asset account is required. It is possible to use multiple inventory accounts, since products can be linked to distinct inventory accounts, but it makes reconciliation more complicated, and Dear’s reports make it unnecessary to use the balance sheet to keep detail about stock holdings.
Inventory Accrual/Stock in Transit (requires Inventory Accrual to be enabled)
Inventory Accrual is HIGHLY RECOMMENDED because it makes stock reconciliation easier, and because it is accounting best-practice.
Inventory Accrual (Goods Received, Not Invoiced) 
Doesn't accept payments
Stock in Transit (Goods Invoiced, Not Received) 
Doesn't accept payments
Gift Card Liability (requires Gift Cards to be enabled)
Gift Card Liability 
Dear allows payment entry in AP and AR. Payments are sent to Xero (if enabled).
When a payment is recording, the user chooses a “payment method”, which maps to an account in Dear. Typically, these are bank accounts, such as a traditional cheque account, or a PayPal or Stripe current asset account. Therefore, Dear detects payments methods by scanning for bank accounts, credit card accounts in Xero and “payment enabled” ordinary accounts. Account codes are needed
Additional payment methods are detected: accounts which have “payment enabled” are detected as a payment method too.
In General Settings, purchase accrual accounting is set, as mentioned above.
Dear expects a PO to have stock receipt and an invoice. Assuming sensible names for the accrual accounts, the Stock Receipt books:
CR Goods Received Not Invoiced
Valuation at this stage is based on the PO price, since there is no invoice yet. This initial valuation is based on the receipt date.
And the Invoice books:
DR Goods Received Not Invoiced
CR Accounts Payable
The inventory is revalued at the invoice price. The date of the revaluation is the invoice date.
In the Product Master page, you can view the transactions which lead to the inventory valuation for that product.
Dear fetches its tax rules from Xero.
There are priority rules.
Tax Rules in DEAR can be assigned to customers, suppliers, products, the sale/purchase process and individual order lines to allow fine-grained control of your transaction process. Tax rules at the order line level override all other tax rules.
The order of priority is as follows:
- Order line
- Purchase/Sale process document header
Payment terms and due dates
Dear pays no attention to Xero’s settings for terms. It calculates them, and sends to Xero a due date on the document.
Starshipit is an excellent cloud-based transport manager, for dispatching, manifesting and interacting with couriers and other transporters. We have clients who are very happy with the product, and with the support. GrowthPath rates Starshipit very highly.
The out of the box Dear integration has some deficiencies. It doesn't work with advanced orders (multiple fulfilments) and it struggles with high-volume sites (> 400 orders a day).
This performance problem is not a problem with Starshipit or Dear, just a problem with the integration.
GrowthPath has a much more sophisticated approach to Dear integrations, with logic and techniques that provide a much more powerful and higher performance integration.
GrowthPath will build custom-logic into the integration. Some examples of this are below. Our development is in-house.
Overview of the GrowthPath Starshipit Integration
- Completely replaces the existing Starshipit Dear integration.
- Can map Dear warehouse to specific Starshipit child accounts, to support multiple locations.
- Other advanced routing logic can be built-in, to handle orders by channel, for instance.
- Works with Advanced Orders. It sends fulfilments to Starshipit, not Dear orders, so multiple fulfilments are possible.
- Will convert simple orders to advanced orders if necessary.
- Will optionally split a multi-location order into fulfilments by location.
- Will optionally auto-pick orders based on stock. This includes handling the assembly of Auto-Assemble BOMs. This feature looks back a certain number of weeks, and therefore is an auto-filler of backorders when stock becomes available, a huge time saver for high-volume businesses.
- Advanced order splitting logic, for click and collect, fulfilment of orders over multiple Starshipit child accounts if this is optimal, re-routing of orders to the nearest stock point (enabling retail locations to participate in filling online orders, particularly if they are close to the customer)
- Can send either Picked or Packed fulfilments to SSI, depending on your workflow.
- Retrieves Starshipit orders after labels are printed, and completes the fulfilment in Dear (packing if necessary)
- Retrieves Starshipit tracking details and updates Dear
- Errors and exceptions are handled by email rather than a UI. Status messages and errors are written to an additional attribute on the Dear Sales Order header. The intention is to avoid yet another login.
- Optional server monitoring via a third-party alert if services fail.
This integration is hosted on a client-specific GrowthPath Application Server. Client-dedicated servers are much more secure, higher performance and allow you to take over the server subscription at any point for business continuity assurance.
This is a high-performance integration, capable of > 1000 orders a day. It uses locking and caching and other advanced features of the GrowthPath application server.
Some of these steps require updates of the GrowthPath Dear cache in order to perform well. Therefore, they run on batch jobs every 15 minutes.
The GrowthPath Application Server will use multiple API connections if they are available. Multiple API connections are necessary for high-volume sites.
The core background jobs are monitored and can be viewed by clients upon request. This is “deadman” monitoring: it alarms if a background process does not check-in on a certain schedule.
This is a sophisticated solution for advanced customers. Usually, such businesses have opportunities for advanced logic in the integration.
To use the GrowthPath Dear-Starshipit integration, you will need to subscribe to the GrowthPath Application Server. Allow an annual fee of $2K AUD for this. You only need one subscription, regardless of how many Dear instances you have and how many GrowthPath integrations you have. If your data requirements or workload is especially high, you may need a more expensive server.
The Starshipit integration is not a subscription product. You pay a fixed price up-front fee. The price depends on the amount of custom logic you need. Allow between $6K and $20K AUD.
Dear Systems (Dear Inventory) to Zoho CRM Integration
GrowthPath has a connector between Dear and Zoho CRM which runs off our GrowthPath Application Server. Full Documentation
This is an advanced connector which has logic and mappings that go well beyond the capabilities of Zapier-style connectors. It is robust, handles very high transaction volumes and uses the advanced caching, server monitoring and other performance features of the GrowthPath Application Server.
The sync currently does a Dear to Zoho CRM push of Dear Customer to Zoho CRM Accounts and Dear Contacts to Zoho CRM Contacts. All Contacts belong to a Customer on the Dear side, and are therefore assigned to that Zoho Account.
If you have custom fields in your Zoho Accounts, Contacts or Deals, we can write logic to populate them based on Dear contents and business rules.
You can control which stages of the Dear lifecycle get mapped to which of your Zoho pipeline stages, and for each of these stages you can assign a confidence percentage of winning the deal.
You map the Dear sales person to the Zoho Deal owner, and account owner. All Zoho Accounts are owned by the Zoho user selected by the sales rep mapping logic, which chooses a Zoho user based on the Dear sales representative (more below). If your Dear Sales Rep exactly match your Zoho users, no mapping is needed.
The sync will push Dear quotes to Zoho Deals. Mapping rules below control this. As the Dear sale moves through its lifecycle, the Deal in Zoho CRM can have its stage changed.
A representation of the quote lines are saved to the Deal quote, in the description field.
This is compatible with all versions of Zoho CRM and CRM Plus.
Deployment uses the GrowthPath Application Server and a one-off fixed price fee.
GrowthPath Application server
The GrowthPath Application Server is a dedicated server with software developed to allow GrowthPath's advanced integrations.
The Application Server is a stack of software which makes it fast and easy for GrowthPath to solve complicated integration problems.
The elements of the stack are
- A robust, battle-tested cache Dear's data, including the ability to bring together all your deployments of Dear in multiple currencies
- A library of Dear automation code for ordering, shipping and production steps, which is also battle-tested. With this code, we can develop highly advanced automations and integrations
- A library of connectors to a growing range of cloud software: Zoho Analytics, Zoho CRM, Capsule, Shopify, Starshipit, Xero
- We have library for custom 3PL integrations
- A front-end server for cloud-interfaces to your customers, using Django
Based on surveying the market and listening to the customers we acquire, this technology stack is well ahead of any competitor. It is the result of constant work since 2012 and a growing number of deployments. We tend to get clients with scale and requirements which can't be met elsewhere, which is further testing and developing our technology.
What does that mean for clients?
Most of GrowthPath's integrations involve Dear Systems (a cloud ERP). An ERP is the transactional heart of your business system. Our integrations move data from Dear to other platform (such as Zoho Analytics, Power BI, Zoho CRM, Xero, Starshipit, our 3PL module), and they perform automations and updates in Dear.
Our integrations also often do automation in Dear, such as order routing, create and processing assembly orders based on a configured BOM, shipping orders after the 3PL confirms dispatch, or rewriting payment references for better B2C payment matching to bank feeds.
Some of our clients are very high volume users. Traditionally, an integration calls the Dear API each time it needs information. This does not scale very well, since the Dear API has limits. Also, several integrations may be retrieving the same information again and again, which is a waste (and it is slow). Instead, the GrowthPath Application Server has a cache which has an up-to-date copy of Dear's data. Our integrations use the cache, which is much faster. As well, locally cached data can be processed with much more sophisticated queries. Also, some larger clients use multiple instances of Dear. The cache means we can bring this data together.
Many simple integrations don't use caching because it is hard to get right. Because GrowthPath uses the same cache for many different integrations and automations, we have been able to invest and develop our cache to the point where it is a very significant technical advantage. GrowthPath's cache is widely deployed and is very robust after years of production use. It has developed many advanced features, including the ability to share its workload over multiple Dear API connections for very high volume sites that are not yet ready to move to one of Dear's dedicated server options. It contains many tweaks and optimisations .
The cache is stored in a high-performance database that offers traditional SQL and more modern JSON data processing. The Dear cache is a collection of JSON records that are straight from Dear.
Our code library has a large number of building-blocks based on the cache (for reading data) and in combining the low-level of the Dear API into business workflows. For example, we have code which will take an authorised Dear Simple Sale, and will split the order into multiple fulfilments across different locations based on logic that determines the fastest way to get all lines delivered bearing in mind costs, and then feed these fulfilments to a 3PL. When the 3PL confirms manifesting, we complete the shipment in Dear and post the tracking information back to the online portal. This complex code path is handled by building blocks we already have. Likewise, we have built a custom configurator that will read order line comments for product options, produce a configured custom BOM, and pick and complete the order assembly with a batch code based on the customer's order.
Our Analytics connector uses the cache to peform complex combinations of Dear data to enable powerful reports. It also has integrity checking to make sure the Analytics data is accurate: web-based APIs are not as reliable as traditional high-speed integrations running on the same server.
How is it deployed?
Each client gets their own server. The technology is deployed using containers, and we have a zero-downtime deployment method, so new versions are deployed seamlessly. Your key applications and services are monitored with a third-party server monitor to alert to downtime and failure. The stack is scalable, although it is not actually very CPU intensive.
The code-base is common to all clients, although sensitive information is individual to each deployment.
Most clients use a GrowthPath-deployed server, for which we use Digital Ocean. You can however provide your own server from AWS, Digital Ocean, Azure, Google. The server needs to be an Ubuntu LTS instance.
The stack uses 100% open source technologies. GrowthPath is a financial and code contributor to the main open source components we use in our Application Server, and so far two of our connector libraries are open-sourced.
Cloud ERP API Comparison
DEAR Systems, Cin7, Unleashed
Why does the API matter?
The API does two things
- it allows information to be extracted for better reporting
- It enables automation, by creating documents and actions. This means that you can automate gaps and workarounds, and add more advanced functionality.
Examples of workflows and API support
Case: Automate the creation of products from another source, such as an online store or a product master database
Case: Add a product configurator front end, and send custom BOMs to manufacturing module
Dear allows creations of assembly orders and therefore one-off BOMs, and it allows them to be stepped through the process of authorising, allocation stock and completion.
Case: For near real-time interfacing, have the integrated app respond to events as they happen in the ERP (such as order received from online channel
Dear has webhooks, which send signals to the integration, rather than the integration having to ask on regular intervals "has something happened"
The Best API: Dear Inventory
Dear has the best API, by far. It allows most processes to be fully automated, from end to end. It is also better documented, and it has webhooks, which means that you can ask Dear to contact your app when something happens, such as an order being submitted. WIthout webhooks, your app must constantly ask for any updates. (polling)
The other cloud ERPs have significant gaps, meaning there are few if any complete processes which can be scripted.
The Dear API is an add-on to the base plan, and webhooks require an additional subscription to the Automation module.
|API Version||V2||V1||Unversioned, V1?|
|API Limits||60 per min per connection but multiple connections can be added. Dedicated server plans have no rate limit.||60/min, 5000/day||Varies by plan|
|Cost||Add-on to plan||Included in plan||Varies by plan|
|Search||Yes, but limited||Yes, any field||Yes|
|Delete||Blocked for integrity, instead, make inactive||No||Yes|
|Search, Create, Update||Price Tiers (price list pricing): Yes||Price Tiers (price list pricing): Yes||Price Tiers (price list pricing): Yes|
|Advanced Pricing (matrix rules)||Note: In Oct 2021, Dear added end-points for its advanced matrix pricing capability, which makes Dear's pricing module very powerful.||No||No|
|Stock availability and valuation|
|Search||Yes, but limited||Yes, any field||Yes|
|Stock Transactions (goods movement)|
|Search||Yes||Yes, any field||Yes|
|Delete||Blocked for integrity, instead, make inactive||No||No|
|Search||Yes, but limited||Yes, any field||Yes|
|Delete||Make inactive||Make inactive||No|
|Search||Yes, but limited||Yes, any field|
|Create||Yes, via Customer||Yes||Yes, via Customer|
|Update||Yes, via Customer||Yes||No|
|Delete||Yes, via Customer||Yes||No|
|Search||Yes, but limited||Yes, any field||No (Unleashed doesn't have multiple contacts per customer)|
|Create||Yes, via Customer||Yes||No|
|Update||Yes, via Customer||Yes||No|
|Delete||Yes, via Customer||Yes||No|
|Search||Yes, but limited||Yes, any field||Yes|
|Delete||Blocked for integrity, instead, make inactive||Yes||Yes|
|Search||Yes, but limited||Yes, any field||No|
|Search||Yes, but limited||Yes, any field||Yes|
|Search||Yes, but limited||Yes, any field||Yes|
|Create||Yes (including multiple fulfilments per order)||No||Yes (including multiple fulfilments per order)|
|Update||Yes (including multiple fulfilments per order)||No||Yes (including multiple fulfilments per order)|
|Search||Yes, but limited||Yes, any field||Yes|
|Search||Yes, but limited||Yes, any field||No|
|Search||Yes, but limited||Yes (does not sync to Xero)||No|
|Create||Yes||Yes (does not sync to Xero)||No|
|Update||Yes||Yes (does not sync to Xero)||No|
|Search||Yes, but limited||Yes (does not sync to Xero)||Yes|
|Create||Yes||Yes (does not sync to Xero)||Yes|
|Update||Yes||Yes (does not sync to Xero)||No|
|Search||Yes, but limited||No|
|Search||Yes, but limited||No||No|
|Search||Yes, but limited||No||No (Unleashed does not handle payments)|
|Create||Yes||No||No (Unleashed does not handle payments)|
|Update||Yes||No||No (Unleashed does not handle payments)|
|Delete||Yes||No||No (Unleashed does not handle payments)|
|Search||Yes, but limited||Yes||Yes|
|Search||Yes, but limited||No||No|
|Search||Yes, but limited||Yes||Yes|
|Search||Yes, but limited||Yes||Yes|
|Search||Yes, via Product||Yes||Yes|
|Create||Yes, via Product||No||Yes|
|Update||Yes, via Product||No||Yes|
|Delete||Yes, via Product||No||No|
Cloud software is simple. Implementations should be too.
Since 2013, a 100% success rate (client still using the system three years after going live).
We reduce risks
By being vendor neutral, and using our Go/No-Go milestone, we eliminate the wrong-system risk.
We focus on pragmatically getting ready to go live. There are always surprises after going live. We build that in to the project plan, an approach born of our experience on both sides of ERP implementations.
Advanced Data Conversion
With deep expertise, automation, API scripts and a lot of business feel, we treat your valuable historical data very seriously. Data conversion done wrong is huge business risk.
We build self-sufficiency
Our fixed price implementations finish with a Handover milestone, not with a Go Live milestone. We guide implementations with a strong focus on knowledge transfer.
This is your new system. Your key users need to explore it and learn it, which is why we guide the implementation, rather than manage it. The result? No reliance on third parties to keep using the system.
In-house CRM, Analytics and 3PL connections
GrowthPath has mature CRM connectors with both a simple CRM, CapsuleCRM, and an sophisticated CRM, Zoho CRM. Our integrator goes well beyond standard connectors, include two-way contact sync and quote sync.
We have a sophisticated and powerful Dear to Zoho Analytics connector, which can even source data from different Dear instances in different base currencies.
We have a framework for powerful 3PL integrations
We have advanced reporting for long-lead-time businesses, including promise date calculations based on in-bound POs, even fast enough for dynamic updating of Shopify shopping carts.
A GrowthPath project proceeds in milestones, until all the key pillars of the ERP implementation are ready.
Reaching the Go/No-Go milestone is the first part of the project.
Cloud ERP Implementation FAQs
How long does it take?
Three to five months, typically. Very hard to do it faster and do a good job. If you want to rush, you can expect higher fees because the risk of rushed projects goes up a lot, and we value happy, self-sufficient clients. To succeed, we need real users to work in this project, and real users have real jobs to do in the meantime.
What about the planning fallacy?
The planning fallacy means projects usually take longer and cost more than people think, because people are biased towards optimism (which is usually a good thing) and because there are people who benefit by promising a faster completion date than they actually think is possible.
The best advice against falling into the planning fallacy is to
(a) not to treat the next project as something completely new, but to instead respect the experience of previous projects
(b) make sure people don't have incentives to over-promise
GrowthPath does fixed price projects, and we base our estimates of experience.
How long does it take someone to learn the new system?
A a rough rule, users should allow 20 hours of good quality system exercises to reach sufficient competence to go live.
Most of of this is self-directed learning. GrowthPath does have project options where we provide a lot of hands on training, but most clients don't pay for that, and have very successful implementations anyway. In these standard implementations, users get about five to seven hours of training with GrowthPath. We prefer this approach, because it cements knowledge transfer and the objective of becoming self-sufficient.
How much does it cost?
GrowthPath does fixed price quotes. Our proposal is based on a quite a lot of preliminary information gathering. The proposal will include options regarding the amount of data conversion required, the type of training, whether GrowthPath does project management or not, the integrations required, the functionality required and the selected ERP system.
The fees are designed to reduce risk. This means you can stop the project if the Go/No-Go decision is unfavourable, and you will only be charged for the clearly defined fee to proceed to that point.
Does GrowthPath visit on site?
It's the cloud, so we do most of our implementations using remote technologies. We can be on-site, particularly in Asia where travel times from our Australian/ASEAN home base are reasonable. If you are based in Melbourne, you can expect onsite visits. We have implemented in Europe, Asia, and through Australia, many times without being on-site.
For business which have staff in multiple locations, our ability to remotely manage these projects is a big advantage, since even if you bring everyone together for training, multi-location support is unavoidable during and after the project. Better to choose an implementation partner who knows how to make this work.
Should we do a parallel run of old system and new system?
No. We go live when we are ready to use the new system, and that's it. Running two systems is much more than twice the work, and because systems work in different ways, you can even in a perfect world get different results.
What is the best time of the year to go live?
Our clients go live around the year. You don't have to go live at the start of your financial year. It is better to time it for a quiet period, if you have seasonality. Going live part way a financial year means some extra work bridging old and new (in payroll, for instance) but this only happens once.
Simple and Collaborative Implementation Projects
Cloud systems are simple and fun to use, and I keep the same approach with project management. Trello is a good tool. It manage due dates, it assigns tasks to people, and it's easy to use. Visually, it is easy to see what needs to be done. All key users are board members.
The Project Milestones
1. Preliminary Shortlisting
Based on interviews, a recommendation is made, addressing the scale of the business, the processes of the business and the information requirements. You should see a demo of the recommended solution, and spend some hands on time in a demo environment, to get a high level feel for how it works.
A very early GrowthPath question is: what reporting, analysis and insights do you need?
We have a detailed on-line interview used to gather a good foundation, and then we use interviews and reviews of the existing reports.
Sometimes, there may not be a clear candidate, but this is rare. Also, it is possible that a business is too complex for cloud ERP.
2. Validation/Go No Go: The most important milestone
In the Validation phase, we prove that the selected system has a high chance of succeeding.
This is the most important phase. A possible conclusion is not to proceed, but if we do proceed, we can be confident of a successful implementation.
This phase is a careful balance of investigation, setup and system exploration, without investigating every nook and cranny of the business.
It is not feasible to test every possible situation because of the time and effort applied. Auditors face a similar problem, and we use the same type of risk evaluation approach.
For success in this phase, we do a good chunk of data conversion, so there is real data to use for the validation testing. This involves key users, which is is why their system knowledge takes big steps.
Key functional areas to examine for the go/no-go decision include:
- Transaction volume
- Price rules
- Backorder management
- Manufacturing/contract manufacturing
- Critical reporting requirements
- Critical compliance requirements
3. Go Live
Going live focuses on data conversion, getting forms and reports ready, and completing the training of key users. This is a busy phase, with a lot of attention to detail, and with users doing considerable self-learning.
You may consider this as the real go/no point, but GrowthPath has never had a project fail if the decision at the end of Phase is to proceed.
Depending on your agreement with GrowthPath, you will have a period of support, usually two to three months.
When the support period is completed, we have reached handover. Your ongoing support needs should be met by the vendor of your system. GrowthPath is always available to help if required, but we do not make ongoing support an expected revenue flow. Our clients achieve self-sufficiency.
Project Timing and Client Commitment
The exact time for a project depends on the complexity of the project, the time required for technical work and the availability of key staff.
GrowthPath proposals provide more information based on the specifics of the project.
Typical projects take three months to reach the Go Live milestone, and three more months to reach Handover.
Customisations and Integrations for Dear, Xero, Cin7, Shopify, Neto and more
About Integrations and Cloud apps
Large business systems are built from modules. For instance, traditionally you had a GL module, an AR module and a Sales module. Accounting has worked like this since the days of fountain pens: it calls these modules "ledgers", so if you are familiar with the "debtors ledger" and the "stock ledger" you already understand the concept.
Business systems before the cloud bundled many modules under one "integrated" solution because there was no agreed standard to connect modules from different providers. Sometimes business systems had to be connected anyway, and it was a very expensive process, requiring custom coding and a lot of software to keep everything working. So traditional ERPs all individually reinvented their own GL ledger, not because they found some exciting new way to do double-entry book-keeping, but because it was cheaper than integrating to an already-existing GL package. All this reinventing of wheels was a bit crazy. Just like shipping containers standardised the process of loading ships, the rise of cloud computing has changed this: integrations now use standardised technology for moving information around, and asking customers to pay for reinventing the wheel usually does not make economic sense any longer.
Cloud ERP systems, such as Dear Systems or Cin7, provide a small number of standard integrations (e.g. with Xero or Shopify). Dear also provides Zapier, a "no-code" connector to a much bigger universe of Cloud Apps.
GrowthPath is an expert at more advanced integrations.
Also, we can build "internal" integrations where the API of the cloud App (Dear, Cin7, Xero...) is used to automate processes internally, such as rules-based order-splitting across different locations.
Out of the box integrations
Cloud apps have taken-off due to simplicity and price. And a reason for that is that they focus on doing a focused set of things quite well, rather than trying to many things less well. They can afford to ignore some important functionality because integrating with other cloud apps is so easy. So integrating with an "ecosystem" has become a selling point. Most apps come with a core set of integrations bundled with the package. ERP apps, such as Dear and Cin7, include integrations with Xero and Quickbooks Online, for instance, and also with Shopify, WooCommerce, eBay etc.
We call these "out of the box integrations". The advantages of these integrations are they are cheap (often bundled for free) and supported by the ERP vendor.
However, there will be gaps. There are so many CRMs, for instance, that ERP vendors would be exhausted providing their own integrations.
You may also find that even when an out-of-the-box integration exists, it isn't good enough
Bridges such as Zapier and OneSaas
There are services which let you build connections between apps with no coding. These work by distilling certain core functions. For example, a CRM app always lets you define a new contact. Likewise, every CRM lets you define a new contact. So if Zapier knows how to detect a new contact created in five ERPs and if it knows how to create new contact in 50 CRMs, then with a few clicks, it offers 250 new connections.
These services are convenient, but not compelling, since they exploit "lowest common denominator" features. The transaction-based costing can be expensive too, eventually.
Custom Integrations and Workflow Customisations
The most expensive but most powerful integration is coded specifically for your requirements. This has higher upfront costs, but lower ongoing costs, and on this basis alone it may be a good choice, although compared with Zapier, you would see payback between three and five years, typically. The business case for custom integrations must be based on the advantage of an integration which does exactly what you want.
Integration between software applications is not new: an entire layer of enterprise software called Middleware is well-known to IT managers in large firms. But the way you built such integrations was not standardised. Integrations required a huge mix of proprietary technologies, and simply accessing interface documentation required large licence fees.
Cloud apps are radically different. Documentation is free, and the interfaces are defined with open-source technologies. Most cloud apps allow free access, or cheap access, to their interfaces.
As part of our integration work, GrowthPath has written a number of advanced integrations using cloud APIs.
In some cases there are solutions in the market, but our clients wanted a more specific solution that provided better value and automation.
Cloud software is largely 'what you see is what you get'. Vendors don't do customisations per client (except Cin7). New features and improvements are frequently rolled out, but you don't have much influence is setting development priorities.
However, the APIs allow automation to be built.
Here are some examples:
- Reordering based on sales history and custom forecast logic
- Integration with global corporate procurement systems
- Advanced customer service forecasting of order completion dates
Also, integrations can include business logic, not just information exchange. For example, data can be transformed before being sent to a data warehouse for advanced reporting.
Integrations and customisations typically cost AUD $3000 - $20000. GrowthPath provides a limited but broad licence to our source code, and we work exclusively with open-source technologies: this is designed to avoid vendor lock-in with GrowthPath.
Shopify Payments and Xero Reconcilations
We have an integration which produces a bank feed from Shopify Payments for fast Xero reconciliation.
We also have an integration which optimises Dear and Xero reconciliations when using Stripe: we change the Dear payment reference to match the Stripe bank feed, allowing automatic reconciliation. We also have an automation robot which performs Xero bank reconciliations.
Document Recognition for automated PDF PO entry
GrowthPath has an integration module using Amazon's AWS machine learning document reading service, Textract, which we use to read customer PO PDFs and enter as orders into Dear.
The workflow is that you forward emails containing the PDF to an email address. Our integration will recognise the customer and enter the PO as a sales order in Dear.
GrowthPath CRM Integrations: Dear to Zoho CRM, Dear to Capsule
Most of our advanced integrations are with Dear Systems and Xero. Both Xero and Dear have very good APIs.
- Dear Inventory Capsule CRM: Dear to Capsule sync
Opportunity, Organisation and Contact sync
- Dear Inventory - Zoho CRM: Sync of customers, contacts and quotes: Read more
Dear Systems Data Warehouse/Business Intelligence Integrations
GrowthPath has a highly advanced data warehouse feed. Most of our clients connect it to Zoho Analytics.
A Zoho Analytics Dashboard combining Zoho CRM data and Dear Inventory data
"Highly advanced: means:
- We handle multiple Dear instances, even in different currencies
- Automatic integrity checking of the data
- We have developed added-value analysis tables which combine data from different Dear endpoints for powerful reporting well beyond what Dear offers, and well beyond any simple connector-based mere on storing raw data from Dear's endpoints
- Our connector uses GrowthPath's advanced Dear cache, for very high performance. The Dear cache can share load among multiple API connections. We can do very frequent updates of Analytics data.
- We have client-specific ETL layers to correct historical data errors and badly-designed attributes and classifications
Analytics, and the additional complexity of using slow and sometimes unreliable cloud APIs places unusual robustness and integrity checks. The GrowthPath connector has been live for about three years now. Around 20 Dear sites are using it.
- Microsoft Power BI and other BI Tools: GrowthPath's Analytics Connector populates a cloud Postgresql server (dedicated, not multi-tenant). This provides a high-quality set of tables for use with Microsoft BI and as a feed for other BI tools.
- This is Beta release.
Dear Systems 3PL, WMS and shipping management integrations
GrowthPath has a library of middle ware for quick deployment of sophisticated logistic integrations.
An example 3PL integration
We can handle
- Batch and serial tracking at the 3PL and Dear, or only at the 3PL
- Advanced order integration
- Reliable and Robust automatic invoice generation for partial shipments (auto-invoice what has been shipped so far), linked to web-hooks for manifesting updates
- Automatic order-splitting across multiple locations, routing fulfilments, based on business logic including optimisation logic
We have integrated with multiple 3PLs using REST APIs and traditional file transfer. Our approach is suitable for advanced integrations requiring custom logic.
We also have good experience with MachShip and an advanced Starshippit Integration which goes well beyond the standard Dear integration.
Order Configurators for Dear Systems
We have made order configurators which interact with customer-facing front end tools to allow customers to specify a range of options to build a custom product.
We then turn this into a custom BOM, produce an Assembly Order and use batch logic to link this back to the Customer Order.
Promise Dates for orders (Cin7 and Dear)
We have logic which simulates allocation of stock to orders, providing accurate order fulfilment dates, considering current stock and inbound POs. This provides customers with high-quality updates on when they can expect their order.
In some cases, clients have used this information to provide accurate back-in-stock dates. Unlikes standard approaches, our logic takes into account both open customer orders and multiple POs.
Custom Workflow automation
GrowthPath has written a number of custom workflow automations suiting specific requirements.
For example, a JV handling B2C sales with Shopify, where the JV makes the sale and collects the revenue, and is a separate legal entity (so the standard Shopify integration can't be used). Our integration routed those orders to the Dear backend, but substitutes prices for with the agreed transfer price.
It keeps Shopify updated with stock levels. It forwards fulfilment and tracking to Shopify. It creates Xero invoices in the JV Xero instance.
Simplified Shopify Stocklevel sync for Dear: Sometimes the standard Shopify integration is not suitable because it binds the product catalogs too closely, with a dangerous risk of overwriting valuable front-end data. GrowthPath has a minimalist Shopify stock sync, which bypasses the need to use Dear to manage the Shopify product catalog.
- Order import in various formats
- PO export and integration with supplier systems
- Advanced payroll data format processing
- Dear Inventory <-> Pepperi: Contacts, Product and Orders
Desktop MYOB integrations
- MYOB to Zoho Analytics
Can consolidate multiple MYOB instances into one pool of data
On July 1, 2018, the ATO requires all Australian businesses with more than 20 employees to use Single Touch Payroll. The census date is actually in April 2018. Users of MYOB Account Right Premier face an interesting problem. They are using software which doesn't really get feature updates because MYOB is encouraging subscribers to move to Account Right Live, a monthly-subscription product. This product was called Account Right Live for a few years. MYOB now calls it AccountRight, and calls the legacy product AccountRight Classic.
Account Right (Live) is not available as an upgrade for legacy MYOB users, because the new product does not have quite all the features of the existing product (although this may change). There may be other reasons it does not appeal: it requires a Windows computer. It can store data in the "cloud", but it's is often too slow and larger businesses are most likely going to revert to local data, which means you basically have your old MYOB, with all the funny limitations and dated reporting. Many businesses have stayed with legacy MYOB because they can't use AccountRight (Live) or don't find it worth the effort of changing.
The end of the road is approaching for AccountRight Classic, no doubt. However, if you are a diehard old-MYOBer, there is a solution which means you can stay with legacy AccountRight Classic at least for a little bit longer.
Easier access to Dear Inventory advanced pricing
Dear Inventory has a powerful advanced pricing module in addition to the standard ten price lists and customer-level discounts.
It also has an interim layer of customer price lists per SKU. Dear's pricing is complicated and has too many choices, but it is powerful.
King of all of these is what I call the Advanced Pricing Module, which Dear calls the Deals and Discounts module.
For a long time, I had to make this note: "Not many clients use the advanced features because it's hard to understand and hard to set up; for example, the second step requires a CSV upload in many cases."
Dear added a graphical front end to advanced pricing, making it easier to use, but this was still clunky for more than a few rules, since there was no bulk update feature.
But in October 2021, Dear has added good API end points allowing powerful automation and updates for this module. Below, I discuss how these rules are created in the backend. API supports opens the possibility of using this for more complex businesses.
Advanced pricing is the place to add quantity breaks and free shipping rules, as well as much more.
Dear Inventory has several ways of calculating pricing. Pricing for many businesses in complex, and Dear is rising to meet this ... with complex choices.
1. Simple price lists. Dear has ten.
2. Customer discount percentage of a simple price list
3. Customer price lists, at sku level. You can upload CSVs of SKU-based pricing per customer.
4. Markup pricing: You can define pricing based on cost price data
5. Advanced pricing, the topic of this article. Advanced pricing arrives at a particular price for a customer/product combination, the same as (2). However, you can define rules for groups of products, group of customers, and you can do quantity breaks too.
Finally, the rules can have start and end dates, something else you can't do with standard price lists.
The spur for this has been the drive to add B2B and later B2C portals to Dear, and there are some features added to the advanced pricing module which are only for these new sales channels.
In Advanced Pricing, there are two concepts: Discounts and Deals.
The 'Discount' says what will happen, and the Deal defines when it happens, based on the date, the customer and the product.
The rules have start and end times (for promotions) and can trigger on products based on SKU, tag, brand or category, and on customer code, customer type or tag. That's very powerful.
You can access it via Settings -> Reference Books -> Product Deals. Although first, you need to define a Discount rule to add to the Deal.
To use it:
The new form lets you apply a discount to some customers for some products, over some period.
You need to create the "discount" first, though.
Also, you must click the "Apply Discounts" button in order entry. I don't know why. I guess this is a transitional setting.
Step 1: Create discount rules
Creating discounts is done in Settings -> Reference Books -> Stock -> Product Discounts
There are three types of discounts, but 'Free Shipping' and 'Order Level' are only applicable to the Dear B2B portal.
So for the usual Dear order flow, you consider "simple discount" and "volume discounts". Volume discounts are commonly known as quantity breaks. The "volume" refers to the quantity sold on the order line.
The Dear support article is: http://dearsystems.freshdesk.com/support/solutions/articles/1000132666
"Discounts" are the "what happens" part.
Simple discounts are the most common. They include quantity breaks,
The discount and markup rules apply to the price the customer would get if the discount rule were not applied.
From the Dear article:
Types of Discount values:
- Discount amount – all prices will be reduced by this Amount, e.g. ‘$10 off all stock’ campaign. That is, the change modifies the price calculated by the standard pricing (based on the price list and any customer or product discounts).
- % Discount– all prices will be reduced by the percent specified, e.g. ‘10% off all stock’ campaign.
- Markup Amount – all prices will be increased by this Amount.
- % Markup – all prices will be increased by the percent specified.
- Price Override –this Amount is new price for the product, with no reference to what was there before.
- Flat Amount – total line cost will be this Amount.
Note that Flat Amount caps the line price, completely regardless of quantity ordered.
Step 2: Create Deals
A Deal lets you choose when a discount rule is triggered. The selections include a date range, specific or groups of tagged customers, products specified by SKU, category or brand.
Deals also offer "order-level" discounts. A pre-configured example is free-shipping once an order reaches a value threshold.
Allocation Logic in Dear Inventory, explained
Dear Inventory has two order flows, Standard and Advanced. They both let you prioritise stock with soft and hard allocations if you use manual picking. The Advanced module has another option: authorised orders with no allocation at all. In this article, we see the differences between soft and hard allocations, and how to override soft allocations to prioritise which customers get scarce stock.
You can swap a Standard order to Advanced. An order created in the standard process can move to the Advanced process via the Convert button. See the picture below.
Some tips on getting per-location costing in Dear Inventory for more accurate margins.
Dear Inventory is a cloud-based inventory system which is currently GrowthPath's default recommendation for general purpose cloud ERP systems.
Dear has a well-thought approach to stock valuation. From the beginning Dear was designed to give users the chance of activate batch and serial number tracking for receipts, and Dear decided to fully support this with FIFO product costing per batch or serial. In fact, Dear users FIFO costing as its costing method for standard stock as well; the common choice is weighted average. FIFO and weighted average are the same over time.
Like its competitors, such as Unleashed, Trade Gecko and Cin7, Dear allows multiple locations, but it does not keep costs per location.
Imagine that you are receiving stock into an Australian warehouse and a New Zealand warehouse from a Chinese supplier. You may have the same FOB price, but different landed costs. Dear handles landed costs very well and they are practical to use, so you would like to see different costs at the two different sites. However, if you have a standard product without batch or serial, the FIFO calculation is maintained across all locations: the next item you sell with have the same cost price regardless of the warehouse it is shipped from. Not what we want.
But if you activate batch costing for this product, you can solve the problem. When you receive goods, you provide a batch number. You can leave it blank, and Dear will create a batch code based on the PO number. If you apply landed costs to the order, they are also tracked against the batch. Because the batches are stored by location, shipments from the NZ warehouse will only involve batches received there. Auto-pick is smart enough to manage that if you don't want to manually choose batches.
With this approach, costing per warehouse is quite easy, and you will have more meaningful margins. The one thing we can't do with this is keep NZ stock in NZD: if AUD is the base currency of the system, stock with supplier and third party costs in non-AUD is converted to AUD and only AUD. There is no solution.
A note about Dear's landed costs: costing is updated retrospectively, so with Dear, you can receive and ship goods without waiting for supplier and third-party invoices, and still get the benefit of landed costing.
Applying relevant information to make better decisions is a very important outcome of a medium-term IT plan. Cloud solutions are really good at enabling this, even if the first phase focuses more on the operational foundations. There are many options available for cost-effective business intelligence solutions in the cloud. Amazon, for example, has developed a rich layer which has stimulated many offers: Google for “Amazon Redshift marketplace”.
Advanced reporting, or business intelligence, has three components. It has a reporting or data visualisation front end (graphs, dashboards, reports etc). It has a data store and analytical logic layer, which imports data from different sources and allows us to group and relate the data to support the visualisation layer. Business Intelligence products always include these two layers. Many of the cheaper cloud solutions, such as Zoho Reports, effectively stop with these two layers.
The third layer is very important. Technically it is know as Extract and Load, (or data transformation). This retrieves the data and processes it ready for import. It would certainly include sales data at the invoice line level, but may include other data such as Google Analytics, Facebook analytics, marketing spend, out-of-stock scores, inventory aging KPIs etc. Extracting that data is some times not simple. Possibly you have sales data coming from different systems (perhaps due to an acquisition): this extract and load layer needs to standardise the data into a common format.
The benefits from this phase really leverages the investment in the cloud-based foundation layer; it taps the potential of cloud-based systems … for a fairly small incremental cost, there is a lot of value.
A hidden gem: Neto/Saasu Integration
Neto is an excellent hosted online store. It handles wholesale and retail very well (simultaneously), and has the best-on-the-market integration with Australian shippers, anywhere. Better than Unleashed, Dear Inventory, Shopify ...
On top of that, Neto looks after multiple price lists, variations, multiple stock locations,has a decent template engine, a fast backend, good ebay integration. It does backorders like MYOB, which is actually much more suited for smaller wholesalers than the current approach of Dear and Unleashed. A startup from Queensland with Telstra as a significant shareholder. It's not perfect: It doesn't do multi-currency, its reporting is average. And it has no purchasing module. It doesn't do supplier invoices, receipts and costing. For this, is expects you to integrate it with something else. A Neto / Saasu integration offers a lot for the money.