Skip to forum content
FrontAccounting forum
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 60 of 245)
Topics by apmuthu User defined search
Posts found: 1,476 to 1,500 of 6,111
There is no real difference in installing FA 2.4.2 or 2.4.4 and moving it across PHP versions since only a few config files are generated during the install. If the code in the core and the extensions used are compatible with the appropriate version of PHP, then all should be okay.
The upgrade, however may not be that straightforward across PHP versions. Various users experiences on and off the wiki/forum will need to be referred.
Upgrade of PHP version will affect older FA installs. The older PHP functions / syntax may have gotten removed in later PHP versions.
There is probably no change in the way Amount in Words is used in FA for quite some time spanning multiple versions. How does the system know that the preferred language of the Supplier / Customer is non English?
Switch service provider or check if they allow multiple versions of PHP to co-exist (CGI?).
Take a backup of the FA DB and the scripts (if you have specific versions of extensions / customisations).
The DB v10.x is that of the MySQL plugin replacement called MariaDB.
There are no real MySQL DB changes from v2.4.2 to v2.4.4 other than some records for the sys_prefs table records and their dependencies.
The function user_company() is in includes/current_user.inc and expects the default company to be defined in the config_db.php file for use on the login screen if no company is available / selected as yet.
The files that changed from FA v2.4.2 to FA 2.4.4 and those that changed thereafter to the current GitMaster are available in the announcements page from where you can sequentially overwrite the existing ones without having to install them (the install folder's files may be ignored).
The databases may have to be upgraded on first admin login into each company.
Along with the PHP 7.1/7.2 upgrade you also run the risk of getting your MySQL version upgraded too to 5.7.x which may need some strict setting to be switched off like zero date.
Check the FA 2.4.4 announcements page for changed file set.
Or integrate the backends and provide reciprocal links in one another if they are independent applications.
@joe: Worth adding to the core with either a checkbox or sys_prefs flag?
Set the PDF to auto print in the printer preferences if the print profiles do not work. Choose a network capable POS printer of use a software driver for it or open the appropriate port like CUPS Ports 515, 631, 9100-9102 TCP on your router and windows firewall.
Then there is no need to make print profiles. Just print the PDF reports directly onto the local printer.
Also make sure your active fiscal year matches the date you wish to input your invoices. In the first instance, the year ended on 31st August and the invoice was input in September and hence the date was set as the last day of the active fiscal year which was the real previous fiscal year by the time the invoice was entered.
Is POS location different from FA location?
Is there a different printer connected to the POS machine?
Yes. Overwrite the existing file.
Actually it is not an extension. It is just a simple php file placed in the FA root and executed therefrom or used online from my server. See my earlier post.
Use the Company Name as Text instead of dropdown for login. Set the config.db variable $text_company_selection accordingly.
Actually, to simplify the extension design, all customers must be registered in the FA system natively first before getting to use the online ordering. Their customer id can be then tagged to a separate set of tables having it's own authorisation, possibly integrated into WordPress and the likes of WP-Adminer plugin for simplifying UI design.
Simpler still will be to have a dumb insecure form with no usernames / passwords that generates a long hash code after populating a standalone table where even rubbish / unauthorised info can get in, throttled by some CAPTCHA system. One of the fields will be a user hash code in that form. The salesman's interface to this rubbish table will be to select "his" customer's records only and decide what to do. If the salesman chooses to capture it as a valid order possibly corroborated in other ways (phone, email, etc), then he can paste the hash code of the customer request record into the FA subsystem which should then populate another field in the rubbish table with the Sales order number from the FA system. This way there is no need for any username/password for the customer.
@joe: see if you want to implement @braathwaate's version of rep108.php, diff attached.
Generally the ID field gets to be the order of display if the date field is not doing it. There may be other places where the date stated could be used like in the audit trail table and some summary records if any. Extract out the actual changes from the difference between before and after one such transaction's backups and see what gives.
Actually, the Debit / Credit Notes have allocation potential, otherwise a mere Journal would have sufficed.
@joe: can we make DN/CN for all Suppliers and Customers alike?
Customer Debit Note: Does a negative value work?
This was corrected in the FA24Extensions repo on 2018-01-07. Unfortunately, the official extensions do not check out such fixes from the unofficial repo.
Does the change straddle an older fiscal year?
If so check your sys_prefs table settings and those in your config.php file as well since many config variables have been moved to company-specific ones in the sys_prefs table.
@chunket: Nice way. Thanks for the feedback.
Clear your cache and the cache in FA.
Posts found: 1,476 to 1,500 of 6,111
