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
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?
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
FA is using average material cost on stock items.
The operation can be seen in /purchasing/includes/db/grn_db.inc in the first function update_average_material_cost($supplier, $stock_id, $price, $qty, $date, $adj_only=false).
On line 66 you will see
$material_cost = ($qoh * $material_cost + $qty * $price_in_home_currency) / ($qoh + $qty);
$material_cost will be currennt material cost multiplied by current qoh + transaction qty multiplied by price in home currency. This will then be divided by qoh + qty.
These operations will be new average matefial cost.
So the calculations are correctly done.
All stock transactions are going through this routine.
Joe
FA is using average material cost on stock items.
The operation can be seen in /purchasing/includes/db/grn_db.inc in the first function update_average_material_cost($supplier, $stock_id, $price, $qty, $date, $adj_only=false).
On line 66 you will see
$material_cost = ($qoh * $material_cost + $qty * $price_in_home_currency) / ($qoh + $qty);$material_cost will be current material cost multiplied by current qoh + transaction qty multiplied by price in home currency. This will then be divided by qoh + qty.
These operations will be new average material cost.
So the calculations are correctly done.
All stock transactions are going through this routine.
Joe
Sure, will download and ask Itronics to do that.
Joe
Ok, done. Included in 2.4.15 at Sourceforge.net.
Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.