Component naming conventions

I'm curious if there are recommended naming conventions for
component instances when placed on the stage. Naming movie clips
and buttons "something_mc" and "something_btn," respectively,
allows Flash to recognize them as such, thus showing the list of
methods and properties when accessing the object in ActionScript.
Naming a movie clip "something" does not allow this list to appear.
Similarly, if I programmatically create an FLVPlayback
component through ActionScript, like
var flvPlayer:fl.video.FLVPlayback = new
fl.video.FLVPlayback();
then I get the methods and properties list when tying
flvPlayer.
But if I drag the component onto the stage and give it an
instance name of 'flvPlayer,' typing
flvPlayer.
does not bring up the list. Are there any names these should
have in order for Flash to recognize it as a component?

In AS2, there used to be custom component code hinting (_cb =
combobox, _lb = listbox, etc.). But I believe they've been removed
in AS3.
However, there
are still some hidden ones that trigger.
You can find them all in the ActionsPanel_3.xml file located
in:
C:\Documents And Settings\[user]\Local Settings\Application
Data\Adobe\Flash CS3\en\Configuration\ActionsPanel\ActionScript_3
They're at the very bottom of the file. You can add your own
as well, just make sure to restart flash for the effect to take
hold. If you completely mess up the file, there's a copy in the
FirstRun directory under Program Files.
Cheers,
FlashTastic

Similar Messages

XML Schema Component Naming Convention

Is there a naming convention when you create an XML Schema? For example,
When you create a Type component, then the first letter of its name should be upper case ie. BMW, Honda, AutombileEngine ...etc.
When you create an Element component, then the first letter of its name is lowercase ie. engine, car, guestCar ..etc.
Do we have such naming convention for XML Schema?
Thanks

I am giving this from my document which i prepared for one of my customer
2 General Guidelines for design of XML schema documents
The representation of data in an XML format will be a key component of development within SOA. Therefore, the design and development of XML schemas should be as rigorous an activity as designing and developing code or designing database schemas. As such, when creating an XML schema you should be working within a development process and working to a set of design guidelines and coding standards (when writing the XML schema file). XML schemas should be reviewed for accuracy and compliance with guidelines and standards. Each of the requirements in the list below is a general requirement for all XML schemas to be deployed in the SOA environment.
• Understandable: XML schemas should be clear, consistent and unambiguous. They should contain human readable documentation and, where appropriate, links to requirements or design documents.
• Semantically Complete: An XML schema should define, for one or more target XML documents, each and every element and attribute that is understood by your solution when processing target documents.
• Constraining: XML schemas are used as contracts between both publisher and consumer. As such, they must be able to be validated as concisely as possible. When designing an XML schema constraints should be identified for the values for all the elements and attributes that the application uses and relies on to the set of values that the application can handle. A valid document should imply valid data within the limits of what can be specified by the XML Schema language.
• Uniquely identifiable: XML schemas should import and include other XML schema files rather than duplicating types and elements locally.
• Reusable: XML schemas should be specified in such a way that types and other XML schemas can leverage elements. Every type defined in an XML schema that is the content type of an attribute or an element should be defined globally (i.e., at the top level in the Schema). Types that are defined globally can be reused in other XML schemas. Schemas should be separated into logical sections which can be included into the main schema file.
• Extensible: Schemas should be designed to be extensible—that is, new elements and attributes can be inserted throughout the document.
Every schema should use at least two namespaces – the targetNamespace and the XML Schema (http://www.w3.org/2001/XMLSchema) namespace.
Create typed elements that can be referred to by object elements:
Example:
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.soa.com"
xmlns="http://www.soai.com"
elementFormDefault="qualified">
<xsd:complexType name="PersonType">
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="SSN" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.company.org"
xmlns="http://www.company.org"
elementFormDefault="qualified">
<xsd:include schemaLocation="Person.xsd"/>
<xsd:include schemaLocation="Product.xsd"/>
<xsd:element name="Company">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/>
<xsd:element name="Product" type="ProductType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
• Recognize that with XML Schemas you will not be able to express all your business rules.
o Express those business rules using XSLT.
• Use type definitions
Elements vs Attributes
• Use attributes for metadata about the parent element.
• Use attributes for data that is semantically tied to the enclosing element.
• Use elements for data that have a meaning separate from the enclosing element.
• Use attributes when the value will be frequently present in order to improve the human readable form of an XML instance document or reduce its size.
• If you don't know which to use, then use the element form (which is more extensible).
2.1.1 Element, Types and attribute names
Create a descriptive name without it being excessively long (no more than 32 characters).
Elements and Types should be named in Upper Camel Case. Upper Camel Case capitalizes the first character of each word and compounds the name (remove all whitespace).
Attributes should be named in Lower Camel Case. Lower Camel Case capitalizes the first character of each word except the first word and compounds the name.
Simple and Complex type names
XML Schema has separate symbol space for elements and types so they may have the same name. The best practice is to append the word "Type" to all simple and complex type names to aid in human readability and comprehension.
Element, attribute and type names MUST be in a singular form unless the concept itself is plural.
2.1.1.1 XML Schema versioning
Use major and minor version tracking:
Major—completely different structure and semantics, most likely not backward compatible
Minor—backward compatible changes which introduce new features without removing or changing the semantics of existing structures
2.1.1.2 Indication of version in the namespace URI
Specify a namespace URI as follows
http://$domain/$groupSpecifier/$namespaceTitle/$version
The groupSpecifier can include several levels, e.g., /www.soa.com/SOA/USA/.
An example namespace could be:
http://www.soa.com/SOA/order/2

Question about CEP Naming Conventions and or Standards

Hello,
CEP is new to the organization that I am working with. I have been asked to draft a few standards around CEP to help promote standardization and proper reuse of CEP artifacts. Can anyone share with me examples of CEP artifacts with a naming convention or their experiences with naming conventions around CEP in general. This is a living standards document for us. We plan on using CEP heavily going forward. Your experiences will help us start off on the right foot.
Thanks in advance,
JJE
Spelling Edited by: JJ.Everett on Sep 7, 2010 11:16 PM

Hi,
Oracle CEP supports reuse of components in several ways. For example, you can design your application as a set of modules that can be deployed independently (different teams can develop each module). Modules can register services, such as an event source or event consumer, and these services can be used by other modules. So, it's possible to plug modules developed by different teams of developers together and reuse them in different applications or environments. A component instance registers itself as a service when its advertise attribute is set to true in the Spring application context that defines a module.
A component implementation can also register a factory as a service that allows instances of the component to be created by other modules. Section 13.1.5 in the CEP Developer Guide describes this. http://download.oracle.com/docs/cd/E14571_01/doc.1111/e14301/adapters.htm#CIHBHEDA
Hope that helps.
Regards,
Seth

Naming conventions for CAF?

Hi,
Where can I find naming conventions for CAF?
Regards,
Rahul

Hi Rahul,
Perhaps this [thread|Re: creating development component projects(CAS)] answers your question.
Regards,
Jan

Standard Naming Conventions in XI

Hello,
Pls send pdfs/links for Naming Conventions in XI
Regards

Hi Henry,
These r the naming conventions to be followed in XI :
1) For Software Component, the naming convention should be :
 SAP_<SID>
where <SID> is the system ID if the applicable system
2) For Software Component Version, the naming convention should be :
 X.X
which shows the applicable version as of this date. Eg. SAP_ECC is at version 5.0
3) For Namespace the naming convention should be :
http://ERPGenie.COM/xi/<SCENARIO>/<SID>
where scenario refers to the interface being developed for and <SID> is the component where that object has relevance.
Eg. http://ERPGenie.COM/xi/OrderOutput/ECC will contain all the objects relevant to the Order Output scenario in the ECC system.
4) In Interface Objects ,
a) Message Interface should have the following naming convention :
MI_<meaningful name>_<IN/OUT/AB>
where:
IN = Inbound
OUT = Outbound
AB = Abstract (For BPM)
Remember to evaluate the IN and OUT based on the point of view from the source system to the target system. Eg. If we send an XML message from xEXTERNAL to an IDoc in ECC, then the XML Message is an OUT and the ECC is an IN interface.
b) Message Type should have the following naming convention :
MT_<meaningful name>
c) Fault Message Type should have the following naming convention :
FMT_<meaningful name>
d) Data Type should have the following naming convention :
DT_<meaningful name>
e) Data Type Enhancements should have the following naming convention :
DTE_<meaningful name>
f) Context Object should have the following naming convention :
CO_<meaningful name>
g) External Definition should have the following naming convention :
ED_<meaningful name>
5) In Mapping Objects,
a) Message Mapping should have the following naming convention :
MM_<meaningful name>_<source type>_<target type>
Eg. MM_ORDERSCENARIO_ORDERS05_OrderXML
b) Interface Mapping should have the following naming convention :
IM__<meaningful name>_<source type>_<target type>
Eg. IM_ORDERSCENARIO_ORDERS05_OrderXML
c) Mapping Templates should have the following naming convention :
MT__<meaningful name>_<source type>_<target type>
d) Imported Archives should have the following naming convention :
IA_<meaningful name>
6) In Services
a) Business Systems should have the following naming convention :
SAP<SID>
Where <SID> is the relevant system ID number
E.g.. SAPECC, SAPCRM, SAP46C
b) Business Services should have the following naming convention :
SRV_<XXXXXX>
Where XXXXXX is up to 6 characters to describe the type of service.
E.g. SRV_MAIL, SRV_FTP, SRV_SEEBRG
7) In Adapter Objects,
a) Adapter Meta Data should have the following naming convention :
AM_<meaningful name>
b) Communication Channel should have the following naming convention :
CC_<meaningful name>_<sender/receiver>
 E.g. CC_MAIL_SENDER
8) In Integration Objects,
a) Integration Process should have the following naming convention :
IP_<meaningful name> (Keep to 10 or less characters ALL CAPS)
 Store these in namespace http://ERPGenie.COM/xi/<SCENARIO>
b) Actions should have the following naming convention :
<meaningful name>
Use Send_ or Receive_ to denote the sending or receiving of messages
Store these in namespace http://ERPGenie.COM/xi/<SCENARIO>/<SID> where <SID> is system where the action is to be performed.
c) Integration Scenarios should have the following naming convention :
IS_<meaningful name> (Keep to 10 or less characters ALL CAPS)
The following web-sites may be helpful for complete naming standards in XI :
http://tsr.strain.at/space/SAP+XI(This web-site gives all detailed information about XI)
http://www.erpgenie.com/sap/netweaver/xi/namingconventions.htm
*********Please reward points if u find this useful.
cheers,
gyanaraj

SAP naming conventions: customer DDIC objects, ABAP programming

SAP Note 16466 Customer name range for SAP objects contains the SAP naming conventions for customer DDIC objects. Rule of thumb is that the names reserved for customer objects start with 'Y' or 'Z'. However, this note contains the naming convention for DDIC objects only.
ABAP Code Inspector (transaction SCI) contains the following naming convention for ABAP programming:
- Global types: T_
- Global constants: C_
- Global data: gv_
- Global field-symbols: FS_
- Global parameters: P_
- Global select-options: S_
- Global field-groups: FS_
- Local types: LT_
- Local constants: LC_
- Local data: v_
- Local field-symbols: LFS_
This is the only place I know for ABAP programming naming convention. Does SAP has somewhere else any additional naming convention guidelines for ABAP programming?
Thanks in advance for your help.
Regards,
Jarmo Tuominen

Naming convention guidelines for ABAP programming is available in here: [Manage Successful Customer Development|https://websmp206.sap-ag.de/~sapidb/011000358700004444532001E].
Naming Data Types and Objects
The names of data types and objects have the form: <Classifier>_<Data type>_<Descriptor>.
The names of data types and objects have up to 30 characters.
Exceptions: names of input parameters and select options have up to 8 characters, and <Data type> and _ are omitted.
First component: Classifier
T Data type
C Constant
G Global data object
L Local data object
FS Field symbol
P Input parameter
S Select option
P Formal parameter in form
FM Formal parameter in function
Second component: Data Type
<t> Elementary data type, optionally followed by length
C<n> Type C of length <n>
N<l> Type N of length <n>
X<l> Type X of length <n>
D Type D
T Type T
I Type I
P<d> Type P with <d> decimals
F Type F
WA Work area
IT Internal table
Third component: Descriptor
Use meaningful English names. Later, your code may be maintained or analyzed by a programmer or support consultant who is not familiar with another language.
Use only alphanumeric characters (A-Z and 0-9) and separate words with underscores (_). Hyphens are reserved for separating components in structured data types.
Examples:
G_I_COUNTER (global counter)
T_IT_BOOKING_LIST (type for list of bookings)
G_IT_BOOKINGS (global internal table of bookings)
PSMOKER (input parameter for smoker flag: note omission of data type and _ for brevity)
Edited by: Jarmo Tuominen on Feb 21, 2011 2:13 PM

Naming Convention and way to locate Table Names in B.I

Hello All,
I like to know information about
How to find a table
Naming convention of table
Important Tables
I will be thankful ,if anyone provide this information..

Hi Path,
I will provide information what i had got through various sources...
1) Identifying Table
The best way to find out from which tables the data source is getting updated is to search in help.sap.com by using the selection criteria "datasource and the name of the data source".
This displays a table which gives the name of the fields and the table names
2) Naming Convention
1./bic/f (cube name) is the fact table of a content cube
2./bic/D (cube name) P is the package dimension of a content cube
3./bic/D(cube name) U is the unit dimension of a content cube
4./bic/D(cube name) T is the time dimension of a content cube
5./bic/D(cube name) I is the user defined dimension of a content cube
6./bic/m (object name) master data of object
7./bic/t (object name) text data of object
8./bic/H (object name) hierarchy data of object
9./BIC/I* SID Structure of Hierarchies
10./BIC/K* Conversion of Hierarchy Nodes - SID
11./BIC/P* Master Data (Time-Ind.): Characteri
12./BIC/Q* Master Data (Time-Ind.): Characteri
13./BIC/S* Master Data IDs: InfoObject
14./BIC/T* Texts: Char.
15./BIC/X* Attribute SID Table: InfoObject
16./BIC/Y* Attribute SID Table (Time-Dep.):
17./BIC/B* Transfer structure PSA/Changelog
18./BIC/A* ODS Active records
19./BIC/F* Info cube F-Fact table
20.BIC/E* Info cube E-Fact table (compressed records)
21./BIC/D* info cube dimension tables
3) Important tables
I has collected some important tables that may help you..
authorization:
RSSTOBJDIR (Management Table for Authorization Objects): Link between specific authorization object and Info source (table used by transaction RSSM)
InfoPackage
RSLDPIO Links datasource to infopackages
RSLDPIOT InfoPackage Text Description
RSLDPRULE ABAP source code for InfoPackages
RSLDPSEL Hardcoded selections in InfoPackages
ProcessChain
RSEVENTCHAIN Event Chain Processing Event Table
RSEVENTHEAD Header for the event chain
RSEVENTHEADT Header for the event chain
RSPCCHAIN Process chain
RSPCCHAINATTR Attributes for a Process Chain
Queries
RSZELTDIR Directory of the reporting component elements
RSZELTTXT Texts of reporting component elements
RSZELTXREF Directory of query element references
RSRREPDIR Directory of all reports (Query GENUNIID)
RSZCOMPDIR Directory of reporting components
Workbooks
RSRWBINDEX?
List of binary large objects (Excel workbooks)
RSRWBINDEXT?
Titles of binary objects (Excel workbooks)
RSRWBSTORE?
Storage for binary large objects (Excel workbooks)
RSRWBTEMPLATE?
Assignment of Excel workbooks as personal templates
RSRWORKBOOK?
Where-used list for reports in workbooks

Forcing naming convention for queries and views

Hello Friends,
Can anyone tell me how to Force user to save queries with starting letter 'Q' and all views with 'V'.
I know how to restrict queries ..
Please tell me how to Froce Views to save with first letter 'V'.
Thanks,
Ram

you need these values in your role to restrict them save queries with starting letter 'Q' and all views with 'V'.
S_RS_COMP
         RSZCOMPID-Q*
         RSZCOMPTP - REP
S_RS_COMP
         RSZCOMPID-V*
         RSZCOMPTP - QVW
S_RS_COMP1
         RSZCOMPID-Q, V
         RSZCOMPTP - REP,QVW
and as you know activity will be 01 for giving create ability, don't forget to restrict on infocube and infoarea. one thing you have to rethink is why you want to use Q, V as a starting letter, I would prefer Y,Z.
and lot of companies do restrict for different naming conventions on different infoarea/infoprovider. just a casual suggestion, it will be better for your company in future, if you restrict the reporting component's naming conventions more specific. something like Zinfoprovider name_reporting component_*.
regards
Message was edited by:
        Keerti Vemulapalli

Naming convention table name Java

Dear expert,
I know that in the ABAP world, when I create a custom table, it have to start with Z.. or Y.. in the name.
Is this the same when I need to create a table in the Java schema?
Thanks for you help.
Mario

Hi, Ferruccio,
In the Java world, table naming conventions apply when you define your tables in the Java Dictionary (which is a metadata representation of a real database).
The names of tables that are defined in the Java Dictionary should:
- begin with a prefix (for example, the name of a component FI_*);
- not exceed 18 characters (including the prefix);
- not contain Open SQL keywords (for example, SELECT, INSERT, UPDATE, MODIFY and DELETE);
- contain only permitted characters, i.e. letters, numbers, and underscores.
I hope that helps!
Regards,
Yordan

Naming convention for Swing components?

What are the official naming conventions for Swing components such as JButton, JFileChooser and so on?
I know that "btn" is used for JButton variables. But where is a official list for all the prefixes?

Well, if you unpack src.jar and consult the component classes you'll find how they set up their names.
You can also call setName yourself to set a different name.
- David

Proper naming conventions for events?

I am finally starting to understand custom events, but I
admit that despite what I have read I am confused at the proper way
to name events and their parts, or when multiple events can be part
of the same class.
For example, attached is an even I created for a quiz that is
dispatched when the user makes a choice in my choice mxml
component.
The dispatch is like this:
this.dispatchEvent(new ChoiceMade(ChoiceMade.CHOICE_MADE));
It seems a bit dumb to have ChoiceMade.CHOICE_MADE. Is there
a better naming convention?
Also, many of the built-in events have "sub-events" such as
MouseEvent having MOUSE_CLICK, MOUSE_OVER, etc. How do I set it up
if I want to have this class able to dispatch more than 1 event,
such as CHOICE_MADE, WRONG_ANSWER, etc?

Yes... but. ( There's always a but! )
You certainly can, and often times should, have Event
constants for specific 'events'.
But other times you should have a more generic 'transport'
event. i.e. ChoiceEvent.MADE which as a custom event also accepts a
parameter and passes it along. This way the event 'transports' some
vital piece of info.
See example code below.
This custom event allows you to (optionally) pass the
answer/choice made along with the event. You can then put your
logic on either side of the event... either deciding the choice was
right/wrong/other and dispatching a right/wrong/other event... or
dispatching a MADE event, and including the answer in that event so
that whomever is listening can do whatever they need to/with the
answer.
~ Bart

XI naming conventions

Hello,
can anybody send me a naming conventions document that could be used for XI development?
my email id is [email protected]
Thanks a ton,
Arjun.

Arjun,
Go through this ASAP methodology where you will find with explanations:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/2791db90-0201-0010-dea7-ec869d783f9c
https://websmp207.sap-ag.de/~sapidb/011000358700004455192006E/NameConventions.pdf
Please go through this urls where you can find some documentation of your query:
/people/michal.krawczyk2/blog/2005/04/09/xi--saps-document-templates
/people/thorsten.nordholmsbirk/blog/2006/07/25/structuring-integration-repository-content--part-1-software-component-versions
/people/alwin.vandeput2/blog/2006/06/07/d-xie-soap-part-4-xi-software-component-architecture-for-point-to-point-scenarios
/people/sap.india5/blog/2005/11/03/xi-software-logistics-1-sld-preparation
Also go thru this blog from Michal- go to Documents Section-
/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions
Go through this threads also:
Naming convention in a real time XI project
Building XI
Re: XI Documentation
---Satish

Storage Location Naming Convention without WM!

Dear all
We are facing serious problem in our Storage Location for Raw Material.
We have 4 types of Raw Material Seating (S), Panel (P), Metal (M), Wood (W). And they are all stored under Storage Location: RWSL.
Requirement:
Although we have visual guideline as to which industrial rack will store the type of Material, it is insufficient. We need a more refined storage location down to which BIN of the rack we will put the Raw Material.
Due to limited time and resource, we cannot have WM implemented right now. Thus, we have come out with 2 alternative to overcome this problem:
Alternative 01:
We will use the Fixed Bin field in Storage Data 02 by putting the Bin number assigned to each Rack.
E.g. For Seating material code:SEAT01, we will maintain the Fixed Bin as R12A01/A02, it means this Seating material SEAT01 will be stored at Rack 12, fixed bin A01 or A02.
Question to Alternative 01: Will it cause problem in GR, GR, Transfer Posting and Stock Count?
Alternative 02:
Instead of going into details to put Fixed Bin field in Storage Data 2, we will abandan the existing Storage Location RMSL by introducing new format for Storage Location
Here is the example of Alternative 02:
For raw materials, we will use 4 digits location numbers, consistent with other Storage locations, the 4 digits storage location will start with u201CR _ _ _u201D to represent each location
And,
R _ _ _ is:
R = Raw materials
2nd digit = Division (S= Seating, P =Panel, W=Wood, M=Metal and W=Wood)
3rd digit = Rack Number (A, B, C, Du2026 and etc.)
4th digit = Rack Zone - each rack will broken down into zone, each rack can possibility have 2 to 3 zone. 1 Zone can be 1 colume of the Rack
An example of a possible location and its meaning will be
RSA1 = Raw materials warehouse, Seating division, Rack A, Zone 1
RPB3 = Raw materials warehouse, Panel Division, Rack B, Zone 3
The challenge of this is that instead of having 1 Raw Material Storage Location like RMSL, we will have a lot more storage locations each for division of Raw material due to the Rack Number we have as well as the Rack Zone.
Question to Alternative 02:
If we use this alternative, will it impact our future implementation of WM? From design wise, is it feasible?
Please advise what is the best approach and the feasible design on it.
Many thanks in advance.
Edited by: Daimos on May 13, 2009 10:15 AM

Hi, here is the Pro and Co of both approaches:
Method 01: Use existing SLOC and add the Storage Bin info
e.g. SLOC: STM1
         Storage Bin: RSC3, where RS = Rack Seating, C3 = column 3
Pro 01:
It will cause less effort as we only need to use LSMW for material master to add in the Storage Bin data for all material of SCM.
Pro 02:
I have tested out that in TCode MIGO, apart from SLOC, the pertaining Storage Bin data also appear. Based on my discuss with Xian Chen, sometimes they use MB1C(GR), MB1A(GI) rather than MIGO due to speed issue, I will need to check the field status if can have Storage Bin field APPEAR, if can, it will solve the problem
Con 01:
The Storage Bin information will only appear in MMBE (Stock Overview) but will not appear in the standard SAP Inventory Report (e.g. MB52 Warehouse Stock). To view it from SAP Inventory Report, we may need to customize the standard report to show the new field Storage Bin. It needs Abap effort.
Con 02:
We must have a very good naming convention for Storage Bin. And again, in the above example, if a material is put in SLOC STM1 at Storage Bin RA A1 or C4, it will set a very rigid rule in the future if we need to change it, as I fear that one the Storage Bin has been used up. It will not allow us to change (need to do testing to find out)
Con 03:
Do we have the time to define all the Storage Bin for each SLOC? Operation wise, the store personnel needs to design it
Method 02: Use the new SLOC
Pro 01:
RSA1 = Raw materials warehouse, Seating division, Rack A, Zone 1. More organized. Easy to tell the material is at which Rack and which Zone of the Rack.
Assumption:
01. we must not have too many rack for one Seating division and also not too many Zone for each
      Division, else it will cause confusion
02. 1 material should stick to 1 Rack 1 zone as much as possible, else later the PP consultant will
     have hard to to perform GI due to too many SLOC assigned to a material.
Pro 02:
In report wise, we are able to show the SLOC in inventory report. No need to enhance the existing inventory report as we do not use Storage Bin.
Con 01:
If there are too many SLOC creation due to it. It may cause problem for PP perform GI as too many selection available for a material. This can be avoided if stick to the General Rule that one material is tied with one SLOC.
Edited by: Daimos on May 16, 2009 5:07 AM

File name naming convention in File Adapter configuration in ID

Hi All ,
I have a query related to xml filename created in IDOC-XI-FILE scenario based on value of one of IDOC field .
The scenario is like this :
I have to send one xml file per store for material master . In this case how can I define my file name with store name in File adapter configuration in ID .
Naming convention should be
<storename>_date_masterdataname.xmlwhere store name is one of field of IDOC .
Plz help me .
Thanks in Advance
Regards
Prabhat Ranjan

Hi Prabhat,
take a look at this weblog:
/people/jayakrishnan.nair/blog/2005/06/28/dynamic-file-namexslt-mapping-with-java-enhancement-using-xi-30-sp12-part-ii
you have to specify variable substitution
(in the file adapter)
and give the path to the store name (in the variable sustitution table)
you file name schema (from the file communication channel can look like this)
%storename%_date_masterdataname.xml
Regards,
michal
Message was edited by: Michal Krawczyk

Is it possible to control the naming convention used by Aperture when importing photos? If so, how

When I import photos from my camera, I have them placed into projects based on the date the photos were taken. However, I do not like the naming convention used by Aperture as it causes the projects to sort into a non-chronologial order. The convention is MMM-DD-YYYY and I want to change it to YYYY-MM-DD. Is it possible in Aperture 3.2.4 to do this?

In the Import panel you can edit the preset for the file name format to "Image year - image month - image day - index" for example; the preset for folder names seems to be gone in Aperture 3,3 - at least I cannot find it any longer. You only seem to be able to enter the folder name manually in the Import panel.

Component naming conventions

Similar Messages

Maybe you are looking for