It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by joe
I have now been looking into this and came to the conclusion that we only add the selection type, Journal Entries.
For reason of backward compatibility, we will not change the 'unsettled transactions'. This will then cause confusing. The 'unsettled transactions' is used in several places now.
Eventually we can change this in a Major update.
The change will be pushed to repo in a while.
Joe
Yes, I can follow your arguments.
Regarding Journal .Entries, you are right. It should be included.
Would you kindly specify the salestypes problem in customer allocations.
Maybe we have the same problems in supplier ledger.
Joe
Hello. I think the meaning of unsettled here is transactions that are due. It has always been set so. Do you want another text, or?
Joe
Work order entry takes the dimensions set on the Created Item. But the Balance Account dimension wasn't stamped. This is fixed and committed to repo.
A fixed file can be downloaded here and replaced in /manufacturing/includes/db.
Joe
@kvvaradha
I hope you are looking at the last committed code from the core.
In the Invoice case we are first testing for $type == ST_SALESINVOICE before the return action (not voiding).
The code works smoothly. And it falls down to post_void_customer_trans with the correct $type and $type_no.
The $type and $type_no are never changed inside the function.
Joe
@kvvaradha
There are no missing breaks. I will explain.
The Customer Payment and the Sales Invoice must fall thru down to post_void_customer_trans($type, $type_no) on line 63 (inside ST_CUSTCREDIT and ST_CUSTDELIVERY.
Joe
Thanks for detecting this.
This has been fixed and committed to stable repo.
A fixed file can be downloaded here.
Joe
When the 'Direct Invoice' or 'Direct Delivery' are selected, the underlying Order references are stamped 'auto'. This means that these Orders are less interesting.
These Orders are there, if you for some reason must print them.
Joe
Hello again,
name changed to DebtorName.
@advocaat.pollet
Your last suggestion regarding $rep->filename change I am not sure this is a good idea. Normally we are not localizing file names.
Please downlows this file, rename, replace and check. If ok we will commit it and an empty.po to stable repo.
/Joe
@advocaat.pollet
Please download the file rep108.php1. Rename it to rep108.php and replace it in the /reporting folder.
Test this and report back.
If it is ok, we can commit it and update the po file.
/Joe
Yes, a good idea. Will do that later this evening.
Joe
@doug86
Did you download the new file /admin/db/voiding_db.inc and replaced it after the new install from sourceforge.net?
This install file is not updated yet. This file is only updated after a new release.
Joe
Oops, will make a rerun.
Joe
Thanks @Braath Waate.
This has been fixed in the core and committed to stable repo.
The fixed file can be downloaded here.
Joe
No, they cannot be voided, but if you want to add the dimension on a GL line, then use Journal Entry and simply counter book the original Inventory row. And another row where you put the correct dimension on the row. Use the same date for the operations as the original booking.
I hope you understand what I mean.
Joe
Yes, and the Customer Credit Note is also fixed and committed to stable. Thanks.
A fixed file can be downloaded here.
Joe
This has no been fixed and committed to stable repo. Thanks for reporting.
A fixed file can be downloaded here.
Joe
Ok, thanks. I will fix.
Joe
I guess we overlapped here. I saw that we cannot change the dimension in Journal Entry.
The easiest way would be to create some Journal entries to fix the correct dimension values.
Joe
I guess you will have to void the deliveries and re-enter them igen, after updating the files.
Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.