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 apmuthu
@cotcomsol: Thanks for the feedback.
Updated my FA24Extensions repo for this extension.
It is also attached herewith.
@joe: would you like to copy over the said function to it's original location? This change done in FA 2.4.x has broken the extension thus far. Any changes to functions in FA 2.3 when porting to FA 2.4 should take into account atleast it's use in all official extensions or fix the latter to accommodate such changes.
Added to the FA24Extensions repo.
construct should be preceded by 2 underscores(_).
There are many GL Accounts and Types and any merge will affect a different subset of tables.
The location redirection does not yet seem to work for the success status message to be displayed and the customer lists to be updated.
This is a composer issue. @cambell can provide an initial one so that users with no composer installed can still partake of it. Standard FA does not use composer.
@joe: is this a core permissions issue for the standard roles?
A compare of the backups before and after voiding will provide the diffs that need to be inserted when cancelling the voiding. Some computed values will be affected like average costing after such insertions.
@boxygen: nice catch.
Committed fix in my repo.
Consider that the price of an item changes over time. The approach hitherto has been to use the price prevailing at the time the invoice is generated.
@joe: A field for dynamic / static pricing may be included in the recurrent invoices table/form to accommodate both situations.
Compare and list the versions of Apache, PHP, MySQL, FA version for both the WAMP and the working server.
If your WAMP is having PHP7 then it will not work out of the box. You need PHP 5.3 to 5.5. Only MySQLi and not MySQL driver support is available for PHP 7 onwards but FA 2.3.x needs MySQL driver support
Take a backup from Setup => Backup/Restore and then do the voiding and then revert by restoring back if anything went wrong.
The way you changed the VAT lines is the quick 'n dirty method to do so and is not recommended as they will get overwritten when the next update is done. The correct way is to make a change in the language .po file and compile it into the .mo file and then use it.
As an example, the standard latin1 en_US.po file is at:
https://github.com/apmuthu/frontac24/blob/master/FA24Mods/lang/en_US/LC_MESSAGES/en_US.po
and is for the standard compiled one at:
https://github.com/apmuthu/frontac24/tree/master/core/lang/en_US/LC_MESSAGES
The UTF-8 version for the en_US lang files are at:
https://github.com/apmuthu/frontac24/tree/master/FA24Mods/lang/en_US-UTF8/LC_MESSAGES
All languages necessary to be choosable must find their folders in the lang folder and be present in the lang/installed_languages.inc file.
Setup => Display Setup will navigate to the Preferences page that can also be reached using the Preferences link at the top menu near the Logout link. Your user role access permission should allow for it to be visible.
Setup => Transaction References is where the Forms Setup is located.
@joe: it would be nice to split the comments at the bottom of all reports to wrap at some width suitable for each report.
The file reporting/rep107.php outputs the Invoice in FA.
The variable $cols shows the start of each field in mm. for the item list lines in the body of the invoice.
The variable $aligns sets the alignments for the above fields.
As the Header2 template is used in this report, check out the lines for address1 (154-157) and address2 (160-163) in reporting/includes/header2.inc which represent the "Charge To" and "Delivered To" addresses.
$show_voided_gl_trans was used in FA 2.3.x in only one place in the gl/includes/db/gl_db_trans.inc file's function get_gl_transactions() in lines 121-122:
if (isset($show_voided_gl_trans) && $show_voided_gl_trans == 0)
$sql .= " AND ".TB_PREF."gl_trans.amount <> 0"; The equivalent function of the same name in the same file in FA 2.4.2 (has an extra person_id parameter that defaults to null) does not use the said variable which is not used anywhere in the entire FA 2.4.x codebase and is also not used in any of the extensions in the official repo.
None of the extensions in FA 2.3.x use the said variable too.
Either we incorporate the said variable, $show_voided_gl_trans in it's FA 2.4.x avatar ($SysPrefs->...) or ditch it in it's entirety now.
@joe: which way?
The VAT is mitigated by making your own en_US .mo file and setting the translations in the .po file and then compiling it to a .mo file that can be used in your FA.
In the reporting/rep111.php file, th eline:
$comments = $_POST['PARAM_4'];can be altered to have the new line character inserted at every so many characters in it for auto break. This way it can be wrapped at the appropriate places in the $comment.
Wonder where the $myrow['comments'] got populated from! This is what should be wrapped. There may be a missing call in rep111.php to get_comments_string() (defined in includes/ui/ui_view.inc) as available in rep210.php.
The equivalent function in FA 2.4.2 is get_allocatable_from_supp_sql(), but it does not accomodate the extra fields, conditions and tables that FA 2.3.x's get_alloc_supp_sql() did in it's version of purchasing/includes/db/suppalloc_db.inc. Hence, make a local function called get_alloc_supp_sql() in the file rep_check_print.php to first call the said function in FA 2.4.2 and then incorporate the extra entities or just replicate the function from FA 2.3.x in it directly and then provide your feedback so that I can update my repo which is now more current than the official one.
The reporting/rep210.php has a similar use of the said function in FA 2.3.x and is replaced in FA 2.4.2 by:
get_allocatable_to_supp_transactions($myrow['supplier_id'], $myrow['trans_no'], $myrow['type']);You can try it's equivalent in the extension under reference.
Yes, just add the html code to the bottom of the invoice by hacking the appropriate report. See this post.
SourceForge is temporarily in maintenance mode.
Download the whole set of post release changed files from this post.
Check out the function check_overdue() in the file sales/inquiry/sales_orders_view.php and how it is called at nearly the end of the file:
$table->set_marker('check_overdue', _("Marked items are overdue."));You might want another function in similar vein, say, called function check_nearly_overdue() and implement a call similar to it near the end of the file. It might mean making another method for the table object's class for a different colour.
Check out the function handle_update_item() in purchasing\po_entry_items.php.
When a PO is made and a GRN for part supply is received and invoiced and an edit of the PO is attempted, only the original ordered Qty can be edited and that too it should be more than the Qty Received that cannot be edited since an invoice has been raised.
If your PO is say for a qty of 7 of a particular item, and your GRN shows that only 3 have been received, if you are now allowed to edit the PO Qty to be below 3 will it not become an anomaly? Remember that such quantities received affect the standard / average costing and provide for additional GRNs for the balance.
If the GRN Qty is not yet invoiced, the PO remains editable even for the Qty received. The PO cannot be edited if it's entire qty has been received in GRN and invoiced.
You can upload images anywhere and provide the link here.
Not everyone's list of transactions may be as straightforward as yours was. Every instance of import_transactions should normally trigger such an error if there were no customers/branches to begin with in the target FA.
Your experience and feedback will be useful to those in a similar situation. Thankyou.
The function check_db_has_customer_branches() in sales/sales_order_entry.php and sales/credit_note_entry.php is the one that normally causes this error. In this case, the import_transactions.php file too calls this function on line 131.
After taking a backup before importing transactions, try to temporarily comment out the said line and then import your transactions and see if everything is in order. This check is there for those who try to import transactions pertaining to customers that do not exist in the target FA system.
To make the $_GET variables persistent, copy it to the session variable.
State where you are using this construct and context.
1. Remove pragma-cache
2. Set expiry for refresh to old date
3. Make sure file_get contents is within the max filesize and timeouts set in php.ini / apache conf files.
4. Zipping the sql will save bandwidth if http gz compression is not enabled.
View discussion.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.