Ok, thanks @kvvaradha.

Committed and a new file here.

/Joe

Ok, we may rather need Janusz's opinion to this.

Joe

@kvvaradha.

Did you mean that it was ok to change the

line 505 in /sales/includes/ui/sales_order_ui.inc 
from:
            sales_items_list_cells(null,'stock_id', last_sales_order_detail($order, 'stk_code'), false, true, true);
to:
            sales_items_list_cells(null,'stock_id', null, false, true, true);

?

/Joe

@kvvaradha

Please make a comment on this. Do you agree with @apmuthu?

Joe

For your information accountants will not be confused about how the accounts are balanced when closing a FY. To bring forward (Close) a balanced accounts to the next FY where balance accounts are equal then the result accounts must also be equal where the former Calculated Return now has landed on the Year Results Account, Debit for Gain or Credit for Loss.
This is normal handling for all accountant.
If you are in doubt, please contact your local accountant.

Joe

As an addendum. Are you using the last 2.4.6 release. Because I maybe recalling an issue a while ago.

/Joe

I don't know what you are doing.
These routines with closing years has been working for at least 12 years without problems.

/Joe

Sure, thanks @apmuthu.

This has been re-committed. Fixed file here.

/Joe

534

(7 replies, posted in Announcements)

Sure, it was my plan too. A little more interactive perhaps.

/Joe

Thanks @kvvaradha.

This has been fixed and committed to stable repo.

The fixed file can be downloaded here.

Joe

@Braath Waate.

You are right. It was my fault that this was a missing parameter. Thanks.

@kvvaradha.

It was you that suggested the correct fix, but I accidently missed this function call on a line. Sorry for that.

Fixed and committed to stable repo. The /sales/includes/ui/sales_order_ui.inc can be downloaded here.

/Joe

Thanks @kvvaradha.

I will check later.

Joe

This has been fixed in core and committed to stable repo.

The fixed file can be downloaded here.

Thanks for finding this!

/Joe

The repo should work again. Sorry for the Miss.

Joe

540

(7 replies, posted in Announcements)

Hello Guys,

We had to transfer the Website to a new Webhost due to outrageous price increase.

This transfer is now done. Hopefully without too much problems.

I can understand that there might be some missing posts. In that case forgive us and try to enter them again.

In a couple of months we will try to release a 2.5 Alpha. Included will be a Human Resource Planning (HRM or Payroll) that has been developed by @notrinos. It will have a few changes to adapt to the core of FA.

There will also be some improvements on the themes. We will implement a poll, with the various new themes presented by some developers.

/Joe

Yes, I can reproduce this. Will talk to Janusz about this.

/Joe

@JimmyC

The file /sales/includes/db/sales_invoice_db.inc has now been fixed and committed to stable.

A Fixed file can be downloaded here

Joe

@JimmyC

Thanks JimmyC. I have found the bug now. There is a zero amount tax record with an amount of 50 that are inserted in the trans_tax-details table.
The tax amount of this is 0 and is inserted as a 0 amount of tax with an unknown account. This record should never create a gl_trans.

I will fix that in a while.

/Joe

@jimmyC

I have been doing some investigation about this empty account line.

This line is created if floatcmp reports a balance. Look in gl_db_trans.inc, line 95.
There should also be an error line in your tmp/errors.log file for the date. Please have a look and report.

But the reason that the account code is empty is that there is no System and GL account for 'exchange_diff_act'.
If you go into Setup/System and GL setup and look up this account, there might be a value here, but if it doesn't show the right account change the account to show the right act, then save the setup.

Then please try another Direct Invoice. Now it should work.

/Joe

the later GL transactions seems to include an empty account line (are there any missing accounts in your chart of accounts.
FA should never post anything to an empty account.
The line could be some rounded values, but the value is 0 so this looks strange.
I have no idea. In my testing everything went ok in the GL lines and it should do so.

Please check that all your default accounts in the System and GL setup are ok. Do this check in the phpMyAdmin.

/Joe

Hello again.

I found the place to fix the bug and this has been committed to stable repo.

/Joe

Hello again @JimmyC.

I see the problem now. When the Document date is earlier than todays date, then the duedate becomes todays date. This is only for Cash Payments.

I have problem finding where to fix this error. Janusz wrote these routines. I will ask him to fix this. Thanks for reporting this.

/Joe

@JimmyC.

I cannot reproduce your examples in version 2.4.6. However there was a presentation bug in Sales Order View.

In the Direct Invoice, the Sales Order is automatically created with the reference 'auto'. The value in the due_date field was the later invoice due_date. So in the dispatch view, you will see the label 'Due Date' instead of 'Requested Delivery'.

Therefore I have changed the 'Sales Order View' to present the 'Due Date' value if the reference is 'auto'.

This should eliminate the misunderstanding.

I am open for other users testing this to see if I have missed another bug.

The view_sales_order.php has been committed to stable repo.

/Joe

This has been committed to stable repo. Thank you @notrinos for providing this.

Remember to change the settings in config.php also.

/Joe

@BraathbWaate.

Ok I will commit it later.

Joe

Committed