all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||
|
|
|
Yellow
|
|
||||||
|
||||||
|
|
|
Notes:
|
|
Known Issues with Manufacturing – (Recipe/Builds) 1. Manufacturing has a number of different names. Kits, kitting, macros, morphs, packages, work in progress, finished goods, builds, recipes, models, spec sheets, plans, drawings, custom products, assemblies, groups, deals, packages, deals, bundles, etc. 2. The name or word “manufacturing” is too limited. We want to be able to handle all kinds of products, services, new products, etc. Our scope may include companies that: - Sell package deals - Build new marketable products - Allow options to be chosen on the fly - Track inventory (raw goods) and also track finished products (builds) - Possibly have unlimited levels of product assemblies - Single line items (currently available in the system) 3. We want to be able to sell anything we want on a single invoice. This may include special line items, parts, units, labor, builds, hidden items, services, etc. 4. We need to be very careful and track quantities in, quantities out, raw inventory counts, finish goods counts, accurate costing, accurate pricing, etc. Most things are easy to put in… what about being able to void, back-out, credit, re-do, etc. We need to build the application so that it can go both forward and backward. To make this even trickier, we need to be date sensitive, location sensitive, and usable (easy). 5. What about table (database) capacity? What limits do we have? Are we painting ourselves into a corner or can we expand at will? What about pulling data back and loop size? Do we have any limits on ColdFusion or list lengths? Before we jump, we might want to scope it out. As it sits right now, we have plenty of room to run and see where it goes. This may be a subject that needs some attention in 6 months to a year. 6. I see manufacturing on a couple of different levels. - Single (line by line) - Apply as you go (say internal tickets to units) - Single on demand (light and flexible) - Multi on demand (light and flexible) - Bulk (same thing over and over) - Build from ground up (single or multi) - Hardcore (building a serialized unit and placing other serialized units on that unit – track everything down to the “T”) - Recipe types: o Build & Sell: Shopping cart – type interface with flexibility to show/hide and add options. o Build & Hold: Raw goods being combined to create a new part – this could be multi layers deep if needed. o Build & Build: Similar to duplicating internal invoices but with a build and apply interface for serialized units. This might work well with mini units 7. What about batches, batch codes, process #’s, etc.? This gets into serialized units. Maybe we need a thing called a “mini unit”. This would be similar to a specific unit but scaled down and optimized for bulk creation, updates, and selling (all in bulk – yet specific with all of its history and batch numbers). 8. Do we want to create an actual build with a main and line items or do we want to use a PO and call it a build PO? - Build Pros: o New item o Wouldn’t balloon up the PO table o Wouldn’t change the PO numbering o Could tie to a specific permission o Could create custom logic and own history - Build Cons: o Additional development o Full new section with add, edit, history, reports, etc. o Need major changes to po_invoice_line_items table - PO Pros: o Logic is already in place for inventory control o Smaller development time - PO Cons: o Permissions get a little trickier o This would blow up the PO table o Need to check all current PO logic o PO’s are tied to payables 9. We would like to create a standalone item called a recipe. A recipe would contain all of the ingredients to make or build something. This could include qtys, prices, costs, descriptions, instructions, add-ons, options, etc. We would also like to include hidden line items and show output in a specific order. - Other ideas on recipes: o Prep time o How long (duration of time) o Yield (qty or output) o Inventory check (do we have enough stuff) o Output (what does it make or what do we call it) o Amounts (qty & costs) o Add-ons & options o Order of ingredients o Instructions o Required items or optional items (choices) o Active and inactive line status o Prep (extra instruction that may be deleted later on or hidden) o Flexible and user-maintained o Able to search or look-up quickly o Tax category (default per line) 10. We need a flexible invoice that can show all the details or just the items that need to be shown (show/hide status). Along with that, we also need to show a single invoice with cost and profit showing. Another way of saying this: customer view vs. shop view vs. back-end view vs. accounting view. All of these items (invoice views) need to contain the same info but may be viewed differently or only by permission. 11. On mini units, how do we track things in bulk yet keep things tied at the hip. This could be a nightmare. We want specific results but no one in their right mind would check 1,000 bolts for a heat code before using them. It seems like a natural disconnect. Good in theory (track everything) but just a shot in the dark in real life. Even if we did make something like this, how do we include checks and balances, quality control, and audits? 12. What about builds (runs). Say for example, we do a build and take 1,000 widgets and paint them or squeeze them into something (changed from the original). We then want to record the build number on all new widgets. Say we also put all 1,000 new widgets into a box and label the box with the build #. Here are a couple questions I would have: - How do we (the system) tie the build to the box #? - How do we know all the items in the box came from the current build? - What happens if there is a gap in time or things get mixed? - What happens if we use 1,000 widgets and only get 950 out the other end? What happens to the other 50? What happens if the box is incomplete? What if we over produce and have excess (but not enough to make the next box)? - What happens to flaws, seconds, and scrap? What if one resale them? - I would imagine that the box (see example in #12) would need the build #, maybe a user maintained build number (date or user code), plus its own port #. The part # would be unique for the end product but not for each box. This would require a multi-part key id (build and user maintained build and part id). My question would be, where do we record those extra fields? Do they get passed along and how do we tie-in or search them rapidly? 13. What about other manufacturing terms: lots, cases, boxes, bins, pallets, racks, loads, runs, cartons, packages, by weight, by size, by volume, sets, clusters, quantities, sizes, groups, collections, bundles, lots, baskets, buckets, bags, stacks, other measurements, liquids, solids, gases, jars, tubes, etc.? 14. What are the differences between manufacturing for internal, for re-sale, for retail, for other? What is needed on the build? What is needed on the finish goods? 15. What about verifying builds? What about payment options? Internal? Payables? $0.00 cost? Not sure. 16. What about roll-backs, voids, and dis-assemblies? This needs to be part of the solution but we also want to control how fast and how deep (levels) the action goes. 17. If you are building and creating, building and creating, etc. How do you keep a running log of what came from where? Parent /child relationships. Do we want to let the users create their own logs (separate table) that can be tied to any PO (build) or any unit? This would be a one to many relationship that could be classified as parent or child. Just an idea… we might be able to use this to tie a single box to multiple serial #’s or invoices. Maybe this parent/child relationship could be for build PO’s or invoices and tied back and forth however the user wants. Basically sell and build in bulk (keep it simple) and then allow the user to put in extra tie-ins that are flexible, searchable, and fully user maintained. We keep things simple and they (the users) add whatever detail(s) they need. This could be huge. It also could be super flexible. We may also want to include options for dynamic naming, multi add feature with a number field that would go from a start to end range. 18. Use the build PO to pull down raw counts and show new output all on the same PO. 19. See #17. Other ideas for the parent/child relationships. - Maybe have 5 to 10 custom titles for parent/child relationships. Tie to a corp and allow them to update them at will. Basically, we create 10 text fields and name them like other_1, other_2, other_3, etc. In the background we allow the corps to set the verbage (titles) for each field. This way they could use any of the words in #13 and track whatever each corp needs. - Maybe allow any extra fields to be hidden to make things look cleaner. - Create a separate add/edit, add multi, search, and PO/invoice tie-in report. 20. Allow recipes to be searched like part numbers. Along with that, allow for parts, recipes, barcodes, and RFID tags all from the parts search field. Only show the non-parts options if the user has those permissions. 21. When doing builds how do we keep track of costs and prices? - Cost options: o Use current cost (from parts table) default o Use fixed cost (hardcoded value) not recommended o Calculate the cost (sum of all used ingredients) (only for recipe output) - Price options: o Use cost (see above for options) (internal or multi build) o Use current price (from parts table) default o Use fixed price (hardcoded value) not recommended 22. On the (additional tie-in and details) PO/invoice relationships (parent/child relationships) add an option to show/hide the relationships. If hidden, they will still be searchable and printable from the sub report page. If they are marked “show”. Show a list of subs below the main invoice details. |