Internal Inventory Sales Transactions

Summary of Requirement

ACME Co. uses Sales Transactions to record internal transfers of material between facilities, however the process is highly manual and time consuming.

Their current process entails the following:

A Sales Order is entered into the System.
The Sales Order is shipped through Starship and shipping data is written back to GP. A Packing Slip and BOL are printed for the Shipment.
The next day, the Sales Order is manually voided and then a Transfer is completed and posted to move the Inventory to its new Site.

There are several factors that make this process ineffective:

The process is manual
From the time the Sales Order is voided to when the Transfer is created, the unallocated goods from the voided Sales Order can become reallocated to new Sales Order lines
When the Transfer posts, the transferred inventory is immediately visible in the “Transfer To” site, even though the inventory does not physically arrive at the “Transfer To” site for a period of days.

Design Specification

View design specification DS0688

MFG and RMA Item Revision Levels

Summary of Requirement

ACME Co. plans to purchase two WilloWare products:

Purchase Order Revision Levels
Sales Order Revision Levels

In addition to the functionality that these two products provide, ACME requires additional features:

ACME would like the current Item Revision Level to be displayed on the Item Inquiry window.
ACME requires the ability to track Item Revision Levels on Manufacturing Orders and Field Service RMA’s. They have viewed a demo of the WilloWare product “Purchase Order Revision Levels” and would like an enhancement to function similarly within these 2 modules.

Manufacturing Orders
The enhancement should track the Revision Level of the Item at the time it was manufactured, support tracking a history of revision level changes per MO and
support manufacturing the same part at different Revision Levels.
The Revision Level should be printable on GP Manufacturing Order Reports.

RMAs
The enhancement should track the Revision Level of the Item at the time it was returned, support tracking a history of revision level changes per RMA Line and
support returning the same part at different Revision Levels.

The Revision Level should be printable on GP RMA Reports.

Design Specification

View design specification DS0704

Current Costs By Site

DS0796

Item Current Cost by Site

Problem Definition

ACME Co utilizes Dynamics GP with a multi-Site environment. Dynamics GP stores each Item’s Current Cost at the Company level. ACME Co requires the ability to track an Item’s Current Cost by Site ID.

Design Features

Current Cost by Item/Site

There is no user interface for this enhancement.

A SQL table (WxxxxCurrentCost) will be provided that will store the following detail:

Item Number
Site ID
Current Cost

Each time a “receipt” transaction is posted in Dynamics GP for an Item Number/Site ID AND that “receipt transaction” updates the Current Cost of the Item, the SQL table will be updated for the Item Number/Site ID combination.

Some examples of a “receipt” transaction are:

Positive Inventory Adjustment
Purchase Order Receipt
Purchase Order Invoicing
Manufacturing Order Receipt

Please Note:

The exact SQL table name will be provided with the enhancement’s instructions when the completed enhancement is delivered.
New records will not be added into the SQL table for an Item Number/Site ID combination until a receipt transaction for the Item Number/Site combination has been posted.

Auto-populate WxxxxCurrentCost on Install

There is no user-interface for this portion of the enhancement.

When the enhancement is installed AND the WxxxxCurrentCost SQL table is empty, the enhancement will automatically populate the WxxxxCurrentCost table utilizing records from the IV10200 (Inventory Purchase Receipts table).

The enhancement will find the most recent record in the IV10200 table per Item Number/Site Combination. It will then insert one record per Item Number/Site into the WxxxxCurrentCost table using the following:

Item Number: IV10200.ITEMNMBR
Site ID: IV10200.TRXLOCTN
Current Cost: IV10200.UNITCOST

Please Note: The IV10200 table can be impacted by GP’s rounding principal. For instance, one Receipt of an Item Number can be broken into 2 separate records. For example:

An Item Number has its Currency Decimals set to 2 places. It has a Unit of Measure Schedule with a base UOM of “Each” and the following conversion:

Each = 1 Each
Case = 6 Each

A PO Line is placed for a quantity of 1 Case with a Unit Cost of $50.00. This would equal a Unit Cost per Each of $8.33333. Since the Currency Decimals of the Item is only set to 2 places when the PO is received, GP will add 2 records into the IV10200 table (the 2^nd record is always for a quantity of 1 and will receive the rounding amount).

Quantity of 5 Each – Unit Cost $8.33
Quantity of 1 Each – Unit Cost $8.35

To mitigate the likelihood that the record has been impacted by GP’s rounding principal, the enhancement will utilize the following approach in determining the most recent Item Number/Site/Unit Cost record:

Find the most recent record for the Item Number/Site combination.
If the Quantity Received is NOT equal to 1, the Unit Cost from that record will be used.
If the Quantity Received is equal to 1, the enhancement will check to see if another record exists in the IV10200 table for the same Item Number, Site ID, Receipt Date and Receipt Number.
If another record exists, the Unit Cost from that record will be used.

If another record does NOT exist, the Unit Cost from the original record will be used.

Revenue Deferral on Imported Transactions

Summary of Requirement

Brief Background on Analytical Accounting (AA)

AA refers to Analytical Accounting in the rest of this document.

AA setup consists of creating Transaction Dimensions and Codes.

A Transaction Dimension is set to have a data type of String, Currency, Date or Boolean. A Dimension with a string data type is assigned a list of user-created Codes.

Collectively these data types will be referred to as Values. During transaction entry, one Value is selected or entered for each Transaction Dimension assigned to the Distribution Account, thus providing the ability to analyze a distribution by the group of Values assigned to it.

Overview

eConnect will be used to create Sales Invoices & Returns in GP. The integration will create one Sales Distribution line (distribution type = SALES) for each sales line on the transaction.

AA Dimensions and Values will also be created for the Sales Distributions during the import. ACMECO sells both non-inventory (insurance) and sales-inventory (travel items). The insurance will have a Deferral Start Date and End Date. These dates will be provided in the AA Values. A special Dimension will be included called “DEFER” that has a Boolean data type. When the Value is TRUE, the deferral module will defer the distribution.

Additional AA Values will also be imported.

All sales transactions will be created in a Sales Batch. A user will log-in to GP to post the Sales Batch. The deferral process will be activated automatically when a Sales Batch is posted.

The deferral module will then:

Locate Sales Distributions that have the AA Defer flag set to TRUE
Create a deferral journal entry that debits the SALES account, and credits an associated Deferral Account. For returns the journal entry will credit SALES and debit the Deferral Account.
Create a deferral schedule
AA Values will be attached to the journal entry

The deferral is done for SALES distribution lines with a Distribution Type = SALES. This does not include taxes, miscellaneous charges, write-offs, commissions, or any other type of SOP distribution.

The Revenue Recognition window will allow the user to select a Date Range, then display all Deferral Schedules that fall within that range. Executing the revenue recognition process will:

Create one journal entry for all deferrals schedules within the date range
Each deferral record will result in a distribution debiting the deferred revenue account, and crediting a Sales account. The Sales account comes from the original Sales Transaction Distribution that generated the deferral schedule, and the Deferred Revenue account was determined during SOP Posting from the Deferral Setup. For SOP Returns the journal entry will credit the deferred revenue account and debit the Sales account.
AA Values will be attached to the journal entry distributions that match those from the original sales invoice distributions.
The Journal Entry will be saved in a Batch for user review prior to posting.

This design specification addresses only the deferral for SOP Invoices and returns imported with eConnect, and recognition of that revenue based on a deferral schedule. No functionality is provided for transactions from AP, AR, GL or any other Dynamics GP transaction. The mention of AP in this document address ONLY the inclusion of some fields on windows and tables that could be used for AP deferrals in the future.

Design Specification

View design specification DS0262

Pre-Enter Lot Number in PO Entry

Summary of Requirement

ACMECO needs to “pre-enter” a Lot Number on a Purchase Order and have it populate automatically when the PO Line is received.

Design Specification

View design specification DS0270

Multiple Copy Sales Form Printing

Summary of Requirement

ACMECO prints multiple copies of Sales Invoices, each having a different footer.

The footer indicates the person or department which receives that copy. For example:

“Copy #1 – Client Copy”
“Copy #2 – Accounting Copy”
“Copy #3 – Internal/Operational Copy”

This is currently accomplished using pre-printed forms, and ACME would like to start using laser printed forms on blank paper. To accomplish this, ACME needs Dynamics GP to print three copies of the Invoice, each copy with a different footer as shown above, and each copy going to a different tray in the printer so that each copy prints on a different color paper. Additionally, ACME needs to be able to reprint one copy of any one of the three versions.

Design Specification

View design specification DS0274

Lot Number Selection In Alternate U of M

Summary of Requirement

ACMECO uses lot numbered inventory in Dynamics GP. While the main transaction windows in GP can use any unit of measure from the Item’s Unit of Measure Schedule, the Lot Number selection windows are all in the base unit of measure. Most of ACME’s transactions are conducted using a unit other than base, so users need to constantly perform conversions from the base when selecting lots.

A solution is desired that allows the user to select/enter lot quantities in the transaction unit of measure.

The following windows should be addressed:

PO Receipts
Sales Transaction Entry
Inventory Adjustments
Stock Count Entry

ACMECO uses a 3rd party catch weight module from Trinity which provides alternate windows for Sales Lot Number Entry and Stock Count Lot Number Entry.

These requirements apply only to a certain group of items that will be identified by a 1 in the Warranty Days field (Item Maintenance >> Options).

Design Specification

View design specification DS0289

SOP & POP Date Rolldown and Purchase Receipts Inquiry

Summary of Requirement

Changing the Requested Ship Date (RSD) in Sales Transaction Entry, and Current Promise Date (CPD) in Purchase Order Entry, can be tedious if the documents have multiple lines. There is no ability to view the RSD/CPD for all lines at the same time, and the available ability to roll-down a new date automatically applies to ALL lines without ability to only rolldown to some lines.

ACMECO needs the ability to view and edit the RSD/CPD for all lines at the same time, to set a new date and selectively roll-down to some or all of the lines.

A second requirement is to be able to perform a purchase receipts history inquiry directly from the PO Line. They need to frequently look up the order history of a part for cost estimation, and it is time consuming to have to manually enter the parameters into the Purchase Order Processing Item Inquiry and/or Inventory Purchase Receipts Inquiry windows.

Design Specification

View design specification DS0290

Multi Bin & MO Receipts

Summary of Requirement

ACME Co. makes nutritional supplements and drinks. There are two areas of need.

Multi-Bin Enhancements

GP is being implemented with multi-bins where each bin represents a different physical location. Bins are being used in this manner so that MRP will plan for all sites. The first requirement is to add additional functionality to multi-bins to better support using bins for each location.

The changes include:

Address information for a Bin
Ability to assign a Bin to a PO Line and have that bin used as the PO Receipt location.

MO Receipt Enhancements

The Manufacturing Process uses two types of components:

Process Components (FOOD Components). All Process Component Item Numbers begin with 141.
Packaging Components.

When producing 100 cases of a drink product, the manufacturing process may yield only 98 cases of finished packaged product. However the raw material consumed will be 100% of the Process Components and 98% of the Packaging Components. Due to shrinkage/loss of the Process components they are consumed completely while producing fewer of the final packaged product, so less of the packaging is used.

The MO Receipt function in GP needs to be modified so that upon “FINAL” receipt of the MO, the Process Components are consumed based on the MO Start Quantity and the Packaging Components are consumed based on the sum of the MO Receipts including the FINAL Receipt Qty.

The ability to manually edit the picklist after the quantities have been calculated at FINAL Receipt needs to be maintained. So, at the FINAL receipt the system should calculate the correct amount of packaging to be used and update the picklist, but the user should still have the ability to override those calculated numbers before posting the MO Receipt.

Design Specification

View design specification DS0312

SOP Hold Removal Auto-Allocation

The original Pick Order Processor included logic that changed the Shipping Method to the “highest priority” of all picked orders and used that shipping method on the invoice. This functionality is desired in the Batch Processor as well. The shipping method should only change if one or both are true:

At least one original orders have a shipping method other than UPS GROUND.
At least one original orders was invoiced prior being transferred to the current invoice

Design Specification

View design specification CR0408

Assembly Serial Linking

Summary of Requirement

ACME Co. has a new product being released that is going to affect how they create configurations in service. Currently they are using the MO Serial Linking to build configurations. This new product has serial numbered components in a purchased assembly and these serial numbers need to be included in the configuration. Since the assembly is purchased, the component serial numbers never hit GP inventory and are not on a MO.

ACME Co. needs an Assembly Linking function to add to the current MO Linking results. The Assembly Linking window will need to allow the user to specify the MO number and top-level serial number and then populate a list of non-GP components that require linking. ACME will create a MFG BOM that will be used as the basis for the Assembly Serial Linking.

The linking structure may go like this:

Top Finished Good: On MO

1st level Component: On MO and linked via MO linking.
- 2nd level Component: On MO and linked via MO linking.
  - 3rd level Component: On PO and linked via MO linking
    - 4th Level Component: SN never in GP and linked via Assembly Linking

The user needs to be able to enter or change the ComponentSN up to the point where the Top Finished Good SN is sold.

Design Specification

View design specification CR0439

Extended Pricing & SOP Automation

Summary of Requirement

ACME Co. is using Extended Pricing (with Myridas Extended Pricing Enhancements) to calculate a “replacement cost” for items. Multiple price sheets, using the “uplift” pricing methods added by Myridas, are used to build upon the Base Cost of an item, adding additional cost to cover things like bagging and fuel surcharge. ACME Co. provides a Margin Inquiry window for SOP that shows the margin on the document as a whole. This is calculated using the current cost of the items from the Item Master. ACME needs to be able to see the margin calculation on a per-line basis, as well as for the document as a whole, and the margin calculation needs to be based on the “replacement cost” described above. All price sheets used for calculating “replacement cost” will begin with a C. Such as “C BAG FEE”. The Base Cost price sheet will be the only C-price sheet that is set to use Net Price Only

The other C-price sheets will use with either of the two Cost Uplift price types:

If the Cost Uplift % method is used, it should always be calculated as a percent of the cost provided in the Base Cost price sheet. There will be one additional Price Sheet for Gross Margin %, which will always use the Cost Uplift % method. It will always begin with C and contain “GM%”. For example:

All Price Sheets for the replacement cost calculation use only the Base Unit of Measure. The “values” could be positive or negative (i.e. -$0.75 or -1.25%).

The system should store the Line Margin information attached to the sales line, so that in the future, reports can be run on historical invoices which show the Replacement Cost at the time the transaction was created. ACME Co. would like to capture: Unit Replacement Cost, Extended Replacement Cost, Gross Margin (dollars) and Gross Margin % for the line.

ACME Co. also needs a way to view the detailed calculation view of each line which shows how the Price Sheets assigned to the item contributed to the total cost, a utility to calculate the Replacement Cost for all items within a user selected range and store the Replacement Cost in the List Price field.

Sales Automation

ACME Co. has also requested the following list of enhancements to the sales transaction entry process:

Some items are “agency” items. These are noted as such in the Item Category #1 field. The field can contain the Agency (a Vendor ID), or it can be blank (non-agency). If the item is an Agency item, the Agency will be in the Item Category field. Only Sales Inventory and Discontinued type items use the Agency field. The following needs to happen in Sales Entry when an Agency Item is used:
- The Agency from Item Category #1 needs to be added to Sales User Defined Text Field #1.
- The user should not be allowed to co-mingle items on one sales order from different Agencies. If an Agency Item is on an order, the order must contain ONLY other items from the same Agency, or it can also contain non-Sales Inventory type items (Misc Charges, Flat Fees, Services). In other words, if the document contains an Agency Item, any other “Sales Inventory” or “Discontinued” type items on the transaction must all be from the same Agency.
- Agency controls should be applied to all SOP Types
- When an Agency Item is selected on a sales transaction, flash the item number field RED.
- Warn the user if they attempt to enter/select an Item that is not allowed because of the Agency rules. Warn the user: You cannot use items from a different Agency.
- If a transaction contains Agency items, set the back-color of the Customer Name field to RED. It should turn red when selecting and viewing an existing document, or scrolling through documents.
A Customer can have multiple Ship To addresses. If they do, ACME Co. does NOT fill in the Ship To address ID field on Customer Maintenance. This ensures that a Ship To does not fill by default on Sales Entry. However, since Ship To Address ID is not a required field, users can then save a transaction without a Ship To Address ID. Make Ship To Address ID a required field. This should be applied to all SOP Types.
There should be only one Shipping Method used on the document (the header and all lines should match). Do not allow the user to get out of the document if there is more than one Shipping Method used on the transaction. This should be applied to all SOP Types.
There should be only one Site ID used on the document (the header Default Site and all lines should match). Do not allow the user to get out of the document if there is more than one Site ID used on the transaction. This should be applied to all SOP Types.
When Sales Date Entry opens, put focus into the Requested Ship Date field.
Payment Terms Controls
- If the Payment Terms on the transaction begin with a “C”, these are transactions that require pre-payment (such as COD, Cash Only or Credit Card). Alert the user about these Payment Terms by setting the back-color on the Amount Received field to bright green. (Something similar to this color). Also change the font in that field to BOLD. This should be applied to Quotes, Orders and Invoices.
- Prior to allowing the user to print any document (picklist, packing slip, order/invoice) for an order or invoice, if the Payment Terms begin with a C, and the Amount Received is less than the Document Total, warn the user: Payment must be collected for this shipment. This is applied to document level printing only.
- Payment Terms Change control. If the Customer Record Payment Terms ID starts with a C, only allow a Payment Terms change on a Sales Transaction to different Payment Terms ID that starts with C. For example, it would be OK to change from Credit Card to COD, but not to Net 30. If the Customer Record Payment Terms ID does NOT start with a C, the terms on the sales transaction can be changed to anything. This should be applied to all SOP Types.
The Customer Note contains important “alert” information. An existing customization pops-open the Customer Note on Sales Entry when the Customer is selected. However, it is very easy to accidentally edit or delete the note. Lock the Note and disable the Attach and Delete buttons when the Customer Note is opened from ANY location except Customer Maintenance. If the “ID” on the Note
Sales Returns. ACME Co. is using a window from Field Service called Create Return. This is accessed from Sales Entry via Additional >> Create Return. When the window opens they have to always select the Type ID. Since there is only one, they want this to default in (see red arrow below).When service creates the return it sets the Batch ID on the transaction equal to the SOP Document Type ID. In the example below, the Batch ID on the transaction would be RMARTN. ACME Co. wants users to change the Batch ID to be the Batch ID assigned to their Site. Do not allow the user to get out of a document if the Batch ID matches the SOP Document Type ID.

Design Specification

View design specification CR0443

Order Fulfillment Utility

Summary of Requirement

ACME Co. is a white label manufacturer supplying nutritional products to a large, national retail supplement chain. The retailer places orders for a large amount of inventory to be fulfilled out of dedicated distribution centers. There are multiple Customer IDs (stores) for the Retailer associated with each DC. The same item can be on multiple orders, for multiple Customer IDs (stores), with different Requested Ship Dates.

As ACME Co. produces inventory some portion is allocated to each DC so that all DCs get some inventory from each production run. The quantity to allocate is based on a ratio of the original Quantity Ordered for each DC. So if the POs for the three DCs ordered 20, 10 and 5 of the same item, the available quantity would be allocated to each DC as follows:

(20 / 35) * Qty Available
(10 / 35) * Qty Available
(5 / 35) * Qty Available

The Quantity Allocated is then assigned a Ship Number. A Ship Number is assigned per truck, so if the allocated inventory is more than one truckload the allocated quantity will be split, and assigned to multiple Ship Numbers.

This process is currently done manually, with the user finding Orders for the available inventory, figuring out how much to allocate to each one, then manually adjusting down the Quantity Ordered on the original Orders by the quantity of inventory allocated to the DC, then putting the quantity allocated onto new sales orders that can be fulfilled and shipped. Because creating the “split” orders is a manual process, it induces errors in pricing and quantities, and it is time-consuming.

ACME Co. would like a utility that:

Identifies the open orders that need the available inventory
Figures out how to distribute the available inventory across the DCs
Provides the ability to assign the allocated quantities to one or more Ship Numbers
Creates new sales orders per Ship Number, showing the inventory assigned to that Ship Number
Update the original Sales Orders to show the “remaining quantity” ordered after the allocated quantities are put onto the new sales orders
Changes the Batch ID on the new orders to the “Released” Batch so that they are picked up by the SOAP Module (see DS0304).

Design Specification

View design specification CR0460

Automated Lot Transfer

Summary of Requirement

ACME Co. needs to prevent accidental transfer of inventory from a QA location into “released” inventory. The need the following:

Users should have the ability to indicate the status of a Lot is “released”.
Once a Lot of an item is released it should be automatically transferred to a predefined Site-Bin

Design Specification

View design specification CR0463

SOP-to-MOP Enhancements

Summary of Requirement

The following requests are addressed:

Sales Document Holds
Sales Line Holds
Requested Ship Date Audit Trail
Customer Assigned Serial Numbers
MO Holds- ability to control if the hold removes the MO from MRP, CRP, both or neither
Depot WO to MFG MO Integration

Sales Document Holds

ACME Co. needs the ability to make the demand created by sales lines “disappear” from MRP when a Hold is applied to the sales document.

Sales Line Holds

ACME Co. frequently needs to put a specific sales line on hold, either due to a customer request, or to resolve an internal production issue. Placing lines on hold complicates their need to report on delivery performance against requested ship date.

ACME Co. would like the system to:

Track a reason code for putting a line on hold and/or changing a requested ship date
Create an audit trail of changes to Requested Ship Date. The audit trail should show:
- The time, date and user ID
- Before value and After value of the Requested Ship Date (what is was changed from, and what it was changed to).
- A reason code for the change
Remove the line from MRP when it is put on hold

They need the ability to define different types of Line Holds, and each Hold should have a Requested Ship Date associated with it. When a user puts a line on hold, by selecting a Hold ID, the system should automatically set the Requested Ship Date to the pre-defined value.

For example, CUSTOMER Hold might set the date to 12/31/9999, while ENGINEERING might set the date to 12/31/3000. The exact date is not important, just as long as the date falls outside of any possible MRP date range. Setting the Requested Ship Date well into the future is what makes the sales line invisible to MRP.

If the user manually changes the Requested Ship Date, the system will require them to enter a Reason Code for the change.

Changes to due Holds and manual changes (i.e. to move to a new date requested by the customer), will both be recorded in the Requested Ship Date audit trail.

Sales Line Requested Ship Date Audit Trail

Track all changes to Requested Ship Date, who made the change, a date/time stamp of the change, and why it was changed.

Customer Serial Number Entry

ACME Co. has a handful of customers who provide the serial numbers ACME Co. needs to use on the assemblies. For all other manufacturing orders the serial numbers are autogenerated by GP.

Sales needs the ability to record these serial numbers attached to a sales transaction.

One MO is created per unit ordered. So the quantity on a parent MO is always 1.

Production needs to be ability to select from the list of assigned serials to use them on an MO. The serials will be assigned either using the Serial Number Pre-Entry (from MO Entry), or during MO Receipt.

The Traveler package contains a document with the Sales Order Number, so the user will be able to provide that number in manufacturing to retrieve the serial numbers.

When selecting from the serial numbers, the user needs to be able to see all serials assigned to the document (i.e. if there are multiple lines on the order, the user should be able to see all lines/all serials, and select from any of them).

As a serial number is selected for use, it should be marked as such (i.e. used). Once used, it should continue to display on the window, but it cannot be selected a second time.

MO Holds Change

ACME Co. needs to refine the MO Holds functionality. In some cases they need to note that there is a hold, but keep the MO visible to MRP and CRP so that the lower level subassembly MO’s are still produced. To support this requirement, ACME Co. needs the ability to control whether the MO Holds window removes CRP information for an MO, removes MRP information, or just adds the Hold ID. Depot WO to MFG MO Integration A previous customization from WilloWare provided the ability to create an MO from a Depot WO, and link the WO Parts to the MO Picklist. That design required each item to have a “repair” routing in manufacturing. In reality, depending on the type of work to be performed, any one of several different “routings” will be used, and the generic routing steps would be similar for many different items.

The Depot WO process will be as follows:

An RMA is created, and a Depot WO generated from the RMA
When the returned unit arrives, a tech assesses the unit to make a decision about the work that needs to be performed.
When that decision is make the tech will change the WO “Type” to indicate the type of work to be done.

At that point ACME Co. needs to create the MO linked to the Depot WO using a manufacturing routing that corresponds to the WO “Type”. The following is needed to support this:

The ability to associate a Manufacturing Routing with a TYPE
Modify the existing “create MO” functionality so that it is run manually from the Additional menu.
Modify the “create MO” functionality so that it uses the correct Routing for the WO Type.

Design Specification

View design specification DS0375

Long Serial Numbers

Summary of Requirement

ACME Co. has some items with Manufacturer’s Serial Numbers (or Lot Numbers) up to 40- characters in length. These Ser/Lot Numbers need to be printed in Sales Transaction Entry.

When the long Ser/Lot items are received in purchasing, ACME needs to be able to record the incoming Ser/Lot provided from the vendor. One item, Smart Boards, have a long serial number comprised of two separate serial numbers. These need to be recorded individually, associated with the SmartBoard (i.e. the Smart Boards need to have two long serial numbers).

In the rest of this document, the long serial/lot numbers/multi-part serial numbers will be referred to as Long Keys.

There are other serial/lot controlled items in the ACME inventory which do not also have Long Keys.

ACME needs to be able to identify which items require Long Keys, and additionally, which of these Long Key items also have the “multi-part” serial numbers.

The Long Keys should print on sales documents.

Also, they need to be able to locate, or cross-reference, the Long Keys to the GP serial/lot numbers and vice versa.

Design Specification

View design specification DS0431

Assembly Serial Entry & Field Service Enhancements

Summary of Requirement

ACME Co. produces serial numbered units with several serial numbered subassemblies. Many of these items are from subcontractors and never go through ACME inventory.

GP Manufacturing is used to produce the complete unit, and many of the subcontracted items are not part of the Picklist. GP provides a way to record the serial number of the final assembly but since the subassemblies are not part of the Picklist, there is no place to record these serial numbers. Many of the subassemblies also have serialized subassemblies that need to be recorded.

GP Service is used to track equipment records, configurations and returns. When a sales invoice is posted, the Service module automatically creates Equipment Records (ER) for the serial number of the final unit, but not for serialized subassemblies.

ACME processes all returns from Service Calls. The RMA is generated from the Service Call Parts Line. ACME adds an “R” suffix to the item number of the returned serial number before creating the RMA and an ER Supersession is created to update the Equipment Record with the “R” suffix.

A solution is required that will allow ACME to record the serial numbers of the subassemblies that will be linked to its final serial numbered unit. ACME should be able to record this information at any time during the manufacturing process, and also change the information up to the time of shipping. The user should be able to use a scanner to scan the serial numbers for the subassemblies.

The list of subassembly items that need to be tracked will be listed in a Kit item, so a method needs to be provided to tie the final unit item number to the kit item number. This information should be used to provide the user with an entry window that shows the subassembly item numbers, and provides a place to enter their serial numbers.

When the Equipment Record is created for the sold unit, the system should also create ERs for each of the tracked subassemblies and build a multi-level configuration.

When an I-Line item is added to a SVC Call, an “R” needs to be added to the item number in the 6th position and used for the R-Line. If the I-Line item is serialized, and more than one item exists in the item master with the same first 5 digits, a window needs to pop-up, allowing the user to select which item to choose.

When the SN is identified on the replacement item, the replacement serial number should replace the returned serial number on its configuration. The new serial number is installed by the tech, it needs to take over the warranty and contract information from the returned serial number. The warranty on the replacement serial number is the remaining warranty of the returned serial number or 90 days, whichever is greater. The returned item needs to be canceled off the contract.

If an item number that ends in “RR” is entered as the I-Line, this needs to be treated as a Repair and Return as follows:

1. If the “RR” item doesn’t already exist, it needs to be created as a copy of the SVC Call header item, but at $0 cost.

2. When the R-Line is returned, an equipment record is created for the “RR” item that is a duplicate ER of the item from the SVC Call header.

3. When the I-Line is shipped, the ER for the “RR” item is moved to the Equipment Record Audit table and then deleted from the SVC Master table.

Occasionally, the actual serial number returned to inventory is different than the serial number on the RMA. Since the linked In-Transit Transfer changes the equipment record customer and equipment status before the RMA is received, the original serial number is left with the wrong customer and status. ACME needs the original equipment record to change back to the original customer and the equipment status back to the default equipment status.

SVC allows saving default accounts to service types. These account numbers are used by SVC when billing a SVC Call. Once account type absent from this list is for Markdowns. ACME would like to record a default Markdown account number and have it flow to billing.

All changes to Equipment Records and Configurations need to be recorded in an audit table and be viewable from the UI.

Design Specification

View design specification DS0432

Accounts Payable Allocation for Property Management

DS0444

Property Management AP Allocations

Problem Definition

ACME Co. is a property management company. Bills received by the management company need to be allocated in different ways to the properties they manage. An existing software package that handles this resides outside of GP, and needs to be brought inside the software.

The properties have a hierarchical structure linking groups of them together. The relationship is:

Federation
- Association
  - Condo Corporation
    - Buildings

At the bottom level, the Buildings, the system tracks the number of units within each building. Most of the allocations are calculated using a ratio of the number of units contained within some level of the entity-relationship, to a total of units. For example, if a Federation contains three Associations, an expense could be allocated to each Association by looking at the number of units within each Association vs. the total number of units in the Federation.

Design Features

Setup

The Setup window is used to specify which segment of the GL account structure will be swapped by the AP Allocations app.

Navigation: Tools >> Setup >> Purchasing >> Allocations

Field	Function
Profit Center Segment	User enters or selects from the Lookup the segment.

Allocation Maintenance – Option 1

Allocation Maintenance is used to create/maintain the allocation structure. The allocations are defined by a series of 1-to-many relationships as follows:

Federation
- Association
  - Condo Corporation
    - Building

Cards >> Purchasing >> Allocation Maintenance

When a Federation ID is entered, the Associations scrolling window will fill automatically. The remaining windows will be empty until further selections are made.

The remaining windows display based on a selection from another window. As shown above the “NA” association is marked (the “>” indicates “marked”), which causes the Condo Corporations window to fill with the Corporations under the NA association.

Selecting the “NA” condo corporation causes the Buildings scroll to fill with the buildings which are under the “NA” condo corp. The Association and Condo fields to the left of this window show the selected Association and Condo.

Field	Function
Federation ID	User enters a federation ID or selects one from the Lookup. 20-character, upper case.
Name	Editable. 40-character.


	Associations Scroll
Association ID	User enters the Association ID. 20-character, upper case.
Name	Association name. 40-characters.
Segment	User selects the profit center segment. The values allowed in this field/displayed in the Lookup are controlled by the Segment selected in Setup.
Federation %	The Federation % calculates automatically, and is not editable. This is a ratio of the number of Units beneath the Association divided by the total number of units in the Federation.

	Condo Corporations Scroll
Condo Corp	User enters the condo corp ID. 20-character, upper case.
Name	Condo Corp Name. 40-characters.
Valuation	Valuation of the Condo Corp. This value is used when performing an Allocation By Valuation. See below for descriptions of the different allocation methods.
Federation %	The Federation % calculates automatically, and is not editable. This is a ratio of the number of Units beneath the Condo Corp divided by the total number of units in the Federation.

	Buildings Scroll
Association ID	This display field to the left of the Buildings Scroll shows which Association ID was selected.
Condo Corp	This display field to the left of the Buildings Scroll shows which Condo Corp was selected.
Building	Build Number (or description). For example, 2713 or, 1101-1108 & 1201-1212. 30-characters, upper case.
Unit Count	Number of doors (units) in the building. Most of the allocation methods (described below) are based on the Unit Count.
Federation %	The Federation % calculates automatically, and is not editable. This is a ratio of the number of Units within the Building divided by the total number of units in the Federation.

	Totals
	The totals in the bottom right display various totals for the Federation.

The “v” buttons are “show detail” buttons which expand the scrolling window lines. The expanded window will show totals for the line from the “sub” windows. For example, expanding the line for an Association will show the following totals for the Condo Corps and Buildings beneath the selected Assocation:

Total Condo Corps
Total Valuation
Total Building Count
Total Unit Count

Likewise, expanding the line for a Condo Corp will show the following totals for the Buildings beneath the Condo Corp.

Total Building count
Total unit count

If entering information for a new Federation, the data entry process would be as follows:

Enter the Federation ID and Name.
Enter all of the Associations, and the information needed for each Association.
Select the first Association by clicking into the scrolling window line:
- Then click into the Condo Corps scrolling window.
- Enter one or more Condo Corps “linked” to the selected Association.
- Select the first Condo Corp line:
  - Then click into the Buildings scroll.
  - Enter one or more buildings, and the information for each building.
Repeat the process by clicking into another Association.

A line in any of the scrolling windows can be deleted by selecting Edit >> Delete Row from the GP Menu Bar. If deleting a row from the Associations or Condos, all records beneath that level will also be deleted. For example, if deleting the “NA” association shown above, the “NA” Condo Corp and all Buildings would also be deleted. Before allowing a user to delete a row the system will:

Present a warning message explaining that a number of records could be deleted from the Condo Corp and Buildings. For example: Deleting an Association will delete all Condos and Buildings beneath the Association. Continue? The user can click YES or NO.

Similar warnings will occur as the Condo level, and the Federation Level. Individual buildings can be deleted via Edit >> Delete Row without receiving a warning.

The different allocation methods will be calculated as follows:

Unit – allocates a percentage of the amount to each Association in the system based on a ratio of units within each Association to the total number of units in the system. $Amount * (ttl Assn Units / ttl Units for all Federations).
Federation – allocates the amount to the Associations within the selected Federation, based on a ratio of the units within each Association to the total number of units in the Federation. $Amount * (ttl Assn Units / ttl Federation Units).
Association – allocates 100% to the selected Association.
Reserve – works the same as Association, but Reserve Cash Accounts are used to pay instead of cash. The user must select the default Reserve Accounts to use on the AP Distributions window prior to performing the Allocation (see next section).
Valuation – allocates to all Associations in the system based on valuation. $Amount * (Condo Corp Valuation / Total Valuation of all Condo Corps).

With the exception of Valuation Allocation, all of the above methods allocate based on ratios calculated using the Buildings table. The Buildings table will be similar to this example:

FedID	AssnID	CondoID	BuildingID	UnitCount
NA	NA	NA	2612	16
NA	NA	NA	2613	12
NA	NA	NA	2614	16
NA	NA1	NA1	3212	16
ABACO	ABACO	ABACO A	1601	48
ABACO	ABACO	ABACO B	1602	40
ABACO	ABACO	ABACO C	1603	48
….

Example calculations using just the information above for a $1000 AP Tranasction.

Unit Allocation

Sum of Unit Count by Association:

NA = 16 + 12 + 16 = 44.
NA1 = 16
ABACO = 48 + 40 + 48 = 136
Total Units = 44 + 16 + 136 = 196
Allocation for NA = $1000 * (44/196)
Allocation for NA1 = $1000 * (16/196)
Allocation for ABACO = $1000 * (136/196)

Federation Allocation

Sum of Unit Count by Association within the selected Federation (NA).

NA = 16 + 12 + 16 = 44.
NA1 = 16
Total Units = 44 + 16 = 60
Allocation for NA = $1000 * (44/60)
Allocation for NA1 = $1000 * (16/60)

Association

$1000 allocated to the selected Association (i.e. NA).

Reserve

$1000 allocated to the selected Association (i.e. NA). User will have selected default reserve accounts to use for the allocation.

Valuation

The Valuations are stored in the Condo Corps table (not shown here). The Valuation Allocation is similar to a Unit Allocation in that the amount is allocated to every Association, but the ratios are calculated using the Valuation Amounts from the Condo Corps table.

Allocation Maintenance – Option 2

ACME Co. has emphasized that the entity relationships do not change. They have been the same for years, and are expected to be the same for the foreseeable future. Given that, the sophisticated Maintenance window proposed above may be overkill, or even not needed.

Since the primary objective is to facilitate automatically creating the allocations for an AP transaction inside GP, all that is really needed is to have the “allocation logic” presented in the next section (AP Allocations). That “logic” needs the underlying entity relationship data. If the data itself does not change often (or ever), the Maintenance window adds little or no value.

An alternate approach is to import the data (entity relationships, unit count, valuation, etc) from the existing system into the new GP tables created for this customization. The AP Allocations window (next section) will use that to create the allocations.

In the unlikely event that changes to the data are needed, those changes would need to be made from the “backend”, directly on the SQL Server.

Everything in the previous section pertaining to HOW the allocations will be created still apply to Option 2. What is removed is the ability to create new Federations, or change anything in an existing Federation from inside GP.

This estimate does not include time to migrate/import the data. We will provide documentation on the structure of the tables, and assistance in understanding what data is expected in the tables, however the actual task of importing and validating the correctness of the data will be Complete Business Solution’s responsibility.

AP Allocations

After entering an AP transaction (below), the user will select Additional >> AP Allocations.

The AP Allocations window will open:

Field	Function
Allocation Method	The allocation method selection will control whether the Federation and Association fields are enabled. Options will include: Unit (Federation and Association disabled) Federation (Federation enabled, Association disabled) Association (Federation and Association enabled) Reserve (Federation and Association enabled) Valuation (Federation and Association disabled)
Federation	The drop-down list will display all available Federations. When a selection is made the field to the right will display the Name of the federation.
Association	The drop-down list will display all Associations within the Federation. When a selection is made the field to the right will display the Name of the association.

CREATE	Will prompt the user to confirm they are ready to allocate the transaction. If so, the software will split the existing “default” purchases allocation (PURCH) and expense allocation (PAY). If there are other distributions (i.e. taxes), they will NOT be redistributed by the AP Allocation routine. Only amounts coded with the distribution type of PURCH and PAY will be allocated. Since the app creates the allocations using the existing “default” distribution accounts, the user must have selected the correct accounts if the default accounts are not appropriate. If necessary, the user can click DEFAULT on the Distributions window to delete the Allocations and rebuild the distributions using default accounts. If no accounts are found in the Distributions table the user will see a warning and be required to select default distribution accounts.

AP Allocations

The segment of the account swapped to create the AP Allocations depends on Setup. If the 2^nd segment is selected (2-xxx-130000-051) the second segment will be replaced, and a distribution created, for each entity within the selected Allocation Method.

For example, if allocating by Federation for NASSAU the 2-xxx-130000-051 account would result in three distributions:

2-040-130000-051
2-050-130000-051
2-060-130000-051

The original distribution created by default by GP will be removed.

Agile Transportation Software Integration

Summary of Requirement

CME Co. sells interconnecting materials for the semiconductor and electronics industry. Their products are sold worldwide, and some of the products are considered hazardous material.

These two characteristics (international shipments of hazardous materials) create unique requirements for shipping. A shipment may pass through a freight forwarder, and a number of different shipping documents can be required based on the method of shipment and destination country.

ACME Co. looked at many of the common freight rate calculation packages that integrate with GP, such as Starship and vShip, but none of them could fully support their needs.

Agile Network’s Transportation Management Solution (www.agile-network.com) has software that meets all of ACME Co.’s needs. ACME Co. will be using the Agile Pack, Ship, Export, Hazmat, and View solutions. Agile does not have an integration to GP, and there is additional information Agile needs about a shipment that GP does not currently have the ability to store.

Pick Tickets are printed from GP with a barcoded Order Number. A user scans this document into Agile to perform the pick and pack. Agile also performs a pick verification during the packing process where the user scans each item that was picked, before packing it, and Agile confirms the correct item/quantity were picked. When the user indicates packing is complete, Agile will go to the GP database and retrieve the order information needed to calculate freight and print the required shipping documents.

On a daily basis a user will execute a process from Agile that sends freight information back into a table in the GP Company Database.

ACME Co. needs to add to GP the ability to store the additional shipping and freight information needed by Agile, and provide a way for GP to update the freight amount based on information provided by the Agile software.

Also, since the Agile system will use only the Shipping Method and Ship To Address on the Sales Transaction Header, to avoid user confusion ACME Co. would like to lock those fields on the Sales line so that they user cannot edit them.

Design Specification

View design specification DS0482

Summary of Requirement

ACME Co. has 17 locations across the state, and a manufacturing facility which produces electrical poles.

When poles are sold, a user manually calculates the estimated Freight Amount and Number of Loads based on knowing:

1) The location of the customer and distance from the manufacturing facility

2) The average weight of each type of pole

3) The cost per mile to transport a given weight

4) The average load capacity of a truck

The freight amount is entered into the Sales Transaction Entry “Freight” field, and the Comment is used to store a note with the Number of Loads, Load Rate, and Freight Cost.

ACME Co. would like the software to perform this task automatically.

Design Specification

View design specification DS0498

Sales Shipment Load Planning

Summary of Requirement

ACME Co. currently enters Sales Orders into spreadsheets, before re-keying them into GP, because they need to calculate full pallets and truckloads and split orders, if needed, if the load for the order would exceed one full truckload.

A full truckload is always 56 pallets, but the quantity of a specific item varies per pallet.

ACME Co. needs GP to:

1. Track the total quantity of pallets on an order and alert the user when a full truckload is reached.

2. Ensure that each sales line is ordered in multiples of whole pallets.

Currently each item does NOT have its own Unit of Measure schedule, so the U of M Schedule cannot be used to contain a Pallet to Each conversion (because it varies by item). As part of a larger Warehouse/Inventory project, ACME Co. will implement item-specific U of M Schedules. The U of M Schedule will contain a Pallet to Each conversion for each item.

Design Specification

View design specification DS0499

Inventory Transfer User-Site Security

Summary of Requirement

ACME Co. develops and manufactures molecular diagnostic tests.

When QA controlled material is received, it is put into a QA site in GP. Since there are no restrictions on which sites users have access to, and different types of users need to be able to perform inventory transfers, it is possible that a non-QA user could transfer QA controlled material out of the QA site.

Generally, ACME may have a need in the future to restrict users to a group of sites in which they work. For example, users who can perform transfers in Maine sites versus users who can perform transfers between Florida sites.

Design Specification

View design specification DS0516

Sales Batch Allocation from Multiple Bins

Summary of Requirement

ACME Co. is using GP with multi-bins enabled, and SOP Order Numbers are set up to allocate by document/batch. Sales transactions are saved in a batch, and any given batch may contain Orders, Fulfillment Orders, or both.

The Batch Allocate/Fulfill routine available in GP does not work well when inventory is located in multiple bins. If a default Sales Fulfillment Bin is specified, it will allocate/fulfill out of that bin, but then if the quantity is required greater than what is available in default bin it will allocate at the Site-level, but require manual user intervention on each sales line to complete the bin-level allocations.

ACME needs a SOP Batch Allocation utility that can automatically allocate/fulfill from multiple bins, and apply business-specific rules for selection the order in which documents should be fulfilled.

Selecting Documents

Documents should be processed oldest first, based on the ORIGINAL order. So if an order has been transferred from Order to Backorder and back to Order, the Document Date on the originating order should be used.

When several documents have the same Document Date, orders should be processed by oldest Customer first. Oldest Customer will be determined by the DEX_ROW_ID in the Customer Master table (lower DEX_ROW_ID equals older Customer). With one exception: ACME has two Customer Numbering sequences, one is all numeric, and the other is alphanumeric. Alphanumeric Customer Numbers should be processed after Numeric-only Customers. Within the Alphanumeric Customers, those should still be processed oldest first.

Selecting Bins

Bin numbers will have the format: 006-00-00-AR. Allocate from bins in the following manner:

• Use bins where the first segment is 006. 006- are Floor Stock bins, and orders will be allocated/fulfilled from the floor first. If more than 1 such 006-bin exists, allocate from the 006-bin with the smallest quantity first. Within a bin, for Lot-controlled items, allocate smaller quantities of the lot first.

• After allocating all inventory from 006-bins, allocate from all other bins (rack inventory) by smallest bin quantity to largest bin quantity. If all bin quantities are the same for an item:

o For Lot Controlled inventory, allocate on a FIFO basis using the Lot Number. The Lot Number mask will be YYMMDD-0000-000001, where the last 6-digits increment (this represents the production date and sequence).

o For non-tracked inventory, allocate from bin in alpha-numeric order.

If a sales line cannot be completely fulfilled, it should be partially fulfilled and the remaining quantity should be put into Quantity To Backorder. The fulfilled quantities are transferred to invoice, and the remaining backordered quantities are left on the open Order.

The allocation routine needs to handle both new sales lines with no allocations and no quantity backordered, and previously allocated lines with a quantity backordered. It should be possible to run the utility again on an order that has quantities allocated/fulfilled, and if new inventory becomes available, it should take quantities off backorder and allocate/fulfill them. In other words, until the order is transferred to invoice, running the utility again should be able to re-process documents and allocate MORE inventory to the document if more has become available.

There is NO serial numbered inventory.

Kits are being used. Kit components need to be allocated.

For regular Orders that are set to allocate by document/batch, the allocation routine should allocate and fulfill the order.

For fulfillment Orders that are set to allocate by document/batch, the allocation routine should allocate and fulfill the order, and set the Fulfillment Workflow Document Status to “Confirm Pick/Ready To Pack”. It should record the “Unconfirmed Pick” status as-if the user Confirmed the Pick, which set the status to Confirm Pick/Ready To Pack.

Design Specification

View design specification DS0523

Item-Country Shipping Restriction

Summary of Requirement

Some ACME Co. products are restricted by federal law from being sold to certain countries. ACME needs a way to track in GP which countries are prohibited for an item, and to prevent use of that item in Sales Transaction Entry if it is prohibited based on the Customer’s Ship to Address.

The following controls are needed:

1) Record which countries are forbidden for an item

2) Prevent using an item on Sales Transaction Entry if the Item is not allowed for a given Ship To Address’s country code

3) Do not allow changing of the Ship To Address Code on a transaction where the change would result in items being disallowed

4) Require Country Code on Ship To and Bill To Addresses used in Sales Transaction Entry

5) Specify certain users as having the ability to Override the following condition and allow use of a forbidden item: If the Bill To is Forbidden but the Ship To is Allowed. When this override occurs, create an audit trail of who did it and when.

6) Prevent changes of Ship To Address information on the Sales Transaction (all changes must be recorded on the Customer Address Maintenance window).

Design Specification

View design specification DS0548

Transfer Backordered Quantities from Order to another Order

Summary of Requirement

ACME Co. needs to automate the transfer of Back Ordered quantities from an Order to another Order, rather than to a Backorder.

Design Specification

View design specification CR0561

Track & Display Incoterms on SOP Documents

Summary of Requirement

ACME Co. has the need to display Incoterms on all invoices created in GP. This includes the 3 digit Incoterm acronym, Incoterm Name and the Detailed Description.

A sample of the fields and data required are as follows:

Incoterm: EXW

Incoterm Name: Ex Works

Detailed Description: The seller (exporter) delivers when he places the goods at the disposal of the buyer (importer) at the seller’s premises or other named place (i.e. works, factory, warehouse, etc.) not cleared for export and not loaded on any collecting vehicle. This term thus represents the minimum obligation by the seller (exporter), and the buyer (importer) has to bear all costs and risks involved in taking the goods from the seller’s premises. However, if the parties wish the seller (exporter to be responsible for the loading of the goods on departure and to bear the risks and all costs of such loading, this should be made clear by adding explicit wording to this effect in the contract.

Design Specification

View design specification DS0564

Assign Finished Good Lot Number based on Component Lot Number

Summary of Requirement

ACME Co. is currently utilizing Quick MO’s with the setting “Manually select serial/lot numbers in Quick MO” selected. To create efficiency in closing Quick MOs, and improve trace-ability, they would like the MO’s Finished Good to have the same lot number(s) as the Lot Controlled component. They would like the Finished Good lot number to be set automatically during the MO Close process.

Design Specification

View design specification DS0591

Vendor Diversity Tracking

CR0595

Vendor Diversity

Problem Description

The ACME Co. needs to track Vendor Diversity information.

Solution Description

Navigation: Purchasing>>Cards>>Vendor Maintenance

The Vendor Diversity ID window will open automatically and position itself along the bottom edge of the Vendor Maintenance window.

$C:\Users\Karen\Documents\Clients\Sikich\Cubs\Vendor Diversity ID.jpg$

Field

Function

Vendor Diversity ID

The user will select a Diversity ID from the dropdown. The initial selection for Vendor Diversity ID will match the current selection:

Excluded
Minority Owned
Non-Minority Owned
Minority Women Owned
Women Owned

All new Vendor records will default to “blank”.

This is a required field.

The Vendor Diversity ID window will display for each Vendor record if the user scrolls through the Vendor records, selects existing Vendor ID’s from the lookup or types in a Vendor ID.

When the Vendor Maintenance window closes, the Vendor Diversity ID window will close automatically.

Controls:

The user will be unable to save the Vendor record if a Diversity ID is not set.
If a Vendor record is deleted, the Vendor Diversity ID record will delete also.

NavigationPurchasingInquiryVendor

The Vendor Diversity ID Inquiry window will open automatically and position itself along the bottom edge of the Vendor Inquiry window.

$C:\Users\Karen\Documents\Clients\Sikich\Cubs\Vendor Diversity ID Inquiry.jpg$

Field

Function

Vendor Diversity ID

The user will view the Vendor Diversity ID set in the Vendor Maintenance window.

This field is not editable.

The Vendor Diversity ID Inquiry window will display for each Vendor record if the user scrolls through the Vendor records, selects existing Vendor ID’s from the lookup or types in a Vendor ID.

When the Vendor Inquiry window closes, the Vendor Diversity ID Inquiry window will close automatically.

Additional:

The Diversity ID currently set within the Vendor Maintenance Card will be kept for each existing Vendor ID.

Historical Inventory Valuation and Historical Lot Numbers Reports

Summary of Requirement

ACME Co.’s activities include fishing, trading, processing and marketing with offices and operations in strategic locations around the world. Their customer base includes famous brands, tuna processing plants and fishing companies.

They currently utilize Dynamics GP with a custom Bill of Materials Module. Within the custom BOM module is an Inventory Valuation Report that provides the Item Number, Site ID, Quantity on Hand, U of M, Unit Cost and Extended Cost. They would like to be able run this report historically with the addition of an “As of Date”. The “As of Date” should pull both the Quantity on Hand and the Standard Cost as of the date entered. The standard Dynamics GP Historical Stock Status report is not visually pleasing nor do they feel that it provides them with accurate information.

In addition, ACME would like to run the standard Dynamics GP Inventory Lot Number Report in the same fashion including an “As of Date” for historical capabilities.

Design Specification

View design specification DS0602

Transfer Sales Order Processing Shipping Method

Summary of Requirement

During the SOP Transfer process from Sales Backorder to Sales Order, the Shipping Method of each Sales Line is transferred properly. However, often Sales Lines have a different Shipping Method than the Sales Backorder Header. ACME would like the enhancement to update the Sales Order Header to reflect the Shipping Method from the Sales Lines. This will ensure that the correct Shipping Account is pulled onto Sales Documents.

The Shipping Method should be updated in the following manner:

• If all transferred Sales Lines share the same Shipping Method, then the Sales Order Header should update automatically to match.

• If all transferred Sales Lines do NOT share the same Shipping Method, the enhancement should create multiple Sales Orders – 1 per Shipping Method.

Design Specification

View design specification CR0607

Add Qty Remaining to POP Documents

Summary of Requirement

ACME Co. requires the PO Line Quantity Remaining to Ship to print on Purchase Orders.

Design Specification

View design specification CR0610

Commodity Purchasing Tolerances

Summary of Requirement

ACME Co. is a global leader in animal health and nutrition providing research-based products worldwide to owners and producers of various animal species. Their employees are experienced with emerging technologies, livestock production and grain merchandising and they support their continued growth.

Their purchased products include commodities whose pricing can change from the time the Purchase Order is placed until the time the Purchase Order is received. ACME is currently allowing their receivers to update the cost of the product as well as quantity and UOM at time of receipt. This can cause improper data to be entered into Dynamics GP that is not easily corrected.

They would like to include tolerances in the system for:

Summary of Requirement

ACME Co. has an existing Sales Discount module which calculates Product Discounts and limits customers receiving Product Discounts unless a dollar threshold has been met on the Sales Document. They would like to add additional functionality, including Freight Discounts into the enhancement, as well as provide for the ability to easily upgrade the enhancement as they upgrade to the next version of Dynamics GP. Therefore, WilloWare will be recreating the entire enhancement.

The general rules of ACME’s Sales Discount enhancement are as follows:

1. Product Discount thresholds are defined by Customer Class.

2. Product Discount eligibility is defined by the Item Class and Price Level.

3. Freight Discount thresholds are defined per Company database.

4. Freight Discount eligibility is defined by the Item Class and Price Level

5. If a Customer receives a Product Discount because they have met the Product Discount threshold OR if any Sales Line has been updated to reflect a decrease in the Customer’s Price List’s standard price, then the Customer does NOT receive a Freight Discount.

6. If the Sales Document subtotal meets a Freight Discount threshold and there are NO Product Discounts on the order then the Customer will get a Freight Discount percentage off of the Sales Order subtotal, but only up to the Actual Shipping Amount.

ACME utilizes Starship software in their shipping process. The Starship software is used to populate the Freight field during either the GP Sales Order or GP Sales Invoice stage. So, if the Freight field was populated on a Sales Order the information must be transferred to the Sales Invoice. At times, ACME uses Starship solely at the GP Sales Invoice stage.

Design Specification

View design specification DS0647

Advanced Manufacturing Data Collection

Summary of Requirement

ACME Co. is a leading manufacturer of custom engineered mechanical seals and welded metal bellows. ACME has a full line of component and cartridge seals that have been sealing the industry’s most basic and challenging applications for over 30 years.

ACME utilizes Dynamics GP as its ERP system. Employee labor time is tracked per Manufacturing Order sequence and entered into the system through the Automated Data Collection window. ACME requires the ability to view all labor transactions for a Manufacturing Order Sequence and update and correct those Employee labor records prior to submitting them.

Design Specification

View design specification DS0655

Automated Sales-MO Generator

Summary of Requirement

ACME Co. is implementing SalesPad to be used in conjunction with Dynamics GP. Users will be entering Sales Orders directly into SalesPad. SalesPad does not have a link to the Manufacturing Module. Creation of Manufacturing Orders direct from the Sales Order is not possible.

ACME would like the ability to auto-generate a Manufacturing Order from the Sales Order. This functionality should work in the background, meaning there will be no user interface for the creation of the Manufacturing Order.

All Sales Lines for Inventory Items which are Sales Inventory should trigger the creation of the Manufacturing Order. The Manufacturing Order should be created for the full Quantity of the Sales Order Line even if there is available Inventory in stock.

The Manufacturing Order should be created with an Open Status and reflect the appropriate Site in which the MO should be built.

Design Specification

View design specification DS0658

Update COGS, Revenue, and Markdown Account when Posting Sales Documents

Summary of Requirement

ACME Co. utilizes Dynamics GP as their ERP system. They currently have many legal entities maintained in the same database. In addition to the core GP Modules, they also utilize the Manufacturing Module. Sales Invoice and Sales Returns Documents may contain both manufactured and non-manufactured items.

ACME’s GL Accounts are comprised of four segments. The last segment is for the Cost Center and is three digits. When posting Sales Invoice and Sales Return Documents, they need the following Inventory Accounts to reflect a specific Cost Center based on the Sales Document ID.

• COGS

• Sales

• Markdown

• Sales Returns

In addition, since ACME utilizes the Manufacturing Module and a FIFO Periodic Valuation Method, when selling a Manufactured Item the Manufacturing Module replaces the single GP Inventory Module COGS account noted above with up to nine manufacturing COGS accounts. The accounts are only added when the manufacturing processes add value to those accounts. For example, if there is no Labor Variable Overhead amount in the routing (Labor Codes), there will not be a distribution to that account. When posting Sales Invoice and Sales Return Documents which contain Manufactured Items, the Manufacturing COGS Account should also reflect the specific Cost Center based on the Sales Document ID:

COGS Distribution Accounts: (1) COGS – Material (2) COGS – Labor (3) COGS – Machine (4) COGS – Material OH (5) COGS – Labor OH (6) COGS – Machine OH (7) COGS – Material Variable OH (8) COGS – Labor Variable OH (9) COGS – Machine Variable OH

Since these accounts are added automatically by manufacturing during the posting process, there is no opportunity to change them manually.

The Sales Invoice Document Type and the Sales Return Document Type will determine the Cost Center to utilize when posting. They require a way to assign a Cost Center per Document Type/Document ID.

Design Specification

View design specification DS0660

Sales Order Line Fulfillment Upon MO Receipt

Summary of Requirement

ACME currently has an enhancement that generates Manufacturing Orders for Sales Lines created through SalesPad and creates the MO to Sales Order link. When the Manufacturing Order is received, standard Dynamics GP allocates the newly available inventory to its linked Sales Order Line. Although the inventory is allocated, the user must still manually perform the fulfillment step. ACME would like all Sales Order Lines to be allocated and fulfilled when a Manufacturing Order Receipt provides available inventory for its linked Sale Order Line.

ACME’s original MO Generation enhancement creates a Manufacturing Order for the entire Sales Order Line quantity even if the full Sales Order Line quantity has not been backordered i.e. there was some available inventory in stock or they have overridden the shortage. The new enhancement will not only fulfill the backordered quantity of the Sales Order Line, but also fulfill any previously allocated quantity, as long as a large enough quantity is received during the MO Receipt process.

Design Specification

View design specification CR0663

Automated Sales Document Allocation Based on Predefined Priority

Summary of Requirement

ACME Co. utilizes Dynamics GP as its ERP system. They are using GP with multi-bins enabled and SOP Documents are set up to allocate by document/batch. Sales Documents are saved in a batch, and any given batch may contain multiple SOP Types.

Since their Go Live Date, their business requirements have changed significantly. They have very specific rules on how product should be allocated to Sales Documents. As the rules have some complexity, it makes it difficult to continue to have the allocation process be a manual task.

ACME needs a SOP Batch Allocation utility that can apply business-specific rules for selecting the order in which documents should be fulfilled. Their current Allocation Rules are set by Priority and a high-level overview is below:

1. Any Sales Document for Customer IDs assigned to Customer Class ECOMMERCE or ONLINE regardless of Requested Ship Date or Hold Status.

2. Any Sales Document with a Backorder quantity that is past due or due to ship on the current date. Documents must NOT be on Hold.

3. Any Sales Document with Payment Terms set to PREPAID with an Account Balance less than or equal to $0.00 where the Requested Ship Date is less than or equal to the current date plus 10 days regardless of the Hold Status.

4. Any Sales Document for Customer IDs assigned to Customer Class INTERNATIONAL where the Requested Ship Date is less than or equal to the current date plus 10 days. Documents must NOT be on Hold.

5. Any Sales Document for Customer IDs assigned to Customer Class RETAIL where the Requested Ship Date is less than or equal to the current date plus 7 days. Documents must NOT be on Hold.

6. Any Sales Document for Customer IDs assigned to Customer Class PACESETTER, OEM or PROFESSIONAL where the Requested Ship Date is less than or equal to the current date plus 7 days. Documents must NOT be on Hold.

ACME requires the ability to update the Allocation Rules in the future as business requirements may change. In addition, ACME requires the ability to view allocated Sales Documents by Batch and select Sales Document Lines to unallocate.

Design Specification

View design specification DS0668

Automatic Backorder, Allocation and Fulfillment

Summary of Requirement

ACME Co. utilizes an EDI system to import the majority of their Sales Order Documents into Dynamics GP. Based on the rules of their EDI system, all Order ID’s have been set up to “Allocate by Line” and to “Use a Separate Fulfillment Process.” When Sales Order Documents are imported through the EDI system, quantities are immediately allocated to Sales Lines, if available. The bulk of their Sales Orders are released to their 3rd party Warehouse.

Releasing the Sales Order document, locks it within GP and no changes can be made to it. ACME has several Sales Order Document IDs, which require all Item Numbers and quantities to be Backordered to prevent the release of the order to their 3rd party warehouse.

Currently, the users must open each Sales Order, review the lines and manually update each line to move the Qty to Invoice to Qty to Backorder. They would like a faster way to do this per Sales Document.

ACME would also like to be able to quickly allocate, or allocate and fulfill, all Backordered Sales Lines on a Sales Order Document when adequate quantities are available to satisfy the entire Sales Document. ACME has a multi-Site environment, but they do NOT use multiple bins. They also do not use any Serial or Lot tracking functionality.

Design Specification

View design specification: DS0671

Quick MO Automation

Summary of Requirement

ACME Co. currently utilizes Dynamics GP to manage and support Inventory Control. In conjunction with the Inventory Control module they also use Manufacturing. The manufacturing process handles make to stock counter tops (a.k.a. Granite Slabs) and sinks which have a standard bill of material as well and are valued at standard cost. In addition, ACME fabricates custom tops and sinks from the made to stock items. They do this by cutting to size the slabs/counters and applying custom edges based on customer specifications.

A custom in house application (CA) is used to enter and track customer orders and fabrication jobs. These jobs are released to a cut planner (cutting optimization software) which identifies how to best utilize the standard make to order counters (a.k.a. Slabs). The material consumption for Slabs is stored in the CA per job and each custom top receives a unique job number in the CA.

For example, a custom job will consume .42 units of a standard slab where 1.00 is a whole slab. In addition this custom job requires 192.72422 linear inches of fabrication work/edge work. The custom fabricated counters have an item number within Dynamics GP that is unique to the thickness and color of the slab. This custom fabricated item in Dynamics GP is a serialized item and uses actual costing.

The manufacturing and fabrication (custom) business at ACME runs 24 hours a day 7 days a week. The process using existing applications is highly customized and automated. ACME would like to feed Dynamics GP the necessary information to automate the manufacturing process for both standard slab/sink assembly as well as the fabricated/custom business line. Based on the volume of transactions being processed and the cost involved, ACME would like to utilize the Quick MO process to handle their manufacturing needs.

Design Specification

View design specification:DS0676