Search options (Page 39 of 246)

Search for "count(" in the reporting/includes/pdf_report.inc and we find 15 occurrences that need to be replaced with "count_array("

@joe: can commit this along with the inclusion of includes/ui/ui_globals.inc in it.

Which chart of accounts did you start from that failed to have the auto_increment flag on to begin with?

There is no Field id in the above statement. Only the Field tax_type_id is there.

The said error occurs in the function add_trans_tax_details() defined in gl/includes/db/gl_db_trans.inc. Hence check the whole of the Sales Order cart for any missing / improper data. Also check the value of $tax_id and see if it is properly related record with some valid value for the field tax_type_id in the Tax Setup.

Lines 323 to 330 in reporting/rep303.php:

            if ($barcodes && barcode_check($trans['stock_id']))
            {
                $adjust = true;
                $bar_y = $rep->GetY();
                $barcode = str_pad($trans['stock_id'], 7, '0', STR_PAD_LEFT);
                $barcode = substr($barcode, 0, 8); // EAN 8 Check digit is auto computed and barcode printed
                $rep->write1DBarcode($barcode, 'EAN8', $rep->cols[$firstcol++], $bar_y + 22, 22, $SysPrefs->pic_height, 1.2, $style, 'N');
            }    

@joe: We need to put in BarCode type as a per company variable in the sysprefs table and have a table that looks up the size and checkdigit details preferably from the tcpdf file. Also, the stock_id field can be increased to be greater than the size of all known barcode types.

FA does not have a separate field for Cheque Number in the core - you will need an extension for it - besides it does not qualify as to which bank it pertains to even here. However, it can be part of the memo / detail field in FA.

Banking and General Ledger (tab) => Reports => GL Account Transactions => Choose Accounts Receivables in From and To Accounts - this will yield a report with all customers in it. If sub-ledgers for each trackable customer is created for the AR main head, then it can be filtered on a per customer basis.

@joe: The report attached in the previous post can be made atleast in FA 2.5.

Void the entry in Setup => Void a Transaction.

The said error occurs in the function add_journal() defined and called in write_journal_entries() in gl/includes/db/gl_journal.inc where the full complement of 10 arguments are used. Other functions too call it through:

add_supp_invoice() <= purchasing/includes/db/invoice_db.inc
void_supp_invoice() <= purchasing/includes/db/invoice_db.inc
add_wo_costs_journal() <= manufacturing/includes/db/work_order_costing_db.inc
handle_negative_inventory() <= includes/db/inventory_db.inc
add_exchange_variation() <= gl/includes/db/gl_db_banking.inc
add_cust_supp_revaluation <= gl/includes/db/gl_db_banking.inc
delete_this_fiscalyear() <= admin/db/fiscalyears_db.inc

None of the above functions are directly called in the extension file modules/import_multijournalentries/import_multijournalentries.php.

The file /gl/includes/db/gl_db_trans.inc is included in the above extension file which defines the function add_gl_trans() which has many more arguments but does not use the event_date parameter.

The functions called by the said extension file of importance are:

write_journal_entries() <= gl/includes/db/gl_journal.inc
add_bank_transaction() <= ** (Cannot find it defined anywhere - not even in FA 2.3.x) **

However, these functions are defined:

add_bank_transfer() <=gl/includes/db/gl_db_banking.inc
add_bank_trans() <= gl/includes/db/gl_db_bank_trans.inc

and both do not match the number and type of arguments used in the call.

The missing function add_bank_transaction() can be compared to the function write_bank_transaction() defined in gl/includes/db/gl_db_banking.inc but even this does not match the arguments used in the call.

@joe: where and how do we define the function add_bank_transaction() now?

Lines 25-26 in config.php:

    if (!ini_get('date.timezone'))
        ini_set('date.timezone', 'Asia/Kolkata');

Comment out the first line above and edit the second as needed.

https://gist.github.com/Dreyer/2958946
https://conetix.com.au/support/simple-php-mail-test/

We need to pinpoint the version / build date when it last worked as desired and not as in the policy stated now. Only then can a diff show what needs to be reverted if desired even if it violates espoused design policy.