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
Setup -> System Diagnostics -> Not allowed for System Administrator for non 0 (non default) company.
It should not show up (must be greyed out) in a non default (non zero company) menu?
Line 62 of applications/setup.php:
"admin/system_diagnostics.php?", 'SA_OPEN', MENU_SYSTEM);should be:
"admin/system_diagnostics.php?", 'SA_SOFTWAREUPGRADE', MENU_SYSTEM);Filed Bug 1879.
It is Fuel and not Feul.
The first menu entry has two keyboard shortcuts : &.
Banking and General Ledger -> GL Inquiry -> Choose Account -> Choose Period -> Show
You will see the Ledger Folio of the Account chosen and can see the details of the Outstanding balance.
We may need a hook after all the login fields and before the submit button. This way we can include the Securimage CAPTCHA as an extension.
Normally it would not be a problem for me, as I use only the English language. In the case of changeset 3090, it s a replacement of a translate string - that has to be uniformly carried over to all affected files and the empty.po as well.
In the case of 3091, the new strings can come in during an FA release - if it was done at once, then those using non-English languages can also partake of debugging - we need as many eyeballs as possible on the code to get it up to speed. It will also help those translators in getting the strings translated well before the FA release.
Otherwise, such translate string changes should be withheld till the FA release whence it would update the empty.po as well.
A policy on this score would augur well when more than the current couple of committers comes to pass.
Contact the consultants in the Wiki for custom interface scripts.
What is the other software and what is the sample output format of your sales that you wish to import? Contact the consultants in the Wiki for any custom interface scripts.
See the GL folio for that customer
Application agnostic CSV import would be nice - templates for each Application to import from.
Please refer Wiki page at:
https://frontaccounting.com/fawiki/index.php?n=Main.Config
for all config variables and their possibilities.
A translate string change has been done in sales/manage/recurrent_invoices.php in Mercurial Changeset 3090.
Whenever a translate string change is done, an inclusion and / or substitution in the lang/new_language_template/LC_MESSAGES/empty.po file should be done and all the files that refer to the original string need to be checked for similar substitution.
In this case line 30 of sales/manage/sales_groups.php needs to have a different string but sales/manage/sales_areas.php should remain unchanged.
Also line 13124 in lang/new_language_template/LC_MESSAGES/empty.po needs to be suitably altered.
Changeset 3091 introduces 2 new strings not yet present in the empty.po file:
Cannot download repo index file.
and
Cannot download '%s' file.
Thanks Joe, your Mercurial changeset 3088 does it.
Lookup Fiscal Years in the Wiki.
Check the First Steps in the Wiki.
What format is your existing data in? CSV, Excel, DBF, Oracle, MSSQL, MS Access MDB, etc.,.
Using CSV files and phpMyAdmin, you should be able to get the data into the relevant tables.
If the intention is to keep the changes private, then, it is better to create a separate table for your new fields with a 1:1 relation to the invoice table and keep your changes as an extension. That way, when the base code changes, your extension functionality will be retaianed and extra table(s) fields will not get erased.
Submitting the changes back to the code base is advisable to avoid re-jig of functional code / table(s) at each upgrade.
You may want to post in the Wish List and submit changes / additions to be included in the FA code base or as an extension. That way you can be sure that it would be part of fututre releases and not have to re-jig your changed code each time. Maintaining several code bases for the same project and attempting to patch them at each change is time consuming effort that may not be desirable in the long run....
If there are many lines (yes the order of the lines would matter and a form field in each line would be needed which will take care of it), then we can apportion amounts in any way we choose like loading costs to larger value items or to rounded costs, etc., and possibly with some items not having any shipping costs at all (enter 0 value).
The "N-1" approach was to alleviate the need to manually compute the balance if the total was entered and only one line had the new field blank.
Thanks Andres for starting out on PUT....
It would be useful to put in the Wiki Page URL in the README file in the GitHub so that users can partake of the updated Wiki.
https://frontaccounting.com/fawiki/index.php?n=Devel.SimpleAPIModule
Thanks Joe for fixing it in Mercurial Changeset 3087.
Apportion costs to "N-1" items (till amount available) and let the "N"th item have the rest if still positive.
A 4th option to manually apportion the amount!
This might as well be put into the HG repo. It is the last appearance of Session_register( function that needs to be commented out. In fact all such lines (including needless preceding ifs) can be weeded out:
Line 65 in manufacturing/work_order_issue.php
Line 103 in includes/page/header.inc
Line 72 in inventory/adjustments.php
Line 68 in inventory/transfers.php
Line 40 in purchasing/allocations/supplier_allocate.php
Line 39 in sales/allocations/customer_allocate.php
Fixed in v2.3.12+ Mercurial Changeset 3066 on Sep 17th 2012.
Contact LC Chen of Sita - they undertake training in KL / Selangor area.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.