Author: admin

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.

Complete Count Release 2018-08-29

V12.0.33 / 14.0.23 / 16.0.16 / 18.0.6
* Mass Add/Update: addressed issue that caused duplicate key error when adding items to a Stock Count with multi-bins when there were items with multiple quantity types (i.e. In Use/In Service) in the same bin (#20185059)
* XLLink: added options to export Quantity Available and Quantity On Hand

LeanMFG Release 2018-09-13

V12.0.34 / 14.0.23 / 16.0.13 / 18.0.5
* MO Entry: (1) Addressed issue that caused error “Cannot insert value NULL into column TRXQTYTL” after clicking the Build Picklist button when using a Multi-product BOM that has no input or output items. (2) Added handling for MO with only Labor input with/without cost (i.e. $0 inputs). (3) Added handling for zero cost input Inventory items. (4) Post button now enables on a Manual MO after Inputs & Outputs have been entered. (5) Addressed issue that allowed bypassing Add New Item check on the Inputs tab.

Complete Count Release 2018-08-29

V12.0.32 / 14.0.22 / 16.0.15 / 18.0.5
* Stock Tag Submission: addressed issue that could cause a duplicate key error when moving Complete Count records to history tables. When this happens, the GP Stock Count updates correctly but the Stock Tag Printing information does not get moved to history (#20184931).

MFG PowerPack Release 2018-08-27

V12.0.137 / 14.0.84 / 16.0.50 / 18.0.11
* Serial/Lot Mass Generate: (1) Addressed issue that caused Global lot/serial mask to revert to the item’s mask when generating multiple lots. (2) Addressed issue that caused the Quantity per Lot Number to revert to the Lot Quantity instead of using the Lot Split Quantity. (3) Lot Split Quantity was incorrectly reverting the the Lot Quantity. (4) Lot Split Quantity from the Global Lot Mask is now applied to all Lots. (5) The quantity of Lot Numbers, and Quantity per Lot, now correctly handles the remaining quantity when the Lot Split Quantity does not divide evenly into the Lot Quantity.

Cash Payables Transaction Thru AP Account

DS0684

Cash Payables Transaction Thru AP Account

Problem Definition

ACME Co is a focused network of community and social websites that include G*****.com, T*****.com, A*****.com, and L*****.com. They use Dynamics GP as their ERP system.

To support a reporting requirement of their Auditor, ACME Co needs to create Payables Transactions with the following distributions when the transaction is entered with either a cash or check payment:

1.       Cash Account (standard GP)

2.       Purchases Account (standard GP)

3.       Debit AP account

4.       Credit AP account

The entries in #3 and #4 in the list above are not standard GP functionality. ACME Co would like to automatically add these accounts to the Payables Transaction Distributions.

Design Features

Payables Transaction Entry

There is no user interface for this enhancement.

When a Payables Transaction is entered through the Payables Transaction Entry window and the following criteria is met:

  1. Payment Type equals Invoice, Finance Charge or Misc Charge AND
  2. An Amount is entered in the Cash and/or Check fields

The enhancement will add the following two entries to the Distribution Accounts during posting of the Payables Transaction. Posting is supported through the Payables Transaction Entry window and the Payables Batch Entry window only.

  • Debit to the Accounts Payable Account set in the Posting Accounts Setup Window for the amount(s) entered in the Cash and Check fields combined. The Account Type will be set to PAY.
  • Credit to the Accounts Payable Account set in the Posting Accounts Setup Window for the amount(s) entered in the Cash and Check fields combined. The Account Type will be set to PAY.

In the example below, an AP Invoice has been entered for $1,000.00 with a corresponding $1,000.00 Cash Payment entered at the same time:

The enhancement will add a credit and debit entry to the default Accounts Payable account (Account Type = PAY) for the amount entered in the Cash and/or Check field on the Payables Transaction Entry window during the posting process:

Payables Distribution Zoom

The debit and credit to the Accounts Payables Account will be visible in the Payables Distribution Zoom window for posted Payables Transaction Documents which have been updated by the enhancement.

Pricing & Downloads

We are excited to announce a couple of small changes to our website that we hope will improve you life!  Well…that might be overstating things a bit, but we hope the changes will help you do your job more efficiently, or make a product decision just a little bit more quickly.

First, our Price List is now available on our website.  Just click the PRICING button (or at the top of the webpage, click MORE >> Pricing).

Second, the Downloads page no longer requires a password.  Just click the DOWNLOADS button (or MORE >> Downloads), select the GP Version, and download the software you need.

 

GPPowerPack Release 2018-08-02

V12.0.124 / 14.0.67 /16.0.35 / 18.0.7
* TWK-SOP: Use Item’s Default Site: modified behavior so it sets the Site ID before leaving the Item Number field. Since SOP defaults the site on a new line to the Site ID from the previous line, this change prevents getting prompted to add an Item-Site combination based on the previous lines Site ID. It will now also revert to the Default Site ID on the SOP Header if the Item being entered does not have a Default Site assigned.
* TWK-POP: Duplicate Items Warning: NEW. Warns user if the same Item Number is entered more than once on a Purchase Order.

MOGenerator Release 2018-08-02

V12.0.84 / 14.0.59 / 16.0.37 / 18.0.4
* MORI: (1) MO Query-addressed issue that could cause the query to not save, (2) Override IV Doc Number with MO#-this new user preference setting on the MOGen window causes MORI to override manufacturing when it creates Inventory Adjustments. Instead of using the default Next IV Adjustment Number, the adjustment will be created using the MO# plus a suffix for each subsequent Adjustment (such as MO00123*1, MO00123*2, MO00123*3 and so on). This option was added to address a condition reported in very high volume environments with multiple MORI processors where the normal GP logic that generates the Next IV Document Number allows two nearly simultaneous processes to receive the same Document Number.

GPPowerPack Release 2018-07-24

V12.0.123 / 14.0.66 /16.0.34 / 18.0.6
* TWK-SOP: Auto-Open Customer Detail: addressed issue that caused Customer Detail Entry to pop behind SOP Entry if user clicked on Customer Detail Entry with the mouse rather than using the keyboard (#20184512)
* TWK-SOP: Display Ship Weight in Title Bar: added a setup option to control whether shipping weight for kits comes from the Kit Item or the Components.

MOGenerator Release 2018-07-16

V12.0.83 / 14.0.58 / 16.0.36 / 18.0.3
* MORI: (1) Error Log- added button to “hide” errors. This changes records errors to a new status code so they are no longer displayed in the error log window. (2) Changed how conversion to Base UofM is handled in the MOPick table to account for a UofM Schedule that has circular conversions. (3) Changed timing of when a “split” MO is created during a partial receipt so that all errors checks must pass before the split MO is created. (4) Added Edit MORI Data window (accessible from Error Log window GoTo button) to facilitate manually changing data in the MORI tables from inside GP.

Trying Our Software

In additional to being fully functional in Fabrikam, all of our software is also fully functional, without registration keys, in <TEST> companies.  There are two benefits from this:

First, you can download and test our software using your live data without needing a temporary, time-limited key.

Second, if you already have our software but are not registered for all of its features, you can test ALL functionality in the <TEST> company without changing your registration key.

In short, all functionality of all of our modules is always available in a <TEST> company.

In case you are not familiar with a <TEST> company, here’s a quick overview.

Dynamics GP has a little feature that is not well documented, which provides support for Test and Historical company databases.  To enable this feature, put <TEST> or <HISTORICAL> at the end of the Company Name, as shown below:

<TEST> must be placed at the end of the Company Name (i.e. “WilloWare Inc. <TEST>”).

The primary effect of this is that it Zeros the Employee Count so the Employees in a TEST or HISTORICAL Company do not affect payroll.

It also causes a warning to pop-up during login to help alert users that they are not in the live company:

And, it will also cause WilloWare software to enable full functionality.

NOTE: During log-in you will receive a warning that the software is not registered.