26

(4 replies, posted in Announcements)

Announcement

This is a 2.4.17 release, which is a new feature release as well as a bugfix release.

A couple of php 8.2 problems has been fixed. This release should now be PHP 8 compatible. The following versions has been tested: 8.0.0, 8.0.7, 8.0.12, 8.1.6 and 8.2.0.

Please report any bugs/problems found via our Mantis Bugtracker at http://mantis.frontaccounting.com.

Download instructions

In Sourceforge FrontAccounting (http://sourceforge.net/projects/frontaccounting), select
Files -> FrontAccounting 2.4 ->2.4.17.

For Windows users select the zip file. For all other users select the tar.gz file.

Security

FrontAccounting should NOT be used via unsecure http protocol. If you really need this - change SECURE_ONLY constant in /includes/session.inc to false (comment in the file added). Unfortunately this option cannot be added in sysprefs/config.php because the settings are not available before session is started.

Common

  • PHP 8.2 fix. Deprecated dynamic class member adds. Huge error.log.

Sales

  • Mark Inactive Customers in Reports (when no Filter).

  • Added Payment Link (Payment Service) for XUMM. A Dutch free Payment Service (see announcement forum).

Purchasing

  • Mark Inactive Suppliers in Reports (when no Filter).

  • Bug 5709: Opening Balance is calculated incorrectly in supplier balance. Fixed.

  • Bug Found in Supplier Invoice in Calculating Unit Tax

27

(7 replies, posted in Wish List)

Guys,

You can select the Customer Transactions and then filter by Sales Invoices or whatever you want.
Now you can see the order nr, reference and invoice no. And you can press the corresponding numbers for further details.

Joe

@boxygen

You are right. This has been fixed and committed to stable repo. Thanks for reporting.

A fixed version kan be downloaded here and replaced on your server.

Joe

@kvvaradha.

@Janusz reports back that these function was established for the unstable version and is intended to be used in the future.

So we will keep them.

Joe

Hello all.

There are missing items in your source.

I have

if ($_SESSION['PO']->trans_type == ST_SUPPINVOICE) {
    cash_accounts_list_row(_("Payment:"), 'cash_account', null, false, _('Delayed'));
}

So this should be      false, _('Delayed'));

I have never seen _false anywhere in the source. It should have cast an error. Also the function parameters are stopped after a , character after _false.

Joe

I will ask Itronics, if these functions are needed in the future.

Joe

This has been restored now. Fixed back to deliver_to in class. Commited to stable.

The reason this occurred was that the php 8.2 has deprecated dynamic member addings to classes, and I mistakenly took the wrong variable. Sorry for that and thanks for seeing this.

Joe

Thanks @apmuthu-
I will check this asap.

Joe

Your suggestion has now been implemented and committed to stable repo.

We use the bank_name field for the 'XUMM XRP' name. It is importand that this field contains XUMM as the first name and XRP (currency) name as the last 3 characters.
The name in the Payment Link has changed to XUMM XRP.
This is now prepared for future extension, f.i. XUMM USD.
Internally we do not use the Bank Account currency name. The XRP can cause abnormal exchange traffic.
Instead we rely of the last 3 characters in the name.

will you, @lp, edit the Instructions accordingly.
The changed file, /include/ui/ui_view.inc, can be downloade here and replaced..

Joe

Sure, I will fix that.
Should we use the same name, or only XUMM?

Joe

Thanks for these instructions.
This is going to be implemented in the next minor release. But if you want to try this already now you can download the file /includes/ui/ui_view.inc here and replace on your server.

Joe

This has been committed to stable repo and instructions will be put in the Announcement Forum by @lp.

Joe

hello,

I understand your concern, but when printing all the suppliers, we have to include the inactive suppliers, otherwise we have differences from the GL reports.

Maybe we should mark them as (inactive), right?

39

(3 replies, posted in Announcements)

Announcement

This is a 2.4.16 release, which is a new feature release as well as a bugfix release.

A couple of php 8 problems has been fixed. This release should now be PHP 8 compatible. The following versions has been tested: 8.0.0, 8.0.7, 8.0.12 and 8.1.6.

Please report any bugs/problems found via our Mantis Bugtracker at http://mantis.frontaccounting.com.

Download instructions

In Sourceforge FrontAccounting (http://sourceforge.net/projects/frontaccounting), select
Files -> FrontAccounting 2.4 ->2.4.16.

For Windows users select the zip file. For all other users select the tar.gz file.

Purchase documents

We have changed the purchase order detail line description to be updated with the entered
value from editable description or from the Supplier Description field from Purchase price table.

There are so many options for the description field, so we have to get the po line description
held together with the Purchase Order.

Otherwise all other stuff is handled as before.

FA is backward Compatible with this, so there should not be any problems with printing older
Purchase Orders.

At the same time, we have re-established the option to enter fractions of the purchase price.
Up to 6 decimals can be entered, if needed. But only use this option if needed.

Items and Fixed Assets Attachments

The Items and Fixed Assets can now have Attachments if you need this, and when entering new items,
there is an extra tab for entering Attachments. The operation is the same as for Customers and
Suppliers. You can also use the Setup - Attach Documents for this new option.

Security

FrontAccounting should NOT be used via unsecure http protocol. If you really need this - change SECURE_ONLY constant in /includes/session.inc to false (comment in the file added). Unfortunately this option cannot be added in sysprefs/config.php because the settings are not available before session is started.

Common

  • Bug. add_domain function generates a big list of not found domain file errors. Fixed.

  • Bug 5676: Currency stored in MySQL DOUBLE Type causes strange error. Fixed by explicitly SQL ROUND to price dec in
    updating allocations.

  • Bug 5684 Attach documents: error message when attaching document on some php8 versions fixed.

  • Annoyance 5683: Allow attachments from most needed post-creation option screens.

Sales

  • Bug 5678: Customer/Supplier Transactions Ageing Display Calculates Incorrectly (including full allocs) in Customer/Supplier Inquiries. Fixed.

  • Bug 5687: Unable to dispatch SO for service items with u/m decimal places set as "user defined" when SO item qty is less than 5. Fixed.

  • Changed get_unic_dec to get_qty_dec in customer documents for eliminating return -1.

Purchasing

  • Bug. Supplier Payment db calls void_cust_allocations. Fixed to void_supp_allocations.

  • Bug 5678: Customer/Supplier Transactions Ageing Display Calculates Incorrectly (including full allocs) in Customer/Supplier Inquiries. Fixed.

  • Bug5679. Supplier Invoices: error when second invoice to GRN was entered, fixed.

  • Supplier description is overwritten when receiving items. Fixed.

  • Bug 5695: Purchase Order Item Description should be saved on the PO line description directly. Fixed.

  • Allow fractional entry of Purchase Order Line Price. Up to 6 decimals.

  • Bug 5682: Voided PO Deliveries showing up in inquiries. Fixed by changing to Voided icon instead of GL icon.

  • Bug 5697: In Supplier Transaction Inquiry, Aging balances are Incorrect. Fixed.

Item and Inventory

  • Bug 5692: Translatable Strings in locations.php were not translatable. Fixed.

  • The average material cost test for either qoh > 0 and qoh + qty > 0 has changed to 0.0000000001 to avoid strange php results for very small values.

  • Implemented an Items tab for attachments and modified the existing setup attachments.

Fixed Assets

  • Implemented a Fixed Assets tab for attachments and modified the existing setup attachments.

Bank and General Ledger

  • Bug 5685: Bank Statement w/Reconcile report includes gl_trans values that are "0.00". Fixed.

Sure, I will take them too begore a release.

These items has now been fixed and committed to stable repo.

See forum topic https://frontaccounting.com/punbb/viewt … p?id=10276

Joe

We have changed the purchase order detail line description to be updated with the entered
value from editable description or from the Supplier Description from Purchase price table.

There are so many options for the description field, so we have to get the po line description
held together with the Purchase Order.

Otherwise all other stuff is handled as before.

FA is backward Compatible with this, so there should not be any problems with printing older
Purchase Orders.

At the same time, we have re-established the option to enter fractions of the purchase price.
Up to 6 decimals can be entered, if needed. But only use this if needed.

@apmuthu.
Will you check the Wiki and try to update this.

Due to this and other bug fixes we will soon make a minor upgrade.

Joe

Hello again,

@ckrosco
I understand your problem with the price decimals. We could simply remove the rounding and only calculate the $price = $price * $data['conversion_factor']. This lets you decide how many decimals the $price should be in. Or as you showed, 6 decimals. What do you think?

Joe

@ckrosco
The supplier_code should only be updateded if there is no data for supplier price record. So this has been changed and committed.
Please replace the file on your server.

Regarding the price truncation, I will have a closer look into this.

Joe

Hello @ckrosco

The only place the supplier's code or Description is shown is on the written purchase order. On all other places we are using our own name due to internal confusion otherwise.

So this is not a bug. The only person(s) that need to know the suppliers code is the suppler himself. Right?

Joe

Thanks @kvvaradha for participating in this discussion.

Joe

As you can only have 10 decimals (6 in UOM) in User Preference dialog the test for qoh or qoh+qty > 0.0000000001 will handle all situations now. I have made rigorious tests and it seems to handle all situations now.
All values less than 0.0000000001 will not be possible in the algorithm and no calculation will be executed.

Joe

After having tested this weighted average material cost, I have found that the test for qoh > 0 and for qoh+qty > 0 will fail for very small values under 0.0000000001, so the test will be changed to test for this value instead to avoid these fails.

Joe

@kvvaradha

To use our weighted average material cost, we must use the same decimals in the items qty. It is this that causes our miss calculation. F.i. if you start with qoh with 0.09 our algorithm is just fine. If we use the qoh of 0.08 we will get a zero value and nothing is calculated. Just fine.

So I see no problems here.

Joe

$kvvaradha

yes, if the ($qoh + $qty) is less than 1, there will be strange results. Before calculating this new material_cost, maybe we should first test if the (qoh + qty) >= 1. what do you think?

The routine get_unic_dec() will sometimes return -1. If the return value is -1, then the UOM is using the user defined decimals on the UOM. And should be tested by user_qty_dec(). I will check if all calls to get_unic_dec() is testing for this.
I am aware of the user_price_dec problem with material price. Maybe a standard flag on the home_currency function. to return the value without rounding. I am jsut afraid of ev. side effects. What do you think?

Joe