Down payments in Purchasing

As always, the process presented here is supposed to be a concept only and needs to be adapted in both wording and details to the individual situation.

Introduction

As soon as purchasing has to deal with larger quantities or sums, or if one has to deal with a foreign transaction, it is very likely that the process will start with a down payment and an associated proforma invoice.

Odoo provides such a process in its standard function. As long as a transaction is in the status „offer“ or “offer sent,” a proforma document can be dispatched via an additional button (we have already talked about this in detail in a separate blog).

But where can we find this function in purchasing? If you create an inquiry, you cannot generate an invoice since there is no such button available. It only appears once the inquiry is confirmed and thus has turned into an order. But as long as no delivery has been generated, you get the message that there are no ”billable lines“ when you try to create an invoice. In other words, no products have been delivered yet. And even if you have delivered just one article with quantity 1, only this item will be transferred to an invoice proposal.

Of course, you could use a custom adaptation to get around this, provided that you are using a system that allows for the installation of adaptations.

Suggested solution

Before we start, let it be said that although the solution presented and described here may seem strange –it works!

Product

Since each inquiry and order item has to be linked to a product, you cannot avoid creating a new product for this process. If a “down payment“ product already exists in the sales department, it should not be converted for this purpose since it was probably created within the system. Re-using system objects in other contexts is generally not a recommended approach!

As shown here, the product selected should be a ”service“ product:

To do this, we recommend setting the billing type in sales and purchasing to “Based on delivered quantity“ ( as shown in the previous two screenshots). This has the advantage that the advance payment / down payment can already be included in the order request so that the amount and timing are part of the communication with the supplier, and the time at which they should take effect can be selected manually.

Choosing another type of billing means that the purchasing department has no control.

Another critical factor is whether the down payment can or should be claimed for VAT. If so, a corresponding VAT rate needs to be stored in the “Purchasing“ tab. In our sample, however, we will leave the VAT out of consideration and focus only on the process and its associated steps.

The process in fast forward

In the first step, we will create an order request. In our case, without the down payment, but of course, we could already include several down payments here. It may even be advisable to agree on this in advance as part of the payment process and record it in writing.

Step 1: The order

In our example, we order a whiteboard pen for a notional $ 100 and confirm the request, which will provide us with the following purchase order:

Step 2: The down payment

Once we receive the proforma invoice from the supplier, we add a new item. In our case, this is the product “proforma“:

We must ensure the quantity is 0 and the product has a negative value.

The simple explanation is that a quantity unequal to 0 would distort the order value. The unit price has to be negative because it will be deducted later in the supplier’s purchase invoice(s), i.e., it must reduce the value of the delivered item.

As mentioned above, it is quite possible to add several identical items, and, of course, we could add a separate paragraph to the order for better visibility. Unfortunately, however, we cannot work with percentages. In this case, a calculator or the formula function integrated in Odoo would have to be used.

Step 3: Initiating pre-payment

The receipt is ready and has been checked, and now we want to inform the accounting department that the pre-payment has to be initiated. We do this by entering a “-1“ in the “Receipt“ column in the line of the proforma product. The button “Generate invoice“ turns green. If you click on it, a draft invoice is generated:

Here, we can see why entering a -1 and not a positive quantity is necessary. Otherwise, we would have received a negative sub-total, and Odoo would have interpreted this as a supplier credit note.

We could, of course, correct the values, but a) the document would be attached here, visualizing the issue much better, and b) it would make no difference to the actual process. In fact, I have tested this, and it was less work in the subsequent process without the correction and, thus, more efficient.

Step 4: Confirmation of invoice and payment

In reality, we cannot confirm the invoice ourselves since we would need an accounts payable clerk or accountant for that.

The accounting department has a dashboard where the draft invoice will appear, indicating that it must be confirmed. If we do not want to rely on this process, or if things are urgent, sending an internal note to an appropriate user profile makes sense to ask for confirmation.

Once the invoice has been posted, we can see this in the order because, at this moment, a -1 also appears in the column “Billed“:

The way of payment is the usual one, as you know it.

Step 5: Delivery of products

In the next step, we receive the delivered product(s) and process it/them in one or several step(s).

This will look as follows:

In our example, this is pretty straightforward since our focus is on handling the down payment.

As a result, however, Odoo will change the order status to “Awaiting incoming invoice. “

Step 6: Preparing the final invoice

If now the time has come to expect the final invoice or for the down payment to be taken into account in the next invoice, we go to the corresponding item and set the value in the “Receipt” column back to 0 so that the screen will look as shown below:

Here, we see that ”Receipt“ has the value 1 for the whiteboard pen, but 0 has been invoiced. In other words, Odoo will include this line in the next invoice proposal. Since this also applies to the “proforma” line, it will also be included.

Step 7: Final invoice

Regardless of whether the supplier invoice arrives by e-mail or is uploaded, and also irrespective of whether the OCR recognition acknowledges our document number or that of the supplier or whether the assignment is made manually via the accounting department, the invoice proposal will take both items into account:

This ensures the deposit is considered and deducted directly from the total amount. The payment proposal will be offered with the reduced value.

How would an adjustment look like?

Generally speaking, adjustments of any kind should be based on a process in the Odoo standard and not invent something completely new. This increases the chance that something workable will come out in the end.

In this case, it may be possible to add another button (e.g., “Enter down payment”) to the header of the order, creating the item(s) described in Step 2, to avoid any errors.

Conclusion

Those who have known or used Odoo for some time may remember that this function existed in earlier versions. Why it has been discontinued is not even a matter of conjecture; only Odoo can provide an answer.

Perhaps there is an even better solution in the standard, but we still have to find it.

The generated down payment invoice may look very unusual, but in the end, what matters is the document, and the payment can be made with it. Deferring the delivered quantity so that the down payment is considered in the final invoice may also seem strange. But in real life, there also needs to be a note from the purchasing to the accounting department as to when the down payment should be taken into account, especially if there have been several down payments.

Of course, it is possible to buy apps to cover this problem. We also have worked with them in the past. But then we had to realize that these apps did not work so well, after all, and that they had to be improved with great effort.

This is why we usually propose solutions in the standard, even if they look rather unusual.

Was this article helpfull information to you? 
Would you mind to leave us a review of your experiences with openfellas?

​​​​​​review openfellas