Accounting mailing list archives

accounting@odoo-community.org

Avatar

Re: GR/IR Clearing Process

by
kevin.mcmenamin
- 23/12/2015 18:59:21
I agree - the way we separate is based on a link to a PO line and checks if the line is for a stockable product - if yes, then use the clearing account. If no link to a PO line or a PO line for a service, then expense.

Kevin McMenamin
ERP Capability Manager

Mobile  +64 22 651 3753
Phone  +64 9 977 5805
Email   kevin.mcmenamin@solnet.co.nz

Solnet Solutions Limited
Level 19, Crombie Lockwood
191 Queen Street, Auckland 1010
PO Box 6619, Auckland 1141

www.solnet.co.nz  




From:        Jordi Ballester Alomar <jordi.ballester@eficent.com>
To:        "Accounting" <accounting@odoo-community.org>,
Date:        23/12/2015 10:25 p.m.
Subject:        Re: GR/IR Clearing Process





Thank you very much Kevin.

I think there needs to exist a separation between the use cases of a logistic invoice that has been created in advance of a shipment, from a credit/debit memo.

The 3 way match process is closely related to the clearing of the GR/IR. IMHO each PO line is a 'Transaction' that should be reconciled by means of the 3 way match.

You post credits to a 'Transaction/PO Line' in the GR/IR account as you receive goods, resulting in a credit balance from PO line perspective.

You post debits to the PO line transactiom in the GR/IR account as you process the invoice, regardless of how was the invoice created.

The automatic/manual reconciliation process will attempt to rconcile debits & credits for the same transaction / po line.

With this approach you do not care if you use serialized products, if you invoice the whole order in advance or if you invoice based on PO lines. That is a choice not related to the clearing of the GR/IR account.

A debit/credit memo would not generate postings to the GR/IR account, but in order to do that there needs to be an indicator that an invoice IS a debit/credit memo, which is now missing.

El dia 22/12/2015 23:38, <Kevin.McMenamin@solnet.co.nz> va escriure:
have put V7 and V8 onto github at https://github.com/KevinMcMenamin?tab=repositories

in both cases we went down the path of overwriting core functions rather than inheriting  as too many things we wanted to change. I'll publish V9 once I get a bit further.


Kevin McMenamin

ERP Capability Manager


Mobile  +64 22 651 3753
Phone  +64 9 977 5805
Email   kevin.mcmenamin@solnet.co.nz

Solnet Solutions Limited

Level 19, Crombie Lockwood
191 Queen Street, Auckland 1010
PO Box 6619, Auckland 1141

www.solnet.co.nz  




From:        Jonathan Wilson <jon@willowit.com.au>
To:        "Accounting" <accounting@odoo-community.org>,
Date:        23/12/2015 10:40 a.m.
Subject:        Re: GR/IR Clearing Process





@kevin: is it possible to get the code? I'm not so sure it will a easy upgrade to V9 but needs more investigation.

Jonathan Wilson
www.willowit.com.au
ph: +61 3 8506 0393
mob: +61 4 000 17 444
2013 & 2015 Odoo Best Partner Asia/Pacific

Creators of  Odoo-Pentaho integration project






On 23 December 2015 at 06:53, <Kevin.McMenamin@solnet.co.nz> wrote:
What we did was include the stock move for all moves plus invoices so can match at a line level based on the stock move id. There is a scheduled job whcih runs each night to do the reconciliation (with a user defined tolerance)

Kevin McMenamin

ERP Capability Manager


Mobile  +64 22 651 3753
Phone  +64 9 977 5805
Email   kevin.mcmenamin@solnet.co.nz

Solnet Solutions Limited

Level 19, Crombie Lockwood
191 Queen Street, Auckland 1010
PO Box 6619, Auckland 1141

www.solnet.co.nz  




From:        Jonathan Wilson <jon@willowit.com.au>
To:        "Accounting" <accounting@odoo-community.org>,
Date:        22/12/2015 07:53 p.m.
Subject:        Re: GR/IR Clearing Process





Jordi: technically I can't argue with you, however functionally I think a reconciliation that cannot identify exact products on a po could be a problem.

On 22 Dec 2015 5:23 pm, "Jordi Ballester Alomar" <jordi.ballester@eficent.com> wrote:
Jon, I was thinking on maintainig the PO id (not PO line id), because that would generally be a good enough reconciliation. In a single PO there can be two items with the same amount, but does it really care if the reconciliation is crossed between a GR of item 1 and IR of item 2? I guess that what you want is to reconcile overall at PO level.

I fear that might be hard to move the PO line from po line -> invoice line -> account move line

El dia 22/12/2015 6:38, "Jonathan Wilson" <jon@willowit.com.au> va escriure:
@Humberto: are these modules only applicable if anglo-saxon is used?
@Jordi: I like the design. You are suggesting using PO line id's (not the PO text name) as the link? 

Jon

Jonathan Wilson
www.willowit.com.au
ph: +61 3 8506 0393
mob: +61 4 000 17 444
2013 & 2015 Odoo Best Partner Asia/Pacific

Creators of  Odoo-Pentaho integration project






On 22 December 2015 at 08:22, Humberto Arocha <hbto@vauxoo.com> wrote:



https://github.com/Vauxoo/addons-vauxoo/tree/8.0/account_anglo_saxon_stock_move

https://github.com/Vauxoo/addons-vauxoo/tree/8.0/account_anglo_saxon_stock_move_purchase
https://github.com/Vauxoo/addons-vauxoo/tree/8.0/account_anglo_saxon_stock_move_sale



https://github.com/Vauxoo/addons-vauxoo/tree/8.0/stock_accrual_report


Jordi, did you really check these modules?

All your comments are fully fulfilled with these modules.


stock_accrual_report actually allows end user to verify where those lines where fully reconconciled,
partial reconciled not reconciled.

Best Regards.




Quien suscribe,

Hbto



On Mon, Dec 21, 2015 at 10:53 AM, Jordi Ballester Alomar <jordi.ballester@eficent.com> wrote:
Hello,

Find below some of my conclusions:

Account GR/IR (or GNRI) should normally stay low or zero, and the balance should reflect the transactions that are outstanding from the 3 way match perspective.

In order for the user to be able to analyze the status of this GL account, there should be the possibility to reconcile debits and credits of the same transaction, so that the remaining balance indicates the value of products that have been received, for which no invoice has been entered or viceversa.

If this reconciliation between transactions does not occur, it will be very hard to identify the causes of an existing balance in this GL account.

Reconciliation using manual process is now difficult due to the lack of information about the purchase order & line available in the journal items.

Existing automatic reconciliation tools in Odoo will only use the GL Account and Partner as the basis to reconcile debits and credits, which will not be enough to reconcile the full transaction.

In order to be able to reconcile this account the journal items should indicate the originating purchase order (and ideally the purchase order number as well).

The automatic reconciliation tools should be adjusted in order to incorporate the PO as criteria for the reconciliation process.




The automatic reconciliation tool then should allow the user to indicate that during the reconciliation the system should group debits and credits belonging to the same GL account, partner AND purchase order.






On Fri, Dec 18, 2015 at 2:43 PM, Jordi Ballester Alomar <jordi.ballester@eficent.com> wrote:
Thanks Fréderic, I will look into the module.



On Fri, Dec 18, 2015 at 8:37 AM, Frédéric Clementi <frederic.clementi@camptocamp.com> wrote:
I hope I am not off topic since I dis not read everything (sorry) but to automatise the reconcile why not using the account_advanced_reconcile, you could even code an extra specific reconcile rule ...

camptocamp

INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Frédéric Clementi

Project Manager 
Business Solutions

+41 21 619 10 41

www.camptocamp.com


2015-12-18 6:53 GMT+01:00 Jordi Ballester Alomar <jordi.ballester@eficent.com>:
Thanks to all.

@Ray, I am familiar with ASA module. I use a modified version of it that we built ourselves.

As Kevin says, you quickly can end up with thousands of credits and debits in the GR/IR account and if it's out of balance it's impossible to tell why.

When you reconcile all debits and credits belonging to the same transaction you can better understand what is left to reconcile, and when there are discrepancies, you can further investigate.

What Kevin suggests seems to be the way to go. We also do the same thing, but still missing the report to assist the user in the reconciliation process.

The existing automatic reconciliation tool would not do that job at all, because it will match debits and credits with the same amount and partner, but the credit and debit may belong to different transactions. But if you have nothing else, perhaps it is a viable workaround..

At the end for the 3 way match process to be completed, you need full traceability in the transactions to allow users to be confident that what was received was invoiced.

Regards,
Jordi.

El dia 18/12/2015 1:53, <Kevin.McMenamin@solnet.co.nz> va escriure:
We have an automated process that does this in V7 and V8 (and will end up migrating to V9. Otherwise you end up with 1000's of entries in the clearing accounts and no simple way to work out what the balance is made up of. A amnual process would only work with a very small customer.

Our version of anglo-saxon add the stock move id into the account.move.line for both the stock move and invoice transactions then uses this as the basis for reconciling.


Kevin McMenamin

ERP Capability Manager


Mobile  +64 22 651 3753
Phone  +64 9 977 5805
Email   kevin.mcmenamin@solnet.co.nz

Solnet Solutions Limited

Level 19, Crombie Lockwood
191 Queen Street, Auckland 1010
PO Box 6619, Auckland 1141

www.solnet.co.nz  




From:        Ray Carnes <ray.carnes@bistasolutions.com>
To:        "Accounting" <accounting@odoo-community.org>,
Date:        18/12/2015 01:23 p.m.
Subject:        RE: GR/IR Clearing Process





The clearing happens when the Invoice is validated.

 

You don’t want it happening without a user being involved, because you use uncleared entries to detect unvalidated Invoices.

 

Ray.

 

From: Eric Caudal [mailto:eric.caudal@elico-corp.com]
Sent:
Thursday, December 17, 2015 3:53 PM
To:
Accounting <accounting@odoo-community.org>
Subject:
Re: GR/IR Clearing Process

 

As far as I know there is no automatic clearing.
I am wondering (I think I tested long time ago but cant remember result) whether it is an option to set the clearing account as reconciliable and launch an automatic reconciliation on it.

--
Eric Caudal
[Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Hong Kong/Shenzhen/Singapore) Odoo Gold Partner, best Odoo Partner 2014 for APAC

On 12/18/2015 12:38 AM, Jordi Ballester Alomar wrote:

<blockquote cite="mid:CALVkZEf-WZKz6S7tC9SFz24QDuRCJ6h-RJVEa3Y1JGq4Oh+-wg@mail.gmail.com" type="cite">

Anglo Saxon option will include automatoc clearing? In v8 or v9?

El dia 17/12/2015 17:23, "Ray Carnes" <ray.carnes@bistasolutions.com> va escriure:

You mean the Anglo Saxon option already available?

Ray Carnes
Senior Odoo Consultant | 909.864.4576 | Skype: bista_ray
Time zone: US Pacific | Office: Greater Los Angeles
Bista Solutions, Inc.  | Empowering Business Success


From: Jordi Ballester Alomar
Sent:
‎12/‎17/‎2015 7:53 AM
To:
Accounting
Subject:
GR/IR Clearing Process

Dear accounting experts,

 

Has anyone faced the need for a GR/IR clearing process?

 

In the context of perpetual inventory management (real-time inventory), that's the process by which Goods Received / Invoice Received account (also called GRNI - Goods Received Not invoiced) debit and credit entries originating from the same purchase order are reconciled.

 

The unreconciled entries in this GL account represent the valued goods that have been received from a supplier, for which no invoice has been entered yet.

 

 

Regards,

--

Jordi Ballester Alomar

Founder | Eficent

(+34) 629530707 | jordi.ballester@eficent.comhttp://www.eficent.com

Twitter: https://twitter.com/jbeficent_erp | Linkedin: https://www.linkedin.com/in/jordiballesteralomar

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

 

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmaster@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.

_______________________________________________


Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--
Jordi Ballester Alomar
Founder | Eficent
(+34) 629530707 | jordi.ballester@eficent.comhttp://www.eficent.com
Twitter: https://twitter.com/jbeficent_erp | Linkedin: https://www.linkedin.com/in/jordiballesteralomar



--
Jordi Ballester Alomar
Founder | Eficent
(+34) 629530707 | jordi.ballester@eficent.comhttp://www.eficent.com
Twitter: https://twitter.com/jbeficent_erp | Linkedin: https://www.linkedin.com/in/jordiballesteralomar

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmaster@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmaster@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/accounting-28
Post to: mailto:accounting@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe

Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmaster@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.

Reference