Special pricing for items and labor

When pricing items for a project, 75% of the time it's perfectly acceptable to use the standard price types for the project and it's nice that we can assign specific price types to a customer. However, there are specific areas where D-Tools is weak on item pricing and it needs attention.

Manufacturers Advertised Price (MAP) - We need to have a price field for MAP and we need MAP to sync with partner updates. A lot of manufacturers have posted MAP pricing that is easily available to our customers and their purchasing bean counters. To manage pricing on an item correctly, only syncing 'cost' is half of the process, we still need to check/verify if MAP exists on an item and update the sell price to match. So while partner syncing does save us from accidently screwing our margins, we still have manual work to perform to ensure we are not selling over MAP. It's embarrassing when a customer comes to us as asks why we are selling an item over the advertised price. Some manufacturers like Crestron also have multiple MAPs depending on the customer type.

Special Pricing Agreements (SPA) - This is a project level price adjustment that is common, but has the potential to ruin either the project or catalog or both. Certain manufacturers offer discount pricing for items in a specific project.

Labor Price Types - Some customers have either negotiated labor rates or fall under 'prevailing wage' rules which are technically also "special pricing" for labor. These should automatically apply to all projects for specific customers.

Item Validation Tool works against you in all of these situations.

Issue 1: Manually overriding the cost and sell of an item adds risk to the catalog. Depending on what prompts are enabled, editing the item in any way triggers the 'Update to Catalog' dialogue which typically defaults to all fields. So any custom changes made to an item that are specific to the project but not appropriate to the catalog can be inadvertently pushed. This then can ruin the item for the next person/project.

Issue 2: The pricing validation tool can screw you.

• There is no indicator in the utility to inform the user that an item was intentionally modified and should not be corrected. If more than one person is auditing a project, if they don't already know about any special pricing circumstances, there is huge potential for human error in an application with no undo.

• The reverse could happen where the pricing could potentially be pushed to the catalog. If the user auditing the project mistakenly thinks the price was updated manually to reflect "current" or "new" pricing, rather than "special" pricing.

• Since the special pricing potentially affects a large swath of items, the items that actually need attention are diluted the list making it very easy to miss items that actually need attention.

Issue 3: SPA pricing needs to be referenced on POs and typically expires.

We need two indicators:

• In the project, we need an indicator if an item has special pricing set.

• We need to know if the special pricing has expired in the item validation tool, in the project, and when adding the item to a PO.

Potential solution for SPA pricing: Add a utility where

1) You can add/upload a quote/SPA from the manufacturer to you project.*

2) Designate/link the uploaded file to one or more of the manufacturers from the catalog that may or may not be already listed in your project. So all existing or future items added are associated with this SPA.*

3) Have a field for the uploaded file to list the reference number associated with the quote/SPA.

3) Have a date field for the uploaded file for if/when the special pricing expires.

Additionally:

4) Include a BOM column with an indicator (like the dot for an item that is on the current drawing page) that indicates the item pricing was intentionally overridden because of special pricing, the indicator should have two states. One state for valid special pricing and one state for expired special pricing.

5) Items linked to a valid SPA are omitted from listing in the item validation utility for cost/price, but DO list if the special pricing has expired.

6) We would like 'Price Types' added to labor and be able to assign labor price types to specific customers the same way we assign product price types. This would allow us to keep all the existing labor types as is, requiring no extra effort to replace the labor type or adjust the labor rate for the project. Also, this should prevent the item validation tool from flagging the labor price difference from the catalog.

*If the file uploaded could be a .csv, it would be amazing if the SI could reference the uploaded csv to automatically override the item pricing in the project to save time.