Still not clear if you have packed the information into a single field as a formatted string or if you've distributed the parts of the composite "Part Number" among columns of the table. Complex Types are intended for the later scenario.
Also not clear if you're saying that the same table columns could be interpreted EITHER as one type (Part.PartNr) or another type (ProductionLot.BatchNr), depending upon context. If column interpretation is "flexible", you won't be able to use Complex Types. In other words, there must be a single meaning to the columns that constitute a conceptual composite.
If the same columns can mean different things, you'll have to treat them as separate properties and devise custom properties in your business objects to differentiate the various "composite" interpretations. That's not hard to do either (and is viable in all versions of DevForce).
--
Complex Types are supported in DevForce 2009 (v.5.x) and DevForce 2010 (v.6.x) but not DevForce 2005 ("Classic", v.3.x).
Complex Type support is latent in DF 2009 because the Entity Framework v.1 DESIGNER didn't support them; you had to play tricks with the XML in the EDMX. VS 2010 removes that obstacle, possibly for EF v.1 as well.
In any case, I strongly recommend making the move to DF 2010. Contact
sales@ideablade.com , especially if you are an existing customer.