Lot Availability Query

Recently I have been working with a client who has implemented Inventory Bill of Materials to Assemble materials having lot tracked components. It is important to fulfill orders with a single lot. So, quickly viewing component lot availability was a must.

While there is a Lot Inquiry window (Navigation: Inquiry >> Inventory >> Lots) the flexibility and information available in this window pales in comparison to what is possible using the following view coupled with SmartList Builder.

Lot Number Inquiry

CREATE View [dbo].[_Lots]

as

select LOTS.[ITEMNMBR] AS Item_Number,

LOTS.[LOCNCODE] AS Location_Code,

LOTS.[DATERECD] AS Date_Received,

LOTS.[LOTNUMBR] AS Lot_Number,

LOTS.[QTYRECVD] AS QTY_Received,

LOTS.[QTYSOLD] AS QTY_Sold,

LOTS.[ATYALLOC] AS QTY_Allocated,

cast(LOTS.UNITCOST as money) Unit_Cost,

LOTS.[VNDRNMBR] AS Vendor_Number,

isnull(VEND.VENDNAME,'') as Vendor_Name,

case when LOTS.LTNUMSLD = 1 then 'Yes' ELSE 'No' end AS 'Lot Number Sold',

case when LOTS.QTYTYPE = 1 then 'On Hand'

      when lots.QTYTYPE = 2 then 'Returned'

      when lots.QTYTYPE = 3 then 'In Use'

      when lots.QTYTYPE = 4 then 'In Service'

      when lots.QTYTYPE = 5 then 'Damaged'

      else 'ERROR'

      end

      AS QTY_Type,

LOTS.[BIN] AS Bin,

LOTS.[MFGDATE] AS Manufacture_Date,

LOTS.[EXPNDATE] AS Expiration_Date,

ITEMS.[ITEMDESC] AS Item_Description,

ITEMS.[ITMCLSCD] AS Item_Class_Code,

ITEMS.[LOTTYPE] AS Lot_Type,

(LOTS.[QTYRECVD]-LOTS.[QTYSOLD]) AS QTY_ON_HAND

from IV00300 as LOTS

inner join IV00101 as items on LOTS.ITEMNMBR = ITEMS.ITEMNMBR

left join PM00200 as VEND on LOTS.VNDRNMBR = VEND.VENDORID

GO

Grant Select on _Lots to DYNGRP

Engineering Change Request View SQL Script

Since Dynamics GP Manufacturing originally began its life as a third party product, some of the core features supporting Manufacturing modules never made it into the product. For instance, Quality Assurance, Engineering Change Management, Routings, Forecasting and Job Costing do not have any out-of-the-box SmartLists.

I typically wind up using SQL Views, SmartList Builder and now SmartList Designer to create custom built SmartLists for these modules. In this post, I have included a SQL Script, which can be used to create a SQL View as the foundation for SmartLists or SQL Server Reporting Services (SSRS) Reports for Engineering Change Requests. Here it is:

Create VIEW Engineering_Change_Request

AS

select

DATEENTERED_I Date_of_Request,

CASE WHEN CUST.CUSTNMBR is not null then CUST.CUSTNAME

       Else  ''

End Customer_Name,

CASE WHEN CUST.CUSTNMBR is not null then CUST.CUSTNMBR

       ELSE ''

End Customer_ID,

ECMH.ENDDATE ECR_Complete_by_Date,

ECMH.ITEMNMBR Part_Number,

ECMH.ITEMDESC Part_Description,

'' Old_Rev,

ECMH.REVISIONLEVEL_I New_Rev,

ECMH.ECM_Short_Description ECR_Description,

DoEC.text1 BOM_Changes,

RFC.text2 Reason_for_Change,

NCO.text3 Notify_Customer,

EI.text4 Expected_Impact,

ECML.DISPOSITIONNOTES_I WIP_Instructions

from EC010031 ECMH

inner join EC050031 ECML on ECMH.ECNumber = ECML.ECNumber

left join RM00101 CUST on ECMH.CUSTNMBR = CUST.CUSTNMBR

left join EC010100 DoEC on ECMH.ECNumber = DoEC.ECNumber

left join EC010200 RFC on ECMH.ECNumber = RFC.ECNumber

left join EC010300 NCO on ECMH.ECNumber = NCO.ECNumber

left join EC010400 EI on ECMH.ECNumber = EI.ECNumber

GO

Grant Select on Engineering_Change_Request to DYNGRP  

Use Statistical Accounts to calculate meaningful Key Performance Indicators in Dynamics GP

It is not uncommon during financial statement design to create reports intended to monitor Key Performance Indicators. Dynamics GP's statistical account feature provides functionality, which expands this capability beyond simple financial ratios.

Statistical accounts (A.K.A. Unit Accounts) allow organizations to keep track of non-financial data in the General Ledger, like square footage, head count, machine hours, labor hours, quantities produced, inspected, rejected, sold, returned and/or serviced in summary or detail. 

Statistical accounts can be posted to without the need to balance the transaction, increasing or decreasing the balance of the account as necessary. These account balances can then be pulled into financial reports via FRx or Management Reporter and used in calculations to compute things like sales price and cost of goods sold per unit, cost of labor per hour, revenue per service call, etc.

In order to use this feature, Statistical Accounts must be created and maintained. Statistical Accounts are maintained in Financial > Cards > Financial > Unit Account

Unit Account setup is similar to Financial Account Setup; however, there are some additional settings available in this window.

Account Number is a required field, and can make use of the sub-account structure to track statistics at a departmental, divisional or product line level. 

Description is also a required field, so some value must be entered in this field. 

All other fields are optional. 

The Alias field can provide a shortcut to speed account entry.

Decimal Places allow for the configuration of from 0 to 2 decimal places for tracking statistical data.

Series allows for the selection of modules, in addition to the General Ledger, which will allow the entry of statistical data for this account. Options are Sales and Purchasing. It is typical for statistical information to be collected and imported or entered monthly.

There are also a pair of check boxes, one of which is only present in more recent releases of Dynamics GP (2013 & 2015).

The Inactive check box does precisely what it appears to do. Checking this box makes this account inactive, which prevents it from being used, but does not remove it from the system. One of the options in the Year-End close can automate the removal of inactive accounts, so be careful there.

The Clear Balance During Year-End Close check box was added in version 2013, and also does precisely what it appears to do. When this box is checked, the balance at Year-End Close is not treated like a typical Balance Sheet Account. Typically, Balance Sheet Accounts are zeroed and their balances are brought forward into the next year as beginning balances. This is not optimal when statistical/unit accounts are being used to track units of production or sales, where it is best if the beginning balance for the year be zero.

All other fields are used to view information about the account and cannot be edited in this window.

Once accounts are properly configured, statistical information can be tracked by posting entries to the General Ledger, which use posting date to assign transaction information to the appropriate fiscal period(s).

I have seen statistical accounts used to track numerous relevant statistics at many organizations (miles, gallons, trips, calls, etc.) The use of Unit Accounts in Dynamics GP is limited only by your imagination.

How to determine the first fiscal year in a Dynamics GP Company in SQL

For Dynamics GP users who are familiar with the Fiscal Period setup window, which exists at the company level, it should come as no surprise, rapidly identifying the First year an entity was established can be a time-consuming endeavor. 

To do this manually, one would need to go to Tools > Setup > Company > Fiscal Periods, and select the Year from the drop down list, in order to see the oldest year in each company in Dynamics GP. For organizations with numerous entities, especially those who have performed such an exercise, they know manually performing this task is daunting.

Users have to keep track of where they are in the process, make a list, validate the list, etc. Alternatively, the following query has proven useful in identifying the first year in Fiscal Period setup, in each of the organization's entities.

select 'Fabrikam' Company_Name, MIN(YEAR1) First_Year from TWO..sy40101

UNION 

select 'Company 1' Company_Name, MIN(YEAR1) First_Year from CO1..sy40101

UNION

select 'Company 2' Company_Name, MIN(YEAR1) First_Year from CO2..sy40101

It is important to note, the Company Name must be manually updated in the query above, and the Entity/Database ID must also be edited.

An Ounce of Prevention; Dynamics GP Year-End Close Routine and Misclassified Accounts

Every year, Microsoft, Numerous Bloggers and SBS Group Central California, the place I call home, dust off, and revise our Year-End Closing procedures for Dynamics GP and distribute them far and wide. The purpose is obvious, this procedure happens once a year and things sometimes change, so guidance is a good idea.

Even so, we ultimately see forum entries and receive technical support calls asking what to do if an account, or worse yet, some accounts were misclassified at the time of the Year-End Closing. Let me tell you, if we aren't talking about restoring a back up, the fix for this problem requires some finesse.

The root problem is, typically, at some time during the year, a user or users have quickly created a new expense account, or again, worse yet many expense accounts to post to, and while doing so, they accepted the default Posting Type. Dynamics GP's default Posting Type is Balance Sheet; of course, Expense Accounts should be classified as PNL or Profit and Loss accounts. 

When Dynamics GP Year-End closing procedure is initiated, Balance Sheet Accounts are zeroed and their Year-End Balances are brought forward as the beginning balances for the next year. Profit and Loss accounts are also zeroed, but their balances are cleared to Retained Earnings. When an account is misclassified it is handled incorrectly by Dynamics GP throwing off both the Balance Sheet and Profit and Loss.

There is a preventative measure we implement for our clients, which can prevent this problem from happening. In short, we create SmartLists with a reminder, which let users know when accounts have been misclassified well prior to the Year-End Closing Routine being run. Here is a how-to article on this process.

First, browse to SmartLists > Financial > Accounts and select the default (*) SmartList Favorite. You'll want to add the Main Account Segment to this view, so click on the Columns Button, select Add, then Find Next: Main Account Segment and click Ok. See image one below.

Note: as an aside, it is a really good idea to add the Main Account Segment to Account related SmartLists, as selecting a range of accounts, which include sub-account segments like company, department of division is impossible. Additionally, other segments, like department and division can be added to restrict results for these criteria as well.

Image 1 - Add Main Account Segment

Optional: You may find it useful to move the Main Account Segment to the first position/column in your SmartList. This can be accomplished by Selecting the Main Account Segment in the Change Column Display window, and clicking on the top arrow to the right of the column list. This will promote the Main Account Segment to the first position/column. See image two

Image 2 - Make Main Account Segment First Column in SmartList

Once you have added the Main Segment, you can select the Search button and enter the following criteria:

Main Account Segment > Is Greater Than > 3999

AND

Posting Type > Is Equal To > Balance Sheet

IMPORTANT: This assumes 3999 is your highest Balance Sheet Account. This may not be the case! It is uncommon, but not unheard of for the 3XXX series of accounts to be included in the Profit and Loss category (sometimes as revenue accounts). It is also possible you use more than 4 characters in your main account segment. So, adapt this criteria to your situation!!! Additionally, it is possible to do the reverse of this criteria; below 4000 and Profit and Lost, just to be thorough...

See Image Three below

Image 3 - Search Criteria for Misclassified Accounts

You will see a list of accounts, which are suspect. It is possible, there are accounts in this range which are Balance Sheet accounts (as account numbers are discretionary). So now the real work begins. It is up to the Finance Team to determine which of these accounts truly belong in this range. Once they make the determination, all other accounts should be reclassified. At this point, a tally of the results should be done to determine the number of Balance Sheet accounts are within this range - this will be important when you set your reminder, and when you give instructions to folks who will address the problem of misclassified accounts.

The final step in this process is to save this SmartList as a Favorite, which is accomplished by clicking on the Favorite Button and entering in a unique name for the Favorite. We typically call these Favorites _Misclassified PNL Accounts and _Misclassified Balance Sheet Accounts. Using the underscore brings these lists to the top of the SmartList Favorites list. See image four below

Image 4 - Save Favorite with Reminder

RECOMMENDATION:  For extra credit, it is wise to create these Favorites with Reminder. Doing so will tickle people when there are accounts that meet this criteria. It is possible and recommended to set the reminder at a number greater than the legitimate misclassified accounts, so the reminder only activates when new accounts meet this criteria. This will prevent the reminder from becoming "white noise" and consequently being ignored by users. See image five below

Image 5 - Set the Number of Records Greater than Legitimate Accounts in this range

Now you have your SmartList favorite, and reminder set up, when a new account is created, which meets your criteria, all you need to do is double-click on the problem account, select the correct Posting Type and click save. 

Remember, an ounce of prevention is worth a pound of cure. Once your reminder is set, when the number of valid accounts is exceeded, users will see there are misclassified accounts, which need to be addressed.  See image six below.

Image 6 - Reminder on Home Page

Dynamics GP Stuck Process and Process Monitor

From time to time, I will receive a call from a customer who has posted a transaction, and is deeply concerned that nothing appears to be happening. More often than not, the problem turns out to be a report sent to screen, which was minimized and is blocking further processing.

It is not uncommon for a user who is about to post a transaction in Dynamics GP to print an edit list of the transaction to screen. If the user does not close the window containing the report, all future reports and processes will be held, until it is closed.

Imagine if you will, a user in Finance prints an edit list for a General Ledger transaction in preparation for posting.

Now the same user receives a phone call, and has to open another Dynamics GP window or External Application to answer a question or two, or three, etc. etc. etc. Several minutes pass, and the user returns to Dynamics GP to post the transaction.

Upon posting, nothing appears to happen. The Posting Journal report does not open. The user, being a savvy Dynamics GP user immediately opens the Process Monitor to view the status of the Batch.

The report open on the screen does not show in the Process Monitor window because technically, it has completed processing (technically). This is the first sign an open report printed to screen is the culprit -- the General Posting Journal is the next process in the cue. At this point the user should be looking at the open windows in Dynamics GP in order to find the window causing the hang up.

Once the window is identified, it must be closed. Immediately after the window closed, the processes being held up will continue until completion. In this case the General Posting Journal is printed and the batch posting is completed.

Once the processes complete, the Process Monitor window will be empty, and normal processing in Dynamics GP can be continued.

This type of problem is an infrequent occurrence and has an easy diagnosis and solution; therefore it has not been a priority addressed in recent releases. I for one would like to see the problem rectified, but understand the cascading problem it represents.

A report being run to screen prevents other reports from printing. A posting report being printed is a requirement of the posting process being completed. You see where this is going, right...

My humble suggest would be to enable Dynamics GP to render multiple reports to screen, instead of just one.

Want Free Technical Support for Microsoft Dynamics Products, Join the Dynamics Community Online

Microsoft maintains a number of support options for the Dynamics family of products; CRM, AX, NAV, GP and SL (Customer Relationship Management, Axapta, Navision, Great Plains and Solomon respectively).

Most enhancement plans come bundled with Microsoft Technical Support incidents. For customers current on their enhancement plans there is a searchable Knowledge Base (KB), which is an excellent source of support and how-to information.

There are more blogs, you-tube channels and online forums than can easily be counted, most offering their services free of charge, as-is, no warranties. There are excellent User Groups, and lest we forget the stalwart Partner and Independent Software Vendor channels.

If you are the type of person who starts troubleshooting with a healthy dose of Internet search engine, then you've probably already discovered the Dynamics community sites.

If you have stopped at merely reading content and implementing recommendations, then you are missing out on a resource of limitless potential. 

Every day, some of the brightest minds in the Dynamics community answer questions posed to them by Dynamics customers and partners who pay nothing for the service. These questions range wildly from the simple to the complex, and typically result in numerous suggestions/options to help resolve the issue at hand in a timely fashion.

If you haven't joined the Community, please consider doing so. You can find out more, and sign up at the following link:

https://community.dynamics.com/

Dynamics GP Receivables Aging is Too BIG, long, many pages...

I was recently working with a new customer on an upgrade. As part of the upgrade process, I have clients print various reports for comparison (before and after) the upgrade process. Typically I advise clients to print these reports to PDF, or similar file format. Some print outs can be quite large.

In this instance, the Receivables Aging report was more than 1500 plus pages long. So, I asked, "what's up with that?" Turns out, their previous partner had told them, "that was just how GP worked." Rarely do the words , "that's just wrong"  escape my mouth when criticizing my predecessors. I usually say things like that's not the approach I typically recommend, or something similar, acknowledging the possibility users were presented alternatives and may have selected the alternative of their own accord.

In this case, it is safe to say, the partner providing this information was wrong. If you have assumed the Receivables Aging report perpetually grows, or have been told this by someone, allow me to disabuse you of this notion.  There is a mechanism in GP, which can be used to shrink the aging by moving fully applied payments to history.

This tool, which can be misunderstood by users and consultants, is called Paid Transaction Removal...  Sales > Routines > Paid Transaction Removal

I believe the thing that puts people off about this feature is the use of the word Removal. In reality the routine moves transactions to history, which occurred before the specified cutoff dates. 

This process, when run, will “set in stone” cash applications for past documents, and prevent NSF transactions from being processed on payments within the Cut Off date. My recommendation to clients is leave enough cushion within the cutoff date to allow normal processing of NSF transactions, and changes in Cash Application.  

Some clients, do this at the end of every month (i.e. publicly traded companies), and others leave a full year open by processing at year end with a cutoff date of the year before (i.e. 12/31/2013 when closing 2014).  This makes a lot of sense, because closing a year, actually hard closes the prior year, and adjustments can be made to the last closed year in GP. 

As with any major update to the database, you should have a backup handy, should things not go exactly to plan.  It is also possible/recommended to update your test database, so you can run this process there to get an idea of the impact.  

When this process was run by a client who had not done it, ever, it took some time to run, so if you are in a similar situation, I would recommend you run this process when you have exclusive access to GP, and no one is going to need to use it for the duration of this process.

Foundation Query for Historical Fixed Asset Depreciation Reporting in SSRS or SLB

Prior to version 2013 of Dynamics GP there was not Historical Depreciation Reporting.  Here is a query, which can be used as a foundation for reporting on depreciation using SmartList Builder or SQL Server Reporting Services (SSRS)

DECLARE @Year INT, @StartPeriod TINYINT, @EndPeriod TINYINT

Set @Year = '2015' --Sets the Year of the Report

Set @StartPeriod = '1' --Sets the Starting Period of the Report

Set @EndPeriod = '12' --Sets the Ending Period of the Report

select

FAM.ASSETID Asset_ID,

FAM.ASSETIDSUF Asset_Suffix,

FAM.ASSETDESC Asset_Description,

GLT.FAPERIOD 'Period',

GLT.FAYEAR 'Year',

--GLT.FA_Doc_Number, --Removes this column, not in versions prior to 2013

convert(char(10),GLT.DEPRFROMDATE,101) Dep_From_Date,

convert(char(10),GLT.DEPRTODATE,101) Dep_To_Date,

GLD.ACTNUMST Account,

GLM.ACTDESCR Acct_Description,

cast(GLT.AMOUNT as money) Amount

from FA00902 GLT

left join FA00100 FAM on GLT.ASSETINDEX = FAM.ASSETINDEX

left join GL00100 GLM on GLT.GLINTACCTINDX = GLM.ACTINDX

left join GL00105 GLD on GLT.GLINTACCTINDX = GLD.ACTINDX

where FAYEAR = @Year

and FAPERIOD between @StartPeriod and @EndPeriod

Order by GLT.FAPERIOD,FAM.ASSETID,FAM.ASSETIDSUF,GLD.ACTNUMST

CASE Statement for SOPTYPE in Dynamics GP Sales Tables

I have amassed a number of useful CASE statements, which can be incorporated into SQL queries run against Dynamics GP. When Querying the SOP Type Field in Dynamics GP Sales Open [SOP10100].[SOPTYPE] or History [SOP30200].[SOPTYPE] tables: use the following case statement to return text versions of the default SOPTYPE in Dynamics GP:

select

CASE SOPTYPE

      WHEN 1 THEN 'Quote'

      WHEN 2 THEN 'Order'

      WHEN 3 THEN 'Invoice'

      WHEN 4 THEN 'Return'

      WHEN 5 THEN 'Back Order'

      WHEN 6 THEN 'Fulfillment Order'

      ELSE 'ERROR'

END SOPTYPE_TEXT,

CASE Statement for Manufacturing Order Status in Dynamics GP (MANUFACTUREORDERST_I)

I have amassed a number of useful CASE statements, which can be incorporated into SQL queries run against Dynamics GP. When Querying the Manufacturing Order Status Field in Dynamics GP (MANUFACTUREORDERST_I): use the following case statement to return text versions of the default statuses in Dynamics GP:

case WO010032.MANUFACTUREORDERST_I

      when 0 then 'invalid entry'

      when 1 then 'Quote/Estimate'

      when 2 then 'Open'

      when 3 then 'Released'

      when 4 then 'Hold'

      when 5 then 'Canceled'

      when 6 then 'Complete'

      when 7 then 'Partially Received'

      when 8 then 'Closed'

      else 'ERROR'

End MO_Status

Here is a list of the Dynamics GP Tables containing MANUFACTUREORDERST_I

ISSP0201 – Manufacturing Series Sales Order Preferences

MOP10213 – MOP Order Activity

MOP1070 – MOP Edit MO Status Header

MOP1071 – MOP Edit MO Status Line

MOP3000 – MOP Variances

MOPGetMOVariances

MOPV1100 - MFGMOList

MOPV3001

MPO10001 – MRP CRP Scheduled Orders

mvarMOStartEndQtys

PK010033 – MOP Item Master

SOPS113B – MOP Sys Preferences

WO010032 – Manufacture Order Master

WO010213 – Manufacture Order History

CASE Statement for Inventory Item Master Item Types [IV00101].[ItemType]

I have amassed a number of useful CASE statements, which can be incorporated into SQL queries run against Dynamics GP. When Querying the Item Master Table in Dynamics GP (IV00101), use the following case statement to return text versions of the default Item Type field (ItemType):

case [IV00101].[ItemType]

      when 1 then 'Inventory'

      when 2 then 'Discontinued'

      when 3 then 'Kit'

      when 4 then 'Misc Charges'

      when 5 then 'Services'

      when 6 then 'Flat Fee'

      else 'ERROR'

end   ItemTypeText

Inventory Bill of Materials versus Manufacturing Bill of Materials in Dynamics GP

Inventory Bill of Materials vs Mfg Bill of Materials

Mariano Gomez salvaged this post from the Microsoft Dynamics GP Partner Forum comparing the features in Inventory Bill of Materials versus those in Manufacturing Bill of Materials. Props go out to Microsoft's Jim Shauer for a detailed explanation. I have made some changes to the document for clarification of murky matters.

The Dynamics GP Inventory Bill of Materials module works closely with the Inventory sub-ledger. Users can define bills and assemble the bills in this module. Bills and components on bills have effectivity and obsolence dates.  Components can be inventory, service and flat fee items, and costs can be per unit or per assembly transaction (i.e. setup costs).

The Dynamics GP Inventory Bill of Materials module works best for companies with a simple assembly/production processes where finished good production is recorded after the fact. Assembly transactions can be entered, released and then posted, and quantities can be changed; however, there is a vast difference between Inventory Bills and Manufacturing Bill.

Inventory bills do not use the same tables as manufacturing bills and do not have a packaged migration path to advanced features provided by the broader set of Manufacturing modules, like Material Requirements Planning, Master Production Scheduling, Engineering Change Management, Quality Assurance, etc.

The Manufacturing Bill of Materials module stores a list of components and sub assemblies, required to assemble a finished good. Users deploy this module together with Manufacturing Order Processing to perform assembly transactions. It also requires the use of the Inventory sub-ledger. Every bill must also have a corresponding Routing. These modules provide the ability to track labor costs, machine and overhead. Below is a detailed list of features and limitations of the two modules.

Dynamics GP Inventory Bill of Materials features:

Enter a design quantity on the Bill Of Materials.

Design Quantity in conjunction with the scrap % calculates Standard quantity

Create a link to associate component lot or serial numbers with finished goods

Keep historical information for Bill of Materials (Effective and Obsolete Dates)

Copy components from one Bill of Materials to another

Use substitute or additional components during assembly

Override quantity shortages during assembly transactions

User defined fields for the assembly document

Visual indicators for Serial\Lot tracked items and overrides

Dynamics GP Inventory Bill of Materials Limitations:

Does not use Routings for assignment of Labor, or Machine Time

Does not Track Work in Progress (WIP)

Assemblies BOM types are limited to sales inventory or kits (phantoms)

Lead times are not tracked

Quantities can only be entered in Base Unit of Measure

No Integration with Sales Order Processing or Purchase Order Processing

No Material Requirements Planning

No Data Collection Support (time entry)

Manufacturing Bill Of Materials features:

Tracks Work in Progress (WIP) for Material, Labor and Machine time

Enter fixed or variable quantities on the Bill of Materials

Create a link from components to a particular routing sequence

Keep a revision level of all changes made on a Bill of Materials

Maintain multiple Bill of Materials types (Categories)

Manufacturing BOMs are production BOMs for non-configurable items

Engineering BOMs are used Engineering Change Management

Configured BOMs are production BOMs for configured items

Super BOMs contain the configuration options for configured items

Archived BOMs are used to maintain unlimited historical BOMs

BOM Copy (easy creation of production, engineering or archived BOMs)

Components have an effective in date and effective out date

Label a component as an alternate part

Lead Times for components can be calculated

Quantities can be entered using the U of M schedule (not just BASE U of M)

Choose to have a lot tracked item pull the quantity from a single lot

Multiple User Defined Fields for components

Visual indicators for items (Alternates, Serial/Lot tracked, or Phantom)

Automatically update BOM changes using the Mass Update

Mark items as Floor Stock; component value posts to an expense account

Enter Reference Designators Position numbers