First things first - after nearly four years, hundreds of hours and many thousands of dollars, we are very strongly considering dumping the new ERP system we've been working on and staying with DBA.  
 
Among other things we'll need to address, in the interim we've decided we would like to get away from recording (and entering) labor on WOs while still issuing actual material since that can vary wildly from a standard or average. Essentially, we'd like to backflush labor and issue materials. Is there any way to do that in standard DBA?  
 
Thanks,

This is how we are currently set up:
Labor (setup and run time) is entered on Routings. This allows us to do Estimates.
Actual labor is captured on time sheets and entered as a type L "Material" (the labor part has a BOM quantity of 0, we just have it there so we don't get the "part is not on BOM do you want to add it" warning).
Materials are on BOM as well, with expected/average quantity so we can do estimates as well as to ensure adequate inventory once a WO is created.
 
Putting the labor on the BOM is problematic because setup time cannot be properly accounted for unless you calculate it for the WOBOM every time. If we were to calculate the BOM labor from the Routing, unless the labor was then removed from the Routing, any Estimate made for the part would have twice the labor cost on it.
 
We would still prefer to do Estimates within DBA, as it makes sense - all the info is already there. We do have a system for estimates in Excel, for new items we've never made and are quoting, so we don't have to create items that we may never build. If/when we get the job we use that to build the Routing and BOM in DBA.
 
Keep the ideas coming
 

One of the challenges we would have is setup time. Since setup time is not insignificant and we run a very wide variety of quantities (between 20 and 2000 would be very common), the amount of setup time per part could have a fairly large effect on the total cost per part.
 
To further complicate things, we often batch various species of wood together, so the setup time should be spread across the parts in all species of the same run. For instance, we may run 20 LF of Walnut but 1000 LF in Maple so the setup time for the Walnut would be significantly different if we looked just at that one WO as opposed to the total run of 1020 LF. With 40 minutes of setup time it should be .04 minutes per LF as opposed to 2 minutes which could easily be a cost difference of more than 50% of the actual total cost of the finished product.
 
Complete automation of the process may be too much to expect. I'm thinking now that maybe a Crystal Report where a WO* can be selected and the completed quantities are entered and then it would use the Routings to calculate the total standard cost/time that could then be manually entered as a single Material Issue.
 
Any further thoughts on this issue?
 
 
*we use a single WO prefix per batch type with incremental suffixes for the individual species.

We are trying to get away from recording actual time, because it is too complicated in our situation. Since we batch multiple items together, even if you had a time clock at every workstation it would be a real pain to clock in and out at the beginning and end of every item type within the batch. True, sometimes we will work on one item for a couple hours, but at others two people will work together on 8 for a total of 10 or 15 minutes and would literally spend as much time at the clock (16 punch in/outs) as working. What we currently do is have one WO Traveler for each group of items and clock in and out on the paper with a standard mechanical time clock, and when it is all done we manually total up all the time and split it up based on the run sizes.
 
We actually had a customization done for the ERP we were going to switch to, whereby WOs could be grouped together and you could clock into a group routing and the system would split up the time based on the total amounts worked on. However, that introduced other problems, for instance some of the items have almost identical routings, but have an extra step. Also, we couldn't come up with an uncomplicated way to account for rejects that can be re-manufactured or sold as "seconds". This is the reason we decided that we wanted to go with standard costs. We've done quite a bit of time study and feel we have pretty good numbers as far as the labor component goes.