You know what I hate?

[Kjetil Kilhavn]

The problem I see with "extreme" naming standards is they are not very forward-compatible. For those of you who don't understand the concept of forwards-compatibility - you have been using Microsoft products for too long.

When another country or plant or whatever wants the same functionality you either have to copy the object with the maintenance hell that creates, or use the same object and see your nice plan about reflecting who its for fall apart.

When it comes to object types I agree completely with Mike; object type ID = z<original>, name = z<original> and description = <original> (extended). There should be only _one_ extended, because a "real" subtype is not an extension, it is something new and more specific. Instead of an "Accounting Document (extended)" it may be e.g. a "Cash call".
-- 
Kjetil Kilhavn, Statoil OFT GBS BAS DEV SAP
 

> -----Original Message-----
> From: sap-wug-bounces at mit.edu 
> [mailto:sap-wug-bounces at mit.edu] On Behalf Of Srinivasan Ramanan
> Sent: Tuesday, December 19, 2006 2:42 PM
> To: sap-wug at mit.edu
> Subject: RE: You know what I hate?
> 
> Dear WUG,
> 
> I have written a documentation for our client about where 
> freely definable objects , texts and etc., are possible.
> I made it a point not to start with Z or Y. But as for bug 
> hunting and identification concerned a prefix would 
> definitely be a boon. Hence in my documentation I defined 
> that prefix as follows.
> 
>                1. Where ever the freely defined objects are 
> Co.code specific = use value of Co.code
>                2. Where ever the freely defined objects are 
> Plan       
> specific = use value of Plant
>                3. Where ever the freely defined objects are Whse     
> specific = use value of Whse num.
>                4. Where ever the freely defined objects are object    
> specific = use coined value.
>                       e.g : Object is ZBUS2032 for Credit 
> Memo for Co.code
> USA1
>                               suggested prefix is = 
> USA1_CM_changed , USA1_CM_approved
> 
> This my seem unnecessary at the beginning, but it is really 
> helpful so that when cross-client workflow speciifc events 
> are created , both developer and users are comfortable in 
> understanding the design.
> 
> We have really reaped benifits of this type of definition in 
> the freely definable texts with our client.
> 
> regards
> Srinivasan
> 
> 
> >From: "Alon Raskin" <araskin at 3i-consulting.com>
> >Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >To: <sap-wug at mit.edu>
> >Subject: You know what I hate?
> >Date: Mon, 18 Dec 2006 16:59:29 -0500
> >
> >I know that this is mostly an academic argument but I would love to 
> >hear peoples thoughts on this...
> >
> >You know what I hate? I hate it when I look at a Z Business Object 
> >(delegated sub-type) and someone has created a method called 
> zUpdate or 
> >an attribute called zAmount. Is there really a need for the 
> 'z' in the 
> >name of the attribute/method? Perhaps there is something I 
> am missing 
> >here so please feel free to point out the error of my ways.
> >
> >Do people do this because they don't realise that they can 
> redefine an 
> >SAP delivered attribute/method? Or are they concerned that SAP will 
> >deliver an attribute with the exact same name? I assume that the 
> >redefined method/attribute would not be effected but perhaps someone 
> >has had this happen...
> >
> >I understand why people do it with append fields on a table 
> but why do 
> >this for a BOR sub-type?
> >
> >Regards,
> >
> >Alon
> 
> 
> >_______________________________________________
> >SAP-WUG mailing list
> >SAP-WUG at mit.edu
> >http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
> _________________________________________________________________
> Type your favorite song.  Get a customized station.  Try MSN 
> Radio powered by Pandora. http://radio.msn.com/?icid=T002MSN03A07001


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.