Menu
▾
▴
#768 Wrong Sum Total Debit/Credit in GL Journal
Wrong Sum Total Debit/Credit in GL Journal
How to produce.
1. Open GL Journal
2. Key in required field
3. Goto Journal line and entry 2 record, 1 record in base currency and 1 record in foreing currency ( don't forget currency rate)
4. Back to Journal tab, you will find Total Debit<>Total Credit.
In Journal tab total debit should be sum of Accounted Debit not Source Debit, vice versa
Thx
Logged In: YES
user_id=1238223
Originator: NO
Patch submitted as Tracker ID 1791080
http://sourceforge.net/tracker/index.php?func=detail&aid=1791080&group_id=176962&atid=879334
colin
Logged In: YES
user_id=1516206
Originator: NO
hi hendikin,
I have added some additional fixes to Bug#1789935 - Wrong Sum Total Debit/Credit in GL Journal.
Make Total Debit and Credit balance to complete and post the document.
MJournalBatch.Java :
comment these looping below to ignore updating the currency rate in Journal Line to be the same as Journal
public String prepareIt()
{
...
//Bug 1353695 Currency Rate and COnbversion Type should get copied from journal to lines
/*for (int i = 0; i < journals.length; i++)
{
MJournal journal = journals[i];
MJournalLine[] lines = journal.getLines(true);
if (journal.getCurrencyRate() != null && journal.getCurrencyRate().compareTo(Env.ZERO) != 0)
{
for (int j = 0; j < lines.length; j++)
{
MJournalLine line = lines[j];
line.setCurrencyRate(journal.getCurrencyRate());
line.save();
}
}
if (journal.getC_ConversionType_ID() > 0)
{
for (int j = 0; j < lines.length; j++)
{
MJournalLine line = lines[j];
line.setC_ConversionType_ID(journal.getC_ConversionType_ID());
line.save();
}
}
}*/
MJournal.Java : get the amount from Acct
public String prepareIt()
{
...
for (int i = 0; i < lines.length; i++)
{
...
-- AmtSourceDr = AmtSourceDr.add(line.getAmtSourceDr());
-- AmtSourceCr = AmtSourceCr.add(line.getAmtSourceCr());
++ AmtSourceDr = AmtSourceDr.add(line.getAmtAcctDr());
++ AmtSourceCr = AmtSourceCr.add(line.getAmtAcctCr());
Doc_GLJournal.Java : new parameter m_AcctSchema_ID added
private DocLine[] loadLines(MJournal journal)
{
...
for (int i = 0; i < lines.length; i++)
{
-- docLine.setAmount(line.getAmtSourceDr(), line.getAmtSourceCr());
++ docLine.setAmount(m_C_AcctSchema_ID, line.getAmtSourceDr(), line.getAmtSourceCr());
DocLine.Java : check if document currency is the same as acctSchema Curr? If they're same then get Amt from source
otherwise convert the amount.
-- public void setAmount(BigDecimal amtSourceDr, BigDecimal amtSourceCr)
-- {
-- m_AmtSourceDr = amtSourceDr == null ? Env.ZERO : amtSourceDr;
-- m_AmtSourceCr = amtSourceCr == null ? Env.ZERO : amtSourceCr;
-- }
++ public void setAmount (int C_AcctSchema_ID, BigDecimal amtSourceDr, BigDecimal amtSourceCr)
++ {
++ m_C_AcctSchema_ID = C_AcctSchema_ID;
++ MAcctSchema m_acctSchema = MAcctSchema.get(Env.getCtx(), m_C_AcctSchema_ID);
++ if (m_C_AcctSchema_ID==0 || m_acctSchema.getC_Currency_ID() == getC_Currency_ID())
++ {
++ m_AmtSourceDr = amtSourceDr == null ? Env.ZERO : amtSourceDr;
++ m_AmtSourceCr = amtSourceCr == null ? Env.ZERO : amtSourceCr;
++ }
++ else
++ {
++ m_AmtSourceDr = amtSourceDr == null ? Env.ZERO : MConversionRate.convert (Env.getCtx(),
++ amtSourceDr, getC_Currency_ID(), m_acctSchema.getC_Currency_ID(),
++ getDateAcct(), m_doc.getC_ConversionType_ID(), m_doc.getAD_Client_ID(),
++ m_doc.getAD_Org_ID());
++ m_AmtSourceCr = amtSourceCr == null ? Env.ZERO : MConversionRate.convert (Env.getCtx(),
++ amtSourceCr, getC_Currency_ID(), m_acctSchema.getC_Currency_ID(),
++ getDateAcct(), m_doc.getC_ConversionType_ID(), m_doc.getAD_Client_ID(),
++ m_doc.getAD_Org_ID());
++ }
++ } // setAmounts
public void set Amount (BigDecimal LineNetAmt, BigDecimal PriceList, BigDecimal Qty)
{
...
-- setAmount (m_ListAmt, m_DiscountAmt);
++ setAmount (m_C_AcctSchema_ID, m_ListAmt, m_DiscountAmt);
}
public void setLineNetAmtDifference (BigDecimal diff)
{
...
-- setAmount (m_ListAmt, m_DiscountAmt);
++ setAmount (m_C_AcctSchema_ID, m_ListAmt, m_DiscountAmt);
}
rgds,
eddy
Logged In: YES
user_id=1599854
Originator: NO
Hi all,
I think the correct fix to this should be to make c_currency_id not editable for journal and journal line, c_convertype_id, currencyrate and dateacct not editable for journal line. This should eliminate the various tricky/strange combination now possible with the screen.
If vote is positive, I will implement this into trunk.
Regards,
Low
Logged In: YES
user_id=948611
Originator: NO
Hi,
Yes Low, I agree with your approach.
[+1] to implement as you've suggested.
Regards,
Alejandro
Logged In: YES
user_id=1238223
Originator: NO
I think this is a drastic measure Low.
The journal lines are often representative of documents and they will have different currencies, dates & hence exchange rates. If they must be the same then we are saying we will force users to create multiple journals one per date/currency combination ... is this correct?
Perhaps, I do not understand the problem correctly, but I see no issue with the lines having different currencies and/or different exchange rates on different journal dates. I think so long as the Journal is the correct total of the journal lines I think all should be ok.
colin
Logged In: YES
user_id=1180760
Originator: NO
Good thing, lots of approaches to review here :-)
First, raising priority to 9 as the data is corrupted.
croo - I reviewed the patch provided by Colin (not tested) and I think it solves the problem OF THIS TRACKER in the easiest and direct way. +1 to implement it in trunk
eddych - this is a different problem:
Make Total Debit and Credit balance to complete and post the document.
Not reviewed the code, but I like to have this option in Adempiere.
Just I think it must take account of the C_AcctSchema_GL.UseSuspenseBalancing
hengsin - I remember we talked about this, but I don't remember the conclusion :-(
As I understand the Batch parameters are just values to inherit to the Journal (and they're being wrongly inherited, i.e. Account Date and Period)
But as Colin says, if there are no problems having lines with different parameters, then I don't see the reason to solve that.
Regards,
Carlos Ruiz
Logged In: YES
user_id=1180760
Originator: NO
Implemented in trunk the patch from Colin with revision 4521.
Regards,
Carlos Ruiz
Logged In: YES
user_id=1599854
Originator: NO
carlos,
this is an incomplete fix:
* the help text for totaldr and totalcr for journal and journal batch say it is in 'Document Currency', if we apply Colin's patch, this needs to be changed too.
* this will also impact the control total checking, if the control total should also be in the 'Base Currency' instead of 'Document Currency', we will need to update the help text too. Otherwise, the control total checking will need to cater for this changes.
Regards,
Low
Logged In: YES
user_id=1180760
Originator: NO
Hi Heng Sin, you're right.
I think your problem report deserves a new bug report with priority 1 (documentation) - and close this priority 9 bug.
Regards,
Carlos Ruiz
Logged In: YES
user_id=1238223
Originator: NO
>>this is an incomplete fix:
Actually I do agree with hengsin!
I looked again at your last comment hengsin because as I said in my response I simply didn't *understand* how it would solve things. Thinking about it more I would add that I think the idea to limit currency is correct BUT I would change where that restriction applies. For me it would be better is the Batch & Journals should always be in the currency of the schema to which they apply. Because I would think it must be possible to enter the journal lines in any currency necessary - but it is the converted (the the schema currency) amounts that would be posted to the GL.
Now while saying that I have never used or tested multiple schemas and thinking about this leaves me wonder how it's supposed to work!?
Also I can imagine that there could be an imbalance when manual lines are entered in different currencies and dates and I would feel it's up to those entering data to create a posting to the currency gain/loss account as needed.
what do you think?
colin
If the patch is applied then this tracker is concluded. Discussion still open it seems from Colin's last comment.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).