Odoo Version: 16 Enterprise
Background
Good customer, bad customer, we all have those. Now, how do I create a customer in Odoo so that my colleague in sales knows what to do, and how exactly does the prepayment and down payment process work – and are they the same or not?
These questions are among the most frequently asked ones. If you search on YouTube, you may get all kinds of information. However, I have yet to find a video suggesting a process from data creation to final settlement.
It is essential to know that in Odoo, the confirmation of an offer automatically triggers the generation of deliveries (both internal and external if there are multi-level warehouse processes). These, in turn, may result in the recalculation of demand and corresponding feedback within the modules Purchasing and, if applicable, Manufacturing.
The question now is whether we– option 1 – want to demand payment before a delivery schedule and confirmation (prepayment) or – option 2 – have enough confidence in the customer so that a down payment can run concurrently with delivery scheduling (by creating a “merchant invoice with due date”).
Option 1 is commonly referred to as a prepayment or proforma process, and option 2 as a down payment.
The decision is not only crucial for the configuration and generation of deliveries. The timing and occurrence of the legal conclusion of the contract also differ.
In the proforma process (prepayment), we send a proforma invoice to the customer, representing an offer. With the payment, the customer accepts the offer. The payment, therefore, serves as the customer’s “declaration of intent” with which the contract is concluded.
The
preparation of the down payment invoice already presupposes the
declaration of intent and, thus, the conclusion of the contract.
Configuration
The first and probably most important task is the separation of the debtors according to these two categories.
As we have already learned from the blog on monthly invoices, the payment terms may be used to map much more than the term itself suggests, particularly since a) it makes a difference in terminology both internally and on the printed text and b) the default payment terms are visible when you create an offer.
Your best choice is to take advantage of the separation between internal and external text to allocate a name (or maybe an abbreviation) to the payment term and add instructions to the internal user (e.g. “only Prepayment, 30 days” or “30% down payment, 30 days”).
In this case, the most practical approach is to create two additional payment terms by duplicating or copying the default payment term. This will automatically apply all respective settings and translations.
For our example, that is sufficient. In reality, you can insert additional notes regarding the payment process into the external text. This way, the customer will already see that he has to pay a down or pre-payment when he receives the offer after placing an order.
Note: The default payment term should be at the top of the list.
Here
is an example:
I created the two additional terms at the bottom
of this example by copying “immediate payment” and “30 days
net”. Consequently, there will be no visible difference in the
documents, but the wording should tell my colleague in sales how to
deal with the customer as soon as he places an order.
Master Data
In the next step, these newly created terms should be assigned to at least one customer each.
In this fictitious case, Deco Addict is a customer who passed our credit check and proved trustworthy. Thus, the delivery may be scheduled and a down payment invoice created once the order has been confirmed. On the other hand, Azure Interior has received a negative credit check, and the order can only be confirmed after prepayment.
The payment terms are stored accordingly in the master data record.
Let us now look at the two processes themselves.
Process Down Payment
We receive an inquiry from Deco Addict, and the sales department issues an offer. As soon as the responsible salesperson gets the offer, he will access Odoo and see in the customer’s payment terms that the order may be confirmed and a down payment invoice may be created.
He will proceed as follows:
Step 1: Order
confirmation
The order has been placed by phone, and the offer has been sent. We see that a down payment invoice needs to be created in the payment terms. The example shows that the percentage to be paid should have been evident from the term’s name, but since it is not, we will assume 50%.
Step 2: Generating an invoice and entering the down payment
To generate the down payment, we need to click on the button “Create invoice”:
This takes us to the draft invoice:
For the user in sales, the process would end here for the time being because, if the authorizations are set correctly, sales may create or draft invoices but not post them. You are (should?) only (be) able to do that if you are in accounting.
In our example, we are admin and may continue directly with the next steps.
Step 3: Posting the Down
Payment Invoice
Next, we post the down payment invoice by pressing the “Confirm” button. This gives us an invoice number. The date will be set to the current day.
Using the “Send & Print” button, we generate a document image of the invoice, which we can send by e-mail.
In
the sales order, the down payment is now also visible:
Step 4: Shipping and
final invoice
The order is now shipped, and Odoo forwards it to the invoice run. If the order is now also transferred to an invoice, the result will look as follows:
As you can see, the down payment is listed,
reducing the amount to be invoiced.
Prepayment process
In our example regarding prepayment, we create an offer for Azure Interior. After sending the offer, we receive the order. In the terms, we can see that this customer has to pay in advance before the delivery is scheduled. Using the “Send Proforma” button, we send the proforma invoice with the payment request.
Step 1: Sending a
proforma invoice
A quote has been created and sent to Azure Interior.
Mr. Freeman contacts you and places the order. We immediately see that the customer has been set to prepayment, and we send him the proforma invoice via the “Send proforma invoice” button.
A standard template text is imported into the e-mail that a) may be adapted by the administrator and b) may be individualized by the user according to the transaction.
The work is done for sales, and the ball is now in the customer’s court.
Step 2: Recording the
payment on the bank statement
We
are changing roles again because the payment now appears in the bank
journal, and accounting takes over.
In our case, Azure has paid the total amount of 320.56 US$, using the quote number as the payment reference.
You will see an additional “Orders” tab in the posting proposals. This tab is only displayed if quote or order numbers appear in the payment reference. If you click on this tab, you will get a link to the open and sent quotes:
Clicking on the link will take us to our offer, for which the proforma document has been sent.
Step 3: Confirmation
of the offer
Now, of course, we need to decide whether to accept the payment or not. If the down payment needs to be higher, we recommend contacting the responsible salesperson via an internal note or resubmission and notifying them about the posted payment. In this case, the quote will remain in its current status. You can return to the payment and post it against accounts receivable, as suggested.
However, in our case, the customer has paid 100%, the offer can be accepted, and the delivery is scheduled. Just press the “Confirm“ button.
This can also be processed by a user in accounting. This way, we can create the down payment invoice as in option 1 above.
Step 4: Creation of a
down payment invoice
This step is the same as the one described above, except that we do not enter a percentage down payment but the paid amount. You may import the correct data via Copy & Paste from the operation system clipboard.
Step 5: Confirmation
and sending of the down payment invoice
We
now generate the down payment invoice, which can also be confirmed
directly.
Of course, we can send the invoice directly to Azure, but we send it more conveniently together with the order confirmation, which has to be sent as well, after all. If the invoice recipient differs from the person ordering, we must do that anyway.
Step 6: Sending the
order confirmation
Returning to the order via Breadcrumbs, we can see that the down payment is now also recorded.
An order confirmation should be sent to the contact person via the “Send by e-mail” button to confirm the down payment and delivery date.
Step 7: Posting the
payment against the down payment invoice
Now
we go back to the bank statement, again using the Breadcrumbs. Under
the tab “Reconciliation of existing entries,” we can see our
created down payment invoice and are able to select it for
reconciliation as the counter document.
Once you confirm the transaction, the down payment invoice is considered cleared.
The
following steps are the same as in Option 1. I.e., after delivery,
the order is placed in the invoice run, and the down payment is
included in the settlement. In our case, the balance is 0. The
merchant invoice has yet to be provided to the customer.
Conclusion
Of course, the process can be extended to include many more details. Moreover, we have entirely disregarded taxes in our example. Entering the fixed amount for the down payment invoice was easy since no taxes had to be discounted from the receipt. This and several other details need to be taken into account.
Our example was only meant to illustrate how a transaction can be handled in Odoo Standard. At first glance, it is a rather long click track that might be inconvenient if you have many prepayments. However, once a process is in place and you know the appropriate parameters, you can program it for automatization.
A point still open is that in option 2 of our example, the commissioned proforma offers are not followed up. This is also part of the process in most cases since the customer’s declaration of intent only occurs with the payment. Sometimes, the ordering itself can be already considered a binding commitment. In that case, you should create a filter in the offer overview that selects all offers sent according to whether a proforma e-mail has been sent and group the latest changes according to date. However, these would have to be followed up via the Chatterbox of the respective process. This can be done semi-automatically via an appropriate mail template.
Was this article helpfull information to you?
Would you mind to leave us a review of your experiences with openfellas?
Talk to our experts.
We will find the solution best suited to you and your products!