Search options (Page 80 of 247)

@joe/@itronics: Yes, this needs to be corrected and the empty.po updated.

You will need to pull in the data from FA into your application from within your application or program a trigger in the FA DB to populate your application DB.

To pull in FA data from within your application, use the FA SlimAPI to create a script that can be run on demand or in a cron job.

Connecting to other applications is best done using the REST API (See SlimAPI in the wiki).

@joe: Which setting closes a date (not fiscal year) for further transactions / edits?

@joe / @itronics: any progress on @braathwaate's commit and way forward here?

Short of creating your own custom module / hard code changes, you can prefix all items in each location with the appropriate Loc ID prefix. Also to produce Item A from each location prefix it with the appropriate Loc ID. Now the BoM for ItemA_Loc1 will be present n Loc1 only and hence can be used for manufacturing in Work Centre 1.

Native FA allows any location to supply any item to any work centre.

For now, focus on the field order in the tables where memo_ is present in your output above, especially in the first one below:

ALTER TABLE `0_budget_trans` MODIFY `memo_` tinytext NOT NULL;
ALTER TABLE `0_comments` MODIFY `memo_` tinytext;
ALTER TABLE `0_gl_trans` MODIFY `memo_` tinytext NOT NULL;
ALTER TABLE `0_supp_invoice_items` MODIFY `memo_` tinytext;
ALTER TABLE `0_voided` MODIFY `memo_` tinytext NOT NULL;

Do not make any change to your current schema unless you are sure of the direction of change (from which schema to which) for now.

FA now natively supports upto PHP 7.1.x only. PHP 7.2.x is not yet supported.

PHP 5.3.x is still the most widely used and texted version for FA so far for long time users though later versions happen to be discussed in the forum as newbies try to grapple with their maiden installs.

Most script based installs (Scriptaculous, cPanel, SimpleScripts, Fantastico, public OpenVZ templates, etc) rely on outdated versions of FA where the hosting providers make several versions of PHP available on a per application basis possibly in CGI mode.

PHP 7.2 Incompatibilities.

PHP 7.1 to 7.2 Migration Notes.

What's New in PHP 7.2.

The show_codes checkbox "name" is available in the preferences menu and gets stored in the users table.

The show_po_item_codes is present as an entry in the sys_prefs table. Under Setup => Banking and GL Setup => Show PO item codes can be checked, and we can then see the item_code printed out in the PO report (rep209.php).

In fixing this, we need to suppress the display of the Item Code heading if not chosen.

The class sys_prefs contains the method show_po_item_codes() which promptly returns the value from the sys_prefs table.

Hence, for now, change line 142 of reporting/rep209.php:

            if ($SysPrefs->show_po_item_codes()) {

to be:

            if ($SysPrefs->show_po_item_codes() || user_show_codes()) {

What is the logic behind this redundancy.....

Which version of FA are you using?
Did you modify the PO report file - rep209.php?
Did you recently change your PHP / MySQL versions?

https://frontaccounting.com/fawiki/uploads/Help/Rep209_PurchaseOrders.png

Then when the manufacturing charges invoice is raised, put in the cost of goods sold and price of goods received instead so that the net result is what you need to book as manufacturing charges after allowing for tax credits.

Alternatively:
Treat the Company B as a regular Customer and another account for Company B as a Supplier. Keep the Sales and Purchases separate and provide for tax credits on purchase back of manufactured items.

If your tax accountant agrees, make a delivery on consignment for manufacture to Company B so that no billing needs to be done except in escrow and contra-ed when the purchase is made.

When we create a new company (non-default) and choose the en_US-demo.sql company, we get the extra permissions by default - 256;257;258;259;260 but the code possibly handles this anomaly by restricting such permissions for the non-default company. When we edit the System Administrator Role in the new non-default company without making any changes (dummy save), the said permissions vanish in the backup. There is no restoration of any backups involved here.