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 77 of 246)
Topics by apmuthu User defined search
Posts found: 1,901 to 1,925 of 6,143
@braathwaate has now provided backwards compatibility (using the NonSplat_fix.diff in Post #3 here) where both get_js_history() and set_posts() work. As an example, after applying the fix above, the file sales/inquiry/sales_orders_view.php works for both Ajax as well as js history of the $_POST variables from the form.
Using the attachment, test by entering a transaction_number under "#" and then moving the cursor to the next field - the ajax will refresh the filtered page.
Some of the inquiry files will need to be synched with subsequent changes in the core.
The fiscal years must be numbered in order so that closing the fiscal and purging it will nor affect the newer ones as it is ID based. If you have just one fiscal year now, then just make all fiscal year id as 2 and then create the previous fiscal year with id=1. They will appear as f_year as well in the sys_prefs table.
audit_trail.fiscal_year
fiscal_year.id
sys_prefs.name='f_year'
Read the following posts and the l;inks therein and FA's current limitations.
Current 2018: https://frontaccounting.com/punbb/viewtopic.php?id=7270
Circa 2010: https://frontaccounting.com/punbb/viewtopic.php?id=800
This entire commit should be made backwards compatible as in my previous post (or a comment added that it is for PHP v5.6+ only) as the current PHP versions that FA supports cannot handle the new constructs effectively. There are no $_GET variables available when the new set_posts() function is called in this way as the session.inc erases all $_GET values except for those coming in thru Ajax - js http requests. The set_posts() however acquires the ajaxed GET variables correctly.
The persistence of the history works on substitution of ...$vars with $vars and changing to get_js_history(array(......)). The ChangeVar of the combo boxes do not work even with the set_posts(array(......)) fix.
For those wishing to test it further, the attachment would be useful. It contains the BraathWaate files with the existing counterparts in the core and the altered ones to incorporate this commit into the inquiry files with the backwards compatibility fix for the new functions.
Create a Credit Note / Debit Note for each Balance Sheet Entry at the beginning of the blank current and first FA fiscal. Alternatively make a Journal entry for all the balance sheet figures on the last day for the previous fiscal, open a new fiscal year, close the old fiscal year and the old closing balances will get transferred as opening balances in the new fiscal. Note that the former will allow for allocation to Supplier/Customer but the latter will address non tracked payments / receipts only.
Setup => Access Setup => Role => Edit Role
He means to print more than 50 characters in the first post in this topic. Which report is @netracer referring to?
@joe: The explanation is okay but any change from FA 2.3 that warranted this in FA 2.4? Just a design decision that may fill up the ID space quickly. Is such a change of transaction number of any real benefit?
Thanks @joe.
There are a host of inquiry files that needs to be merged and tested as well.
Will get the diffs after testing.
In includes/ui/ui_view.inc, the newly added functions set_posts() and get_js_history() use the splat operator available in PHP 5.6+ for variable length argument lists.
Some workarounds are here.
We need to make it backwards compatible with the attached diff file.
@joe / @itronics: Do we intend to revert to FA 2.3.x functionality for retaining the same transaction number? Why was it changed in FA 2.4.x?
@uurfi: Open a new topic for each issue.
As a start try to change the field size and see if that satisfies the entry. Then change the font size on display/print.
Create and use a new en_IN.mo file by editing and compiling the en_IN.po file based on empty.po with the said "VAT" being replaced with "GST" everywhere.
@braathwaate has sent me a good pull request that needs to be incorporated into the core after checking if any critical extension breaks. The key file diffs are attached - includes/ui/ui_view.inc and js/insert.js.
@joe/@itronics: can do the needful.
Use FA 2.4.3+ as it has a lot of fixes.
You need to have some items and customers before you can create a sales quotation.
Also use a Chart of Accounts that matches the en_US-new.sql for tables, fields, field types and fields orders apart from missing SysPrefs entries fixed. Checkout the latest Charts from here.
1. Check tables with large logs and purge them especially after changing the debug variables in the config.php.
2. Use the command line to dump the backup - mysqldump
3. Use a MySQL client like SQLyog.
4. Increase the php.ini's script timeout and max transfer size / memory limit variables
5. FA's time limit is also hardcoded at 180 seconds or so - search the wiki.
In a separate new company, make 1 sample transaction to simulate the wrong entries you mad. Study the before and after sql backups Now appropriately edit the actual company's DB with these updations, possibly having the sqls created from a spreadsheet.
Using FA under localhost on Windows/Mac desktops is about the easiest it will get.
Most proprietary applications help you migrate your data from other's programs into theirs but will not help in doing the reverse. In the case of FA, you have access to the raw tables that you can manipulate/extend at will and migrae in/out without reference to anyone.
Identify the Sage DB used and it's version. See if an ODBC driver exists and is interface-able. Then identify the core elements you wish to import - Customers, Suppliers, Items, Pricelists, Chart of Accounts, etc. Export such data into an FA usable format and import using the Import extensions in FA.
Doing it yourself right is cost-effective. Asking others to do it might turn out more expensive than buying Sage, etc.
If the customer paid by non-cash means, say by cheque, then it would go directly to bank but still needs to be allocated to the appropriate sales invoice(s).
@uurfi: does this happen only to journal entries in FA 2.4?
@joe/@itronics: This needs to be fixed if true.
Use PHP upto 7.1.x. PHP 7.2.x still has issues with FA. Make sure that the MySQL Strict Date setting is disabled to allow for zero dates and times. Otherwise revert to PHP 5.5 or less.
The finished goods must then be moved to the appropriate warehouse location.
@joe: any issue here?
Setup => System and General GL Setup => Tax Algorithm
Toggle the choices and see what suits you. Logout and login again for it to be effective.
Hence the DB Record Number will change on such editing as the Audit Trail needs to keep track of it.
Test with Git Master FA 2.4.3+ as many fixes are included now since the original release.
State your server platform, PHP/MySQL versions.
Posts found: 1,901 to 1,925 of 6,143
