Unless you edit /delete any transaction, an audit trail will generally not occur.

For a brand new sql/en_US-new.sql based company, on entering 1 customer, 1 supplier and 1 item, there are no audit_trail entries at all. GL Transactions will certainly have records generated in the audit_trail table.

All audit_trail records except latest one should have the field gl_seq set to NULL to avoid need for subqueries (absent in MySQL 3) all over the code - see code and comments in function add_audit_trail() in includes/db/audit_trail_db.inc file.

Read the Wiki.

1,827

(9 replies, posted in Setup)

@poncho1234: It is not everyday we have the tax rates being changed. Hence your experience is valuable. Thanks for the feedback.

1,828

(9 replies, posted in Setup)

@poncho1234: Must we then create all new items for the new tax rate so as to preserve the old items with the old tax rate?

1,829

(9 replies, posted in Setup)

Make a credit note in the new fiscal with the new 15%. Pass an adjustment Journal Entry for the difference.

@Joe: What is the best practice here - an editable Tax Rate?

1,830

(9 replies, posted in Installation)

@oakstreet1: Thanks for the feedback as it will avoid sidetracking users especially newbies.

1,831

(4 replies, posted in Announcements)

Attached is the changed files list that can be used to upgrade FA from FA v2.4.3 to FA 2.4.4.

Take care to compare the config.default.php with your existing config.php file and make changes in the latter as needed for the new VARLOG/VARLIB constants introduced in this version.

Also verify that the data in the sys_prefs table in all your company's databases have the necessary records to match those in the new sql/en_US-new.sql file now. Refer this commit for an example.

1,832

(9 replies, posted in Installation)

Keeping your MySQL version to be <= 5.5 will avoid needing to enable date strict mode to allow for zero dates and times to be acceptable.

zLib compression - HowTo.

1,833

(9 replies, posted in Installation)

Are you working a Windows platform? If so, you may have to disable gettext in your php.ini and you will then get array based translation.

Use Manufacturing in FA.

I am yet to get a satisfactory answer from @itronics on the need for the number change on edition of a Journal Entry and as to how and where the code changed from FA 2.3.x to 2.4.x.

In one way, such editions will now clearly standout of sequence of other entries to indicate that some change has occurred - a sort of answerable audit trail exposure.

Taking the sql backup diffs between before and after adding a single Inventory Item, the following sequence of SQL statements are observed (Assumed TB_PREF=3_):

SET @StockID      := 'MT501';
SET @ItemDesc     := 'Camera 5 MP';
SET @ItemLongDesc := 'Digital Camera of 5 MP resolution';
SET @ReOrderLevel := '0';
SET @MBFlag       := 'B';    -- BoughtOut, Manufactured, D: Charges/Services
SET @CatID        := '1';    -- stock_category.component_id -- Components
SET @LocationCode := 'DEF';  -- locations.loc_code
SET @Units        := 'each'; -- item_units.abbr 
SET @TaxTypeID    := '2';    -- item_tax_types.id
SET @SalesAc      := (SELECT `value` FROM 3_sys_prefs WHERE `category` = "glsetup.items" AND `name` = "default_inv_sales_act");
SET @COGSAc       := (SELECT `value` FROM 3_sys_prefs WHERE `category` = "glsetup.items" AND `name` = "default_cogs_act");
SET @InventoryAc  := (SELECT `value` FROM 3_sys_prefs WHERE `category` = "glsetup.items" AND `name` = "default_inventory_act");
SET @AdjAc        := (SELECT `value` FROM 3_sys_prefs WHERE `category` = "glsetup.items" AND `name` = "default_adj_act");
SET @WIPAc        := (SELECT `value` FROM 3_sys_prefs WHERE `category` = "glsetup.items" AND `name` = "default_wip_act");

INSERT INTO `3_stock_master` VALUES
(@StockID, @CatID, @TaxTypeID, @ItemDesc, @ItemLongDesc, @Units, @MBFlag, @SalesAc, @COGSAc, @InventoryAc, @AdjAc, @WIPAc, '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '', '0', '0', '0000-00-00', '0000-00-00', '');

INSERT INTO `3_item_codes` VALUES
(NULL, @StockID, @StockID, @ItemDesc, @CatID, '1', '0', '0');

INSERT INTO `3_loc_stock` VALUES
(@LocationCode, @StockID, @ReOrderLevel);

-- If a jpg image of the item was added to company #, then it would be named company/#/images/<StockID>.jpg
-- Here it would be: company/3/images/MT501.jpg
-- item_codes.id has no relevance in FA except for uniquely choosing the item and not even for sorting
-- Foreign Items can have different item_code and stock_id for the same item

Here, first a stock item is added to the stock_master..
Then one item_code is allotted for it which may be different from the stock_id if the item is a foreign one.
The stock_id is assigned to a location and a Re-Order level fixed for it.

The above can be useful for bulk importing of inventory items from disparate systems.

1,837

(13 replies, posted in Reporting)

@joe: What are the consequences of this pull request. @rafat seems satisfied.

1,838

(0 replies, posted in Accounts Payable)

Taking the sql backup diffs between before and after adding a single Supplier, the following sequence of SQL statements are observed (Assumed TB_PREF=3_):

SET @Supplier  := "Finger Chips Intl.";
SET @SuppShort := "FCI";
SET @Contact   := "Jackson";
SET @Phone     := "568974521";
SET @EMail     := "supplier1@example.com";
SET @Website   := "http://www.fci.com";
SET @Address   := "Alpha Street,\nGladystown - 654543";
SET @GST       := "8954587411";
SET @DefCurr   := (SELECT `value` FROM `3_sys_prefs` WHERE `name`="curr_default" AND `category`="setup.company");
SET @CredAc    := (SELECT `value` FROM `3_sys_prefs` WHERE `name`="creditors_act" AND `category`="glsetup.purchase");
SET @PayDsctAc := (SELECT `value` FROM `3_sys_prefs` WHERE `name`="pyt_discount_act" AND `category`="glsetup.purchase");

INSERT INTO `3_suppliers` VALUES
(NULL, @Supplier, @SuppShort, @Address, '', @Phone, '', '', @Website, '', @DefCurr, '4', '0', '0', '0', '1', '0', '', @CredAc, @PayDsctAc, '', '0');
SET @SupplierID := (SELECT LAST_INSERT_ID());

INSERT INTO `3_crm_persons` VALUES
(NULL, @SuppShort, @Contact, NULL, @Address, @GST, NULL, NULL, @EMail, NULL, '', '0');
SET @PersonID := (SELECT LAST_INSERT_ID());

INSERT INTO `3_crm_contacts` VALUES
(NULL, @PersonID, 'supplier', 'general', @SupplierID);

Here, first a Supplier is created.
Then a Person is created.
Finally, this new  Person is assigned to the new Supplier as a Contact.

The above can be useful for bulk importing of suppliers from disparate systems.

1,839

(9 replies, posted in Installation)

The file en_US.mo should not be renamed to .po. Instead remove the entire en_US folder if you want or just add in the en_US.po file for your records by either generating it from the .mo file or copying it over from here (ISO-8859-1) or from here here (UTF-8).

I think it is for puritanism only. The reset should be sufficient for now. If any third-party careless code called it, possibly it might go into negative.

The cancel_transaction() resets the value of the $transaction_level to 0 whenever a script is called in FA, and it happens when the DB connection is setup each time in includes/db/connect_db_mysqli.inc.

@joe: any fixes here?

1,842

(13 replies, posted in Reporting)

The function get_counterparty_name() defined in admin/db/transactions_db.inc is a quite extensive one whereas the alternative used in @BraathWaate's pull request, function payment_person_name() defined in includes/types.inc may not cover all types of transactions.

@joe: will this pull request make for covering all types of transactions required here?
@rafat: can you extensively test @BraathWaate's pull request with your data?

Analysing the diffs of backups before and after adding 1 Customer resulted in a set of INSERT statements when parsed out and sequences with variable extractions done resulted in the following (Assumed TB_PREF=3_):

SET @Customer  := "PKA Enterprises";
SET @CustShort := "PKA";
SET @Phone     := "28557841";
SET @EMail     := "pka@example.com";
SET @Address   := "Joe Smith Road\nTimbuktoo - Z9HG34";
SET @GST       := "1234578";
SET @Location  := 'DEF';
SET @DefCurr   := (SELECT `value` FROM `3_sys_prefs` WHERE `name`="curr_default" AND `category`="setup.company");
SET @Credit    := (SELECT `value` FROM `3_sys_prefs` WHERE `name`="default_credit_limit" AND `category`="glsetup.customer");
SET @DfPayAc   := (SELECT `value` FROM `3_sys_prefs` WHERE `name`="default_prompt_payment_act" AND `category`="glsetup.sales");
SET @PrPayAc   := (SELECT `value` FROM `3_sys_prefs` WHERE `name`="default_sales_discount_act" AND `category`="glsetup.sales");
SET @DrsAc     := (SELECT `value` FROM `3_sys_prefs` WHERE `name`="debtors_act" AND `category`="glsetup.sales");

INSERT INTO `3_debtors_master` VALUES
(NULL, @Customer, @CustShort, @Address, @GST, @DefCurr, '1', '0', '0', '1', '4', '0', '0', @Credit, '', '0');
SET @DrNum := (SELECT LAST_INSERT_ID());

INSERT INTO `3_cust_branch` VALUES
(NULL, @DrNum, @Customer, @CustShort, @Address, '1', '1', @Location, '1', '', @PrPayAc, @DrsAc, @DfPayAc, '1', @Address, '0', '', NULL, '0');
SET @BranchID := (SELECT LAST_INSERT_ID());

INSERT INTO `3_crm_persons` VALUES
(NULL, @CustShort, @Customer, NULL, @Address, @Phone, NULL, NULL, @EMail, NULL, '', '0');
SET @PersonID := (SELECT LAST_INSERT_ID());

INSERT INTO `3_crm_contacts` VALUES
(NULL, @PersonID, 'cust_branch', 'general', @BranchID),
(NULL, @PersonID, 'customer', 'general', @DrNum);

Here, first a customer is created and then a branch for the said customer.
Then one Person is created.
This Person is then allotted to both -  customer and cust_branch.

The above can be useful for bulk importing of customers from disparate systems.

1,844

(13 replies, posted in Reporting)

The Bank Statement only knows Customer and Suppliers as that is where the AR/AP allocations take place. Everything else is a mere Journal kind of Transaction without tracking allocations that can be seen in the GL Account Transactions.

@joe: is this right?

1,845

(4 replies, posted in Accounts Receivable)

The commit has not appeared as yet in the GitHub repo.

@Rmendez confirms that this commit solves his issue.

Committed the Auto Chart of Accounts Generator in my FA24Mods repo.

This generates the standard 4 digit CoA based on the en_US-new.sql file.

Upload the generated Chart to the sql folder and use it to create companies based on it.

Can also access it online.

This method can also be used to generate a skeleton for any new extension as well.

1,847

(4 replies, posted in Accounts Receivable)

The screenshot is self-explanatory. The concerned file is sales/sales_order_entry.php. Whilst the max length of the form field allows 35 characters, the displayed form field is restricted to 10 characters.

In the DB tables, the field sizes are all normally VARCHAR:

reflines.pattern - 35
refs.reference - 100
sales_orders.reference - 100
debtor_trans.reference - 60
purch_orders.reference - TINYTEXT
supp_trans.reference - TINYTEXT
supp_trans.supp_reference - 60
stock_moves.reference - CHAR 40
workorders.wo_ref - 60
wo_manufacture.reference - 100
wo_issues.reference - 100
suppliers_supp_ref - 30 (***less than general form field max of 35***)
cust_branch.branch_ref - 30 (***less than general form field max of 35***)
journal.reference - 60
grn_batch.reference - 60
dimensions.reference - 60
bank_trans.ref - 40

@joe: are there an rationalisations needed amongst these fields and field types.

1,848

(4 replies, posted in Accounts Receivable)

@Rmendez asked:

I am using FA version 2.4.3...............
Can you help me with this??............Please................
"Increase size of Reference field in Direct Invoice"

There are no BEGIN ... COMMIT raw blocks in FA core codebase and possibly not even in any official Extension.

However, local SQL wrapper functions begin_transaction() and commit_transaction() exist and have such a check for non negative values as defined in includes/db/sql_functions.inc.

Create an account for you bank in the chart_master - Banking & GL => GL Accounts
Then assign / link that account as a Bank Account - Banking & GL => Bank Accounts
Thereafter, you can use it in Quick Entries like normally.