Payment registration on a sales order is done via menu option 'Order completion'. This order completion function is part of Order Entry Optimization and needs to be activated. 

The payment parts within this form are only available if there is a store present on the sales order. From this dialog the user has the possibility to register payments, generate an order confirmation, release the order to the warehouse, generate a packing slip or invoice. The function release to warehouse can only be used if the indictor Use warehouse management processes is set for the warehouse.

To be able to create payments the Microsoft Dynamics 365 for Finance and Operations user has to be linked to a register and payment methods have to be setup for that register.

The order completion form can also be opened via a scan action.

The primary goal of this form is to support the specific counter sales scenarios in an easy way, to reduce handling by the warehouse / store personnel. The regular tasks for the sales order are grouped together in this form, to confirm the sales order, perform the release to the warehouse, to post the packing slip and to invoice the sales order. Please notice that for the pick-up and take-away scenarios a direct invoice can be processed, including the posting of the packing slip.

Secondly this form handles the direct cash payments by the (anonymous) customer.

As mentioned earlier, several scenarios are possible for direct payments by the customer:

• Customer picks up the products himself and pays by cash (or PIN or credit card) immediately
• Customer orders the products, let the goods be picked first, to pay immediately and take away
• Customers comes to pay immediately for earlier delivered goods or for pre-payment

In the payment registration tab of the order completion form the user can register multiple payments against the sales order and they all follow the same process:

The value of the field Amount receivable is determined by the radio button Pay based on:

• Take away now +delivered
  The amount is calculated based on order lines where:
  • The warehouse of the order lines matches the warehouse of the register attached to the active user that is processing the order; as you can only take away goods physically from the counter where you are right now.
  • and the delivery date of the order lines is today or before today as we assume that you will not take goods away that have a delivery date in the future. If you do want to include them you have to manually change the delivery date.
  • and the mode of delivery of the order lines are marked as Pickup mode of delivery
  • and it will take the quantity deliver remainder or a pick is being processed the quantity to be picked and when picked it will take the quantity picked as we assume that you can only take away what has been picked.
  • or the value of all lines that have been delivered but not invoiced
• Selected lines
  • The system will look at the quantity deliver now in the order lines. With this option it will be possible to specify that you want to pay specific lines. When you let the system determine what the quantities should be that can be delivered, the values of deliver now will only be used for the payment not for the packing slip or invoice posting.
• To be paid
  • Based on the order totals and what has already been paid, the system will show the amount that still needs to be paid. 

Only payment registration methods that are valid for this drawer or terminal are visible to the user and can be used to create the payment.

When a worker registers a payment it gets the status To be received. This means that the money has not been put in the drawer yet. This is done via the button Receive payments. These payments will posted to the ledger account via the payment journal that has been setup in the counter sales parameters.

When the payment registration form is closed the system checks whether there are payments that needs to be received and will ask you whether you have received them or not. Based on the answer payment records will be deleted or posted. A third way to receive these payments is to post the confirmation, release to warehouse, post the packing slip or invoice from the payment registration form.

A prepayment is created as a customer transaction that marked for settlement against the sales order. This standard Microsoft Dynamics 365 for Finance and Operations function will automatically settle this transaction against the invoice that is created for this order.

If desired it is possible to split the payment, e.g. in card and cash. In the field Amount receivable, enter the partial amount to be received by card, and press the payment registration method. Now press the other payment registration for the remaining amount.

Pre-payments

A prepayment is a payment that has been received before the order has been invoiced. Basically all payments are prepayments as in Microsoft Dynamics 365 for Finance and Operations you always receive the payments before you invoice.

It is also possible to force the customer to prepay before the order is available for further processing. This can be achieved by enabling the prepay checkbox on the customer. Each sales order that is created for such a customer will be marked as "Cash" and "Prepay" as within our solution prepayments can only be done by cash or card payments.

As long as the total order value has not been paid the sales order can not be processed (=can not be set complete):

• Order confirmation
• Release to warehouse
• Post packing slip
• Post invoice
• Create transfer order from the sales order line
• Create purchase order from the sales order header
• Create direct delivery order from the sales order header

Use a prepayment for a different sales order

When a prepayment has been received for a specific sales order, this prepayment can be used on a different sales order. This can be done via the open transactions link in the payment registration form.

This form shows all open transactions for this customer. The prepayments are recognizable based on the invoice id which is the sales order number with a payment sequence Id.

By enabling the mark field this prepayment will be transferred to the current sales order and will be used for settlement when the invoice for this sales order is created.

Pay an open invoice

When a customer is standing at the counter sales desk and he is ordering goods and he also want's to pay an open invoice, it is possible to select this open invoice via the Open transactions menu item in the Customer tab in the Order completion form and mark the selected payment for settlement.

The value of this invoice will be added to the amount receivable on this order. After the payments have been received and the completion form is closed or the order is invoiced, the payments will be used for settlement of the selected invoices.   

Cancel payments

A received payment (Prepaid/Paid) can be cancelled based on the parameter “Allow payment cancellation” on the register.

E.g. he has registered a payment per EFT Terminal, before the actual transaction on the terminal was completed and for some reason the customer couldn’t use his card or changed his mind to pay with another method.

In order to be able to cancel a payment, the user needs to be linked to a register and the parameter "Allow payment cancellation" has to be active on the worker.

The cancellation function is meant to be used for the correction of administrative errors assuming that the actual payment transaction has not been executed. The payment transaction will get the status cancelled and should be left out from when making a summary of the total payments that have been received for a certain register.

Payment registration overview

The payment registration overview shows all payment registrations for all stores, registers, drawers and terminals. From this form the Voucher and the sales order for which this payment has been made can be viewed.

The overview can be launched from the menu Counter sales > Inquiries and reports > Payment registration overview. Or from the Customer service form, with the menu-option Journals > Payment registration overview.