1

(13 replies, posted in Report Bugs here)

Just an update to this in case others have the same technical issue.

It seems setting an antivirus exemption for httpd and mysqld seems to resolve the problem for now (note: client and web server and db server are one and the same computer using XAMPP).

Also see this link: https://docs.bitnami.com/installer/faq/windows-faq/configuration/configure-antivirus-windows/#disable-execution-scans

Other things to look at are giving explicit firewall exclusions for localhost and also setting the browser (in my case Firefox) to NO PROXY.

Probably it was the antivirus setting that helped to resolve the issue.  Was using Gravity Zone End Point Protection and set it to scan all processes aggressively.

2

(13 replies, posted in Report Bugs here)

Hi Braath,

I want to put in some more question to this post just to have more clarity.

You have indicated a scenario where the end user intentionally opens multiple windows or tabs (for different business processes) and by consequence runs into the technical issue.

Let's compare this with what I have observed.

The technical issue that I have encountered is happening even if running Chrome in incognito mode (thus no cache) and there is only 1 one window with 1 tab open and the first action that I am trying to do is a direct invoice immediately after login.

Further more, the technical issue is most often encountered with Chrome and rarely with Firefox.

As such, could it be that the technical issue that I am encountering is different from what you have described but with a few overlap (similar behaviour and error messages).

Next, I want to check if it will help to tinker with the php.ini inside XAMPP folder.  Specifically those having to do with server caching settings (not very sure if the caching eventually ends up on server side or the client browser side) (*client and server are one and the same computer*).

Sidenote #1: I only have a lesser than basic knowledge with PHP, sorry.

Sidenote #2: I think the edit check (for other open FA window and tabs) might be a relevant feature to have.

3

(13 replies, posted in Report Bugs here)

Hi Braath,

Noted with thanks.

Had a look at the mantis page link.

I will be doing the edit to config.php for now.  Many thanks for the input.

Will also use Firefox just to be on the safe side.

Best regards,

Kanay

4

(13 replies, posted in Report Bugs here)

Hi Braath,

Noted with thanks. Will try the change in settings on config.php .

I am not able to access http://mantis.frontaccounting.com as I do not have login access to that.

Please assist to copy and paste the information from there and into this forum post.

Best regards,

Kanay

5

(13 replies, posted in Report Bugs here)

Hi Development Team,

I regularly get this error message when attempting to do direct invoice.

"This edit session has been abandoned by opening sales document in another browser tab. You cannot edit more than one sales document at once."

The error shows even when there is no other window or tab opened with FA.

Was running FA 2.4.6
OS is Win 7 Pro
Chrome (updated) (regular occurrence of error)
Firefox (extreme rare occurrence of error)
Initially running PHP 5.6.40 (from XAMPP) (error happens)
Switch to PHP 7.3.9 (from XAMPP) (to troubleshoot but error still happens)
Installed FA 2.4.7 (error still happens)

I can't consistently replicate the error and when I click around the interface to recreate the same error, i encountered another issue.  The log in instance does an uncommanded log out (in Chrome) .

So now I have 2 issues: Session abandoned and uncommanded logged off.

Additional info: Just prior to uncommanded logoff, there seems to be a Chrome windows that pops up and offers to translate the page (Chrome built in page translate).

I am not able to make sense out of it as everything was more or less okay for the past few years.  These started happening in August 2019.

There was no significant change done to the FA system just prior to the errors showing up.

Could this be due to any of the following?

Windows updates?
Chrome updates?
Chrome change of theme from default to something else?
Character encoding in db?
Using wrong character encoding when doing restore backup through myPHPadmin?

I hope someone can help to make sense of these.

Best regards,

Kanay

Noted with thanks.

I think I might make an effort to pick up PHP skills.

Please give some suggestions on what is a good starting point (book or website) for someone to learn PHP and MySQL for web applications (especially ERP applications).

To the Development Team,

The Supplier Transaction Inquiry for GRN does not filter the results by date range.  Instead it shows all the GRN inside the database.

Supplier Transaction Inquiry for Supplier Invoices and Supplier Payments are working okay.

Many thanks for looking into this possible bug.

Hi Janusz,

Thank you for your input.

I am using 2.3.16 and occassionally doing some tests on 2.3.18.

The issue was noted on 2.3.16.

The way the figures are being handled in 2.3.18, it is quite correct in trying to nail down the most accurate value for the inventory item.

The program calculates the difference in value between GRN and Invoice (due to fluctuations in exchange rate) and passes this value back to the total value of the specific inventory item thus influencing the average value to be as accurate as possible.

But I believe there are some downside in trying to get this level of accuracy for the inventory values.

#1. The postings in GL become quite complicated and someone without knowledge of the working of FrontAccounting will have difficulty making sense of the GL entries.

#2. Theoratically, (I hope I am not wrong here) the final determinant of the true value of an inventory item is what was the exchange rate when the inventory purchase invoice was paid for.  That means, the exercise of adjusting inventory values for fluctuation in exchange rate upon invoicing (for a GRN) is something that can be argued as not being necessary.

#3. Refering back to point #2, coding to adjust the inventory value for exchange rates flutuations upon the time of making payments may be taking things too far and also result in GL posting that are too complicated to comprehend.

#4. The application's intent to get the value accurate can be defeated under certain circumstances.  This happens when a sales transaction for the product happens in between the GRN entry and Supplier Bill entry.

Let's take this scenario Company ABC with USD as base currency
    A. Company ABC receives (GRN only) 100 units of Product X at EUR 1.00 each
        Exchange Rate: EUR 1.00 = USD 1.33
        Product X Quantity on hand = 100 units
        Product X Total value = EUR 100.00 = USD 133.00

    B. Company ABC sells 50 units of Product X one week after the GRN
        Product X Quantity on hand (balance) = 50 units
        Product X Quantity on hand Total value (balance) = EUR 50.00 = USD 66.50

    C. Company ABC receives the bill (2 weeks after GRN) for the GRN of 100 units of product X
        New Exchange Rate: EUR 1.00 = USD 1.25
        FA 2.3.18 would post as follows for the invoice entry
        Debit GRN A/c.......... USD 133.00
        Credit Supplier A/c.... USD 125.00
        Credit Inventory A/c...    USD 8.00 (negative amount applied to Product X)

    D. Effectively the value of Products X becomes
        Total on hand value = USD 57.50 (based on 65.50 - 8.00)
        Average cost = USD 1.15 (based on 57.50 / 50)

    E. The accurate value should have been
        Total on hand value = USD 62.50
        Average cost = USD 1.25

#5. I have noted that FA 2.3.18 automatically adjust for cases where posting of adjusting values might cause negative or positive inventory values when quantity is zero.  This is okay.  But things go wrong when quantity is not zero and adjustment values are generated.  Refer to #6 below.

#6. Under certain scenarios, there may be cases where the inventory quantity is positive but the value is negative.  (tested on FA 2.3.18)

Let's take this scenario Company XYZ with USD as base currency
    A. Company XYZ receives (GRN only) 1000 units of Product J at EUR 10.00 each
        Exchange Rate: EUR 1.00 = USD 1.30
        Product J Quantity on hand = 1000 units
        Product J Total value = EUR 10,000.00 = USD 13,000.00

    B. Company XYZ sells 998 units of Product J one week after the GRN
        Product J Quantity on hand (balance) = 2 units
        Product J Quantity on hand Total value (balance) = EUR 20.00 = USD 26.00

    C. Company XYZ receives the bill (2 weeks after GRN) for the GRN of 1000 units of product J
        New Exchange Rate: EUR 1.00 = USD 1.28
        FA 2.3.18 would post as follows for the invoice entry
        Debit GRN A/c.......... USD 13,000.00
        Credit Supplier A/c.... USD 12,800.00
        Credit Inventory A/c...    USD 200.00 (negative amount applied to Product J)

    D. Effectively the value of Products J becomes
        Total on hand value = USD -174.00 (based on 26.00 - 200.00) (negative value)
        Average cost = USD -87.00 (based on -174.00 / 2) (negative value)

    E. The accurate value should have been
        Total on hand value = USD 25.60
        Average cost = USD 12.80

What I am trying to emphasise here is as follows.
##1. The GL posting should be reasonably clear for those who know book keeping but are not familiar with FA
##2. Any value only adjustments to inventory (without corresponding quantity change) should be totally avoided
##3. The inventory values should only be committed upon GRN and must not be altered when supplier bill is entered
##4. The exception to ##2 and ##4 above is when the accountant makes an informed decision to partially devalue inventory or make inventory obsolete

I believe sales return and purchase returns affect the inventory value.  I am unable to give my input on this for now.

Best regards,

Kanay

Hi apmuthu,

Thank you for your input.

Turning off auto exchange rate might reduce the number of incidents but that does not quite address the issue.

My explanation for this follows.

Example: If the account administrator, routinely changes the exchange rate, there will highly likely be a difference in exchange rate at the time of GRN compared to the time of invoice input.  In such a situation the same issue comes about even if the auto exchange rate is turned off.

-------------------------------------------------------

I have tweaked my earlier suggestion so that you need not make any changes to the DB structure but just the coding.

Suggestion with scenario follows.

SCENARIO
-------------
Domestic Currency is USD

On Monday
-- Exch Rate is 1 USD = 0.75 EUR
-- I received Product XYZ (GRN only) 1 unit at price of 75.00 EUR (equals 100.00 USD)
-- GL posting >>> Debit Inventory 100.00 and Credit GRN clearing account 100.00

On Friday
-- Exch Rate is 1 USD = 0.78 EUR
-- I received invoice for Product XYZ 1 unit at price of 75.00 EUR (equals 96.00 USD based on latest rate)
-- GL posting >>> Debit GRN clearing account 96.00 and Credit Accounts Payable 96.00

This leaves a value of 4.00 in the GRN clearing account which cannot be traced back to it's originating transaction.

SUGGESTION
-----------------

Step 1: Establish if difference in exchange rate between GRN and INVOICE has happened.

Step 2: Establish the base currency difference in value of inventory items between the GRN and INVOICE transactions.  In this case it is USD 4.00.

Step 3: Post GL as follows

---Debit GRN clearing account 100.00

---Credit Accounts Payable 96.00

---Credit GRN Account 4.00 (yes, put back to GRN account) (separate line)

Only other additional thing is to include a memo tag "AUTO VARIANCE DUE TO EXCH FLUCTUATION" to the USD4.00 posting to the GRN account.

This way, the auditior can see where the variance is coming from and why.

Hope the suggestion helps.

Best regards,

Kanay

Hi,

This is for the attention of the development team.

I have noted something in the way that FA handles the inventory values when it comes to taking values out of the GRN clearing account and would like to put forth an alternate method of handling the numbers.

For example.

Domestic Currency is USD

On Monday
-- Exch Rate is 1 USD = 0.75 EUR
-- I received Product XYZ (GRN only) 1 unit at price of 75.00 EUR (equals 100.00 USD)
-- GL posting >>> Debit Inventory 100.00 and Credit GRN clearing account 100.00

On Friday
-- Exch Rate is 1 USD = 0.78 EUR
-- I received invoice for Product XYZ 1 unit at price of 75.00 EUR (equals 96.00 USD based on latest rate)
-- GL posting >>> Debit GRN clearing account 96.00 and Credit Accounts Payable 96.00

This leaves a value of 4.00 in the GRN clearing account which cannot be traced back to it's originating transaction.

Suggestion
--------------
My suggestion is that GL posting should be as follows
Debit GRN clearing account 100.00
Credit Accounts Payable 96.00
Credit Inventory Variance Account 4.00

This makes the source of the variance value traceable back to the originating transaction.

Hi apmuthu,

Thank you for your input.

Should I try this patch on version 2.3.16 or the latest version 2.3.18?

Right now I am still running version 2.3.16.

Best regards,

Kanay

Hi apmuthu,

Thank you for your input on this.

I can confirm that this happens even when the bank account and vendor account are both tagged to the base currency.  That is, there is no foreign currency component to the transaction.

I also tested it on the test demo data (4 digit American Chart of Accounts) and was apple to replicate the same issue with version 2.3.17.

Hi apmuthu,

Thank you for your input.  Taking out the bank charges and posting it as a separate journal does solve the problem.

I am concerned that an unaware user could unknowingly commit inaccurate GL posting by using the bank charges feature.

Hi Martin,

I am facing the same issues.

It only happens with the latest version 2.3.17.

I have made a post on the bugs report section as well.

You might want to try out version 2.3.16 till the developers look into this.

Cheers,

Kanay

Hi to all,

I noticed a slight error in the GL postings for a supplier payment with bank charges (before applying against invoice).

It could be a rounding error.

It only happens for a specific combination of exchange rate, settlement amount and bank charges.

The issue is consistently replicable in version 2.3.16. 

The scenario is as follows.

Base / Home Currency: SGD
Vendor's Foreign Currency: EUR
Made a payment of EUR 7150.91 to vendor.
The bank converted amount is SGD 12139.22.
Over and above this, the bank charges are SGD 35.18.

The GL posting should be as follows:
Debit Accounts Payable 12139.22
Debit Bank Charges 35.18
Credit Bank Account 12174.40

Instead, what I get is as follows:
Debit Accounts Payable 12139.22
Debit Bank Charges 35.17
Credit Bank Account 12174.39

I will glad to give more clarification to resolve this.

Cheers,

Kanay

Hi to all,

I want to bring up this discrepancy in the GL Posting for the latest stable release 2.3.17.

I applied a payment against a local supplier (whose transactions are in base/domestic currency).

In such a scenario, there should not be any amount posted to Exchange / Gain Loss Account.

But, for some reason, there is a significant figure being posted to the account.

The discrepancy happens only with version 2.3.17 and is consistently replicable.

It does not happen with version 2.3.16.

I would be glad to furnish more information to resolve this.

Cheers.

Kanay