Back

The DCC FileMaker solution as I inherited it was set up to handle priced products in the conventional manner: you'd select product from a dropdown list of products, it would look up the unit price for that product, multiply it by the quantity for that product and arrive at a calculated extended price based on unit price times quantity.

That's standard pricing, but the problem was that DCC didn't actually use standard pricing at all, so the resultant numbers were not useful to the Financial Department. The actual pricing for some products depended on:

• The Client. Some clients did enough business with DCC, or enough of the same type of work, that DCC would give them a discount because of the sheer volume of work they were ordering from us;
• The Quantity. Within a single job, the price of many items was structured so that the unit price would fall as the quantity rose from one plateau to the next. To keep things interesting, the price plateaus were not set up identically for all products, but differed a bit.
• The Size. Several products would be ordered to a customer-specified size, and the price would be determined by the next highest size in a price hierarchy. Again, to keep things interesting, the priced sizes for one product would not always be the same as the priced sizes for another, so for any given ordered size the next highest priced size might be different depending on the product ordered.
• The Laminate or Mounting. A handful of large-format products would be laminated or mounted and the associated charge for Lamination/Mounting would depend not only on the Client, the Quantity, and the Size, but also the specific laminate or mounting material used.

When the NY JobTicket structure was revamped in the major rearchitecturing, this included replacing the standard pricing with a routine that would input the correct unit price for the product line as it was being entered.

Developing a pricing structure that would handle the variations of DCC's price structure, without depending on a horrendously cumbersome script or field definition chock-full of cascades of "If this, then that, if this other thing, then this instead" logic, was one of the more interesting challenges I encountered while working on this solution. (It uses a two-phase lookup routine, triggering one lookup when the product name is entered which sets parameters limiting what can be looked up when the quantity is confirmed. A default price for each product-variant is found if no client-specific price exists).