Brightpearl orders and returns (for both sales and purchases) have up until now been marked as paid by the existence of a payment accounting journal (SR or PP) that contains the order reference. In version 4.90 we are introducing order_payments, which will now be the entity that marks the order as paid regardless of whether an accounting journal exists.
What action you will need to take
Before going into the changes related to order payments, here are the actions we recommend that you take before and after your account is upgraded to 4.90. The rest of this document will help explain what and why.
Before the upgrade to 4.90:
- Staff training
These changes may mean that some workflows need to be completed slightly differently so we recommend that all of the relevant staff members are informed of these changes. The users who are most likely to need to make changes will be your bookkeeper and/or accountant, and anyone who manages payments and refunds. We will be publishing a training video and the support documentation very soon.
- Update private apps
If you have installed private apps which download payments into Brightpearl you will also need to ask your developer to update the app to use the new API calls or order_payments instead of sales_receipt POST. If you plan to go fully multi-currency when it is released, then these changes should be done in time for version 4.91. We will be publishing more information on the API changes very soon.
After the upgrade to 4.90:
- Check settings
Check and update payment methods as required
- Update workflows
Ensure all payment corrections now entered are processed from orders and not from accounting
Features of order payments
Although there will be changes to some workflows, most of the payment processing workflows remain unchanged and even a little more streamlined. Here are some of the reasons you’ll benefit from these changes:
You will now be working with payment methods in the orders module instead of bank account codes, making it easier to identify which option to use. The payment method controls which bank account will be used for the accounting and whether a payment gateway opened for processing a card payment.
Order_payments mean you will have more detailed payment reports available directly within the orders module to easily track payment history, without having to check accounting. These reports will provide more information than is available from accounting, such as the payment method and type.
Control from the orders module
You will have more control over payments from within the orders module without the need to access accounting, including reversing and cancelling payments (more options being introduced soon, such as authorizing, voiding and capturing).
More detailed order payment statuses
You will now be able to filter to orders with a payment status of “Authorized”, i.e. those with pending payments (auth only) which are waiting to be captured and accounted for later.
Automatic accounting creation
As has always been the case, your accounting journals will automatically be created from the actions carried out in the orders module. The difference now is that a pending payment can be processed which will update the order payment status but doesn’t affect accounting until it is captured.
Faster & cleaner adoption of accounting module
If you haven’t been using Brightpearl accounting, Brightpearl will still have been creating the payment journals to mark the orders as paid. Now with order_payments those journals are not required, so the whole accounting module can be switched off. This also means that if you now want to migrate your accounts into Brightpearl we can fully reset the accounting module at any time without losing the details of which orders are paid. This means a faster and cleaner implementation of the accounting module if you chose to adopt it after your initial go live. As part of the upgrade to 4.90 all historical orders will be data fixed to create orders_payments, see how your account will be upgraded below.
How do order_payments work?
Order_payments will be created for any payments that are entered into Brightpearl which relate to an order or return, this includes:
- Payments entered in the orders module, directly against an order/return
- Payments entered in the accounting module, against an invoice/credit which is for an order/return
- Payments downloaded from sales channels for orders
- Payments received via the API for orders/returns
An order payment related to a sale is called a customer_payment and an order payment which is related to a purchase is called a supplier_payment.
Note that an order payment is not relevant when paying quick invoices/credits or supplier bills/credits for which there is no order or return record - no entry will be seen on order_payment reports for these financial only payments.
Processing a customer_payment in the orders module:
When a payment is entered against a sales_order an order_payment (customer_payment in this case) is created. This can be seen on the customer payment report. If that payment was captured right away a sales_receipt journal (SR) is then created in accounting. But if the payment was auth only (a pending payment) then no accounting is required at this stage.
Processing a customer_payment in the accounting module:
When a payment is entered against a sales invoice via the customer payment allocation screen (and not via the order screen) a sales_receipt journal (SR) is created. If the invoice is related to a sales order, then an order_payment (a customer_payment in this case) is also created and this can be seen on the customer payment report. If the invoice is quick invoice and therefore not related to an order, then no order_payment is created.
Important conceptual changes
These changes mean that there is a clear separation between the orders module and the accounting module. The accounting module is the final destination of all data flows and where the accountant can complete accounting tasks in isolation, without making changes across other modules. Only actions that happen in the orders module will update the accounting, and not the other way around. This is already the case for invoices and inventory accounting:
Editing, reversing or cancelling a payment
Brightpearl allows payment accounting journals to be edited or cancelled. Currently this will also update the order payment amount and status, i.e. cancelling an SR journal will mark the order as unpaid again.
In 4.90 editing or cancelling the journal will not update the order. This means that although the payment accounting can be changed or removed, the order will continue to appear paid by the original value. This is already the case for invoices, shipping of orders and receiving goods into stock - editing these journals will not change the order status or inventory values.
If you want to keep payments in sync across both modules you must ensure that any corrections for payments against orders are always done from the orders module. The changes made to the order will automatically correct the accounting as well. This is just the same as un-invoicing from the order rather than cancelling the accounting journal.
Remember that the orders module updates accounting, but accounting changes will not update orders. Performing workflows from the orders module will therefore automatically ensure that both modules are updated and kept sync.
Any workflow which involves editing the order reference directly on the journal
Up until now the bookkeeper/accountant has had control over the orders module by changes made in the accounting module. For example, if a payment was incorrectly allocated to one order, the reference in the journal could be edited to unallocate it, leave it on-account or allocate it to a different order. In 4.90 any changes made to payments for orders must be done via the orders module if it is to be reflected on the order.
If the order reference were to be changed on the journal it would only update accounting and not the order. To encourage the correct workflows to be completed that will keep all the Brightpearl modules in sync, the order reference can no longer be edited on a journal.
How to enter a reverse payment
Note: Reversing a payment will not refund a payment processed via a payment gateway, only record the reversal in Brightpearl.
- Open the order or credit.
- Click Take/Make payment or Refund .
- Select Reversal .
- Select the date on which to record the reversal payment.
- Enter the payment reference .
- Enter the amount (positive value).
- Click Submit .
How to cancel a payment
- Go to Sales > Order payments , or Purchases > Order payments if it’s for a purchase.
- Search for the payment using the filters.
- Click Cancel in the actions column.
Taking & making payments & refunds in the orders module
Payments made in the orders module are those which are:
- Entered from within the order or return screen
This process remains largely unchanged. However, up until now, when a payment is entered against an order or return you were asked to select the bank account code where the accounting would be posted. In 4.90 you will now be selecting the payment method you’d like to use. The bank account code used for the accounting is set against the payment method and and if you’re using a payment gateway app then this must also be linked to your payment method - this causes the payment gateway processing window to display instead of the manual entry window.
This means that you must have the following set up:
- Payment method
- Bank account assigned to payment method
- Payment gateway linked to the payment method (as required)
When your account is upgraded to 4.90 we will automatically create payment methods and link your payment gateways. This means that you can continue to process payments against orders after the upgrade and using the currently familiar bank account names. We recommend that after the upgrade to 4.90 you check your payment methods and make any changes you want to. To understand more about how we will create the payment methods and what you might want to change see how your account will be upgraded below
Handling of overpayments on orders
Before version 4.90 Brightpearl recognized an overpayment as soon as it is taken against an order. The overpayment would automatically be split away from the order to leave the order as paid in full. The overpayment is left on-account within the contact's financials as credit. If any changes are then made to the order (before invoicing) this could result in the following complications:
- If the order total gets reduced another overpayment would be recognized resulting in another on-account payment for the contact. This makes it difficult to track the payment history
- If the order total gets increased at any point then it is likely that the overpayment will be used to pay the difference. Since it has already been moved to the contact's financials this payment can only now be allocated back to the order via the accounting module
In version 4.90 any overpayment will only be recognized at point of invoicing allowing for any changes to be made to the order without causing complications with the payment allocation.
Taking & making payment & refunds in the accounting module
Payments made in the accounting module are those which are:
- Entered against invoices, credits from a customer/supplier payment allocation screen
- Entered as on-account from a customer/supplier payment allocation screen
- Created from the bank matching process
When a payment is entered from the accounting module you will still be selecting bank account codes. When a payment is entered in the accounting module it will always post a payment journal. Where the payment is allocated against invoices or credits which relate to an order or return, an order payment will also be created - this will ensure the order is marked as paid. These order payments will always be recorded with a payment method of OTHER.
How your account will be upgraded
When your account is upgraded to 4.90 we will be performing the following things:
- Creating order_payments for all historical orders
- Creating payment methods
Data fixing historical orders
This is essential since orders will now only be marked as paid when an order_payment exists. Without these your paid orders will look unpaid. Since no payment methods existed for these historical transactions, all the order_payments will be assigned a payment method of OTHER. You will be able to see all these order_payments on the order payment reports.
Creating payment methods
Payment methods will be required in order to enter any payments against orders. To ensure you can continue to work as normal we will be creating payment methods which exactly mirror your current bank account and payment gateway setup. This means we will create a payment method for:
- Every bank account
An active bank account will create an active payment method, a bank account set as inactive will create an inactive payment method. You can delete any payment method which hasn’t yet been used. Each payment method will be given the following details:
- Name = Account code and name of the bank account nominal
- Code = Account code of the bank account nominal
- Bank account = The same bank account nominal
- Every payment gateway app installed
This means additional payment methods will be created if Sagepay or Authorize.net are installed. PayPal is a little different, explained below. Each payment method will be given the following details:
- Name = This will be Sagepay or Authorize.net
- Code = This will be SAGEPAY or AUTHORIZENET
- Payment gateway = The relevant payment gateway app (Sagepay or Auth.net)
- Bank account = The bank account selected in the payment gateway settings before the upgrade
Understanding payment method fields:
- The name is what users see on orders when taking/making a payment. This is also recorded on the payment reports.
- The code is used for mapping to apps. If a payment is downloaded via an app and it includes a matching payment method code, the payment method name will be recorded against the order_payment and the bank account from that method will be used for the accounting.
- An installed payment gateway will need to be linked to a payment method to allow back office payments to be processed. When these payment methods are used the payment processing window will automatically open instead of the manual entry window.
- The bank account is where the accounting will be created when a payment is processed using this payment method. A bank account can be set per currency, but this will only be relevant Brightpearl releases multi-currency support.
If you are using Sagepay or Authorize.net
As a result of creating a payment method for bank accounts and payment gateways, you will have a duplicated payment method for Sagepay or Authorize.net. There is no way for us to know for sure whether the bank account you use on a payment gateway is used only for the gateway payments or is also used for manual payment entry. To ensure you can perform both options we’ll create a payment method for each. If one isn’t needed then it can be deleted.
If PayPal as a web portal payment method is set up
PayPal doesn’t currently support processing of payments in the back office and so we will automatically link the PayPal gateway to the payment method created from the PayPal bank account. This means no duplicate payment method.
The PayPal sync which downloads transactions into the PayPal log is not a payment gateway but more of a bank feed from which you are able to create transactions in Brightpearl - it does not need to be connected to a payment method. However, when linking these PayPal transactions to orders please note that the option to do so has been moved into the list of payment methods: