Search options (Page 92 of 246)

This must a a user preference and not a site-wide or company-wide setting.
This will entail a flag in the user table but settable by the sysadmin and not the user themselves as that could be leveraged for security violations like brute forcing.

@joe: Thanks for the Bloomberg commit.

The incremental patch file for the Google fix is attached herewith.

No need to bother with the number_format statement. The Bloomberg fix uses another part of the page which does not have any locale formatting. I have changed it a bit and re-uploaded it. If you were the first to download it then download it again.

PHP Simple XML Parsing

YAHOO has blocked all access to FA's means of exchange rate acquisition.
Checkout:
http://download.finance.yahoo.com/d/quotes.csv?s=USDIDR=X&f=sl1d1t1ba&e=.csv
The widget js that does the job is at:
https://widget-yahoo.ofx.com/resources/1500309750700/js/app.js
The new page to look at is:
https://widget-yahoo.ofx.com/
and this sports the separator with locale as well.

ECB is still available with no separators:
http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml

Google is also still available with no separators:
http://finance.google.com/finance/converter?a=1&from=OMR&to=IDR

Bloomberg is available for select currency sets with a separator:
https://www.bloomberg.com/quote/USDIDR:CUR

Also we need to check if locale specific separators will have their say as well.

From the wiki:

Hence we need a month value as well to get the period.

The function that can now be tried is:

function calculate_next($myrow)
{
    if ($myrow["last_sent"] == '0000-00-00')
        $next = sql2date($myrow["begin"]);
    else
        $next = sql2date($myrow["last_sent"]);
    if ($myrow['days'] == -1 && $myrow['monthly'] > 0) {
        // ignore months when days = -1
        $next = add_days(begin_month($next), -1); // last day of previous month
        $myrow['days']=0;
    }
    $next = add_months($next, $myrow['monthly']);
    $next = add_days($next, $myrow['days']);
    return add_days($next,-1);
}

For 30 days it appears okay so we do not need to change that portion.

For -1, the invoice needs to be raised on the last day of the month for the period from the last day of the previous month to the day before the last day of the current month.

The new function replacement should be:

function calculate_next($myrow)
{
    if ($myrow["last_sent"] == '0000-00-00')
        $next = sql2date($myrow["begin"]);
    else
        $next = sql2date($myrow["last_sent"]);
    if ($myrow['days'] == -1) {
        // ignore months when days = -1
            $next = add_days($next, 2); // <-- changed line
            $next = end_month($next);
            return $next;
    } else {
        $next = add_months($next, $myrow['monthly']);
        $next = add_days($next, $myrow['days']);
        return add_days($next,-1);
    }
}

@poncho1234: hope you are using the FA 2.4.3+ bleeding edge code and not just the release.

Month is a calendar month and not 30 days.

Months and days can be used together like 1 month and 7 days.

The functions "add_months" and "add_days" are defined in includes/date_functions.inc.
The functions "days_in_month" and "end_month" are also defined therein.

We can use the native PHP function cal_days_in_month(CAL_GREGORIAN,10,2005); to get the days in a month / end of month. This function has been available since PHP 4.1+. The "-1" can be implemented using these functions.

Lines 79-81 of the function calculate_next():

    $next = add_months($next, $myrow['monthly']);
    $next = add_days($next, $myrow['days']);
    return add_days($next,-1);

can be altered to make for the "-1" functionality of last day of the month as:

if ($myrow['days'] == -1) {
// ignore months when days = -1
    $next = add_days($next, 1);
    $next = end_month($next);
    return $next;
} else {
    $next = add_months($next, $myrow['monthly']);
    $next = add_days($next, $myrow['days']);
    return add_days($next,-1);
}

Please test and provide feedback for inclusion into the core.

Windows / DOS line endings are chr(13).chr(10) or "\r\n" whilst Unix line endings are just chr(10) or "\n". In frontaccounting, we can run the following on Unix to convert them wholesale (assuming the webroot to be /var/www/frontac):

cd /var/www/frontac
find ./ -type f \
        -name "*.php" \
     -o -name "*.css" \
     -o -name "*.js" \
     -o -name "*.txt" \
     -o -name "*.inc" \
     -o -name "*.sql" \
    | xargs dos2unix

The sql in the function getAverageCost() defined in the file reporting/rep301.php (Inventory Valuation Report) is like:

SELECT move.*, IF(ISNULL(supplier.supplier_id), debtor.debtor_no, supplier.supplier_id) person_id
FROM 1_stock_moves move
     LEFT JOIN 1_supp_trans credit ON credit.trans_no=move.trans_no AND credit.type=move.type
     LEFT JOIN 1_grn_batch grn ON grn.id=move.trans_no AND 25=move.type
     LEFT JOIN 1_suppliers supplier ON IFNULL(grn.supplier_id, credit.supplier_id)=supplier.supplier_id
     LEFT JOIN 1_debtor_trans cust_trans ON cust_trans.trans_no=move.trans_no AND cust_trans.type=move.type
     LEFT JOIN 1_debtors_master debtor ON cust_trans.debtor_no=debtor.debtor_no
WHERE stock_id=102
  AND move.tran_date < '2017-11-27' 
  AND standard_cost > 0.001 
  AND qty <> 0 
  AND move.type <> 16 -- ST_LOCTRANSFER
ORDER BY tran_date;

This means that when the purchase invoice is made on 2017-11-27, the sql above computes the average cost to just before the said date and not including it. If a subsequent date is used for the query, then all is well (save for the irrational value at times not obeying the decimal limit).

@joe: must we correct line 65 in it:

            AND move.tran_date < '$to_date' AND standard_cost > 0.001 AND qty <> 0 AND move.type <> ".ST_LOCTRANSFER;

to be

            AND move.tran_date <= '$to_date' AND standard_cost > 0.001 AND qty <> 0 AND move.type <> ".ST_LOCTRANSFER;

so that it takes into consideration all transaction up until the end of the day and not to just before the date?

The decimals issue can be corrected by appropriately formatting the return value at the end of the said function or where it it used in line 211 in the report although line 229 uses it without assignment when $details is present. The culprit is line 357 in includes/current_user.inc for irrational numbers with large number of decimal places when the value of $dec becomes 14. It is best hard coded to 2.