Trying to handle multi-site manufacturing in one database
Solution ID = KB-238
Version = All Version
Module : SLMFG
Fact 1 : SFC
Fact 2 : Multi-warehouse
Symptom 1 : Trying to handle multi-site manufacturing in one database
Symptom 2 : You are trying to use the multi-warehouse functionality in one database to manage the manufacturing process in multiple manufacturing facilities but several reports, screens and functions in in the application only use the default warehouse
Database : Progress, SQL
Cause
The Syteline multi-warehouse functionality was not designed to handle multi-site manufacturing within the same database. The design intent of the multi-warehouse feature as well as the majority of the current system functionality assume that all manufacturing is taking place in the warehouse which has been entered as the "Default Whse" on the Inventory Parameters screen.It is recommended that you make each manufacturing facility a separate site. The multi-site processing in the Syteline version allows you to have global item masters, designate supply sites for items, pass transfer order requirements between sites, etc.
Fix
The following points illustrate that the system was not designed to handle multi-site manufacturing within one database:
1) Original Design of the multi-warehouse feature
When multi-warehousing was added for Symix 2.6, it was only a warehouse field added to CO line items and PO line items. There was no Whse field on jobs which implies all manufacturing was being done in the default warehouse.
2) Purpose of the "For Whse" field on the Job screen
The field which most commonly leads people to believe they can do this is the "For Whse" field on the Job Order screen. However, that field was added to indicate into which warehouse the parent item was to be moved when finished, NOT that the job is being processed in that warehouse. That field didn't exist until Symix version 3. Several users stated that they didn't want to use transfer orders every time they completed a finished good and needed to move it to another warehouse for shipping so we added it as a time saver. The label "For Whse" (as opposed to just "Whse") was meant to indicates this. Development stated cleanly after the release that the above was the intent of the field and it was not meant to handle multi-site manufacturing.
3) "For Whse" set to default warehouse on subjobs
Regardless of what warehouse is specified in the "For Whse" field on the top level job, it is always set to your default warehouse on subjobs created by the application. If you elect to "Copy BOM" when using the the Copy Routing/BOM activity or you use the X-ref button on a job material, the subjobs created will always be the default warehouse. This is because the system is assuming that all of the manufacturing is being done in the default warehouse that the top level item will then be moved to the top job's "For Whse" when complete.
4) The inventory Alloc to Job field
The Alloc to Job field which how many of the item have been allocated to the manufacturing process is at the item level, not the item warehouse level. If the design intent was to handle multi-site manufacturing, the Alloc to Job field would have been at the item warehouse level as is Alloc to CO and On Order (from POs). So, functionality that uses Alloc to Job like the
5) MRP single warehouse processing
MRP can be run for only the default warehouse if you set the "Whse Considered For" to Single in the MRP Parameters. In that case, it only considers POs, COs, transfer orders, etc. that are for the default warehouse. With that set to Single, MRP still creates material requirements for all materials used on all jobs regardless of the "For Whse". Therefore, it is making the assumption all materials are coming from the main warehouse.
6) Wedge DC backflushing
If using wedge data collection and entering job transactions which backflush material and you have the auto-post flags set so that the transactions bypass the unposted job transaction screen, the system backflushes materials from the default warehouse.
7) Job Paperwork pick list always uses default warehouse
When you elect to print the material pick list portion of the job paperwork, the report always prints the default warehouse in the heading of the pick list and lists the that in the default warehouse for each material regardless of what is in the job's For Whse. Again, the assumption is that all materials will be coming from the default warehouse.
8) Scheduling and capacity planning is not warehouse specific
There is no warehouse field on departments or work centers so you cannot group them or designate that they are in a specific warehouse. Therefore, you cannot do any scheduling or capacity planning by warehouse, functionality which would exist if the system were designed to handle multi-site manufacturing in one database. Some users have attempted to work around this by creating separate departments and work centers for each facility and then building an item's current routing using work centers that are "in" the facility where that item is manufactured. However, if the same items can be made at different facilities, problems arise since you can only have one current routing per item.
9) On Hand on Job Operation/Material Status report
This report has a field showing "On Hand" for each material in the job's BOM. That field is calculated using only the quantity on hand at locations in the default warehouse.
10) Time Phased Inventory Status screen
If you display this screen for an item which is used as a material on jobs, the JM requirements will appear in the default warehouse regardless of what is in the "For Whse" field for those jobs.
Note: This started working correctly with the fix to bug 18954 (fixed for 4.0r8.02, Sl2h00 and SL3b01). Prior to that fix, when gathering job requirements for the item displayed, it was incorrectly selecting jobs where the "For Whse" matched the warehouse you were in (the screen is by warehouse).
11) Purchase Requirements report
If you run the report and leave the warehouse range blank (i.e. all warehouses) or enter a range of warehouses that includes the default warehouse, allocated to job is included in the calculation (i.e. deducted from quantity on hand) which determines whether the item should be printed. Also, the jobs on which the material is used will print if you elect to show Time Phased Detail.
If you run it for a specific warehouse other than the default or for a range which does not include the default, the allocated to job is not deducted and the time phased detail does not list job's on which the item is a material.
12) The location of the default WIP accounts.
The WIP accounts and unit codes are at the product code level rather than at the distribution account level. That, in effect, means that you can have only one set of default WIP accounts and unit codes for each item. If the system was designed to handle jobs being produced in multiple facilities (warehouses), the WIP accounts would be at the distribution account level so that when you added a job they would default based on the item's product code and the job's "For Whse".
Issuing Materials From Other than the Default Warehouse
As described in point 2, a common misconception is that the "For Whse" field on the job screen indicated in what warehouse the job is being processed. People put a warehouse other than the default in that field and expect the material requirements to show up in that warehouse, screens and reports which check the availability of material to only use that warehouse, and the materials to be pulled from that warehouse.
The following features do indeed allow you to check availability of materials in and issue materials from other than the default warehouse. Like the For Whse field, these features are designed to be time savers in that you can issue material directly from the warehouse in which it resides rather than processing a transfer order.
1) Job Pick List "Whse" option
There is a "Whse" field on the Job Pick List screen. The materials are picked from whatever warehouse you enter in that field. Though you can enter any warehouse, it defaults to the default warehouse rather than the job's For Whse which implies the system expects you to pull the material from the default warehouse.
2) Warehouse selection for manual material issues
You can manually issue individual materials on the Job Material Transaction screen. On that screen, if you select Edit/Warehouse Change and choose a warehouse, the material will be issued from that warehouse.
3) Backflushing uses the current warehouse
There is a globally shared variable for each user which keeps track of what warehouse they are "in" when moving around the application. Upon login, it is set to the warehouse entered for that user on the user master "Whse" field. If that's blank it is set to the default warehouse. This variable is what is changed when you use the warehouse selection activity on any screen which has that option. It is also changed automatically by the system when you move to certain screens.
When you post job transactions which backflush materials (from SFC not from DC), the system backflushes the materials from whatever the posting user's current warehouse is when they post the transactions. So, if you were trying multi-site manufacturing, you could change your warehouse and post batches of job transactions so that the backflushing for each job occurred in its "For Whse".
4) Material Availability report
There is a "Warehouse" option on that report which defaults to "All". If you enter a specific warehouse, the report will look only in that warehouse when checking the quantity available of each material.
5) JIT transaction backflushing
When you post JIT transaction, the "Whse" field defaults to the current warehouse and can be changed to any warehouse. When the transactions posts, that is the warehouse into which the parent item will be moved and from which the materials will be backflushed (if you have backflushed materials in the parent's current BOM).
6) Production Schedule backflushing
When you enter a PS Complete transaction, the Whse field defaults to the production schedules "For Whse" and it cannot be updated. That is the warehouse into which the parent item is moved and from which the backflushed materials are issued
