How should invoices and payments be created?

Lesson 9 of 15 8 min read

The Invoice settings that decide whether invoices are created as reserve invoices, which warehouse they carry, and when a payment is recorded alongside them.

If you create invoices in Enterpryze through Supply Lens, for example for web orders that have already been paid, the Invoice Configuration decides what those invoices look like and whether a payment is recorded with them. This lesson groups those settings into three decisions.

Good to know

The Invoice Configuration also has the Business Partner settings from the previous module (group, price list, account code, payment terms and addresses), plus defaultDueDateDays, sendEmail and the address format settings you met on orders. They work the same way here.

Decision 1: reserve invoice or ordinary invoice?

A reserve invoice is created in a draft-like state, so it is not immediately finalised. An ordinary invoice is final when it is created.

createInvoicesAsReserve	When true, every invoice is created as a reserve invoice, whatever its financial status. This adds an extra step before invoices are finalised.
createPaidInvoicesAsReserve	When true, invoices for paid orders are created as reserve invoices, so they are not immediately finalised.

Guidance:

Choose createInvoicesAsReserve if your finance team wants to review every invoice before it is final.
Choose createPaidInvoicesAsReserve if paid orders in particular should wait, for example until the goods have left the warehouse.
Leave both off if invoices should be final as soon as they are created.

Decision 2: which warehouse goes on an ordinary invoice?

fallbackWarehouseCode	The Enterpryze warehouse code sent on every line of an invoice that is not a reserve invoice. A reserve invoice is always sent without a warehouse code, whatever this says.

Enterpryze requires a warehouse on every line of an ordinary invoice, and the invoice Document in Supply Lens carries no location to take one from. So:

Blank means failure

If fallbackWarehouseCode is blank, every invoice that is not a reserve invoice fails translation. If you create ordinary invoices, set this to a valid Enterpryze warehouse code. Supply Lens cannot check warehouse codes against Enterpryze, so double-check the spelling.

Decision 3: should a payment be recorded too?

generatePaymentByFinancialStatusMap	Maps each financial status to true or false: whether a payment is generated in Enterpryze for invoices in that status. Supports a default for statuses not listed. An invoice worth nothing never gets a payment, whatever the map says.
sendPaymentOnResend	When true, a payment is generated even when an invoice is being resent rather than created for the first time.
setPaymentAmountToCreatedInvoiceTotal	When true, the payment amount is the invoice total as created in Enterpryze, rather than the amount from the source document. Useful when Enterpryze applies adjustments or rounding.
transferAccountTagMap	Maps order tags to the transfer account used when generating payments, so different kinds of order can be paid into different accounts.

Guidance:

Generate payments for statuses that mean the money has been taken, such as a paid status, and not for statuses where payment is still pending. Use the default for everything else.
Turn on setPaymentAmountToCreatedInvoiceTotal if you see small differences between the invoice total and the payment, so invoices are not left open by a penny.
Use transferAccountTagMap when, for example, PayPal and card orders settle into different accounts and carry different tags.
Think carefully about sendPaymentOnResend. It is useful when the original payment was never created, but check you will not record the same payment twice.

An illustrative example (check the exact status names with your implementer):

"generatePaymentByFinancialStatusMap": {
  "paid": true,
  "default": false
}

Rendering diagram...

Fernhill invoices paid web orders

Fernhill's finance team wants paid web orders invoiced in Enterpryze with the payment recorded, so the customer balance is zero. It sets generatePaymentByFinancialStatusMap to paid: true with default: false, sets fallbackWarehouseCode to its main warehouse code, and turns on setPaymentAmountToCreatedInvoiceTotal after spotting a few one-penny rounding differences in testing. It leaves both reserve settings off, because the team does not want to finalise invoices by hand.

Recap

Reserve invoices are not finalised immediately: choose all invoices, paid invoices only, or neither.
Ordinary invoices need fallbackWarehouseCode. Blank means they fail. Reserve invoices never carry a warehouse.
generatePaymentByFinancialStatusMap decides which financial statuses get a payment. Zero-value invoices never do.
setPaymentAmountToCreatedInvoiceTotal avoids penny differences, and transferAccountTagMap routes payments by tag.
Use sendPaymentOnResend with care to avoid double payments.

Quick guides for this topic

How do I add Enterpryze?

Complete and continue

Your progress is saved in this browser. Create a free account to keep it everywhere, take quizzes and earn certificates.

How should sales orders be created in Enterpryze?Which documents should Supply Lens pick up from Enterpryze?