Sure, but this is not suggesting that at all. It is suggesting that when the entities were changed to use a BigDecimal instead of a Double for storage (work that Scott had completed I believe) and this set of entities appear to be missed. The suggesting is changing the entity model from "floating-point" to "fixed-point" in the exact same manner as what was done with the other entities that went through this conversion.
The trouble with the service definition approach is that for general CRUD type services the definition is usually defined using an "auto-attributes" element. So what we run into now is a call to "createProductionRun" requires a quantity as a BigDecimal (as per its entity model). The implementation takes that context and uses it to call "createWorkEffort" that requires a quantity as a Double ... and poof
The solution here was to either say "Double" is right for WorkEffort and the service implementation needs to convert from BgiDecimal -> Double before calling runSync OR the entity model is incorrect and we should convert it to "BigDecimal". The latter is the one that Scott indicated was probably the correct solution.