Search options (Page 176 of 247)

Then let it be like that except that a constant string can be defined for now as '999' and used in the function Achieve();
Lines 137 to 147 in reporting/rep707.php:

function Achieve($d1, $d2)
{
    if ($d1 == 0 && $d2 == 0)
        return 0;
    elseif ($d2 == 0)
        return 999;
    $ret = ($d1 / $d2 * 100.0);
    if ($ret > 999)
        $ret = 999;
    return $ret;
}

can be

define('OUT_OF_RANGE', 999);

function Achieve($d1, $d2)
{
    if ($d1 == 0 && $d2 == 0)
        return 0;
    elseif ($d2 == 0)
        return OUT_OF_RANGE;
    $ret = ($d1 / $d2 * 100.0);
    if ($ret > OUT_OF_RANGE)
        $ret = OUT_OF_RANGE;
    return $ret;
}

The define can be placed into the file that contains the other constants.

The said function Achieve() is duplicated in gl/inquiry/profit_loss.php.

In reporting/includes/excel_report.inc we find that 9999999 is used to represent "infinity".

In includes/ui/ui_view.inc, the value 999999999999 is used to represent "infinity".

In includes/date_functions.inc, the value 9999 is used to represent the max year.

In admin/view_print_transaction.php and admin/void_transaction.php, the value 999999 is used to represent the max ToTransNo.

Lines 44 to 47 of reporting/includes/header2.inc:

        $this->SetDrawColor(205, 205, 205);
        $this->Line($iline1, 3);
        $this->SetDrawColor(128, 128, 128);
        $this->Line($iline1);

control that line color and thickness (height).

You might want to refer this link:

function hex2rgb($hex) {
   $hex = str_replace("#", "", $hex);

   if(strlen($hex) == 3) {
      $r = hexdec(substr($hex,0,1).substr($hex,0,1));
      $g = hexdec(substr($hex,1,1).substr($hex,1,1));
      $b = hexdec(substr($hex,2,1).substr($hex,2,1));
   } else {
      $r = hexdec(substr($hex,0,2));
      $g = hexdec(substr($hex,2,2));
      $b = hexdec(substr($hex,4,2));
   }
   $rgb = array($r, $g, $b);
   //return implode(",", $rgb); // returns the rgb values separated by commas
   return $rgb; // returns an array with the rgb values
}

Actually quite a few POS / Billing systems exist as FOSS: phpPointOfSale (now OpenSourcePOS) at SourceForge and SimpleInvoices at GitHub should be nice replacements using PHP/MySQL.

@ahrtgnbn: nice decision

@instance: Your existing system is more a Point of Sale than an Accounting System and their developers have simplified operations by restricting it to Direct Sales and Purchase Invoices. Since it has hooks, you may want to make use of it to classify customers for appropriate decisions / reporting leveraging external tables. Not tying up the db directly between the two may alleviate non-high availability issues.

Fixes of a non critical nature will only go into FA v2.4 (dev policy) and they will need to be backported manually - my FAMods is a small step in that direction. Each developer will have their own private repository with their real fixes and only some would sync it to the public one. I cannot have multiple repos as maintaining them is a nightmare and would not benefit from peer review and hence GitHub and the FA Wiki (need to make one in MediaWiki when time permits). This decision may have ruffled a few feathers initially but now over 40 forks of it have  proved a tremendous vote of confidence.

So the missing 8th parameter (PARAM_7) will not throw errors. Hence, a backport will be "correct", but is not deemed to be necessary. Backporting will help minimize the differences between files in FA 2.4 and 2.3 to make for easier porting forward of fixes in FA 2.3 to 2.4.

1. FA 2.4 is still a work in progress with basic FA v2.3 functionality merged into it and some new features being implemented. The db schema is subject to change and quite a few unused fields in FA v2.3 will be removed and some new ones are now being introduced. For all but very basic small installs, FA 2.4 will be trouble at the moment. Progress on FA 2.4 has been slow (yes, years in the making...) and in bursts and spurts when the key dev @itronics gets the time. Meanwhile changes in FA 2.3 need to be incorporated in FA 2.4 from time to time as well. If you know what you are doing and can manage a separate fork of 2.4 for your trajectory, then it will be suitable. If only basic usage is envisaged and no upgrades are needed, FA 2.4 might just fit the bill.

2. You need items in inventory before they can be chosen to be ordered! If all items in your supplier invoices need not be tracked, then they can be listed as a Service Item with editable description. If you do not wish to track inventory at all (Service Item) and avoid purchase order generation itself, then just maintain journal vouchers - manually compute taxes if any....

@instance & @ahrtgnbn: Thankyou for your kind words. With 2 dedicated Canadians on the team, FA is now set to scale great heights!

OFX (Open Financial eXchange) can be used directly in FA as it is XML. An extension can be hammered out for data interchange between FA and OFX. That way there need be no CSV conversions / import / export rigmarole.

Where 1-way data transfer is envisaged, the target database can have the affected tables replaced as views of queries based on the source database tables. That way there will be no need for any data exchange at all.

When implementing Inventory, the foreign item codes may cause the item_code tables to have different item_codes for the same stock_id which is intentional to enable different vendors to map their same products onto common stock_id of FA and such item_codes will be used for ordering from the respective suppliers.

FA does not have history of item prices in it's price lists but all goods sold / purchased will have such history in their transaction records.

The wiki will need good cross referencing within it's pages and between the wiki and the forum threads besides summarizing the distilled info from the forums into properly linked wiki pages in context to enable easy and intuitive search / navigation.

When time permits, do test out the FA v2.4 as it is now undergoing some final testing before release. There is a separate thread on it's developmental progress.

Sales Groups were introduced (settable in the Customer branch only) for filtering Customers but is currently being used only for recurring invoice generation and will be available in reports in FA 2.4 (see another post on this).