The term "Netable" applies to parts that may be considered as supply to meet MRP demands.  You cannot have a "Netable" part that is excluded by MRP.  In order to differentiate between inventory with an AVL with the same MPN, but one is RoHS compliant and the other not, we recommend that the user establishes a warehouse with a "noncompliant" location.  Making that location non-nettable will prevent MRP from considering the part as available, but still allow usage of the part in kitting.  In order to do that, we have added the "Allow use of Non-netable Warehouse Locations" feature to the Kit Default Setup screen,  this allows the user to choose whether or not non-nettable material may be used in the kit lists (except for MRB warehouses, which can never be used without disposition). Any parts in the MRB warehouse are deemed questionable until the parts are validated and returned to a normal warehouse.  So they will NOT be considered by MRP. Also keep in mind you cannot ship form a non-netable location.

Please be sure to follow the procedure below to install this program. It is highly recommended that you follow this procedure on your TEST system first before applying it against your Live ManEx System.

 Once satisfied with the results in your test system, you may proceed with your Live ManEx System.  

Please be sure to follow the procedure below to install this program. It is highly recommended that you follow this procedure on your TEST system first before applying it against your Live ManEx System.

 Once satisfied with the results in your test system, you may proceed with your Live ManEx System.  

There are three approaches to establishing ABC codes. 

The FIRST is Manual where there is no calculation involved.  Whatever the user selects at the time an item is added to inventory (or anytime thereafter) will be the ABC code, and it won't be changed.

The SECOND approach is to calculate the ABC codes based on inventory value AND usage.  The Usage is also calculated in the ABC code setup and works like this:  The usage is based on how much material is issued to the kits, or out of the stockroom, and it checks the data for the last 30 days.  So the first time the calculation is done, the total amount of issues are gathered, and become the usage for the last 30 days, and become the estimated usage.  This number is multiplied by 12 and assigned as the EAU (Estimated Annual Usage).  The NEXT month, the calculation is repeated.  Only this time, if the user wishes, the data can be averaged with the previous months calculation to give a two month picture of usage.  This is done by giving the second calculation a weight of 50% (2 months).  The two months are averaged, and extended by 12 to establish a new EAU.  In the third month, the process is repeated, except that the weighted would not be 33%, to average three months.  The user can decide if they want to stop at a three-month rolling average, and use 30% each month thereafter, or go for a four-month rolling average and keep it at 25%.  Or, if the user has an unusual month, they can change the weighted for that month up or down, depending on whether it was a good or bad month.

The THIRD approach is to calculate the ABC codes based on inventory value at the time of the calculation.  This is done by extending the cost of all inventory items into a list, with the highest value at the top of the list.  The part at the top of the list might be Large PCB, with only one in stock valued at $1,000,000.  Or it could be a Small PCB, with 100,000 in stock valued at $10 each.  It is the extension of the value that is sorted by the highest number first.  The total value of all of the stock is then calculated.  In the setup, if the "$ On Hand" is selected, each ABC code must be assigned a percentage, and the total of the percentages assigned to each code must total 100%.  Typically, A codes are assigned around 80%, B codes are 15% , and C codes are 5%, but each User can make their own choices.  Then the inventory list ordered by the highest value is examined and the first 80% (cumulative) are assigned A codes, the next 15% assigned B codes, and the last 5% assigned C Codes.  The codes are then reviewed again, to see if there are any long leadtime conditions attached to the ABC codes.  If there are, the code may be increased (towards A) depending on the leadtime entered in the setup for the code.  The reason for this is that some users may wish to count very long leadtime items more frequently than the ABC code would suggest.  You may have a $0.25 part that would normally be a C code, but has a 26 week leadtime.  So you would want to keep a closer eye on that part, because it would not be good to have everything but a $0.25 part to build an assembly.  So the ABC code would be increased to B or A (depending on the ABC setup) so the part is counted more frequently than it would if it stayed a C code part. 

In ManEx, we allow more than the standard ABC codes, so it the user wanted a finer cut at the distribution, they could have up to 26 ABC codes if they had a need, and all of this would still apply.

Once the EAU is calculated, the EAU is used to extend the inventory value of each item, and the stacked values are assigned ABC codes as described in the THIRD approach.  The leatime consideratiion also is applied after that.

Question - How does Pull-in Push-out days affect MRP?

For example:  If the order policy is set to daily, and the existing work order is setup to meet a monthly demand, the user will get an action message to adjust the work order according to a daily grouping of the demand (reduce the existing wo qty and create new wo(s) as needed).  In the same scenario, if the order policy was changed to monthly, then the single work order should not be affected.

If the user wants to maintain an order policy that is NOT consistent with their desired grouping, they must either firm plan the order, or create a separate Work Order for each demand grouping.  The latter would result in multiple Work Order’s due on the same day with a qty set for each demand’s required qty rather than one Work Order on that day for the total demand.

The approach to cycle counting is based on the ABC codes setup with the System setup.  No matter how the ABC codes are assigned, they are used for the cycle count the same way. 

When the cycle count button is activated, these events take place:

1. A list of part numbers and AVLs is created for each ABC code.  Presumably, the list is long for C (low cost) parts and short for A (high cost) parts.
2. The parts in each list are reviewed for last count date, and any parts with the last counted days less than the cycle count days is removed from the list.
3. For each list, the number of remaining parts is divided by the number of work days the cycle count frequency is for the ABC code, resulting in the number of parts per day to be counted for each ABC code.
4. From each ABC list, parts are randomly selected until the number of parts per day quantity is reached.  Those parts are then cycle counted.  They stay on the cycle count list until they have been counted and/or reconciled.  When reconciled, the date completed is the new last counted date.
5. Each day, the user should create the cycle count worksheet, and clear them as soon as possible.  Parts on the list are frozen until counted and reconciled.  Parts not reconciled will remain on the list until they are dispositioned, so a list may get quite long if it is not attended to quickly.

For example, lets say that A parts have a 30 day cycle, B parts a 90 day cycle and C parts a 180 day cycle. Let's say there are 500 A parts, 2,000 B parts, and 15,000 C parts.

1. Then 17 A parts, 22 B parts, and 83 C parts should be counted each day.
2. At the fifth day, 85 A parts, 110 B parts, and 415 C parts would be counted, leaving 415 A parts, 1,890 B parts, and 9,585 C parts uncounted.
3. On this day, we would have to count 13 A parts, 21 B parts, and 54 (9,585/180) parts.

The part numbers are not intelligent(outside of ManEx they have no meaning).  Without the software to provide complete information, it is just a number.  The main concern when creating a part number is not to ensure a sequential part numbering by class, but rather the ability to track additional information (AVL, on hand qty, where used, standard cost, etc) by one internal part number.  Because of this, the actual number doesn't really matter as long as the system knows which additional information to attach to the internal part number.  This is why ManEx works as well with a manually created number as with an auto-generated number.  If you use auto-numbering, the numbers can be arranged on the shelf in ascending order (even if there are gaps between the numbers).  The auto-numbering in ManEx simplifies the part number creation process and provides a count of the total parts in your system (141-0001000 to the 1000th part loaded).

Additionally, it is common in this industry to add new parts and obsolete old parts as the customer base changes and grows over time.  Even if the parts were setup sequentially by class and type, as you suggetsed, they would eventually have gaps in the numbers as old parts are made obsolete.  There is a no way to prevent this and it is not worth your time to fix it after it has occurred.

Not having all parts numbered sequentially by class and type does not affect the quality of the information provided.  Users are able to purchase, track inventory, and kit all parts by part number.  ManEx will still accurately maintain all important information by part, by customer, and by BoM.

If is absolutely critical to have all parts by class and type sequentially numbered. Users do have the option of manually creating the part numbers.  This will allow you to use any part numbering method. 

Go to the Number System module to Setup "Auto" or "Manual" numbering.

Note:  With the auto-numbering setup the way it is you can have 10 million parts in your system. 

The Estimated Annual Usage (EAU) is calculated by taking the most recent 30 days of issues to kits, and multiplying that by 12 (months).  WHen the user first begins using the EAU, the factor shoudl be 100%, meaning that the full 30 days is used to extend to an annual quantity.

If the month following (after another 30 days of experience), running the EAU again will weight the second run against the first run.  So the factor for the second run should be 50% (or the equivalent of a 60 day average).

In the third month, (after a total of 90 days of data), the factor would be 33%, thus averaging out all three months and extending that average for a year's period.

If the user wished to maintain a rolling 3 month average, then the following months would also be 33%.  A 4 month rolling average would be obtained if the user entered 25% on each subsequent month.

Another consideration is that if the user just finished a really big month, with record consumption (an presumably sales), and doesn't want the blip to cause excessive forecasted EAU, they might enter a 20% factor instead of 25% or 33%.  On the other hand, if the user has a very slow month, and doesn't expect it to continue, they might want to give a higher rating to that month, say 35% instead of 25% or 33%.  This would have the effect of not understating the expected EAU.

Question:  If I have more than one customer that uses the same MPN, how do I "Disallow Part from Purchasing/Kitting"  for only one of the customers?

Answer:  If the part is listed on the BOM as a customer/consigned item then it is controlled by the "Disallow Part from Purchase/Kitting" option within the Customer Level of Inventory Control Management.  If the part is a BUY part on BOM(s) for different customers the Kitting module is controlled by the "Disallow Part from Purchase/Kitting" option within the Inventory Control Management module   Since it is BUY on the BOM the system is looking at the BUY settings.  For further detail see Article #3211 .  For Buy parts that are used for multiple customers we recommend that you un-check that AVL so it is no longer approved at the BOM's level for that product.  

A:   There are many utilities to identify all internal parts that use a selected MPN. However, if you want a master list of all parts so that you can review and delete any that are not needed, below is a simple set of instructions you can follow:

The main information for an item master (Internal part) is contained in the INVENTOR table.  For every AVL that is added to the part, a record is created in the INVTMFHD table.  The AVL is linked to the item master by the field Uniq_key in each table.  When an inventory warehouse/location is added to an AVL, another record is added to the INVTMFGR table.  The Warehouse information is linked to the AVL information by the Uniqmfgrhd field.

When a User adds a customer part number to an item master (internal part), an additional record is added to the INVENTOR table.  This record contains the same information as the internal part, but with a DIFFERENT Uniq_key, and is identified with a Part_sourc field as CONSG, and includes the customer part number and revision.  This additional record is used both for consigned information and to identify the customer part number by customer.  It is linked to the internal part through the Int_uniq field, which contains the internal uniq_key associated with the customer part.  When the customer part number is added, the AVLs and Locations are also duplicated in the INVTMFHD and INVTMFGR tables, in the same linking as described for the internal parts.

When a supplier part number is added to the table INVTMFSP.  There the supplier information is contained as well as the supplier part number.  Because it is linked specific to an AVL, it is linked by the Uniqmfgrhd field to the INVTMFHD table, in similar fashion as the INVTMFGR table.

Diagrammatically, it could be described as:

INVENTOR  . . . . . . . . . . . . . . . . .  Item Master
       INVTMFHD . . . . . . . . . . . . . . . . . Manufacture information
             INVTMFGR . . . . . . . . . . . . . . . .  Warehouse information
             INVTMFSP . . . . . . . . . . . . . . . .  Supplier information

So there will be one set of these for every internal part number, and may be multiple sets of the same information for different customer part numbers.

Question: 

User had made a few changes to the BOM through the Bill of Material Module and then went into the Kit module and depressed the update kit button.  A large number of items appear to be dispositioned and issued to the kit for items that had no qty changes, etc. . .

Answer: 

One of the possible reasons could be the fact that the user went through and changed the assigned workcenter on the BOM.  So when the update kit checks the existing kit to the new BOM changes it sees all of the Workcenter changes and bring them in for disposition.  If the kit was pulled while the BOM Workcenter was STAG  then the user edits the WC on the BOM to Final Inspection, when the update kit button is depressed that item will be pulled into the screen for disposition.

Possible reasons why the Inventory Valuation report would not match the GL balance for the Inventory GL Account #

Section A

Before comparing the Inventory Valuation to the GL Balance the following items needs to have been done. 

• create a backup of your live data files and work from a froze data set when comparing numbers.  This is not a requirement, but it is strongly suggested since inventory valuation is a moving target when trying to work on your live data files.

• Make sure that all invoices have been released to AR (because in the case of the packing list, it will be deducted from inventory right away upon the Packing list being generated, but the corresponding GL transaction will not be generated until released to AR)

• Make sure that all AR Credit Memo's that were generated from RMA Receivers have been approved and posted to the GL. 

• All records Released/posted to the GL.

• Also keep in mind that the same GL Account could be assigned to multiple Warehouses within setup.  And/or, each warehouse could have a different gl # assigned to it, so you can not just run for all Warehouses and expect the Inventory Valuation report to match one specific GL Account.  Before comparing the Inventory Valuation Report to the GL Accounts, it is best to check the Warehouse Setup first and find all of the Warehouses that use the same GL Account #, then run the Inventory Valuation report for just those warehouses, instead of ALL. 

• Keep in mind that you will more than likely see a minor difference between the Inventory Valuation and GL Account # balance when you compare them which is common and is more than likely due to one report rounding individual record differently than the other.  It should be a very small difference in value.  If it is are large discrepancy, then more investigation may be required. 

NOTE:  Concerning the "Inventory and WIP Valuation Report"  the WIP Value on this inventory report should not be used as a validation to the GL Account balance for WIP.  This report was created in order to give the end users an idea of what was actually in WIP for components at this time.  The GL balance for the WIP account will more than likely never match this value due to the fact that so many variables come into play when generating the GL Transactions for WIP.  (shortages, over issues, partial job moved into FGI, kit not closed yet,Configuration Variance, Manufacture Variance, etc. . .)  And one component can be used through out many jobs at any given time, and these jobs could be in various stages within production, it is not possible for the person attempting to compare these values to go through and validate all kit shortages, over issues, what has been partially moved into FGI, etc. . .  

Section B

If you find that the Inventory Valuation report value and the GL Account value do not match even after following the above suggestions below might be a number of other items that contributed to the discrepancy:

• Any GL Account number that is used within the Warehouse Setup should not be used within the Inventory Handling GL Defaults.  For example:  if you find that you had your MAIN1 Warehouse assigned to 1310000-00-00 and happen to have Inventory Handling Issue Default using the 1310000-00-00.  When the user uses inventory handling to issue qty out of stock the system will properly reduce the qty on hand , which in turn reduces your Inventory Valuation report.  But since the Warehouse and inventory handling Default used the same GL account number the Transaction would Debit and Credit the same account.  Therefore, your Inventory Value went down, but your GL Account balance remained unchanged.

• You should not be using the Inventory Handling to issue parts to WIP.  All of this should be handled through the Kitting module to make sure that all of the correct transaction are made within the system.  if you attempt to use inventory handling to issue parts to WIP:
  • The value it not actually associate with any work order within the system.  If you use Kitting properly the system will associate that WIP value with that kit. 
  • Upon Closing the Kit the system will not make the correct transaction to relieve that value out of WIP (unless the users remember to manually inventory handle that value back out upon closing the kit)  If you use Kitting properly the system will create the correct transactions removing that value out of WIP.  It will also make the needed calculation for Config Variance and Mfgr Variance.   ​

• As a Rule you should never create Journal Entries against any of the GL Accounts that are setup within your Warehouse Setup.  (we do understand that there are situation where the JE against these accounts are needed, but it should be very rare situation.)  If you generate a JE against your Stock GL Account, now your GL value would have changed but your Inventory Valuation has not.  Same applies for WIP GL Accounts and/or Variance accounts. 

• As a Rule any GL Account # that is assigned to a warehouse within Warehouse setup should not be used within any other setup screens within the Manex system.  
  • For Example:  there was a user that had the same GL # assigned to a warehouse and then they also had a Sales Type within the system that was using that same GL #.  They also has a Purchasing GL Accounts allowed to select this same GL Account #.  This would cause the Inventory Valuation report to never match the GL Account # balance.   

If you have followed the above suggestion and confirmed that the Setup is correct and that no Journal Entries have been created against these accounts and you find that you still have a discrepancy between the Inventory Valuation reports and the GL Account Balances, please proceed with the following:

• Take note of the Discrepancy value at a particular point in time

• on a daily basis Follow the steps in Section A and confirm if the Discrepancy has changed from the prior day or not.  

• If you find that the Discrepancy has changed from the Prior day, document the detailed information

• Provide Manex with the Detailed, Prior Day backup and the current back up where the Discrepancy has changed.

• Manex will review the days worth of transaction in order to try and determine what could be causing your fluctuation between the two values.   

Question:  Why doesn't the system allow us to assign multiple part numbers for the same customer to one internal part number?

Answer:  While a seemingly simple request, it would take a massive overhaul of the inventory module to accomplish.  Additionally,  we would have to add provisions wherever a customer part number is used, for the user to elect which one to use in every instance. For example, when printing an invoice, we offer the option to include a customer part number.  If we made this change, we would be forced to have the user define which one every time a part shipped out.

Often our users customers want their own part numbers on the packing list and invoice, not our users internal part numbers. We offer that capability, should the user elect to print customer part numbers on the forms (even though shipping turnkey internal part numbers), and if there were multiple customer part numbers, the user would have to pick one each time a product is shipped. How would the shipping clerk know which one to pick if there were multiple customer numbers?

First, it means that the WIP account is proplery address AFTER all kits are closed, and GL records are released and posted.

When there is a cost adjustment while there are components in WIP, the value of the WIP account is not updated until the kits are closed. Then, the WIP value is updated, but erroneously attributed to manufacturing variance instead of cost adjustment.

So, making major cost adjustments when there is a large amount of affected inventory in wip will result in major discrepancies in the reported WIP VALUE from the Production reports and the WIP account value in accounting. When all kits so affected are closed, the discrepancy will be corrected. Put another way, the Production WIP VALUE is calculated on the current inventory in kits (by calculating the remaining assemblies in the kit, extending the QPA for each component based on the current BOM, subtracting any shortages and extending by the CURRENT Standard cost per component) and the GL reports are based on the value at the time of issue to the kit.

At the time this happens, (when the kit is closed) the value of all items issued to the kit is totaled and compared to the value of the totaled BOM component cost for the assemblies completed at the time of the kit closing.. The difference is currently logged as a manufacturing variance.

To validate the standard cost of the items issued in the INVT_ISU records with the current standard costs, system will total that value, and subtract it from the total manufacturing variance for each work order.  Then the true manufacturing variance should be realized, and the difference due to standard cost changes posted at the same time to the inventory adjustment account. Then, the total of the manufacturing variance and the total of the cost adjustment change should add up to the total difference between what was actually issued to WIP and what should have been issued to WIP (via the BOM).

bld qty = 100

In summary, the WIP Evaluation report will provide users with a picture of parts issued to work orders that should be in WIP, and is a guide to the approximate value of WIP Inventory. But it is the General Ledger that keeps accurate track of the real WIP value.

First, only open work orders are considered. Closed or Cancelled work orders are not included. Then the balance of assemblies due for each work order is determined. For each work order included, the original quantity of each part kitted for the work order is determined based on the kit pull, and extended by the balance of the work order, and by the standard cost of those parts. Then kit shortages are checked. All shortages for the work order are then subtracted from the total value of the work order. This information is then displayed within this report. 

This information continues to be reported until the balance of a work order is zero and the kit is closed. At that point, all WIP value associated with the work order is returned to zero.

Only existing material or product may be shipped. Therefore, any inventory to be shipped must have quantities in stores or finished goods. There is no other way to ship.

Material may be placed in finished goods (or stores) by using the Inventory Material Handling (receiving) procedure. 

If a product has been defined as requiring serial numbers, then they must be entered in order to ship the product. The serial numbers may or may not be barcoded. If not, the numbers will have to be entered by hand.  Please refer to the Work Order Management  and Packing List Management  procedures.

o   Create the Packing List and Invoice the customer

o   Create the AP Check to pay the Supplier for the components

o   Create AR Deposit for when the customer paid the original invoice

Question:  When parts with a Run Scrap percentage are issued to a kit they will show up as WIP in inventory. When inventory goes to return the actual excess parts they cannot because it is not considered extra. Is it possible to return more than was expected when closing kits?

A. There is no serial number kitting capability – so to kit sub-assemblies to a higher assembly by serial number, use the serial number assignment detail tab to enter subassemby serial numbers connected to a higher serialized assembly. (Please see the Work Order Management manual). If the higher assembly is not serialized, there is no place to connect or track serial numbers for lower assemblies except back to the Work Order.

Example Situation:

If product #1 has AVL "A" and "B" approved, and product #2 has only AVL "B" approved.  And product #1 is kitted before product #2, the system will allow the user to use all of "B" when "A" could have been used and left "B" stock for product #2. 

Suggested Resolution:

If Users wish to avoid the above situation we suggest that you use the Work Order/Project Allocation feature within the Purhcase Order module.  Then when the part is received, it is allocated to that Work Order or the Project which will avoid the above situation.

MRP is just a program that reviews the supply and demand and creates suggested actions based on the system information.  MRP only suggests the actions and the users are the ones that have the sole control of following them or not.  It would pose to many restrictions on our users stock if we started having the MRP actually control their stock.  

Some of our users were reporting that after they make changes to the BOM and return to the Kit to put the Updates in place that the quantity was not being brought forward into the update kit screen and was NOT returned to stock and seemed to have disappeared from the system.

Explanation:

If the user is simply just depressing the OK button that stock will be issued to the kit and not returned to stock.  When you make changes to the BOM and then update the kit, make SURE that the users are trained to review and disposition every item listed and ensure that they are returning to stock if desired. They can NOT simply just depress the OK button, otherwise they can be issuing parts to the WO, and we can NOT get them back, they will be valued as a Manufacture Variance.

The reason why the parts are NOT re-appearing in stock is due to the Work Center and/or Part removal changes made on the BOM’s.  If the Work Center was changed on the BOM the update kit does not have the original Part/Work Center combination to return the stock to inventory – this is why it defaults to Issue to WO with the option to return to Stock. 

Same rule would apply if a part was deleted from a BOM and the kit updated.  The kitting module would default issue to WO, because it did not have the original Part number information to return directly to stock.  This is why it defaults Issue to WO with the option to return to Stock.

When you depress the update kit button the item is displayed on screen for disposition.  If you take a look at the print screen provided you will see that it is defaulting the qty to be issues to the kit.  If the user is simply just depressing the OK button that stock will be issued to the kit and not returned to stock.  The value of that stock will be accounted for in the Manufacture Variance upon closing the kit.  If you want the inventory to be returned to stock you need to change the qty in the Issue to WO section below to 0.00 and then the Return to Stock qty should update to the amount you wish to have returned to stock.

The following data actions occur when Kitting. (In this set of information a limited BOM was created with only two components, one of which was allocated to a project.)

When kitting the first part, (which is a part allocated to a project)

The  “Inv_res” table, will have a record created for this part and a link to the “Fk_Prjunique” project key.

Once the user issues it to the kit, the stored procedure (trigger) in INVT_ISU table will be create. Once this record is created, the program will check if the part has any allocation records, and decrease allocation qty (actually insert a negative qty record) if found. It first checks if part is allocated to work order, then checks it it’s allocated to project.

The INVTMFGR Qty_oh and Reserved fields are reduced by the amount issued.

In the JBSHPCHK table, a recorded is added that the kit is in process.

In the KAMAIN table, records of all parts of the kit are added, and the record of the issue is recorded.

In the KADETAIL table, all parts in the kit are added as parts shortage, and issue records are added for parts kitted.

In the KALOCATE table, a record is added of the issue.

In the WOENTRY table, the kit status is changed to true. (on first issue)

In kitting the second part,  a non-allocated part:

A record is added to the INVT_ISU table, indicating that the parts were issued to WIP, and a specific work order. Various keys are used for tracking purposes.

The INVTMFGR Qty_oh field is reduced by the amount issued.

In the KAMAIN table records are added of the parts used in the kit, and actual issues thereof.

In the KADETAIL table, issue records are added for parts kitted.

A.  When the kitting records are created via the “Pull Kit” option, they are established from the BOM, by work center and items. If subsequent to a pull item, the user makes a change to the BOM for the product, and then updates the work order, the following events happen:

If the change to the BOM involves the deletion of a part from one work center of the BOM and addition of the part to another work center of the BOM, these count as deletions and additions. Of course, normal deletions may also occur, as well as quantity changes. When the update is performed on a work order, the system checks to see if parts have been issued which are no longer needed. If there are parts in this situation, then the user is asked whether the parts are to be returned to inventory, or have been (or are to be) consumed in the work order. If the user responds with a yes – consume the parts, then the parts are deleted from the kit record (not the issue records and transaction records). They will no longer show up as parts required by the work order. They will show up on the kit history list as being issued to the work order.

The part that has been moved to a new work order is considered as new part requirement. The program cannot distinguish that the part was already issued albeit for another work center. So the part will show up again as needing to be kitted. If the user has fully kitted a work order, then changes the BOM, then updates the work order from the BOM, but does not return extra parts to stock, the effect will be a requirement to reissue those parts for the new work center, and scrap the ones already issued. The user will probably issue the parts (again) to fill the new shortages.

A.  A line shortage entered in the kitting and shortage module will be displayed on the kitting screen until it has been filled. The shortages will be displayed on all shortage reports and screens. After the shortage is filled (issued to the work order) it is no longer a shortage, and will drop off of the kitting screen and all shortage reports.   However, records of the issue to the work order may be viewed and printed from the "Work Order Kit and Shortage Issued" report, or the "Work Order Detail Shortage" report, both found in the Kitting and Shortage Reports . 

A. When the kitting reports are issued, they will not contain either the Y or F items marked in the U/K. MRP will be sure that the items are on hand, or ordered in time for the kit, but the items are not directly kitted. Users may pull items out of stock and have it sitting on a barrel on the floor, from which the floor can pull floor stock without further transactions. Or, they can have a warehouse called floor stock, and keep the stuff on the floor, but then they would have to do an issue each time they took parts out of the barrel.

A.  Once inventory has been dragged from an inventory location, it can NOT be dragged again to fill shortages left from insufficient inventory on the first kit. The appropriate way to add more inventory to the kit from the same inventory location is to highlight the amount already kitted (in the lower right corner of the issue screen) and change the quantity to the revised quantity. That action will remove the additional quantity from inventory and place it in the work order.

A.  There is a Reject Reason Pull down list available on the PO Receiving Screen.  This allows the users to be able to select the Reject Reason code rather then writing notes.  This is created within the Return/Shortage Reasons module.

Question:   Why doesn't the System allow the User to issue Quantities that are Greater than the Shortage Quantity from the "Shortage List & Issue" button in the PO Receiving module?

Answer:  This would require the receiving code to get into yet another level of complexity to take care of the whole new logic, which KIT module is already designed to deal with. The complexity gets even greater when receiving parts that are lot coded and/or serialized. To deal with this new level of complexity we are facing to issues; 1. Slowing down the PO receiving save routine, which can cause lockups like we experienced before not only in the PO modules, but KIT and Inventory modules as well. 2. Managing the code – Even though the code in the PO and KIT modules for the over-issue logic is similar it cannot be exactly the same due to the differences of the data moving in those modules, therefore we cannot create one function to use by both modules, and this usually creates a “code management” issue. As modules evolve the code will start deviate between two modules and we will face un-necessary errors from having two similar codes but serving different functions. The verdict is that the user should use KIT module in situations when the quantity issued to the work order from PO receiving is greater than the shortage quantities.

Problem:  User enters the PO Receiving module and receives PO #990026, for part number XXX-OOO, after entering the accept quantity, user goes to "Shortage List & Issue" button to issue part number XXX-OOO to WO #34.  The KIT required for part number XXX-OOO is 58.5 inches.  The Purchase Order UOM is feet, so the PO Receiving converts the KIT required qty to 58.56 inches.  Which is more than KIT required qty, and makes the "Short Qty" negative.  So system will not allow user to save the issue. 

Resolution:  The user will need to use the KIT module when the quantity issued to the work order from PO Receiving is greater than the shortage quantites. 

When the balance open for a purchase order line is zero, the line is closed. When all lines are closed, the purchase order is closed. However, it is possible to receive more than the ordered quantity into dock receiving. If only the amount on the PO is received, the extra quantity remains left in Dock Receiving, then it will display as open to be received, but as closed status when selecting an order for PO Receiving.  This can be cleared by reversing the dock receipt, or completing the receipt in PO Receiving.

Please refer to the Purchase Order Receiving Management module.

Issue:   When I transfer parts to MRB and enter a reason, and create a DMR the reason for transfering to MRB is correct, but then when I transfer more of the same parts to MRB and enter in a different reason, when I create the 2nd DMR for the second transfer, the DMR is displaying the reason related to the initial transfer to MRB, rather than reflecting the reason related to the second transfer??

Reason:  The system is taking the reason from the transfer transactions and since the transactions are for exactly same parts the program will find the first transfer to MRB and use that reason.   Right now the system cannot identify which transaction to use, unless the part is serialized or lot code enabled.  

 

Q.  When we entered Dock Receiving, the wrong quantity was entered.  How do we fix this?

There should already be a file called <<RESETPOLOCK9.EXE >> located within the Manex Root Directory. (if this file is missing please download the attached)  Running this executable will reset the lock within the shop floor tracking tables.  This executable does not require you to stop the TrigTimer.

This is an analysis of the process when there are cost adjustments made to parts and products during a work order in progress. I began with a database in which there were no other transactions, and the beginning GL was empty. In the word document attached, I detailed every step taken, along with images of the related screens. In the Excel sheet attached, I detailed out the specifics for each transaction, and what caused the changes to the GL.  After each step outlined, all transactions processed were released and posted to the GL so I could display the results with the activity. I also included a Chart of Accounts, should you need further definition of the account numbers.

The activity tracked in the GL correctly in every step.