Finding my way around the guts of FA takes a little time.

Onward and upward!

Would it be better if this subject was moved to Modifications or Development?

Not getting much response under Setup.  Probably should have been submitted under Mods or Dev in the first case.

Just asking if anyone is interested in this or willing to share some insight about getting it done.

Appreciate any suggestions / comments.

Thanks,

bholtz / neholtz

$this->add_lapp_function(0, _("&Batch Control"),
    "batches/batch_control.php?", 'SA_BATCHCONTROL', MENU_SETTINGS);

Displaying below Transaction References OK, but with errors:

Undefined index: SA_BATCHCONTROL in file: /home2/finishl4/public_html/erp/includes/current_user.inc at line 192
/home2/finishl4/public_html/erp/includes/current_user.inc:201:     (current_user Object)->can_access('SA_BATCHCONTROL')
/home2/finishl4/public_html/erp/themes/canvas/renderer.php:224:     (current_user Object)->can_access_page('SA_BATCHCONTROL')
/home2/finishl4/public_html/erp/frontaccounting.php:63:     (renderer Object)->display_applications((front_accounting Object))
/home2/finishl4/public_html/erp/index.php:25:     (front_accounting Object)->display()

A little help as to where to find the SA_ definitions would be appreciated.

Thank you, for your suggestions and insights ... very useful stuff.

If you need to know which customer is in which sales group this post may help

You would then have to do this everyweek, a little bit involved, but a lot easier than writing hundreds of invoices

Also although I've not tested myself but I've seen a topic on here showing how sales prices will affect the sales items prices, when used with recurrent invoices, but cannot find it at this moment - depending on your desired result it maybe worth investigating?

I looked at this myself, but the paradox is automation = non-flexibility, so the more automated the system becomes the less flexible it is, so recurrent invoices = same sale items AND same customers AND same timeframe AND same sales terms AND etc.

For an easier user solution I can only suggest you use the select multiple customers code as in recurrent invoices merged into the existing create sales order code

To be very specific, we are invoicing the membership of a fund  that charges all of it's members a small fee every time a member dies, and pays out the sum of those fees to the beneficiary of the deceased. Therefore, once a week, we check to see if there have been any deaths and we list them on an invoice; the fee and the name of the member who died, then invoice all current members according to the # of deaths we've covered.

So, it would be ideal if we could just open a "direct invoice" like interface, enter the appropriate items, select a group of customers, and send out a bulk invoice. I plan to write such a feature, as soon as I figure out the best and most supportable/sustainable way to incorporate it into FA.

If there was an easy way to modify a template and send it to an entire group, that would be great, although it's an additional step, I'd rather use an existing feature so it is easier to install updates to FA as they become available.

I've been studying the direct invoice process when I have time and trying to decide on the best approach.

Looking at it I see the following requirements:

1. A "Batch" tab on the main navigation with options below to:
   (a) Create a New Batch
   (b) Select an Existing Batch
   (c) Post a Batch
   (d) Delete a Batch

An auto-generated batch_id could be retrieved from Transaction References.
While a second user supplied description field would make the batch unique.
Date & Time data could be automatic or user entered.

2. These batch_ids would need to be selected when entering Sales or other types of transactions.
    This would require the addition of a drop-down selection for choosing the appropriate batch.

3. In Sales-> Order Entry e.g. there could be a number of batches depending upon purpose.
    Inventory would need to be committed upon Order creation and removed once the batch is posted.
    Similarly released if the batch is deleted.

4. POS would have unique batch_ids based upon register location/id.

5. Batch Listings would need to be run and corrected before any batch could be posted to the G/L.

6. Other considerations such as reporting, etc need to be determined.

I would appreciate comments from the Gurus concerning their thoughts on such an undertaking.

Thanks for your consideration.

bholtz / neholtz