Contributors mailing list archives
Re: Your opinion and experience about "Point Bank Management"by
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".
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).
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, <firstname.lastname@example.org> 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 <email@example.com> 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, <firstname.lastname@example.org> 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.
Chief Sales and Innovation Executive
WilldooIT Pty Ltd
Recent Linkedin articles: How to Assess if you've Outgrown Your Business Accounting or ERP System
First Australian Odoo GOLD partner
2017, 2015 & 2013 Odoo Best Partner Asia/Pacific
Creators of Odoo-Pentaho integration project
On Sat, 14 Mar 2020 at 03:33, Bruno Joliveau <email@example.com> wrote:
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!
NUMIGI Solutions Inc., Bruno Joliveau.