Search options (Page 228 of 247)

You can create the modules/_cache/extn-extver-extbuild/_init/config file along with a list of files in the extension and their sha1sums in modules/_cache/extn-extver-extbuild/_init/files and see if it shows up.

Alternatively create your own repo and place your packages in it and change the repo access details in version.php. It hasn't been made easy to get all the files from the repo as the scripts were not deemed ready for distribution yet.

Contact me offline if you want it.

Possibly a GitHub repo may be the answer for manual extension installs. The Linux ar command is used to create the pkg and possibly sign them and hence the ~data file is not extractable in Windows using 7-Zip.

Updated the Wiki with a HOWTO for manual install and language extension creation. An offline PDF version is also available.

Attached the en_IN package for inclusion in the FA Repo.

Edit the lang/installed_languages.inc file and include the following array element into the $installed_languages array (take care of the array index assumed 1 here):

  1 => 
  array (
    'code' => 'en_IN',
    'name' => 'English (IN)',
    'package' => 'en_IN',
    'encoding' => 'iso-8859-1',
    'version' => '2.3.15-1',
    'path' => 'lang/en_IN',
  ),

Hi Joe,

Encapsulate the attached en_IN file for use with FA as a pkg.

It would be nicer to view all prices in same units of qty and currency for comparison and listed sorted in ascending prices!

Try it in a different browser - Firefox?
Also see that you have Java scripting enabled.
Java runtimes would also be nice.

@pierre whilst your change works, it is the non standard way and will get overwritten on updates. The preferred way is to make a copy of the lang/new_language_template/LC_MESSAGES/empty.po file and edit lines 10438-10439 to be:

msgid "INVOICE"
msgstr "TAX INVOICE"

and compile it with gettext as lang/en_SA/LC_MESSAGES/en_SA.mo and make an entry in the list of available languages and see that the locale is properly implemented. Refer Wiki.

GL Account Groups have a parent child relationship that can be used optionally.
Read the Wiki on Account Classes and Groups and Parent Ledgers.

The file purchasing/includes/po_class.inc has the class definition for the class po_line_details which refers to the default Quantity / Price - check the defaults in the table schema as well.

FA core is okay as it is. Make extensions for peculiar (country specific / rare legal) needs. The programming paradigm - KISS - is well protected here and that is why most non-programmers have found it easy to fathom the code. Extending the COA is inadvisable - porting from other accounting systems / fa versions, inadvertant switch flag type fields, backward compatibility issues pervade.

[RANT]:
Non Accountants and Non Programmers must be able manage FA without having to bother with Government - businesses need simple acounting info / capability for day to day operations. Most countries have begun to question the need for Statutory Audit - Self Audit is being encouraged. In the aftermath of Enron / Arthur Anderson / and other major corporations / audit firms / banks fudging accounts, Governments too will soon have automatic billing systems in their countries from which their VATs will be auto-calculated instead of summary submissions each month/quarter/year! There seems to be little trusted data on countries printing / creating money and providing huge windfalls to select individuals of choice - insurance, subsidies, rights.

{NICE]
If you do not sell in currencies (debt denominator) issued by governments - you do not need to pay tax! Corollary - no one pays any taxes for using FA! No one's paying Joe/Janusz any monies for coding and preserving the FA source! Yet FA users will look after you (tax free) when you visit their countries.....People like them are the real assets worth preserving.

Make one like Shipping at the bottom of the invoice or make a service item called, say, VAT Ajustments, with no tax and use it as a free form value.

Caveat: Must remember to do it each time one is needed.

Wow! That's a nice way of managing translation of labels and moving into form fields at the same time! For this to work, we need to have an "id" for each label and it's correspondig form field to be suffixed with a common number something like:

<p>
  <span id="formfieldlabel_001"><?php echo _"(&Name"); ?> :</span>
  <input type="text" size="40" id="forminputfield_001" name="name_field">
</p>

Only then can a generic js included in each form be able to generically do the trick.