Author: admin

MFG PowerPack Release 2019-05-06

V12.2.146 / 14.2.93 / 16.2.59 / 18.2.20 2-MAY-2019
* Item Copy: (1) Routing Map now has options for how it creates the Routing Name. Under the “Routing” option, click the image next to the “Default Routing Name” setting to change the default between Destination Item Number and Source Routing Name (2) Under “Item Currency Maintenance” added a new option to zero List Price (3) The installer will now add a stored procedure to the database (wspItemCopyPost) that will run after all other copying tasks. The stored procedure can be edited to include any custom ‘post copying’ updates that are needed.

NOTE: The Minor Version number increments with this release, so the full installation routine needs to be run to create new SQL objects.

Zero List Price appears below the Item Currency Maintenance option:

The Routing Name Default setting appears under the Routing option:

Click on the image to the left of “Default Routing Name” to toggle between the options.

The new stored procedure (wspItemCopyPost)  has no executable code–it is an empty stored procedure that is called at the end of the Item Copy routine.  The stored procedure can be edited to add any additional updates you need to run.

MFG PowerPack Release 2019-04-09

V12.1.145 / 14.1.92 / 16.1.58 / 18.1.19
* Item Copy: (1) the window now remembers the “Zero Standard Cost” setting rather than defaulting to enabled. “Zero Standard Cost” setting has been moved off the header section of the window and is in now under “Item Maintenance” (2) Performance improvements, (3) Under “Item Price List Maintenance” added a new option to zero the price list after copying it. (4) Routing Map now creates a default mapping for the primary routing using the Destination Item Number as the Routine Name if no mapping is provided, (5) The Routing Map now clears after copying an item
* MO Split: Added routine to check that default separator character gets set when the MO Split Setup window is never opened.

Consulting ToolKit Release 2019-04-09

V12.1.24 / 14.1.18 / 16.1.14 / 18.1.6 Changes
* Updated Registration Key module to address issue that caused the product to not recognize the registration key (#20191132)
* Virtual Triggers: Added a visual indicator to the Databases pop-out to show when databases have not been marked (red) versus when at least one database is selected (green)

 

The Virtual Triggers Setup window now highlights the DATABASES pop-out to help remind you to select databases.  When no Trigger is displayed the tab is white:

 

When a Trigger is displayed that has no databases selected, the tab is red:

 

When a Trigger is displayed that has at least one database selected, the tab is green:

 

 

MFG PowerPack Release 2019-03-27

V12.1.144 / 14.1.91 / 16.1.57 / 18.1.18
* Addressed issue #20190930 (Invalid object name mops0100). Error caused by “TWK: Edit MO Status Allocation Override” which wasn’t checking if GP Manufacturing was installed.
* Setup Window: (1) Added ability to display both Registered and Unregistered modules in the Suite. (2) Window now checks if MFG and/or Field Service are installed and only displays Modules and Tweaks that require those modules if they are installed.
* Capable To Promise (CTP): Added additional menu on SOP Inquiry to open the CTP window.
* Where Used Inquiry: addressed issue when zooming to a new Inventory BOM when a current BOM is displayed and it has changes.

 

The MFG PowerPack Setup window now has radio buttons to display Registered and Unregistered modules.The Unregistered Modules view shows all modules contained in the Suite that are not available with the current Registration Key.MFG PowerPack contains many modules that required the Dynamics GP Manufacturing module and/or the Field Service module.  The Setup window will not only display MFG PowerPack modules that can be used (i.e. it will not show a module if it requires Manufacturing and the Manufacturing module is not installed).

 

GP PowerPack Release 2019-03-26

V12.1.133 / 14.1.76 / 16.1.44 / 18.1.16
* Setup window: (1) moved Alerts, Login Monitor, and System Access Lock from the GoTo button into main window, (2) The main window now has an option to view both registered and unregistered modules

 

The GP PowerPack Setup window has new radio buttons to show Registered and Unregistered modules.

The Unregistered view shows all modules in GP PowerPack that are NOT registered.  Additionally, the setup windows for several modules previously appeared only on the GoTo button and not in the main list of Registered Modules.  These include: Alerts, Login Monitor, and System Access Lock.  This was a frequent source of confusion because if you were registered only for Alerts, the main setup window was blank because Alerts was on the GoTo button.  Now these three modules will appear in the main GP PowerPack list of registered modules.

Blanket PO Release 2019-03-24

V12.1.35 / 14.1.24 / 16.1.10 / 18.1.3 Changes 24-MAR-2019
* NEW: Planned Release Wizard. This utility will calculate and create a number of releases, such as creating a release on the first Monday of every month. It can create planned releases using a fixed quantity until the Control Quantity is met, or, it can divide the Control Quantity evenly over releases in a specified time frame.
* NEW: Auto-Firm Releases Utility. This utility will automatically create Firmed Releases when the Required Date meets selection criteria. Releases can be created before the Required Date by using the Vendor Lead Time and/or Purchasing Lead Time.

The new Release Wizard window is shown below.

The Release Wizard is accessed from the PO Release Entry window.  In the example above, it calculated Planned Releases for each Monday between 4/12/2017 and 6/12/2017.  When the desired scheduled is achieved, the Release Wizard can create a Planned Release for each Date/Quantity, adding them to the PO Release Entry window.

MFG Import Release 2019-03-21

V12.1.43 / 14.1.26 / 16.1.14 / 18.1.7
* Changes to log-out routines to prevent resource conflict with Rockton Security Auditor
* BOM Import: if the Component Quantity column in the import spreadsheet was formatted as Text, the import routine converted the string to a currency value using the dexterity function called value(). This fuction interprets any non-numeric character as a “stop” value, so 1,255.55 is returned as “1”. We replaced all use of the value() function with our own routine that correctly parses a complete number from a string.
* Routing Import: the change described above for BOM Import was also applied to the Routing Import utility.

EZImport Release 2019-03-11

V12.1.12 / 14.1.5 / 16.1.3 / 18.1.1 Changes
* First GP2018 Release
* Added Query window: a new GoTo button on the EZ Import Inquiry windows provides direct access to query the EZ Import tables using the new Query window. For example, from the EZ Import Sales Inquiry window, select GoTo >> View Sales Lines, and the query window will show all of the data in the Sales Lines table for the selected Sales Order. The Query window provides a quick way to see all of the “extra” data assocated with a record that is not visible on the Inquiry windows.

GP PowerPack Release 2019-02-14

V12.1.130 / 14.1.73 / 16.1.41 / 18.1.13 Changes
* UPDATE: POP-Tweak: Purchasing Distributions Override–previously contained “PURCH Distributions Override” and “PURCH Distributions By Line”. In this release the second is split out into a separate Tweak (POP-Tweak: Purchasing Distributions By Line). When Purchasing Distributions By Line creates the new distributions, it previously populated the GL Reference with the PO Line’s Item Number. A new setup option allows choosing to fill the Reference field with (1) Item Number, (2) Item Description, (3) Vendor Item Number, and (4) Vendor Item Description. If you currently have Purchasing Distributions Override, the new Tweak “Purchasing Distributions By Line” will be enabled automatically.

CompleteCount Release 2019-02-10

V12.1.38 / 14.1.28 / 16.1.21 / 18.1.11 Changes
* Tag Submit Routing – Lot Reconciliation: a new routine “allocates” the total counted quantity of a Lot Number across the available receipts of a Lot Number (assuming there are multiple receipts of the same Lot Number). Previously the module attempted to “consolidate” split receipts by putting all of the counted quantity onto one lot receipt record and zeroing the others. The new routine eliminates the potential to create a cost variance even through the total count matches the captured quantity. It handles the valuation methods as follows:
** LIFO: it counts forward from oldest receipt to newest so any shortages come out of the most recent recent (the LIFO receipt)
** FIFO: it counts backwards from newest receipt to oldest so any shortages come out of the oldest receipt (the FIFO receipt)
** AVG is treated like FIFO
* Tag Submit Routine now uses ‘User Date’ instead of system date.
* Tag Submit window UI update

MFG PowerPack Release 2019-02-07

V12.1.143 / 14.1.90 / 16.1.56 / 18.1.17
* BOM History Inquiry: addressed issue that prevent setup options from being recognized for BOM History Inquiry.
* MO Split: added a NEW setup option to choose what the Suffix Separator is. Previously the module was hard-coded to use a DASH (i.e. MO00123-001). If MOSplit is already in use, installing this build will detect that and automatically update MO Split Setup to use a DASH as the seprator. Setup will allow using any single character as the separator. This change also addresses a conflict between MOSplit and WilloWare’s MO Generator “Create Child MOs” utility, which also uses a DASH.

MOGenerator Release 2019-01-10

V12.1.90 / 14.1.65 / 16.1.43 / 18.1.10
* MO Receipt Integration: addressed issue in the 7-JAN-2019 build that caused the Build Picklist routine to fail.
* MOGen-Create Child MOs: addressed issue that could cause the routine to run a second time on a Sales Order.

ETO Release 2019-01-18

V12.1.31 / 14.1.14 / 16.1.7 / 18.1.3
* Add/Edit Component: addressed issue that caused error “This BOM Line is already in use” when tabbing out of the BOM Line field.
* ME: Added visual indicator to show when one or more Est Qtys have been marked as Accepted
* ME: Added GoTo option “Create MO”. The ME window can now create a Manufacturing Order for the Item on an Accepted status estimate. If the Estimate is linked to a Sales Line, it will link the MO to the Sales Line.
* ME Notes Windows: added text to the Save and Delete buttons

MFG PowerPack Release 2018-12-05

V12.1.142 / 14.1.89 / 16.1.55 / 18.1.16
* Capable to Promise (CTP): Added integration to SOP Entry. CTP can pull in a selected item, or all items, from a Sales Transaction.
* MO Split: Updated the routine that creates the MOP-SOP record for each split so that it repeats attempting to create the MOP-SOP record until it can confirm the record exists. This was done to address a rare, sporadic issue at a high volume site where a single MOP-SOP (i.e. 1 out of 20 splits) would not get recorded into the MOP-SOP Links table.
* NEW: BOM History Inquiry: This is a “most recently used” list for GP Manufacturing BOM Entry and BOM Inquiry. Also, it adds a hot key (CTRL + Z) to zoom to a selected subassembly. Use CTRL+Z instead of the “Select Item” button on the BOM windows. “Select Item” only works when zooming to a subassembly that has the same BOM Type & BOM Name as the Parent Item (i.e. if the Parent is a MFG BOM and the child is an ENG BOM, it will not zoom to the ENG BOM). The CTRL+Z zoom will load any selected subassembly and as BOMs are viewed they are recorded in the new BOM History window. To return to any previously viewed BOM, simply double-click on it in the BOM History window.

MFG PowerPack BOM History Inquiry

Price $1200 Demo Manual

 

The BOM History Inquiry window is a “Most Recently Viewed” list for the BOM Entry and BOM View windows.  It provides quick access to a previously viewed BOM, making it easy to drill down into lower level assemblies and then quickly return to the top level.

It also adds a universal Zoom feature.  You can drill into any subassembly by clicking on it in the treeview and pressing CTRL+Z.  This will work with any BOM, such as MFG BOM or ENG BOM and also Configured and Archived BOMs.

Quickly retrieve a previously viewed BOM by double-clicking on it in the BOM History window, or click BOM Inquiry to open the BOM in the Inquiry window.

BOM History Inquiry works with both the BOM Entry and BOM Inquiry windows.

BOM History Inquiry also adds a hot-key (CTRL+Z) to zoom to ANY selected subassembly.  This addresses an issue with the “Select Item” button where it retains the BOM Type and BOM Name from the Parent Item when attempting to zoom to the Component, so that if a MFG BOM Parent contains a subassembly of another BOM Type (i.e. ENG, CONFIG, ARCH), the “Select Items” button will only zoom back to the MFG BOM of the subassembly.

MOGenerator Release 2019-01-10

V12.1.89 / 14.1.64 / 16.1.42 / 18.1.9 10-JAN-2019
* MOGen-MO Scheduler: Altered the restriction that prevents MOs from being rescheduled if they have MFG Component Transactions so that it allows Allocations.
* MOGen-Create Child MOs: Added check of Item Type so it only attempts to create MOs for “Sales Inventory” type items regardless of the SUBCAT_I setting in the Picklist table. This is check prevents the utility from attempting to process bad data when Picklists or BOMs have been imported into the SQL tables with invalid information.

ETO Release 2019-01-09

V12.1.30 / 14.1.13 / 16.1.6 / 18.1.2 Changes
* Cost Rollup: Changed the routine so it only pulls Component BOM Type = 6 (Mfg Est BOM) and treats subassemblies coming from GP Manufacturing as “buy” items and pulls their cost from Item Maintenance (#20185960). Previously it was incorrectly including other BOM Types (i.e. MFG, ENG, etc), attempting to recalculate the cost but arriving at $0 becuase the BOM for the item wasn’t located in the ETO module.
* Delete Estimation BOM: the previous build’s change to separate Child Windows into separate Forms causeD the Delete routine to fail without deleting anything.
* Add Component: Addressed issue that would allow entering and saving invalid BOM information for a Component.
* Copy BOM Utility: Routing Name can now be provided when copying a GP Manufacturing BOM.

MOGenerator Release 2019-01-07

V12.1.88 / 14.1.63 / 16.1.41 / 18.1.8
* MOGen-Create Child MOs: Addressed issue with new routine to process phantoms that caused the Reschedule MOs utility to not be able to traverse a series of related MOs (Parent MO–Child MOs).
* MO Receipt Integration: Addressed issue that caused the picklist creation to fail when importing components using the W7158MOPick table and the LNITMSEQ fields is greater than 32767 (#20186038).

CompleteCount Release 2019-01-04

V12.1.37 / 14.1.27 / 16.1.20 / 18.1.10 Changes 4-JAN-2019
* ExcelLink: (a) The Setup option “Require Starting Count Before Printing Tags” now applies to Exporting the count to Excel. If the option is NOT marked you will be able to select an unstarted count in the Excel Link window and export it to Excel.

MOGenerator Release 2018-12-28

V12.1.87 / 14.1.62 / 16.1.40 / 18.1.7
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). The module will still disable itself on a Client PC if it has an older Build.
* MOGen-Create Child MOs: The following information ONLY applies if you use Phantoms that are ARCH BOM or CONFIG BOM (i.e. “named” bills of material). We found an issue with how GP Manufacturing populates the picklist with the components of a Phantom where Named BOMs are involved. When adding the components of a Phantom to the Picklist (PK010033), Manufacturing correctly sets the BOMCat on each component but incorrectly sets the BOMName to the BOMName of the Phantom. This was causing the Create Child MOs utility to fail because it could not locate a valid BOM for subassemblies within a phantom. A separate routine has been added to the Create Child MOs utility that will navigate the parent BOM (rather than the picklist) looking for subassemblies that need to be created because the Picklist contains invalid keys to locate the BOM (#20185966).
* MOGen-Create Child MOs: A new setup option has been added to the MOGenerator Setup window to enable the “Create Child MOs” utility on the MO Entry window.

GP PowerPack Release 2018-12-20

V12.1.128 / 14.1.71 /16.1.39 / 18.1.11
* Eliminated use of a core dexterity function called Activity_GetBackgroundStatus because we found that when it was called to see if any processes were running in the background, it was also terminating all such processes. Normally the Timed Queue has several processes that check for a date change and check for reports to publish. The change affects:
— TWK-SYS: SmartList Favorite-Keep Open
— GPTalk

BlanketPO Release 2018-12-05

V12.1.34 / 14.1.23 / 16.1.9 / 18.1.2 Changes 5-DEC-2018
* Build for GP2018R2 compatibility
* Updated WW Internal Resources
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). The module will still disable itself on a Client PC if it has an older Build.

MFG PowerPack EMOS Query

Price $1200 Manual

EMOS Query is used to create and save queries that restrict the EMOS (Edit MO Status) scrolling window. For example, a query could select only MOs with Configured BOMs that include the Work Center SAW on the routing.  EMOS Query provides a higher level of filtering so you can quickly narrow down the Manufacturing Orders in EMOS window.

Graphical user interface, text, application Description automatically generated

EMOS Query works like a SmartList query, but you can add as many restriction criteria as needed.  The restriction query can use fields from any of these tables:

  • MOP Order Master (WO010032)
  • Item Master (IV00101)
  • Item Engineering (IVR10015)
  • Picklist (PK010033)
  • Working Routing (WR010130)

Graphical user interface, text, application Description automatically generated

You can also copy a list of MOs from another source, such as Excel, and paste them into the window to restrict Edit MO Status to a list of MOs.

LeanMFG Release 2018-12-03

V12.1.36 / 14.1.25 / 16.1.15 / 18.1.7
* Disassembly: Changed how the disassembly routine calculates output quantities for the original raw materials. Previously it calculated a ratio of the Qty To Disassemble divided by the Original Qty To Build from the MO Header. The the MO was for 10 and you disassemble 5 it would consume half of the raw materials. This calculation did not account for changing the Output Quantity (i.e. you planned to make 10 but only produced 9). Now the disassembly routine calculates the ratio using the Qty to Disassemble and the Output Quantity.
* Posting: adjusted rounding performed in the Outputs calculation to account the Functional Currency Decimal Places issue (see notes for previous release, and also //willoware.com/functional-currency-decimals/).
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). The module will still disable itself on a Client PC if it has an older Build.

SOP-RMA Link for Core Required Parts

DS1036

SOP-RMA Link for Core Required Parts

Problem Definition

ACME Co sells and services fire, sprinkler and security systems. Repair is an important part of the business. With some items, sale of a new part requires return of an old part (or “core”).

Return of the Cores is managed using the Field Service RMA. When a Salesperson creates a Sales Order for a “core required” part, they notify another employee who creates the RMA. Usually there are one or two lines on the order, but there can be over 20.

Manually creating the RMA is error prone. It is too easy for the salesperson to forget to have the RMA created, resulting in parts that do not get returned because there isn’t an RMA.

ACME Co would like to automatically create an RMA for “core required” parts.

Design Features

Overview

An enhancement will be created that automatically creates an RMA when the Salesperson is done with a Sales Order. The RMA will open automatically for the Salesperson to print the RMA Form, and, any subsequent changes to the Sales Order will be synced to the RMA without user intervention.

Setup

Navigation: Tools >> Setup >> Sales >> ACME Co Setup

Field Function
Unit Cost The Item must have a unit cost >= the amount specified. The amount can be $0.
Op Codes This is Item User Category #3. Items must have one of the specified Op Codes to be a “core return required” item.

This window is used to control the parameters used by the software that determine which Items required a core return.

The following logic is used to determine if an Item Number added to a Sales Order is a “core required” part.

  • It ends with -RC in the Item Number
  • It has a companion “spare” or “salvage” Item Number that can be found by swapping -RC for -S in the Item Number
  • It meets the additional criteria specified in the Setup window (i.e. it has a Unit Cost >= $250, and it has one of the Op Codes listed in the window).

SOP to RMA

There is no user interface for this feature.

As Items are added to an Order, if they meet the Core Required criteria (see Setup), they will be automatically added to an RMA. See Create RMA below.

When an Order is saved, and the Order is linked to an RMA, the user will be prompted: Do you want to view the RMA?

    • If they answer YES, the RMA will open in the RMA Entry/Update window

An Additional Menu item will be added to Sales Transaction Entry to access the linked RMA: Additional >> View RMA.

Additional Changes to Sales Transaction Entry:

  • Changes cannot be made to the Sales Order if the linked RMA is open in RMA Entry/Update
    • GP does not normally track when an RMA is open in the RMA Entry/Update window. The enhancement will add activity tracking on RMAs so that it can tell when a user has an RMA open.
    • To automatically fix an RMA that gets “stuck” in the activity table (such as the computer loses power when the RMA is open), the enhancement will automatically clear the Activity table for a User ID when the log-in to GP.
  • Changes made to the Order automatically update the RMA
    • Adding an Item to the Order adds it to the RMA
    • Removing an Item from the Order removes it from the RMA. If there are no Items on the Order, the RMA is deleted.
    • Changing a Quantity on the Order updates the Quantity on the RMA
    • Changes to the Customer information (Address ID, address info, etc) do NOT update the RMA once it has been created. When the first Core Required item is added to an Order, that will cause the RMA to be created. At that point the Customer information is retrieved and set on the RMA.
  • An Order cannot be Voided or Deleted until the linked RMA is Deleted/Voided
    • The user will be warned of the condition, and the linked RMA will open automatically.
    • In the event the RMA cannot be deleted or voided, the link can still be broken by removing the Order Number from the Origin Document field.
  • A Sales Batch cannot be deleted if one or more documents in the Batch is linked to an RMA
    • The user will be warned that links exist, however no further assistance will be provided in locating the document. The user will need to manually locate the linked RMAs and delete/void the RMAs.
  • When an Order is transferred to Invoice, the “Invoice” field on the RMA Additional Fields will be updated
    • If an Order is partially transferred, each time it is transferred to Invoice it will update the RMA with the most recent Invoice Number.

Create RMA

As Core Required items are added to an Order, their corresponding “salvage” item will be added to an RMA. The RMA will be created as described below.

Header Field Source
RMA Number Next RMA Number generated by Service
RMA Type Hard-coded, always CORE-REC
RMA Status Hard-coded, always NEW
RMA Reason Code Hard-coded, always COR
Customer ID Customer from Sales Order
Address ID Ship To Address ID from the Sales Order. Address fields from the Sales Ship To Address Entry window. NOTE: this information is retrieved from the Order when the RMA is field created. Subsequent changes to the Address Info on the Sales Order do NOT synchronize to the RMA.
Origin None
Origin Document SOP Order Number
Office ID Hard-coded, always LOU
Site ID Return Location Code from the RMA Type. Return To address fields from the Site Maintenance window for the Return Location Code.
Bill To Customer ID Customer ID from Sales Order, unless a different Customer ID is specified in the SVC Customer Extension window.
Bill To Address ID Bill To Address ID from the Customer Master
Currency ID Multi-currency is NOT used
Customer PO Customer PO from Sales Order
RMA Additional Fields Source
Text #1 (Order Number) SOP Order Number
Text #2 (Invoice) When the Order is transferred to Invoice, the SOP Invoice Number will be added to this field.
Text #3 (Payment Terms) SOP Payment Terms ID
Text #5 (Salesperson) SOP Salesperson ID
Date/Time Entered System Date/Time when the RMA is auto-created (System Date is the actual date, versus User Date which may not be the actual date).
RMA Line Field Source
Type Hard-coded, always CORE-REQ
Return Item Number As described in Setup, the -RC item from the Sales Order will be changed to a -S item. The -S item will be added to the RMA.
Quantity The SOP Line Quantity Ordered.
U of M There is only one U of M for all items, called “One”. The RMA will always be created using the Base U of M for an Item. If needed, the SOP Line Quantity will be converted to the Qty In Base.
Unit Price Retrieved from Item Price list
Unit Cost The Item’s current Actual/Standard cost
RMA Line Status Same as Header
Office ID Same as Header
Return Site ID & Address fields Same as Header
Ship to Address ID and Address Fields Same as Header
Shipping Method Customer’s Shipping Method from Customer Maintenance
Customer PO Same as Header
Return Price Level If Service Setup has Use Return Price Level marked, the Price Level provided is used. The Return Price Level must exist on the Item’s Price List. Otherwise the Price Level from the Order is used.
Entered Date/Time Same as RMA Additional Fields window

 

Fulfill SOP on MO Receipt

DS1041

Fulfill SOP on MO Receipt

Problem Definition

ACME Co uses CRM to bring sales orders into GP, and if necessary, the process also generates a manufacturing order to produce the sales item. Currently, the standard MOP-SOP linking is used to allocate the inventory when the MO is posted, however since GP allocates the inventory based on the costing layer, the SOP cost is not always the same as the MFG cost. ACME Co needs a solution to ensure the cost on the Sales Order is equal to the cost of the product that was produced by the linked MO.

Design Features

Overview

ACME Co will implement Lot Numbers on their sales items so when the MO is posted, the lot number on the MO can be used to fulfil the linked sales order and ensure the correct costing layer is obtained.

The lot number to produce will need to be pre-assigned on the MO prior to posting.

WilloWare has a Lot Number Pre-Assign feature in MFG PowerPack that may provide the ability to auto-populate the Lot Number on the MO, which can be purchased separate from this this estimate. Testing may be required to ensure it will work with the CRM process.

Alternatively, ACME Co can pre-assign a Lot Number to the MO when it is integrated from CRM.

When the MO is posted, the pre-assigned Lot Number will be used to fulfill the linked sales order.

MFG Posting

The normal Manufacturing Receipt posting process detects when an MO is linked to a Sales Line, and does the following:

  • It increases the Qty To Invoice on the sales line
  • It allocates the inventory in the GP Inventory tables

This enhancement will also fulfill each SOP Line with the Lot Number produced by the MO linked to the SOP Line. This will:

  • Update the Qty Fulfilled on the sales line
  • Populate the SOP Serial/Lot table
  • Update the Qty Sold in the Lot Master table

When the SOP order is transferred to invoice and posted, the correct cost will be posted to the IV account and COGS.

NOTE: If no Lot Number was found to be pre-assigned to the MO then the enhancement will NOT fulfil the SOP line.

Manufacturing Order Receipt Entry Post Button

The enhancement will put a control on the Post button on the MO Receipt Entry window that will prevent posting if:

  1. There is a Lot Number pre-assigned to the MO and more than one lot number was selected in the MO Lot Number Entry window.
  2. There is a Lot Number pre-assigned to the MO and it does not match the lot number that was selected in the MO Lot Number Entry window.

Consignment Inventory

DS1007

Consignment Inventory

Problem Definition

ACME Co makes generator powered lighting units used on construction sites. Each unit is lot numbered, and there is a quantity of 1 for each lot number (the lot numbers are effectively serial numbers). The units are sent out on consignment, but ACME Co still owns the equipment until it is sold.

They need to be able to:

  • Create a transaction (Consignment Order) that records movement of inventory from main inventory to “Consignment”
  • Record the customer/address receiving the inventory
  • Have Sales enter a Consignment Order, and Shipping fulfill it (i.e. select specific Lot Numbers)
  • Track Lot Numbers of inventory in consignment

Reporting

  • Which Consignment Orders have turned into sales
  • Which Consignment Orders are still open
  • Where each Lot Number of inventory is currently located
  • Consignment Inventory by Customer

Design Features

Overview

The majority of ACME Co’s requirements can be met through the In-Transit Transfer (ITT) transaction. The process is described below.

Creating a Consignment Order

When the TO SITE is set to the Consignment Site, special functionality will be activated to support Consignment. The new functionality will provide the ability to lookup a Customer, and Customer Address, and return that information to the Address fields on the right hand side of the window. See Consignment Orders below for more detail.

Sales will enter the Item(s) to be transferred to the Consignment site.

Sales will print the ITT Picking Ticket to send to the Shipping department.

Shipping will lookup the ITT document, fill in the Qty Picked, select specific Lot Numbers, and “Ship” the ITT. See Consignment Shipping for more detail.

Selling Consignment Inventory

Selling Consignment Inventory will begin by creating a regular Sales Order.

The Default Site ID must be set to the Consignment Site. This will activate the new functionality described below (see Consignment Sales Order below), which will ensure that only inventory on consignment to the selected Customer can be sold to that customer.

Returning Consignment Inventory

See Consignment Returns below for more detail. A new window will be created that will allow a user to select Items and Lot Numbers to return. It will create a regular inventory transfer, add the inventory to the transfer, and post it.

Setup

Navigation: Tools >> Setup >> Sales >> Consignment

Field Function
Consignment Site Enter the Site ID of the Consignment Site

The Consignment Site is used in the In Transit Transfer window, and Sales Transaction Entry, to identify when the special consignment functionality should be enabled.

Consignment Orders

Navigation: Transactions >> Inventory >> In Transit Transfer Entry

When the TO SITE is set to the Consignment Site, it will activate “consignment order” enhancements on this window.

The Tracking Reference field label will be changed to “Customer Number”. The field will only allow entry of valid Customer Numbers.

CTRL+Z will open the Customer Lookup window. Selecting a Customer Number will return it to the Tracking Reference field, and fill the Customer Name field. Likewise, if a Customer Number if typed into the field, when the cursor leaves the field the entered value will be validated to ensure it is a valid Customer Number, and if so, the Customer Name will be populated.

The Address fields will fill with the Customer’s primary Ship To Address.

CTRL+Q will open the Customer Address Lookup window. A valid Customer Number must already exist in the Tracking Reference field. Selecting a Customer Address will populate the Address fields.

Sales will enter the Item(s) to be transferred to the Consignment site. Qty Picked normally defaults to the Qty Ordered, but with the Consignment Enhancement enabled, it will default to zero. Shipping will fill in Qty Picked.

See Consignment Shipping below for more detail.

When Sales is done entering the Consignment Order, they will print the Picking Ticket:

This report can be modified as needed to ACME Co’s requirements. Modifying the Picking Ticket is not included in this estimate.

Consignment Shipping

A SmartList will be created for Shipping that shows new ITTs that need to be picked and shipped. They will select documents from the SmartList, which will open the document in the ITT Entry window.

Shipping will enter the Qty Picked and make Lot Number selections. They will click the SHIP button to “post” the transaction. Clicking the SHIP button performs the inventory transfer, moving the selected inventory into the Consignment location.

Creating this SmartList is not included in the estimate.

See Assumptions/Requirements for required GP setup.

Consignment Sales

Navigation: Transaction >> Sales >> Sales Transaction Entry

Selling Consignment Inventory will begin by creating a regular Sales Order.

The Default Site ID must be set to the Consignment Site. This will activate the new functionality which will ensure that only inventory on consignment to the selected Customer can be sold to that customer.

  • The Item Lookup will show only Items on consignment to that customer
  • The Item Number field will only allow Item Numbers to be entered that are on consignment to the customer. This applies to Sales Transaction Entry, and Sales Item Detail Entry.
  • The Sales Lot Number Entry window will only show/allow Lot Number on consignment for that customer. This applies to the Lot Number field, Lot Number Lookup, and the “Available Lots” scrolling window.

See Assumptions/Requirements for required GP setup.

When a specific Lot Number is added to an Order, a link between the Sales Line and the Consignment Lot will be recorded in the SVC_Transfer_Line_Serial_Lot_HIST table (SVC30702). The Sales Order Number will be stored in the Call Number field, and the Sales Line in the Equipment Line field. This will allow:

  • Linking a consignment Lot Number to the Sales Order on which it was sold (or is allocated to be sold)
  • Reporting on which consignment inventory is available to be sold

If the Order is deleted or voided, or inventory unallocated, the changes will be updated in the SVC30702 table. Aside from the special functionality described above, entering a Sales Order will behave like any other Sales Order.

Consignment Returns

A SmartList will be created that shows “unsold” consignment inventory. It will contain the Customer Number, Customer Name, Item Number, Lot Number, and Transaction Date of the Consignment Order (ITT) which put the unit into consignment.

From the SmartList the user will be able to double-click on a line, which will open the Consignment Return Entry window:

Note: the SmartList is used to locate an ITT which placed the inventory into consignment. Selecting a line does not auto-select the inventory in the Consignment Return Entry window.

The process of marking inventory for return is:

  • Click on an Item Number in the left-hand scrolling window to select the item.
  • The Lots window will fill with Lot number that have not been sold (or are not allocated to an unposted sales order).
  • Mark one or more Lot Number.
  • Change Item Numbers, if needed, and repeat the process.
  • Enter the Return To Site (this is the main inventory location)
  • Click POST

Clicking POST will ask the user if they are ready to return the inventory. If YES, it will create and post a regular Inventory Transfer with the selected inventory, transferring it from the Consignment Site into the selected Return To Site.

When a Lot Number is added to the Inventory Transfer, a link between the IV Transfer Line and the Consignment Lot will be recorded in the SVC_Transfer_Line_Serial_Lot_HIST table (SVC30702). The IV Transfer Number will be stored in the Call Number field, and the Line Number in the Equipment Line field. This will allow:

  • Linking a consignment Lot Number to the Transfer on which it was returned to inventory
  • Reporting on which consignment inventory is available. Any Lots in SVC30702 what have a document number recorded in the Call Number field have either been sold or returned to stock.

ETO Release 2018-11-6

V12.1.29 / 14.1.12 / 16.1.5 / 18.1.1
* First GP2018 Release
* Added Reference Designators
* All Mfg Estimate “child windows” are now in separate dexterity forms so that security can be set individually on each window.
* Sales Link: linking an Estimate to a SOP Quote Line now checks if the sales line is already linked to Estimate and does not allow creating a second link.
* Estimate Copy: addressed error “Cannot insert value NULL into column ROUTINGNAME_I” when copying an Estimate BOM (#20185404)
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). The module will still disable itself on a Client PC if it has an older Build.

GP PowerPack Release 2018-10-26

V12.1.126 / 14.1.69 /16.1.37 / 18.1.9
* NEW! TWK-SOP: Trade Discount Calculation-auto-calculates the Trade Discount field in Sales Transaction Entry. Installation creates an empty SQL Stored Procedure which is used by this Tweak to calculate the discount. The proc can be edited to add the custom business logic needed to perform the trade discount calculation to each customer’s specific requirements.
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). The module will still disable itself on a Client PC if it has an older Build.
* BE-Checkbook Register Inquiry: In GP2016R2 and above the scrolling window, which was populated by the CM_Transaction table, is now populated using an identical temp table copy of CM_Transaction. Updated the BE-Checkbook Register Inquiry to work correctly for both tables.12

MFG PowerPack Release 2018-10-25

V12.1.139 / 14.1.86 / 16.1.52 / 18.1.13
* BOM Archive: Added a new option to enabled/disable requiring the Archive Name to be unique. The default behavior is (and has been) to require that the Archive BOM Name is unique across all BOMs so when an archive is created for 100XLG using BOM Name 20170412, no other BOM for any item could have the BOM Name 20170412. This ensured the entire exploded BOM for an item could be archived. However, in cases where multiple items share common subassemblies, this control could result in having to create identical, differently named archives for the same subassembly. By turning Require Unique Archive Name off, if a subassembly already has an archive named 20170412, the archive utility will use that BOM rather than attempting to create a new archive for the subassembly.
* Sales Forecast Integration: Added a new option to include Unit Cost and List Price in the export and import. This optional setting will allow including projected Cost and Price values in the forecast.
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). The module will still disable itself on a Client PC if it has an older Build.

SpellCheck Release 2018-10-23

V12.1.23 / 14.1.14 / 16.1.11 / 18.1.3
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). SpellCheck will still disable itself on a Client PC if it has an older Build.
* NEW: Added dex.ini switch to force use of Word or Web for spellchecking. It can also turn SpellCheck off. Add this switch: SpellCheck=WEB/WORD/EITHER/OFF

MFG Import Release 2018-10-11

V12.0.41 / 14.0.24 / 16.0.12 / 18.0.5
* Routing Import: (1) Addressed issue that caused Labor Code to import blank. (2) Addressed issue in Routing Header Primary flag that prevented unflagging an existing Primary when a new Primary is imported.
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). MFGImport will still disable itself on a Client PC if it has an older Build.

New Installation Process

Key Points

  • A WilloWare product that has Minor Version 1 or above contains the New Installer (i.e. 12.1.36 has the New Installer, 12.0.35 does not).
  • Minor Version 1 (and above) will require a “complete install” on each GP client using the EXE installation file.
  • A change to the Minor Version number (i.e. 12.1.36 to 12.2.37) indicates the build includes database changes (i.e. new tables or table changes), so it requires logging-in as SA and completing the installation routines inside GP.  No users, other than SA/DYNSA can be in GP during this process.
  • Build Number changes (i.e. 12.1.36 to 12.1.37) has no database changes.  No installation routine needs to run inside GP.  The update can be installed with users logged-in, and the CNK can be pushed out using the GP Automated Updates utility.

Overview

Starting in October 2018, new builds of our software made after that date will begin including our New Installer, which will allow installing most updates without requiring running the complete installation routine (which requires getting all users out of Dynamics GP).

With the new Installer we will start incrementing the Minor Version Number when the new release of the software requires database changes (i.e. table or stored procedure changes).  The Build Number will always increment with each new release.

Our release numbers have this format: 12.0.35

This is translates to:

Major Version: 12

Minor Version: 0

Build Number: 35

The Major Version corresponds to the Dynamics GP Major Version.  For example, GP2013 is Major Version 12, so you must install a WilloWare Major Version 12 to match.

When the new installer is included in a product, the Minor Version will increment to 1 (i.e. 12.1.36).  This is needed because the new installer is going to recognize Minor Version = 1 as its “base”.

Due to the Minor Version Number change, the first installation of a new build at Minor Version 1 (or above) will require a complete installation of the WilloWare product on each GP client.  This means that the EXE installer must be run on each client, and that the CNK cannot be pushed out via Automated Updates.  The EXE installer deletes the existing product DIC file from the GP client folder before placing the new CNK.  When the Minor Version changes, Dynamics GP detect this and will not allow unchunking–the older DIC must be deleted first.

For all future releases the Minor Version will only change if the new release requires database changes (i.e. a new table, changes to a table, new or changed stored procedures, etc.).  For example, 12.1.36 to 12.2.37 would indicate the following:

  • For the first client (i.e. the server) you will need all users out of all Dynamics GP company databases, and you will need to log-in as SA and complete the installation process inside GP (which creates/updates SQL objects).
  • You will then need to run the EXE installer on each client

Many new features, and bug fixes, do not require changes to the SQL database.  For such changes the Minor Version will not change–only the Build Number will change.  If the Minor Version does not change, such as going from 12.1.36 to 12.1.37, you will be able to install the new release on GP clients while there are users in the system, and if you use GP’s Automated Updates, you can push out the CNK to all clients using that utility.

As has always been the case, when logging-in our software checks the its version installed on the GP client against the version installed on the server.  If the server has a newer build number it will alert the user that they are running an older version of our product, and then disable the product on that client.  The rest of GP on that client will continue to function normally.  This is a safety precaution to ensure an older client does not make changes to data that are incompatible with the newer build.  Some of our products, such as Extended Lot Attributes and Manufacturing Data Archive have important data integrity controls on each client, so updates should be applied to clients as quickly as possible.

What was the reason for this change?

Previously, every release, regardless of how minor, required that all users be out of the system while the installation process ran.  In many (most) cases, the only thing the installer did was update the build numbers in a tracking table.  The requirement to have users out of the system made it very difficult for many of our customers to get updates installed.

The major benefit of this change is that it will now be possible to install most updates on GP clients while users are in the system.

Another change is that the old process required either (1) Updating all companies to the current build, or (2) Disabling the product in companies you did not want to update.

With the new installer, it will now be possible to test a new build in a Test Company while leaving the Live Company alone.  To do this, create a separate GP client folder for the Test Client, install the new WilloWare build into that client folder, then log-in to the Test Company using the new Build.  When you log-in to a Company with a WilloWare product containing the new installer, it automatically updates the Build Numbers in our tracking table (WCMP9000 in the Company Database).  Note that it is important that the “test client” not be used to touch the live database because it will immediately update the Build Numbers in the Live Database causing the software to disable itself on all “older” GP Clients.

Summary

Build Number change only = can be installed with users in the system

Example: 12.0.35 to 12.0.36

Minor Version change = must run complete install process with all users out of GP.  Full install from the EXE installation file must also be run on each client.

Example: 12.0.35 to 12.1.36

or

Example: 18.1.5 to 18.2.6

 

 

Complete Count Release 2018-10-10

V12.1.36 / 14.1.26 / 16.1.19 / 18.1.9
* Mass Add/Update: added “Min. Items/Day” setting to control how many items are assigned to a count per day when the number of days per count is greater than the number of items to be counted. For example, if 20 items are to be counted every 90-days, a “Min. Items/Day” setting or 2 would assign two items to be counted per day.
* NEW: The Installer will now allow installing new builds on a client without requiring all users to be out of the system. Going forward, “running the install” inside GP will only be required when the Major or Minor Version Numbers change, but it will not be required with each Build Number change (12.0.35 is Major 12, Minor 0, Build 35). CompleteCount will still disable itself on a Client PC if it has an older Build.

Functional Currency Decimals

Dynamics GP allows setting the Currency Decimal Places on an Item to a larger number than the Company’s Functional Currency Decimal Places (FCDP)  For example, an Item could have 5 currency decimals ($12.00124) but the FCDP (which governs the General Ledger) only allows 2 currency decimals ($12.00).  What happens when you add inventory to the system with this sort of setup?  Read on to hear the Halloween Story of the Disappearing Inventory Value.

As mentioned above, this tale starts with Dynamics GP when the Functional Currency Decimal Places is set to 2 and Item Currency Settings are more than 2.

Item TEST6 has 5-decimals. The rest of the story uses this 5-decimal Item because it exaggerates the loss of value.

Create an Inventory Adjustment.

The IV Transaction Line table in the SQL database (shown below) has the correct unit cost, but GP has already rounded the Extended Cost. The value that should be in EXTDCOST is $0.00499 (which is the quantity of 499 multiplied by the cost of $0.00001).  Since the FCDP is 2, GP looks at the 3rd decimal place value and rounds. In this case it rounds to zero. So the extended cost is zero.

The Inventory Posting Journal reflects this:

And the GL Distribution Register is all zeros:

The Purchase Receipt Layer (or “FIFO Layer”) shows the correct quantity, but it too was added at the rounded cost:

No Journal Entry is created because GP sees this as a zero-dollar transaction.

The same situation occurs with Purchase Orders. Although you can enter a Unit Cost to five decimals, it is immediately rounded to 2-decimals in the Extended Cost, which results in zero dollars.

This can also be seen in the PO Line table:

The PO Receipt shows the correct Unit Cost, but Extended Cost is rounded to zero.

When the PO Receipt is posted, just like the Inventory Adjustment, it creates a Purchase Receipt Layer with the correct quantity, but zero dollars.

Item Transaction Inquiry shows the two transactions with the correct Unit Cost. With two receipts of the item, there should now be 998 * $0.00001 = $0.00998 in inventory, but neither of these transactions hit the GL, so the inventory account would still show $0.

Using $0.00001 highlights the effect, but the same thing occurs when the actual inventory value is $523.55449. In this case you lose $0.00449 because the transaction gets rounded to $523.55.

In theory, over a very large number of transactions, there might be enough rounding up and down that the effect averages out. However, it is certainly plausible that you have a manufacturing process which creates a large number of transactions that all lose a significant amount of value.

Avoid the Ghost of Lost Value by avoiding the setup described above.  Make sure the Item Currency Decimals setting does not exceed the FCDP setting.

LeanMFG Release 2018-10-08

V12.0.35 / 14.0.24 / 16.0.14 / 18.0.6
* MO Entry: addressed issue that could cause an “imbalanced transaction” at the GL under the following circumstances: (1) Multi-currency is not enabled, (2) Functional Currency Decimal Places (FCDP) is two, (3) Labor Input Items have more currency decimals than the FCDP, and (4) Labor Input Items have a total cost that does not round evenly to the FCDP. LeanMFG attempts to retain as much cost accuracy as possible, so when there are multiple non-inventory Input Items (labor/overhead), it calculates the total cost all all non-inventory inputs and then rounds that amount to the FCDP, which is debited to the WIP account. The cost of each individual non-inventory Input Item is then rounded to the FCDP and added as credit distribution on the Journal Entry. Sometimes rounding the total of the costs is a slightly different value than rounding each individual cost and then adding them. When that happens, the variance will now be added or subtracted from the last non-inventory (increasing or decrease that non-inventory cost by 0.01).

Complete Count Release 2018-09-27

V12.0.34 / 14.0.24 / 16.0.17 / 18.0.7
* Mass Add/Update: changed how the Set/Update Count Date utility works. It now has options to choose “work days”, and it will allocate groups of items to be counted on each work day within the Count Interval. For example, if 100 items need to be counted every 10 days, the utility will assign 10 items to be counted each day (assuming those are all “work days”) (#20185182).

GP PowerPack Release 2018-09-19

V12.0.125 / 14.0.68 /16.0.36 / 18.0.8
* TWK-SOP: Auto-Open Customer Detail: addressed issue that caused Customer Detail Entry information to not save if the user used the mouse to click into the Customer Number field on the Sales Transaction Entry window, rather than tabbing into it (#20185112)

MFG PowerPack Release 2018-09-19

V12.0.138 / 14.0.85 / 16.0.51 / 18.0.12
* Sales Forecast Integration: re-enabled ability to import a negative forecast so that Appending can be used to perform net change adjustments.
* Item Copy: added a change to the Item Master using dexterity (all of the copying is done via SQL) so it causes any 3rd Party Item Master triggers to fire.
* Quick Disassembly: window now remembers settings on a per-user basis so that each time the window opens the previously used options are selected automatically.

Consulting Toolkit Release 2018-09-18

V12.0.23 / 14.0.17 / 16.0.13 / 18.0.5
* Virtual Triggers: (1) Rewrote VT trigger registration routine to make it more efficient with a large number of triggers, (2) Changed method of choosing databases so they can be marked (checkboxes) rather than manually entering database IDs. The databases window also now has Mark All/Unmark All buttons.