Contributors mailing list archives


Re: Your opinion and experience about "Point Bank Management"

NUMIGI Solutions Inc., Bruno Joliveau.
- 14/03/2020 16:09:46
Many thanks for your contributions Dominic, Jonathan and Graeme!

I understand your feedback regarding analytics, and I will rule out this assumption.

I am reluctant to add the stock module and its dependencies for that.

I like the idea of a register, like a new Odoo model. I do not have fluent English and it is also in this sense that I asked the community in the case of a similar project that has not yet been listed in OCA.

Regarding multi-currency, this is a point that we had hypothesized. I did not put all the ideas in my initial email ;-)

I add one of them that we had discarded and partially corresponds to comments that you shared.

As we need to manage price lists both for sale and in point consumption actions that we will recover from third-party solutions and integrate into Odoo, we had considered using:
1 - multicurrency by creating a new virtual currency "POINTS", the "POINTS" have a rate translation with existing real currencies, as Odoo knows how to do
2 - the customer buys product A ($ 100 for a quantity of 1), we use the standard "Sales" features
3 - when its payment is established, its bank of "POINTS" is credited with the correspondence $ »" POINTS ". Is this a new object like the register you were sharing, why not?
4 - the customer consumes his "POINTS" by various actions through third-party software. Some of identical actions have different prices in "POINTS" from one customer to another. We had considered using Odoo's sale.order with sale_order_type (from OCA) which would also allow us to use price lists and all the sales functionalities. The payment of these sale.order is done by purging the bank of "POINTS".
5 - We have discarded the consideration of purchase workflow to avoid considering the customer as a supplier as well. However, this could be reconsidered to distinct the purchase / sale price list from the same partner.

In the meantime, thank you for your comments which help guide our decisions. We are continuing our reflections before next steps (estimation and costing of this project).
This is really what I appreciate in our ecosystem, and any link or comment is welcome :)

Bruno Joliveau - Architecte applications - Président
(514) 317-7944

Longueuil, Québec, Canada


Le ven. 13 mars 2020 à 23:46, Graeme Gellatly <> a écrit :
I'm still not seeing the issue. If the points are worth nothing then they wont be on balance sheet. If points are worth something then clearly they must be on balance sheet AND a revenue reduction on p&l.  It is no different to any other kind of revenue recognition such as warranty provisions under IFRS. 

Accruing points on an invoice is nothing more than an account id on an invoice line. But even then it doesn't matter, anglosaxon has always created extra entries per invoice line. The identical logic applies. 

Whether odoo is the accounting system or not seems irrelevant. Fundamentally this is accounting whether you want to call it something else or not.  Balances are maintained, there are debits and credits based on activity. 

On Sat, 14 Mar 2020, 4:32 PM Dominique k, <> wrote:
you need to be able to have an invoice in a currency, AND at the same time  records the number of points used or earned.

Beside not all business will want having the points on their balance sheet and odoo may not always be the accounting system. 

On Sat, 14 Mar 2020 at 10:02 AM, Graeme Gellatly <> wrote:
Maybe I'm missing something but isnt this really just a receivable account in a different currency. 

Everything else is just transactions in that currency. 

On Sat, 14 Mar 2020, 2:01 PM Jonathan Wilson, <> wrote:
Hi Bruno

I'm thinking along the line of a register, ie rather like a share register. The register is updated by strategically coded actions and keeps a complete translation/audti trail of all ins and outs. I'm assuming there will also be a financial implication when points are earned, ie they become a liability in the balance sheet, when redeemed they are removed. If a register is used the balance sheet figure can always be reconciled against the register. Additionally, a register will be an easy way to report to the customer. 

I agree with Dominique in not using analytics - sometimes it just easier and cleaner to use our own model, and it also makes upgrades easier.

Hope I understood it correctly and it is of some use to you.

Kind regards

Jonathan Wilson

Chief Sales and Innovation Executive

WilldooIT Pty Ltd

First Australian Odoo GOLD partner
2017, 2015 & 2013 Odoo Best Partner Asia/Pacific
Creators of  Odoo-Pentaho integration project

"Making growth through technology easy"


P: +61 3 9135 1900

M: +61  4 000 17 444


10/435 Williamstown Road

Port Melbourne VIC 3207

DISCLAIMER | This electronic message together with any attachments is confidential. If you are not the recipient, do not copy, disclose, or use the contents in any way. Please also advise us by e-mail that you have received this message in error and then please destroy this email and any of its attachments. WilldooIT Pty. Ltd. is not responsible for any changes made to this message and/or any attachments after sending by Willdoo IT Pty. Ltd. WilldooIT Pty. Ltd. use virus scanning software but exclude all liability for virus or anything similar in this email or attachment.

On Sat, 14 Mar 2020 at 03:33, Bruno Joliveau <> wrote:

Hi Community,

I am writing to get your point of view or maybe, share on existing modules.

As part of a new client project, we need to:

- sell products whose consumption is done at a different rate and volume.

- the customer must have their consumption history and their balance

Relatively classic and common so far ;-)

It is a service activity, but the unit of value is not time. And, a priori, there is no stock management.

Summary customer process:

The customer purchases product A (for example $ 100 for 1 quantity)

In return, the client benefits from a capital of 250 points, for example.

The customer consumes his points by different actions. These actions are reported by several applications. We can collect those actions and create events in Odoo.

The customer must be able to know the evolution of his capital of points.

At this step, several hypothesis considered:

1 - sale order and analytic

- addition of a second unit of measurement in SO

- when the SO is confirmed, this quantity corresponding to the second unit feeds an analytical account

- for a better reading the analytical lines could take advantage of a new type as they already have with timesheets

- each action performed by the customer that triggers consumption creates a new line as a deduction in his capital of points

- the customer has access to his analytical account to view the balance of his capital of points

2 - sale order and product_pack

- rather than adding secondary units in the sale order, the customer buys a pack

- the capital points is a product in its own right with a quantity of 250 (child of the initial product with its quantity 1)

- it is only this product which feeds an analytical account

- the following steps are the same as the previous assumption

3 - sale order and stock

- although there is no need to manage the inventory, we activate and configure the stock features

- the customer orders a product in quantity 1

- an equivalence in stock management is made on a storable product of 250 points

- each action carried out by the customer which triggers consumption creates a new line as a deduction in the inventory management of his capital of points

- the customer has access to his own stock location to view the balance of his capital of points with his history

Thank you for taking the time to read, I hope this is clear enough.

Look forward to your comments and suggestions!

Bruno Joliveau - Architecte applications - Président
(514) 317-7944

Longueuil, Québec, Canada

linkedin youtube custom-icon twitter

Post to:

Post to:

Post to:

Dominique KON-SUN-TACK  [Project Manager]
Odoo Gold Partner, best Odoo Partner 2014 for APAC

Mobile: + 65 8502 2399
Skype: dominique_elico

Post to:

Post to: