Search options (Page 177 of 247)

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).

FA does not have PriceList history but sales price history can be culled out from the invoices. You will have to manually store the old price value in the long_description field of the item in stock_master table.

The code appears incomplete since the "incen_fine" form variable is not defined (did you mean to replace the 'mahamai' with a single +Incentive / -Fine variable).

Any reason why you would want to comment out the $taxes and $tax_total assignments and prevent it forming part of the $display_total?

I would expect the last part of the function display_po_items() to be:

    start_row();
    label_cell(_("Incentive / -Fine"), "colspan=$colspan align=right");
    small_amount_cells(null, 'incen_fine', price_format(get_post('incen_fine',0)));
    label_cell('', 'colspan=2');
    end_row();

//    $display_sub_total = price_format($total + input_num('incen_fine'));

//    label_row(_("Sub-total"), $display_sub_total, "colspan=$colspan align=right","align=right", 2);

    $taxes = $order->get_taxes(input_num('freight_cost'));
    
    $tax_total = display_edit_tax_items($taxes, $colspan, $order->tax_included, 2, $order->trans_type==ST_SUPPINVOICE);

    $display_total = price_format($total + input_num('freight_cost') + $tax_total + input_num('incen_fine'));

    start_row();
    label_cells(_("Amount Total"), $display_total, "colspan=$colspan align='right'","align='right'");
    $order->order_no ? submit_cells('update', _("Update"), "colspan=2 align='center'", _("Refresh"), true)
        : label_cell('', "colspan=2");
    end_row();

    end_table(1);
    div_end();
}

But where does the 'incen_fine' get stored and how?

When done, don't forget to submit it here and to the project to assist others.

Hope this suffices:

https://frontaccounting.com/fawiki/inde … nkAccounts

@ckrosco: In your first post here you stated

Does this mean that you entered the exchange rate manually or got it from the FA exchg rate provider by manually clicking the get rate button?

It would be nice if you provided the changed files (or actual workflow menu click sequence) so that it may be included in the next version natively.

Provide the changed code to test.

If the incentive is calculatable from the quantity, then a enable/disable flag (0/1) is sufficient for it and an amount variable for delays if it is variable with no dependancy will suffice. Better to have a quick entry for those transactions where these issues arise with no fields necessary in the tables. The fields can be avoided altogether if quick entries are used except that manual computation will be necessary.