I think a development made for an Idalica project is worth to be trunkable.
It's about avoiding the usage of clearing accounts (configurable).
The development avoid the usage of the clearing accounts for:
* Bank in transit (B_InTransit_Acct) - customer wants to post directly to B_Asset_Acct
* Unallocated cash (B_UnallocatedCash_Acct) - customer wants to post directly to C_Receivable_Acct
* Payment select (B_PaymentSelect_Acct) - customer wants to post directly to V_Liability_Acct
* Inventory Clearing (P_InventoryClearing_Acct) - customer wants to post directly to NotInvoicedReceipts_Acct (Payables)
The approach was totally configurable and compatible with current behavior.
It's simple - if the transit account is defined the same as the final account
(i.e. B_InTransit_Acct=B_Asset_Acct) then the posting is not done (in fact the posting is still done when necessary against the clearing accounts)
This preserves backward compatibility: if you define the clearing and final different the posting is still done.
What do you think - can we integrate this in trunk?
The development already passed testing phase.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>The approach was totally configurable and compatible with current behavior.
>It's simple - if the transit account is defined the same as the final account
>(i.e. B_InTransit_Acct=B_Asset_Acct) then the posting is not done (in fact the posting is still done when necessary >against the clearing accounts)
>
>This preserves backward compatibility: if you define the clearing and final different the posting is still done.
I like it.
[+1] from me.
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm okay with any enhancement (especially optional ones) so long as it preserves the accounting standards which the application claims to support which is, I think, GAAP at this moment. I know there are other standards selectable in the Accounting Schema but I never saw any code based on this selection so I assume it's GAAP regardless of what is chosen there?
I believe GAAP is considered somewhat vague (and hence the move to IFRS by many) so perhaps there isn't a specific rule that can be pointed to to support any specific change. So what I mean is that us developers (or perhaps even our customers) should not determine the standards but that someone with the right skills & experience should.
My own immediate reaction is that it looks like a step backwards towards the "quickbooks" type application aimed at (very) small business rather than step towards the middle enterprises. Perhaps I do not understand the intent or benefits. Maybe, it would be a good idea to explain the business reasons and how it's intended this functionality should be used rather than just the technical details?
But, as I say, the bottom line for me is so long as it is in keeping with the standards we claim to adhere to I have no objection.
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, there is some background on this one that is generally very interesting. Especially related to: "aimed at (very) small business rather than step towards the middle enterprises. "
The desire of the sponsor was to reduce the volume of transactions that they need to audit. They feel the enhancement can cut their transactions in about 1/2.
As part of their project, they brought in an Accounting consultant from one of the big three US Accounting Consultation firms to review Adempiere and their internal accounting practices. The consultant informed them that the clearing accounts match those used by SAP and what companies in the 25-50M USD/year range begin to migrate toward. Being toward the low end of that range, the consultant supported their desire to eliminate the clearing accounts.
He also mentioned that the clearing accounts support a greater internal separation of responsibility.
We suspect this option might be popular for companies in the 5-25M range, which is a good target for us.
Regards,
Joel Stangeland
www.idalica.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>they brought in an Accounting consultant from one of the big three US Accounting >>Consultation firms to review Adempiere and their internal accounting practices.
>>... the consultant supported their desire to eliminate the clearing accounts.
Well that is indeed very interesting... I would feel much better about it knowing an (independant) professional of that area (i.e. an accountant) okay'd it! As I said I just didn't want us techies defining accounting rules :)
re: market segment
well I've only worked for firms like Nixdorf, AT&T, NCR, StorageTek ... and so on ... so my experience is nearly all in the (really) big business segment. So I will gladly concede on that point! :) It's just what I currently see in Adempiere is more in-line we with my actual experience in these firms but the likes of what I saw when I look at say Quickbooks is more in line with what I learned of basic Accounting in school.
I don't suppose that audit by the consultancy could be made public? We could probably learn a lot from it!
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
interesting point here, I worked with small and big enterprise as Philips, ITT Industries, Atos Origin in case the big enterprise the use of clearing accounts is normal and the accountant understand the reason this accounts.
but in small enterprise the an accounting created by a ERP as Adempiere do not is understand easy way, but it is a reason understandable the accounting man create your accounting using system local and this only let the entry the GL journal accounting, print a Balance Sheet , Trial Balance and Income Statement.
So the accountant uses his approach to generate the accounting fact, then when you said that the ERP will generate the accounting fact; The accountant is set in shock as i said "the accounting in ERP as ADempiere do not is understand easy way to small enterprise".
But clearing account have a reason being even more have only meet a standard, to me are very important when you implement the best business practice.
Clearing account allow to have a good control the business process, so for me each clearing accounts (Not Invoice Receipt, Inventory Clearing, Invoice Price Variance, Purchase Variance, Bank Transient, etc) show a point key the business process.
In my expertise when I give the explain of the points key the business process to clearing account then accountant understand and adopting the best practice :-).
in summary is necessary that accountant understand and adopting the accounting best practice the of the ERP if this do not is this way then my advice is that he continue with your current solution.
Kind Regards
Victor Perez
e-Evolution
CEO
www.e-evolution.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, as I said, from my personal experience I would tend to agree Victor but there are a couple of important & relevant points.
1) it's an optional Accounting schema setting.
So we can take it or leave it.
I think the "same account causing it to skip the posting" is clever programming but an error in the accounting schema setup (and with GL defaults at system/org/BP group/product Group/BP & Product that is a real possibility!) could lead to some unintended consequences. An explicit "I DON'T want to use clearing accounts" checkbox might be safer.
2) As with Joel, Carlos & yourself, I am not an accountant. But we have a certification (of sorts) from a "Big 3" accounting house stating that this is still GAAP compliant. Not that being from the "Big 3" is a cast iron guarantee -just ask those enron people :)- but I am willing to accept that they know more about accounting and GAAP than me!
So while I wouldn't suggest it myself... taking those two points into account I'd lean towards saying "it's ok by me".
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Clearing account allow to have a good control the business
> process, so for me each clearing accounts (Not Invoice
> Receipt, Inventory Clearing, Invoice Price Variance, Purchase
> Variance, Bank Transient, etc) show a point key the business
> process.
>
> In my expertise when I give the explain of the points key the
> business process to clearing account then accountant understand
> and adopting the best practice :-).
Well, I also try to explain customers the convenience of using best business practices, and that can include the usage of clearing accounts.
But is also true that in certain cases clearing accounts could be useless - i.e. suppose a company has as policy ALWAYS make payments through invoices - then the "Payment Select" account is useless - it will generate lots of movements where DB=CR - and it could add extra effort to read/conciliate financial reports, etc.
Finally I think a customer need is a customer need - if this accountant think it can rid of clearing accounts because of normalized business processes - then I think we can attend this need - without harm to accounting process.
Thanks also Colin for your comments,
> I think the "same account causing it to skip the posting"
> is clever programming but an error in the accounting schema
> setup (and with GL defaults at system/org/BP group/product
> Group/BP & Product that is a real possibility!) could lead
> to some unintended consequences. An explicit "I DON'T want
> to use clearing accounts" checkbox might be safer.
That was my first though to solve the problem, adding an explicit parameter "don't use clearing accounts" in accounting schema.
But, researching further we found that "clearing posting" must be used in some cases.
I.e.
99.9% of bank statement just post BankInTransit vs BankAsset with DB=CR
But when posting charges or interests - then the BankInTransit account still need to be used - so making BankInTransit explicitly equals to BankAsset make the trick perfectly without harm to accounting process.
I think is clearer this configuration/behavior than adding a parameter "don't use clearing accounts" when they still need to be used in some cases.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it is clearer to have a flag to set how should the system behave if clearing account set as the same as the final/actual posting account. As Colin pointed out rightly, this can also be a mistake by the user.
Regards,
Low
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good points on the discussion, glad to see people talking about it.
In regard to Low's point, I don't know that adding a flag really gives the user anything but a false sense of security. If they check the proposed flag but mistakenly set up their in-transit and assets to post to the same account, the net result is the same as if it didn't post at all. By suppressing the postings in these cases, it makes it more likely they will discover their mistake (absence of data in the GL) and they will have to change their configuration and re-post anyway. Whether they had the proposed box checked or not, mistakes will still be mistakes and require re-posting. I don't feel strongly that we shouldn't have a flag but I just don't know that it improves the situation significantly.
On Colin's question, you are right that the defaults guide everything. It is just that on these documents there might be individual charge lines that do not follow the default (i.e. Bank Interest or Fees on a Bank Statement Line). On those specific line items the charge posts against something different than Bank In Transit and needs to show up on the GL. So in that example, all of the other bank statement lines in the Bank Statement document post debit and credit to the same account and do not propagate to the GL, but the charge line would post correctly and not be suppressed just because it appears on a "clearing account" document.
Regards,
Joel H
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I post that in a rush and may be have not explain my suggestion clearly. What I'm suggesting is a flag to set it as a company policy - whether the user can set a clearing account the same as the final/actual posting account. I believe either way should be a company accounting policy instead of some ad hoc decisions.
Regards,
Low
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> What I'm suggesting is a flag to set it as a company
> policy - whether the user can set a clearing account
> the same as the final/actual posting account. I believe
> either way should be a company accounting policy instead
> of some ad hoc decisions.
First of all please don't feel like I'm defending my position, just trying to get the best solution.
I don't see the value added of such flag - normally I'm always pro flags to allow configuration and flexibilization of behavior of Adempiere.
But in this case having the flag set or not, the net result on the accounting is exactly the same.
I don't think a posting with the same DB and CR data is useful for accounting.
And as Joel H pointed - accounting in Adempiere has a great advantage, you can delete and repost every time you want.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> we found that "clearing posting" must be used in some cases.
ok. That sounds reasonable... and flexible.
But I think I must not understand fully the enhancement then.
The accounts selected for posting is determined by the (many) GL defaults. right?
I first understood if you want to skip the clearing (intransit) post you, for example, set the default Bank-InTransit equal to that of the default Bank Account?
But how do you organise it so that some transactions posts to the intransit account anyway? surely the default is the same for all?
And do you know is this (from this customers experience) an exception that applies only to bank accounts or are there other examples of exceptions to the clearing use?
I'm not querying you implementation here... just trying to understand! :)
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok thanks for the feed back Joel(H) & Carlos. I'm really not trying to be awkward just to make sure I understand. So just to be sure I understand...
The general documents processing within system remains the same for the user, but just the GL posting changes?
So if , for example, we receive a check from a customer. We create an AR Payment from the customer. This would under normal circumstances result in
Checking Intransit DR
Unallocated Receipts CR.
But now it would (assuming all the clearing accounts are set the same) be:
Checking Account DR (only because we set defaults Bank Intransit = Bank Asset)
Unallocated Receipts CR (as this clearing account is not one covered by the new functionality)
As the Unallocated Receipts is not a clearing account covered by this enhancement it continues as per usual.
When it comes the Bank Reconciliation (Bank Statement).
You still enter the payment on the Bank Statement and reconcile with the actual bank statement as per usual.
The GL transactions would normally be
Checking Intransit CR
Checking Account DR
But now there are none. And this is the purpose of the change... right?
Is the monetary value taken into account as well as the account numbers?
So for example if the payment was 100 USD but there was check processing fee of 10 cents.
So under normal system we'd get
Checking InTransit CR 100
Checking Account DR 99.90
Bank Charges DR 0.10
what would post in the new scenario?
Bank Charges DR 0.10?
If it was I guess we'd really we need an additional
Checking Account CR 0.10 (to balance that ... or not?)
But this is why I ask about the monetary value.
If we posted the check cost separately, it would produce
Checking Account CR 0.10
Bank Charges DR 0.10
On it own which is correct.
But if it's combined as one statement line (as it can be) is this also the result? We have 3 postings
1) Bank Asset
2) Bank Intransit
3) Bank Charge
But only the two accounts as the Bank Asset & Bank Intransit are they same.
But while the two posts to Bank Asset & Bank Intransit go to the same account, they do not balance.
I guess the question I'm asking myself is there a special way this must be used in order to get the correctly results? Not just this example but in general. And is there situations when it could cause incorrect postings!? I've only looked at this one transaction so far as I'm 100% sure I fully understand ... sorry for that! :(
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
are exactly the same - nothing changed there - all accounting keeps posting exactly the same.
What I did is to avoid useless posting on those movements implying clearing accounts.
Your example is perfect to show the situation.
"
So for example if the payment was 100 USD but there was check processing fee of 10 cents.
So under normal system we'd get
Checking InTransit CR 100
Checking Account DR 99.90
Bank Charges DR 0.10
"
Let's put accounts to the example:
SCENARIO 1 - Current behavior:
Checking Account -> 11100
Checking InTransit -> 11110
Bank Charges -> 70200
(this is default in GardenWorld)
Then the posting will be exactly as currently is:
11100 DR 100.00
11110 CR 99.90
70200 CR 0.10
SCENARIO 2 - If checking in transit = checking account
Suppose then you configure your accounts this way:
Checking Account -> 11100
Checking InTransit -> 11100 (this is the change - intransit = checking account)
Bank Charges -> 70200
Then the program do something like:
11100 DR 0.10
70200 CR 0.10
The program will know that the movement
11100 DR 99.90
11100 CR 99.90
is useless and avoid such posting
but still post anything that is useful and needed
> And is there situations when it could cause
> incorrect postings!?
At least in my changes I think it won't post incorrectly - it's just dropping the useless postings with equal values.
But obviously it could be bugs in my implementation, and obviously I'll try to review bugs you find - AFAIK the customer is testing thoroughly and still haven't broken this.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tested 3.3.1b, it worked if there is no foreign currency involved. But if there is gain/loss on forex diff. then the system doesn't operate as expected. See the following scenario:
Home currency is VND
1. Create AP Invoice in USD (1USD, exchange rate = 16030)
Accounting
Debit ABC Account 16030
Credit AP 16030
2. Change exchange rate to 16050
3. Create payment in USD (1 USD)
Debit AP 16050
Credit Cash/Bank 16050
4. Allocate payment to invoice
5. View Allocation, there should be DR (Loss on forex diff) CR AP of 20VND, but there is no posting
View Business Partner Info, "Open Balance" is correct (0)
View AP Account, there is balance of 20VND, which is incorrect.
Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi comunity!!!
I have an issue. The accountant in this company does not want to use the BanK Transit account. Besides he does not want to post the bank reconciliation. He says that bank reconciliation is just a control process.(no posting needed)
I used your advice and I set the bank account asset instead of the bank transit account and it worked perfectly.
About the bank reconciliation we are going to develop an automatic bank reconciliation but with the same idea of not posting the bank reconciliation since the payments go directly yo the asset bank account. What do you think? is there any problem with it?
Thanks !!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There can be a problem if you allow transactions to be entered in a currency that is not the bank account currency.
To prevent this, make Currency read only on the payments window (it should default to the bank account currency), modify the dynamic validation on the invoice field so that it only displays invoices where IsPaid = N and invoice currency = bank account currency (otherwise the callout can change the Payment Currency).
Review the 'Bank Transfer' window/programs to check that they will not create a Payment in the 'wrong' Currency. Hide them if they can.
regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi community.
I think a development made for an Idalica project is worth to be trunkable.
It's about avoiding the usage of clearing accounts (configurable).
The development avoid the usage of the clearing accounts for:
* Bank in transit (B_InTransit_Acct) - customer wants to post directly to B_Asset_Acct
* Unallocated cash (B_UnallocatedCash_Acct) - customer wants to post directly to C_Receivable_Acct
* Payment select (B_PaymentSelect_Acct) - customer wants to post directly to V_Liability_Acct
* Inventory Clearing (P_InventoryClearing_Acct) - customer wants to post directly to NotInvoicedReceipts_Acct (Payables)
The approach was totally configurable and compatible with current behavior.
It's simple - if the transit account is defined the same as the final account
(i.e. B_InTransit_Acct=B_Asset_Acct) then the posting is not done (in fact the posting is still done when necessary against the clearing accounts)
This preserves backward compatibility: if you define the clearing and final different the posting is still done.
What do you think - can we integrate this in trunk?
The development already passed testing phase.
Regards,
Carlos Ruiz
Hi Carlos,
>The approach was totally configurable and compatible with current behavior.
>It's simple - if the transit account is defined the same as the final account
>(i.e. B_InTransit_Acct=B_Asset_Acct) then the posting is not done (in fact the posting is still done when necessary >against the clearing accounts)
>
>This preserves backward compatibility: if you define the clearing and final different the posting is still done.
I like it.
[+1] from me.
Kind regards,
Trifon
I'm okay with any enhancement (especially optional ones) so long as it preserves the accounting standards which the application claims to support which is, I think, GAAP at this moment. I know there are other standards selectable in the Accounting Schema but I never saw any code based on this selection so I assume it's GAAP regardless of what is chosen there?
I believe GAAP is considered somewhat vague (and hence the move to IFRS by many) so perhaps there isn't a specific rule that can be pointed to to support any specific change. So what I mean is that us developers (or perhaps even our customers) should not determine the standards but that someone with the right skills & experience should.
My own immediate reaction is that it looks like a step backwards towards the "quickbooks" type application aimed at (very) small business rather than step towards the middle enterprises. Perhaps I do not understand the intent or benefits. Maybe, it would be a good idea to explain the business reasons and how it's intended this functionality should be used rather than just the technical details?
But, as I say, the bottom line for me is so long as it is in keeping with the standards we claim to adhere to I have no objection.
colin
Hi croo,
Actually, there is some background on this one that is generally very interesting. Especially related to: "aimed at (very) small business rather than step towards the middle enterprises. "
The desire of the sponsor was to reduce the volume of transactions that they need to audit. They feel the enhancement can cut their transactions in about 1/2.
As part of their project, they brought in an Accounting consultant from one of the big three US Accounting Consultation firms to review Adempiere and their internal accounting practices. The consultant informed them that the clearing accounts match those used by SAP and what companies in the 25-50M USD/year range begin to migrate toward. Being toward the low end of that range, the consultant supported their desire to eliminate the clearing accounts.
He also mentioned that the clearing accounts support a greater internal separation of responsibility.
We suspect this option might be popular for companies in the 5-25M range, which is a good target for us.
Regards,
Joel Stangeland
www.idalica.com
Hi Joel,
>>they brought in an Accounting consultant from one of the big three US Accounting >>Consultation firms to review Adempiere and their internal accounting practices.
>>... the consultant supported their desire to eliminate the clearing accounts.
Well that is indeed very interesting... I would feel much better about it knowing an (independant) professional of that area (i.e. an accountant) okay'd it! As I said I just didn't want us techies defining accounting rules :)
re: market segment
well I've only worked for firms like Nixdorf, AT&T, NCR, StorageTek ... and so on ... so my experience is nearly all in the (really) big business segment. So I will gladly concede on that point! :) It's just what I currently see in Adempiere is more in-line we with my actual experience in these firms but the likes of what I saw when I look at say Quickbooks is more in line with what I learned of basic Accounting in school.
I don't suppose that audit by the consultancy could be made public? We could probably learn a lot from it!
colin
interesting point here, I worked with small and big enterprise as Philips, ITT Industries, Atos Origin in case the big enterprise the use of clearing accounts is normal and the accountant understand the reason this accounts.
but in small enterprise the an accounting created by a ERP as Adempiere do not is understand easy way, but it is a reason understandable the accounting man create your accounting using system local and this only let the entry the GL journal accounting, print a Balance Sheet , Trial Balance and Income Statement.
So the accountant uses his approach to generate the accounting fact, then when you said that the ERP will generate the accounting fact; The accountant is set in shock as i said "the accounting in ERP as ADempiere do not is understand easy way to small enterprise".
But clearing account have a reason being even more have only meet a standard, to me are very important when you implement the best business practice.
Clearing account allow to have a good control the business process, so for me each clearing accounts (Not Invoice Receipt, Inventory Clearing, Invoice Price Variance, Purchase Variance, Bank Transient, etc) show a point key the business process.
In my expertise when I give the explain of the points key the business process to clearing account then accountant understand and adopting the best practice :-).
in summary is necessary that accountant understand and adopting the accounting best practice the of the ERP if this do not is this way then my advice is that he continue with your current solution.
Kind Regards
Victor Perez
e-Evolution
CEO
www.e-evolution.com
Well, as I said, from my personal experience I would tend to agree Victor but there are a couple of important & relevant points.
1) it's an optional Accounting schema setting.
So we can take it or leave it.
I think the "same account causing it to skip the posting" is clever programming but an error in the accounting schema setup (and with GL defaults at system/org/BP group/product Group/BP & Product that is a real possibility!) could lead to some unintended consequences. An explicit "I DON'T want to use clearing accounts" checkbox might be safer.
2) As with Joel, Carlos & yourself, I am not an accountant. But we have a certification (of sorts) from a "Big 3" accounting house stating that this is still GAAP compliant. Not that being from the "Big 3" is a cast iron guarantee -just ask those enron people :)- but I am willing to accept that they know more about accounting and GAAP than me!
So while I wouldn't suggest it myself... taking those two points into account I'd lean towards saying "it's ok by me".
colin
Thanks Victor for your comments,
> Clearing account allow to have a good control the business
> process, so for me each clearing accounts (Not Invoice
> Receipt, Inventory Clearing, Invoice Price Variance, Purchase
> Variance, Bank Transient, etc) show a point key the business
> process.
>
> In my expertise when I give the explain of the points key the
> business process to clearing account then accountant understand
> and adopting the best practice :-).
Well, I also try to explain customers the convenience of using best business practices, and that can include the usage of clearing accounts.
But is also true that in certain cases clearing accounts could be useless - i.e. suppose a company has as policy ALWAYS make payments through invoices - then the "Payment Select" account is useless - it will generate lots of movements where DB=CR - and it could add extra effort to read/conciliate financial reports, etc.
Finally I think a customer need is a customer need - if this accountant think it can rid of clearing accounts because of normalized business processes - then I think we can attend this need - without harm to accounting process.
Thanks also Colin for your comments,
> I think the "same account causing it to skip the posting"
> is clever programming but an error in the accounting schema
> setup (and with GL defaults at system/org/BP group/product
> Group/BP & Product that is a real possibility!) could lead
> to some unintended consequences. An explicit "I DON'T want
> to use clearing accounts" checkbox might be safer.
That was my first though to solve the problem, adding an explicit parameter "don't use clearing accounts" in accounting schema.
But, researching further we found that "clearing posting" must be used in some cases.
I.e.
99.9% of bank statement just post BankInTransit vs BankAsset with DB=CR
But when posting charges or interests - then the BankInTransit account still need to be used - so making BankInTransit explicitly equals to BankAsset make the trick perfectly without harm to accounting process.
I think is clearer this configuration/behavior than adding a parameter "don't use clearing accounts" when they still need to be used in some cases.
Regards,
Carlos Ruiz
Hi Carlos,
I think it is clearer to have a flag to set how should the system behave if clearing account set as the same as the final/actual posting account. As Colin pointed out rightly, this can also be a mistake by the user.
Regards,
Low
Hello Heng Sin and Colin:
Good points on the discussion, glad to see people talking about it.
In regard to Low's point, I don't know that adding a flag really gives the user anything but a false sense of security. If they check the proposed flag but mistakenly set up their in-transit and assets to post to the same account, the net result is the same as if it didn't post at all. By suppressing the postings in these cases, it makes it more likely they will discover their mistake (absence of data in the GL) and they will have to change their configuration and re-post anyway. Whether they had the proposed box checked or not, mistakes will still be mistakes and require re-posting. I don't feel strongly that we shouldn't have a flag but I just don't know that it improves the situation significantly.
On Colin's question, you are right that the defaults guide everything. It is just that on these documents there might be individual charge lines that do not follow the default (i.e. Bank Interest or Fees on a Bank Statement Line). On those specific line items the charge posts against something different than Bank In Transit and needs to show up on the GL. So in that example, all of the other bank statement lines in the Bank Statement document post debit and credit to the same account and do not propagate to the GL, but the charge line would post correctly and not be suppressed just because it appears on a "clearing account" document.
Regards,
Joel H
Hi Joel.H,
I post that in a rush and may be have not explain my suggestion clearly. What I'm suggesting is a flag to set it as a company policy - whether the user can set a clearing account the same as the final/actual posting account. I believe either way should be a company accounting policy instead of some ad hoc decisions.
Regards,
Low
Hi Heng Sin
> What I'm suggesting is a flag to set it as a company
> policy - whether the user can set a clearing account
> the same as the final/actual posting account. I believe
> either way should be a company accounting policy instead
> of some ad hoc decisions.
First of all please don't feel like I'm defending my position, just trying to get the best solution.
I don't see the value added of such flag - normally I'm always pro flags to allow configuration and flexibilization of behavior of Adempiere.
But in this case having the flag set or not, the net result on the accounting is exactly the same.
I don't think a posting with the same DB and CR data is useful for accounting.
And as Joel H pointed - accounting in Adempiere has a great advantage, you can delete and repost every time you want.
Regards,
Carlos Ruiz
> we found that "clearing posting" must be used in some cases.
ok. That sounds reasonable... and flexible.
But I think I must not understand fully the enhancement then.
The accounts selected for posting is determined by the (many) GL defaults. right?
I first understood if you want to skip the clearing (intransit) post you, for example, set the default Bank-InTransit equal to that of the default Bank Account?
But how do you organise it so that some transactions posts to the intransit account anyway? surely the default is the same for all?
And do you know is this (from this customers experience) an exception that applies only to bank accounts or are there other examples of exceptions to the clearing use?
I'm not querying you implementation here... just trying to understand! :)
colin
Hi Carlos,
I think this is a common request for smaller company.
As long as it's backward compatible, configurable through acct schema, and allow to be re-posted, +1 for trunk.
Armen
+1 from me too.
Regards,
Low
Ok thanks for the feed back Joel(H) & Carlos. I'm really not trying to be awkward just to make sure I understand. So just to be sure I understand...
The general documents processing within system remains the same for the user, but just the GL posting changes?
So if , for example, we receive a check from a customer. We create an AR Payment from the customer. This would under normal circumstances result in
Checking Intransit DR
Unallocated Receipts CR.
But now it would (assuming all the clearing accounts are set the same) be:
Checking Account DR (only because we set defaults Bank Intransit = Bank Asset)
Unallocated Receipts CR (as this clearing account is not one covered by the new functionality)
As the Unallocated Receipts is not a clearing account covered by this enhancement it continues as per usual.
When it comes the Bank Reconciliation (Bank Statement).
You still enter the payment on the Bank Statement and reconcile with the actual bank statement as per usual.
The GL transactions would normally be
Checking Intransit CR
Checking Account DR
But now there are none. And this is the purpose of the change... right?
Is the monetary value taken into account as well as the account numbers?
So for example if the payment was 100 USD but there was check processing fee of 10 cents.
So under normal system we'd get
Checking InTransit CR 100
Checking Account DR 99.90
Bank Charges DR 0.10
what would post in the new scenario?
Bank Charges DR 0.10?
If it was I guess we'd really we need an additional
Checking Account CR 0.10 (to balance that ... or not?)
But this is why I ask about the monetary value.
If we posted the check cost separately, it would produce
Checking Account CR 0.10
Bank Charges DR 0.10
On it own which is correct.
But if it's combined as one statement line (as it can be) is this also the result? We have 3 postings
1) Bank Asset
2) Bank Intransit
3) Bank Charge
But only the two accounts as the Bank Asset & Bank Intransit are they same.
But while the two posts to Bank Asset & Bank Intransit go to the same account, they do not balance.
I guess the question I'm asking myself is there a special way this must be used in order to get the correctly results? Not just this example but in general. And is there situations when it could cause incorrect postings!? I've only looked at this one transaction so far as I'm 100% sure I fully understand ... sorry for that! :(
colin
Hi Colin, no problem at all - it's good to discuss clearly and deeply before integrating something in trunk.
I find this discussion valuable - it will serve as future reference for those trying to understand this new behavior.
---------------
Explaining in other words:
I didn't change nothing on the posting of default accounts.
These two pages:
http://adempiere.com/wiki/index.php/ADempiere_Accounting
http://adempiere.com/wiki/index.php/Default_Accounts_Usage
are exactly the same - nothing changed there - all accounting keeps posting exactly the same.
What I did is to avoid useless posting on those movements implying clearing accounts.
Your example is perfect to show the situation.
"
So for example if the payment was 100 USD but there was check processing fee of 10 cents.
So under normal system we'd get
Checking InTransit CR 100
Checking Account DR 99.90
Bank Charges DR 0.10
"
Let's put accounts to the example:
SCENARIO 1 - Current behavior:
Checking Account -> 11100
Checking InTransit -> 11110
Bank Charges -> 70200
(this is default in GardenWorld)
Then the posting will be exactly as currently is:
11100 DR 100.00
11110 CR 99.90
70200 CR 0.10
SCENARIO 2 - If checking in transit = checking account
Suppose then you configure your accounts this way:
Checking Account -> 11100
Checking InTransit -> 11100 (this is the change - intransit = checking account)
Bank Charges -> 70200
Then the program do something like:
11100 DR 0.10
70200 CR 0.10
The program will know that the movement
11100 DR 99.90
11100 CR 99.90
is useless and avoid such posting
but still post anything that is useful and needed
> And is there situations when it could cause
> incorrect postings!?
At least in my changes I think it won't post incorrectly - it's just dropping the useless postings with equal values.
But obviously it could be bugs in my implementation, and obviously I'll try to review bugs you find - AFAIK the customer is testing thoroughly and still haven't broken this.
Regards,
Carlos Ruiz
+1 vote to include it in the trunk. The flag option mentioned by Hengin makes sense to me.
Best Regards!
Hi community,
Implemented this new feature in trunk with revision 3780 - added the column suggested by Heng Sin.
Tracker opened
http://sourceforge.net/tracker/index.php?func=detail&aid=1840016&group_id=176962&atid=879335
[ 1840016 ] Avoid usage of clearing accounts
In the tracker I also uploaded a .doc file to show the effect of the change and showing the scripts to test it with GardenWorld.
Regards,
Carlos Ruiz
I tested 3.3.1b, it worked if there is no foreign currency involved. But if there is gain/loss on forex diff. then the system doesn't operate as expected. See the following scenario:
Home currency is VND
1. Create AP Invoice in USD (1USD, exchange rate = 16030)
Accounting
Debit ABC Account 16030
Credit AP 16030
2. Change exchange rate to 16050
3. Create payment in USD (1 USD)
Debit AP 16050
Credit Cash/Bank 16050
4. Allocate payment to invoice
5. View Allocation, there should be DR (Loss on forex diff) CR AP of 20VND, but there is no posting
View Business Partner Info, "Open Balance" is correct (0)
View AP Account, there is balance of 20VND, which is incorrect.
Han
Hi Han, thanks for testing and reporting
I put a fix in trunk for the reported problem with revision 4076.
Regards,
Carlos Ruiz
Hi comunity!!!
I have an issue. The accountant in this company does not want to use the BanK Transit account. Besides he does not want to post the bank reconciliation. He says that bank reconciliation is just a control process.(no posting needed)
I used your advice and I set the bank account asset instead of the bank transit account and it worked perfectly.
About the bank reconciliation we are going to develop an automatic bank reconciliation but with the same idea of not posting the bank reconciliation since the payments go directly yo the asset bank account. What do you think? is there any problem with it?
Thanks !!
There can be a problem if you allow transactions to be entered in a currency that is not the bank account currency.
To prevent this, make Currency read only on the payments window (it should default to the bank account currency), modify the dynamic validation on the invoice field so that it only displays invoices where IsPaid = N and invoice currency = bank account currency (otherwise the callout can change the Payment Currency).
Review the 'Bank Transfer' window/programs to check that they will not create a Payment in the 'wrong' Currency. Hide them if they can.
regards