Key Topics
1. Bin Management & Warehousing
Plan Overview:
The initial implementation will only include three bins: Receiving, Warehouse Storage, and Staging. The bins should align with their existing warehouse setup for simplicity.
Two Warehouses:
Warehouse 1 (Del Zotto): Will use the three bins mentioned above.
Warehouse 2 (Ramseyville Overflow): Only requires a default bin for bulk overstock items. No detailed bin management is planned here for now.
Current Picking and Shipping Workflow:
Items are picked from Warehouse Storage and moved to Staging before shipping.
Items in Staging should not count as available inventory in the system.
Future Bin Tracking:
Full bin tracking will be delayed until users are ready for the added complexity. Future tracking should include capturing the exact bin (e.g., mezzanine, outside) where items are stored.
Items shipped or picked up will need to have their statuses updated in the system for tracking purposes.
Implementation Tasks for Bin Management:
Set up the three bins in Warehouse 1 and one default bin in Warehouse 2.
Ensure that inventory adjustments happen as items move between bins (e.g., from Receiving → Warehouse Storage → Staging).
Test workflows for creating pick tickets and warehouse shipments to ensure smooth operations without bin tracking.
2. Sales Orders and Inventory Tracking
Order Status Tracking:
Introduce a status bar to visually display where the order is in the fulfillment process. This should include:
Open (Order placed but not processed).
Staging (Picked and packaged, waiting for shipment).
Shipped (Left the warehouse).
Closed (Finalized and removed from inventory demand).
Handling Staging Area Inventory:
Items moved to the Staging bin must reflect in the system as “not available” for other orders.
Orders left in Staging for extended periods (e.g., two months) should remain open until shipped or picked up.
Canceled Orders:
Retail orders that are canceled before payment can be deleted.
Orders with payments must remain in the system, marked as Closed, and retain any associated records.
Implementation Tasks:
Configure status tracking logic for orders in GoldFinch ERP.
Test inventory updates as items move from Warehouse Storage → Staging → Shipped.
Ensure canceled orders no longer impact inventory forecasts or demand.
3. Account Record Types
New Record Types:
Rename “Customer Group” to Parent Project to align with terminology used in their workflow.
Add two new record types: Retail Customer and Retail Contractor.
Retail Customers are general consumers (e.g., DIY buyers, website orders).
Retail Contractors are bulk purchasers who qualify for pricing discounts.
Parent-Child Structure:
Each Parent Project will be linked to associated child accounts (e.g., individual orders or tasks under the main project).
Implementation Tasks:
Update record types in Salesforce and align with GoldFinch ERP.
Ensure the data cleanup process for existing accounts is thorough and aligns with the new structure.
Provide training on using and maintaining the new record types.
4. Sales Pricing and Markups
Pricing Logic:
Raw materials (items) have a minimum markup of 70% over the last paid landed cost.
Certain categories have higher markups (e.g., small fittings may have a markup of 120%).
Bulk Pricing Updates:
Eric wants the ability to update pricing for categories of items in bulk rather than adjusting prices individually.
The system should calculate sales prices dynamically based on the last paid landed cost.
Sales Price Records:
Automate the creation of sales price records for components:
Three groups: Preferred, Established, Contractor.
Use percentages (e.g., 20%, 22%, 25%) applied to the standard price for each group.
Implementation Tasks:
Build logic to apply markups dynamically based on categories or last paid landed costs.
Test the creation of sales price records for components using bulk import functionality.
Configure GoldFinch to allow manual overrides where needed for specific customer pricing.
5. Kit Items and Bill of Materials (BOM)
Display Logic for Kits and Components:
On sales orders, display both kit items and their components. The components should show individual prices derived from their BOM, while the kit item serves as an informational header.
On invoices, display only the components unless the customer specifically requests the kit details.
Editing and Customization:
Users should have the ability to:
Edit components on sales orders.
Remove unwanted components from kits at the sales order or quote level.
Implementation Tasks:
Configure BOM explosion logic to display components under their parent kit on sales orders.
Set up rules for when components and/or kits are visible on invoices.
Provide users with tools to edit exploded BOMs directly on sales orders.
6. Customer Behavior & Data
Handling Cancelations:
For retail quotes/orders without payments, deletion is acceptable.
For orders with payments, refunds must be processed, and the order should be marked as Closed in the system.
Retention of Canceled Quotes:
Retain canceled quotes for future reference, as customers may return to proceed with the order.
Implementation Tasks:
Test workflows for order cancelations and refunds.
Train users on when to delete versus close orders.
7. Sales Price Automation
Automation Plan:
Create logic to calculate sales prices dynamically from the standard price using the percentage discounts:
Preferred: 20% off.
Established: 22% off.
Contractor: 25% off.
Avoid manual updates to sales price records where possible by using triggers or workflows.
Implementation Tasks:
Develop automation to calculate sales prices directly on sales orders.
Test price population logic to ensure discounts are applied consistently.