For me following features are generic enough to be included in core FA:
elax wrote: - Sales order list :
* allow order to be sorted by customer (and other) in order list.
- Order Delivery
* add clear quantity button, so the default quantity to dispatch to 0. (usefull when you need to dispatch only a bit from a big order).
* set the initial quantity to dispatch to what is availabe. What is available depend on what other people have order (priority according to order date). I will extract this to a module to allow priority per item.
* Add 'ALL location' in stock movement to see all moves between location. (UI needs tidying up).
- Stock
* filter items in stock check sheet report using regexp or like expression. Needs SQL injection protection.
-* filter invoice report per customer (usefull when a customer want you to send all the invoice). However, the UI is at the moment a bit clamby (because I can't filter the 'from' and 'to' invoice by customer).
Other things:
* sort item by stock_id when displaying cart
This cannot be done in transaction viewers (the view should display cart 'as is'), and probably would be rarely used during cart ediiton. But if implemented carefully (some small icon ui control with tabindex=-1 to not encumber keyboard entry) it could be accepted.
* Add "weights" to locations. Those weights are used to weigh quantity on hand and on demand. This allow for example to have a lost location (item 'lost' won't count as in stock) or order in 'to cancel' location, doesn't count as on demand.
This used mainly by the 'available' feature on order delivery, but could be extended to FA report.
I'm not sure I understand the idea right, but if you mean some flag (checkbox) in location catalogue, which would exclude this location as available for sales, this is good idea.
- Trial Balance
"Clear" the initial balance difference due previous year.
For example if initial balance (of the year) for the stock is 120000 | 100000
display 20000 | 0 instead.
Not acceptable I think. For some types of accounts this is important whether the balance is one or two sided.
Report
* Use readable name for some reports. This is need when you need to send an order, a statement or invoice to a customer.
The normal workflow is export the report (save it) , and attach it in the email. However, whith mangled name, it's easy to send the wrong invoice to the wrong customer.
This should be rather solved by better support for sending invoices by email to customer (when you use direct invoice mailing you have no need to save the report file on the server). We should have at least email templates implemented, as currently hardcoded template is not reday for serious usage.
Janusz