Common Questions

The Yield Percentage field is simply a cosmetic field. There are two philosophies on the yield concept; one being to allow it to recalculate all of the quantitative fields below it and increase the raw materials requirements in production, similar to scrap, to accommodate yield loss. The other philosophy is to use it strictly as a benchmark against actual yield on a historical basis. Recalculating quantities can get very complex and doesn't allow for the built in restrictions in actual environments such as limited space capacity or other manufacturing restrictions that would prevent you from simply increasing the production plan.

For example: I need 50 liters of FG (Finished Good) XYZ, but I have a 50% yield so therefore to produce 50 liters I might need to bump up the raw materials by approximately 50%. However, the problem is that the vat only holds 50 liters. I can't put 100 liters in a 50 liter vat so increasing RM (raw materials) may not be feasible.

The Generate Orders from SO is based on customer, sales order, date range, and product. It no longer looks at PO number. It removes any production orders that meet the selected criteria that are of a 'Planned' or 'New' status. It then regenerates those.

The process selects sales orders (or sales order lines) to generate from based on the assembly or product ID range, date range, customer ID range, and whether the status is PICKED. It then removes any production orders that have a status of PLANNED that meet the same criteria. It then replaces those production orders with new PLANNED status orders. If a product is found more than once on a given sales order, it generates multiple releases on one production order for those lines. No reference is made to Customer Purchase Order. (Production, Production Orders, Generate Orders from Sales)

When recording time in Production, the quantity dictates the overhead per piece. Quantity is considered as Qty Produced PLUS Qty Scrapped. (Production, Production Orders, Record Production Activity)

Scrap does not affect inventory. It is part of the quantity pulled when working with components and it is considered to be in addition to qty produced when recording finished goods, although it does not get added to inventory. The scrap field is not part of the final costing calculation because it is technically, already included in the cost. (Production, Production Orders, Record Production Activity)

In the Resource Availability report, use Available Start Date if orders can start consecutively without regard for start date. Use Estimated Start Date to prevent orders from appearing before their start date. (Production, Reports and Worksheets, Resource Availability)

In the Release Orders you must click on the Apply button to view the available orders. Also note that production orders must have a status of 'Released' or 'Firm Planned'. The status of the production orders is set using the Production Orders function. (Production, Production Orders, Production Orders and Release Production Orders)

The Summarized Bill of Materials report prints the cost and detail of non-stocked subassemblies as part of the report. No subassembly items will appear on the report unless they are stocked subassemblies.

On the Costed Bill of Material report, subassemblies items are shown with their respective cost. Their detail is not shown. The reports should come up with the same overall assembly cost total. (Bills of Material, Reports, Costed Bills of Material and Summarized Bills of Material)

In version 10.5, Traverse could handle what we call “Per Unit” and “Subcontracted” processes. We have added two new types of processes. (Routing and Resources, Operations Setup)

The first is “Run Rate”. A “Run Rate” operation is like a “Per Unit” operation only “reversed” one might say. Instead of time per unit, the user sets up units per time. Per Unit says I can process a unit in 1.5 minutes, for example. Run Rate might state I can process 900 units in 1.5 minutes for example. Per the 900 units, I could have said I produce 1 unit in .1 seconds. It would be the exact same thing. However, let's say we can process 1400 units in 1.25 minutes. I don't have to state the Per Unit time as 1 unit per .0535714 seconds. We simply say 1400 units per 1.25 minutes. So the concept is somewhat just being practical and somewhat simpler way of thinking.

The other method is Batch processing. There are some subtle complications here, but more or less we are stating the time required to process a specific quantity. It involves at least two variables: the time and the quantity. Unlike Run Rate, you can't break it down for slightly smaller or larger quantities. It's like baking cookies; if the oven holds 50 cookies and they take 20 minutes to bake, it won't really matter if you are cooking 10 or 50, you are probably looking at about 20 minutes. Along the same line, if you are cooking 51 cookies, you will need to split them into two batches of 50 and 1 or maybe 25 and 26. Either way you are looking at about 40 minutes. This concept couldn't be handled by version 10.5. Most manufacturers know these batch sizes. They aren't going to bake 51 cookies. They are going to bake 50, or 100, or 5000.

Special Note: Setup costs are on a per batch basis. For example; if the batch size is 50 and the setup costs are $20.00 and one runs two batches, the overall setup costs would be $40.00. This may or may not be proper given the FG product. In cases where repetitive setup isn't required or additional setups are less time intensive, the setup costs should be reduced or perhaps averaged over the number of batches usually run, or build into the run costs.

The Billing Information Rate is not used at all, but it could be used for “pricing” process or operation costs. Let's say we want to create a price quote for a bill of materials; it's going to require a custom report or form of some sort. We can easily get prices for the components from inventory, but what about the processes? What the billing information rate allows one to do is to set a percentage over cost or a flat rate per hour as a billing or chargeable rate so that if I'm writing a customer report, I could pick up this information, utilize the estimated time, and come up with a billable cost of the operation. (Routing and Resources, Work Centers Setup)

Schedules are used in a couple of different areas of the Traverse production module. It is used in the explosion or “releasing” of production orders and it is used in the Resource Availability report. The Schedule ID is referenced in the creation of labor types, machine groups, and work centers and is a required field. It is also a field in the Production Business Rules. The detailed design and functionality was created to integrate with a third party or future internal scheduling software package, thus the setup may seem like overkill at first glance. In most cases one would want to have one simple schedule and use only that one. Below is a good example of what the simplest schedule might look like with the assumption that there are no Saturday or Sunday hours and the plant hours are the same Monday through Friday.

The schedule is used in doing a very rough calculation of how much time the processes of a production order will require so that the system can estimate process start dates. Note that without a true scheduling system, this is just a very rough estimate because the system assumes no other production activity and that all resources have the same availability. What the system does is first calculate the time required to do a process, beginning with the final process. That time is divided by the hours in a day, as found in the schedule which was assigned to the labor or machine for that process, to determine the date that final process should start. Then the next process is calculated etc. etc. (Routing and Resources, Schedules Setup, Labor Types Setup, Machine Groups Setup, and Work Centers Setup)

Example: We have a process that requires 15 minutes of machine time per unit. The schedule used for that machine indicates it is running 15 hours a day, five days a week. We create a production order for 300 units. The system divides the 4500 minutes required by the 900 available minutes in a day to estimate a lead time of approximately 5 days.

The Master Schedule represents the plan of production in terms of item, quantity, and date. We could achieve almost the same effect by creating production orders for finished goods items in terms of date and quantity, but this would be a tremendous task, not only to create, but also to maintain. When Master Schedules are used, it is generally in conjunction with some sort of a sales forecast. In Traverse you can create a Sales Forecast and then, by running the Master Schedule report, create and manage a Master Schedule that meets the needs of the sales forecast. In simple terms, meeting demand with supply. Once you are satisfied with the master schedule, use the various RP reports to tell you what subcomponents will be required and when to satisfy the finished goods demand created by the master schedule. (Requirements Planning, Master Schedule Setup and RP Processing, Standard RP Report)