Some enhancements for accounting

[Nicolas Micoud]

Hi,

I did some improvements on 361 swing and i will put them on idempiere (both swing and zk).
I think that could be useful for everybody so, as it need some customization in database, i'm asking if i should proceed using centralized id or not ?


1 - Allocation : add a new SysConfig to forbid complete if more than 2 documents are selected and they are not on the same fiscal year.


2 - List which indicate if the account is to be used by customer or vendor (non mandatory)
Then, it is easy to filter accounts from forms, reports, ... and make control when you select an account for business partner.


3 - Add the GL Journal in the allocation form :
 > add IsPaid on GL_JournalLine
 > add GL_JournalLine on C_AllocationLine
So, the GL Journal Line can be used as an invoice or a payment.
 
It could be useful for some specific/complex cases, when you cannot deal with invoices/payment only.


WDYT

Regards,

Nicolas

[Alex Yang]

Hi Nicolas,

I like the idea and improvement. Would like to see it integrated:)

Thanks,

Alex Yang

2013/7/4 Nicolas Micoud <nmi...@tgi.fr>

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Edwin Ang]

Hi Nicolas,

My comment is inline

On Thu, Jul 4, 2013 at 2:44 AM, Nicolas Micoud <nmi...@tgi.fr> wrote:

Hi,

I did some improvements on 361 swing and i will put them on idempiere (both swing and zk).
I think that could be useful for everybody so, as it need some customization in database, i'm asking if i should proceed using centralized id or not ?


1 - Allocation : add a new SysConfig to forbid complete if more than 2 documents are selected and they are not on the same fiscal year.

I think this is a good feature. +1 for inclusion

 

2 - List which indicate if the account is to be used by customer or vendor (non mandatory)
Then, it is easy to filter accounts from forms, reports, ... and make control when you select an account for business partner.

I don't really get this one. Can you elaborate more? 

 

3 - Add the GL Journal in the allocation form :
 > add IsPaid on GL_JournalLine
 > add GL_JournalLine on C_AllocationLine
So, the GL Journal Line can be used as an invoice or a payment.
 

It could be useful for some specific/complex cases, when you cannot deal with invoices/payment only.

In 361 and iDempiere, we've added Allocation to Charge. I think that is already serving the same purpose. WDYT?

[Nicolas Micoud]

Thanks for answering guys,


For 2 : the aim is to be able select only customer and/or vendor accounts.
It's easier for users to launch some reports (used for tax, reconciliation, ...) with few account than full list.
You can also control that only some specified account can be used in C_BP_Customer_Acct or C_BP_Vendor_Acct.
Moreover, i need it for 3 :D

For 3 :
If i understand well, the selection of a charge on the allocation form could be considered as an improvement of Invoice WriteOff ?
Your invoice will considered as paid using one account.

With 'my' feature, you can 'simulate' an invoice or payment by creating a gl journal and then allocate one of these line (which will have an account set as customer or vendor (see 2)) to invoices or payments.


Regards,

Nicolas

[Heng Sin Low]

For #3, it could be problematic if the client is using multiple accounting schema.

[Nicolas Micoud]

Correct !

In this particular case, users probably should create 2 gl journal (as a journal must be set on a single accounting schema).
And then allocate journal of main schema => IsPaid column will be checked.

For others journal lines IsPaid checkboxes, we should probably customize MJournal.completeIt

So, those GL journal must be linked.
That make me think : actually, if client use more than one accounting schema, he has to duplicate manually gl journals ??

[Carlos Antonio Ruiz Gomez]

Thanks Nicolas, my two cents of opinion:

On #1 - not questioning the idea - it sounds harmless if developed as a sysconfig key, but I would like to know the accounting reasoning behind.
an allocation document has its own date and period - so I'm just curious why the need

On #2 - does it sound like an SO/PO optional flag?
as you pointed maybe it can be worthy for some reporting purposes

On a similar topic that we could also consider - for LCO I use to add also two flags on accounts - if the account manage bps (like AP/AR accounts) - and if the account manage products (like inventory/depreciation).
I can use those flags for reporting purposes - and also to make bp or product mandatory on journals for those accounts.
Maybe if such need is general then we can also include it on trunk.

On #3 - I don't have a good feeling about this one - agree with Heng Sin's comment.
But also GL Journals are usually a document that doesn't affect the rest of the system (it doesn't affect banks, inventories, AP/AR balances) - and because of that the journals can be reopened, changed and completed again.
If we make this link then reopening becomes a "no, no"
I guess this can be valuable for volume payments (like payrolls) - but the solution I use to apply for those cases is to open a bank/cash account and apply the payments from such account - having payments in journals doesn't sound too natural - I guess it can break more things that we would need to analyze further.

Regards,

Carlos Ruiz

[Nicolas Micoud]

#1 : on adempiere, the allocation date if the higher date of all selected documents.
so, if you select an invoice and a payment (2012) and an invoice (2013) ; the allocation will be generated on 2013.
Which is false, because the 2012 invoice was paid in 2012.

I've just tested on demo.idempiere.com and the allocation date was those of the payment (which was not the higher one). Something change here ??


#2 : Adding checkboxes BP, Product is a good idea as there is a checkbox BankAccount.
My idea is (for BP) to add a list with 2 values (customer and vendor) ; so, it may be possible in the future to add 'employee' (is the tab in bp window is used)


#3 : i agree with your thoughts, but here, accountants love doing gl journals.

It could be useful for handling old payments and/or invoices (or when the period is closed).

eg: you just have no invoice and a payment. This way you could clear bp account properly (MBPartner.setTotalOpenBalance and BPartnerValidate process are modified this way).
It's not used frequently (perhaps 10/20 times in a year, i could check) but it's a good solution for settle mess.
And, yes, you can't reactivate a journal if a line is allocated - you first need to delete the allocation. I haven't got issues since it is available for users

Note also, that if you create a journal line with a bpartner and a customer account, the generated fact will never be reconciled.

But i agree that could be a problem for multi-accounting schemas systems. A trick/solution/workaround must be found.


Regards,

Nicolas

[Carlos Antonio Ruiz Gomez]

On #1 again - allocation document is created and posted to the date that you choose on allocation window.
The case you describe is not necessarily false - you can close period (or year 2012) with a payment unallocated and discover to which invoice correspond on 2013, so the allocation must be done on 2013.

As you say is configurable and is just a validation, it sounds harmless.
But IMHO that sounds better to be validated on a before_prepare_allocation model validator.

Regards,

Carlos Ruiz

[Nicolas Micoud]

For #1, I was not aware of this enhancement ; AFAIR, the allocation date was always updated with the higher ones between all selected documents.

I will try to add this control on the MAllocation.beforeSave, with the ability to activate/deactivate this control through SysConfig (default will be deactivate) and upload a patch.

 

 

For #2, should i create a jira ticket ?

 

 

Regards,

 

Nicolas

--
You received this message because you are subscribed to a topic in the Google Groups "iDempiere" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/idempiere/dZCn-X7hhLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to idempiere+...@googlegroups.com.

[Carlos Antonio Ruiz Gomez]

Yes, please.