Update existing package - naming convention/workflow questions

OK, so we have an existing package:
Adobe_CS6_MasterCollection_en_US_20120910_Install.pkg
Fast forward 1 month...
We now want to update the package so it has latest patches and so it is also renamed:
Adobe_CS6_MasterCollection_en_US_20121010_Install.pkg
How do we do this with AAMEE 3.1...there doesn't seem to be an opportuntity to rename the package.
Is it safe to simply rename the package before we begin to update it? Or can/should we rename it after we have updated it?
And what do we rename...just the *.aamee file? Or do we also need to rename the existing packge that we are updating? Before or after?
Lots of questions....
Our goal/intent is to be able to provide monthly or quarterly updates...this would require our naming convention to show correct date on the package.
Thanks,
Don

Hi,
I understand your problem about maintining the AAMEE packages without renaming them. May be a low cost solution for you right now is to add 1 more level of folder structure where you dont rename the AAMEE packages (and AAMEE package folder name) but rename its parent folder.So if you have an X.pkg made inside X folder on mac, keep this X folder inside Y folder. And you can change this Y manually after successfully updating the package to reflect current status. Doing this, you you are actually changing the path where the AAMEE package is kept on your machine but not the package itself. So you can keep modifying the current package and still maintain the version information.
I completely agree with rahul that the ability to rename the AAMEE package after modifying it is a good utility, but right now this solution may help you in maintainence.
Thanks,
Saransh Katariya | Adobe Systems | [email protected]

Similar Messages

  • Preferred package naming conventions for plug-ins?

    Every combination seems to be in use already...
    VIM plug-ins are vim-plugin_name
    XFCE plug-ins are xfce4-plugin_name-plugin
    GIMP plug-ins are (mostly) gimp-plugin-plugin_name
    I plan on making some plug-in packages for a application what dose not currently have any available. So as the topic says what's preferred package naming convention? I personally like the GIMP format best but just figured I'd ask first (should really be in the guidelines IMO).

    Ok well I guess I'll use the third option for now them.
    While we're talking about naming conventions I was just searching for the python cairo library noticed binding library's could do with some guidance to...
    cairo-perl
    pycairo
    ruby-rcairo
    IMO language-library_name would be a nice guideline.

  • Change Existing objects naming conventions in a Query

    Hi all,
    I Need to change the Naming Conventions of the Query Objects of a Query at the Infoprovider level. Is there any Routine to change the naming conventions or do i need to do it Manually.

    Hi gopinath,
    mine is also a similar case, the problem with the option u gave me is that our implementation is in EDW environment and rework from the scratch is not an option for me. Is it possible to change the query objects naming convention at particular info-provider level, i have about 200 objects created with random naming convention and to be now changed according to a standard naming convention. I need to also consider how the changes effect other queries and reports as well.. So is there any possible way of Custom coding a routine or a program that can solve my purpose.. has any one gone through the same situation?
    thanks,
    kishore

  • -cvs, -git, -snv... is really a good naming convention?

    The unstable packages have the name of their relative stable one with added in suffix the concurrent version system installed.
    I think it is a bad convention since it mixes implementer choices with the the concept of lastest unstable version.
    I think it is better decide a single suffix (e.g., -unstable or -dev) and always use it without difference between the implementer choices of programming.
    Moreover it avoids renaming headaches if someone changes program for keeping versions.
    No flame wars. I decide nothing. It is only a thought.

    Profjim wrote:
    I've seen this discussed before on the forums...
    Edit: http://bbs.archlinux.org/viewtopic.php?id=25938
    I found this in the forum search: http://bbs.archlinux.org/viewtopic.php?id=25938
    It doesn't seem like anything came out of that discussion. I haven't really found the naming convention confusing; it is the large variety of SCMs that is confusing, and that is not going to change anytime soon. The current package naming conventions are unproblematic for me so you'd have to point out exactly where a real problem has cropped up.

  • Sdl_image vs. xf86-input-mouse naming convention

    This is really a minor issue, but I just wanted to point out that, people, we should pick either underscores or hyphens.  Because mixing them just gets confusing.  I realize it can be really hard to make all package naming completely perfect, because of the whole problem where you have to kind of name a package after the application contained therein.  But you know, it's just a thought.
    I'm switching to Hyphen Linux: "We Have Our Package Naming Conventions Totally Under Control." 
    Oh, and I'll say it first:  "Yawn..."   

    The reason for this: it's following upstream stuff. xf86-input-mouse is named this way upstream, sdl_image is also named this way upstream.

  • Package naming structure

    Hi folks,
    Now that we have had HANA for almost two years and our content offering has matured we are taking a look at our package naming conventions and pros and cons to our current package layout.  For example we have organized all of our content based upon functional area;  ie: FI, PP, SD, MM, etc and finally MD for all of our master data (mostly attribute type views).  I was just wondering how some of you are laying out your packages?  Are you organizing like this or something similar?  The pro for this method is if you want to find all your sales related views you can look in SD package however some projects cross multiple functional areas and that's sometimes the con for this method, it can be cumbersome to identify all of the different views that were related to the original project for example.  Just wondering how others are doing this.
    Thanks,
    -Patrick

    There was nothing wrong with CS6 in this situation, it was that the package name of the specific extension I was trying to use that was horribly named, to the point you had to repeat the class name twice, which means most developers would only put it once and it wouldn't work. Being that this was the first native extension I tried to run, it seemed that the native extension feature didn't work.
    Say your name is Bob Smith and you make a native extension that runs your hardware camera as a flashlight.
    If you name the class FlashLight and the package name com.bobsmith.nativeExtensions.FlashLight
    people would have to put
    import com.bobsmith.nativeExtensions.FlashLight.FlashLight;
    or
    import com.bobsmith.nativeExtensions.FlashLight.*;
    to import it. And that woudldn't  make much sense. "FlashLight" is the name of the class. If the class and the package subdirectory have the exact same name, people are going to think the package subdirectory is the class.
    Most people trying to import it would put
    import com.bobsmith.nativeExtensions.FlashLight;
    or
    import com.bobsmith.nativeExtensions.*;
    in which case it wounld not work.
    A non-insane way to name your package would be com.bobsmith.nativeExtensions.hardware
    Then one could put
    import com.bobsmith.nativeExtensions.hardware.FlashLight;
    or
    import com.bobsmith.nativeExtensions.hardware.*;
    That would make sense, either importing the FlashLight hardware feature or all hardware features in the package.

  • ThinApp Updated Package doesn't update existing Sandbox files

    This has to be a common problem, but the discussion topics are not quite the same scenarios. I must be using the wrong search terms to search by in the forums.
    First, the issue in simple terms.. and then greater detail:  I'm having an issue where a very simple app is created, but if the app is re-built with only a couple of changes, not all files in the "existing" users's Sandbox will be updated to reflect the change.  Meaning, if I maintain the same Sandbox path, and it is reused on the updated app, the sandbox will sometimes continue to use the old files from the prior build.
    Example:  Let's say the package consists of...
         ThinApp_Package.exe  (living in \\networkshare\AppHome)
                   App.exe  (original)
                   xxx.dll
                   yyy.dll              
                   user_settings.ini
                   another_config.ini  (original)
          SandboxPath=D:\SandboxFolder\
          SandboxName=App-Saved-Files           (Sandbox shows the original files above just fine)
    Now, if our developer creates a new "app.exe" and it uses a new statement to Read/Write in the "config.ini", I will recompile the app with those two files updated.
    When the new ThinApp package is launched, the new binary "App.exe" will be correct, but the "config.ini" that is being referenced is the OLD, prior file that exists in the Sandbox.  The Sandbox never updates it.
    If I delete the Sandbox, it will be recreated with the new and proper "config.ini" (but, of course all other custom settings for that user is lost).
         Rebuilt_and_Updated_ThinApp_Package.exe  (living in \\networkshare\AppHome)
                 App.exe  (updated)
                   xxx.dll
                   yyy.dll              
                   user_settings.ini
                   another_config.ini  (updated)
          SandboxPath=D:\SandboxFolder\
          SandboxName=App-Saved-Files          
    (The updated "App.exe" runs fine and as expected, but continues to refer to the original "another_config.ini" in the Sandbox from the prior build and does not update... so I have no choice but to delete the Sandbox and lose the users settings)
    More details:  If this is not a common, simple issue (which, I'm sure it is, and I'm overlooking something... I'm not too skilled with ThinApp).
    The App is centrally hosted on a network share (has run this way since Thinstall days), I don't recall the issue before, so I must be triggering it somehow.
    The overall age of the sandbox is not that old.  I can recreate the issue starting with a new Sandbox and then updating the package once.
    The Sandbox is a forced path to the Local User's D_Drive, in a common accessible area for all.
    The Package is WRITECOPY, except for the one sub-folder where the EXE and INI exist, that one folder is FULL (This is due to the App needing to be on the C: drive, but the current company Administrative rules won't allow writing to the C: Drive.
    It is an older 32bit, Visual Basic compiled app, running on Windows 7 (64bit).
    Just as a quick test I have asked the developer to always write a new "config.ini" that creates a time entry on launch, so that the file is forced to be changed (thinking a forced change in the file should force it to the sandbox... but that has no affect, it still does not update the sandbox.
    We have several, similar programs of that hosted in the same manner.. and have for years.  But, it appears that this one is giving me a hassle and I cannot pinpoint the change that causes this behavior.
    So, I guess a general question is, "What is the decision process within ThinApp that would direct the application to view Sandbox Content over -internal- compiled content if the internal content is newer or different size?"  The only common thing between the compiled content and sandbox content is the file name.
    Thanks for helping an amateur.

    Hey there, thanks for the reply.  The project's Default isolation is "WriteCopy".  But the folder that contains the config.ini file is "Full".  (stated in the original post).  You can view the INI the sandbox just fine, as expected... except now it is not updating with the one in the package.   There was never an answer, so I had no choice but to delete the Sandboxes... it is fine now.  But it would be nice to know how/why ThinApp will suddenly misbehave and not update the file.  Reading some undertones in other posts, it seems to happen now and then.
    Thanks again.

  • Export-Import and Naming convention question

    All,
    Newbie here. Have a question related to the naming convention for SAP R/3 system and XI manual export/import process. We are currently in the development environment where our R/3 systems are named as D55CLNT400, D56CLNT300 etc (first 3 characters are the system id, and last 3 are the client number.) This is per the XI best practices convention.
    The question i have is - if we name the technical system as above - and export the configuration objects from the Dev to Test environment - where the R/3 systems are named as T55CLNT400, T56CLNT300 (similar naming structure). Does it mean that we need to manually change almost all of the items in the Test environment on the configuration side (like business sytem name, interface determination, receiver determination etc)
    Is this the correct way or are we missing something??? I would have preferred a way - where we needed to only update the communication channel parameters.
    Thanks.
    Message was edited by:
            thezone

    In the SLD, create three Business System Groups: DEV, QAS and PRD.
    In each of these groups, you must have the relevant application servers (in your case, R/3s) and one integration server (XI).
    Then, for each Business System in Group DEV, define a transport target in QAS group.
    In your case, the transport landscape should be like this:
    D55CLNT400 -> T55CLNT400
    D56CLNT300 -> T56CLNT300
    XI_DEV -> XI_QAS
    Do the same for the QAS group (defining transport targets in PRD group). Observe that you need to have the same number of Business Systems in each group for this to work properly.
    Now, when you transport your configuration objects from XI_DEV to XI_QAS, all the Business Systems in DEV landscape will be replaced for the equivalent ones in QAS landscape.
    More info: http://help.sap.com/saphelp_nw2004s/helpdata/en/ef/a21e3e0987760be10000000a114084/frameset.htm
    Regards,
    Henrique.

  • Naming convention for packages and classes

    Hi all,
    Is there any naming conventions for packages and classes which uses a design pattern ?. If yes what are the conventions used for business delegate,session facade, service locator,DAO and any other patterns.
    rgds
    Anto Paul

    Hi,
    that is a good question and one we have considered also. We dont yet cover the naming conventions for classes based on patterns but maybe will in the future. Currently, in the blueprints apps we tend to do some things like naminga class
    -AccountDAO etc for DAOs
    -For servicelocator we have a class called ServiceLocator viewable at https://adventurebuilder.dev.java.net/source/browse/adventurebuilder/ws/components/servicelocator/src/java/com/sun/j2ee/blueprints/servicelocator/web/ServiceLocator.java?rev=1.4&content-type=text/vnd.viewcvs-markup
    -for session facade, its a bit trickier since the name is so long and we cant add "SessionFacade" to the end of each facade class. I think in general we put "Facade" in the name, usually near the end
    -For Business Delegat, again it seems too long to add to each class name. So in the past we have added
    a "BD" to the names of the delegates. Some examples are at http://java.sun.com/blueprints/patterns/BusinessDelegate.html
    -For transfer objects we usually add a TO to the end of the name. Some examples at http://java.sun.com/blueprints/patterns/TransferObject.html
    Seems like something we could get a bit more consistent about.
    hope that helps,
    Sean

  • Non-technical question about naming conventions used in API

    What does the prefix `PF_` stand for in all the function names in the AE SDK?  It's not immediately obvious to me, and was just curious.  I like to have a sense of how the naming conventions came to be when I'm learning new code.
    Thanks!

    Interesting question.  PF is the abbreviation for the Plug-in Filter package in After Effects.

  • [svn:fx-3.x] 12371: The main AccImpl was updated to handle accessible naming conventions differently than before .

    Revision: 12371
    Revision: 12371
    Author:   [email protected]
    Date:     2009-12-02 08:51:12 -0800 (Wed, 02 Dec 2009)
    Log Message:
    The main AccImpl was updated to handle accessible naming conventions differently than before.  This change was made to make the 3.x branch consistent with the trunk changes.  The updated methods allows the accessibilityName property to overwrite the logic that was previously used to build the accessible name for components that were inside of forms.  This method also provides a method to allow developers to specificy that no form heading or form item label should be included in the accessibilityName for the form field by using a space.
    QE notes: none
    Doc notes: none
    Bugs: n/a
    Reviewer: Gordon
    Tests run: checkintests
    Is noteworthy for integration: no
    Modified Paths:
        flex/sdk/branches/3.x/frameworks/projects/framework/src/mx/accessibility/AccImpl.as

    Revision: 12371
    Revision: 12371
    Author:   [email protected]
    Date:     2009-12-02 08:51:12 -0800 (Wed, 02 Dec 2009)
    Log Message:
    The main AccImpl was updated to handle accessible naming conventions differently than before.  This change was made to make the 3.x branch consistent with the trunk changes.  The updated methods allows the accessibilityName property to overwrite the logic that was previously used to build the accessible name for components that were inside of forms.  This method also provides a method to allow developers to specificy that no form heading or form item label should be included in the accessibilityName for the form field by using a space.
    QE notes: none
    Doc notes: none
    Bugs: n/a
    Reviewer: Gordon
    Tests run: checkintests
    Is noteworthy for integration: no
    Modified Paths:
        flex/sdk/branches/3.x/frameworks/projects/framework/src/mx/accessibility/AccImpl.as

  • Naming Conventions for Workflow

    Hello,
    does anybody have a document for Naming Conventions for Workflow.
    I found nothing the last hour.
    Thanks in advance for any help ...
    Stefanie

    Hi,
    I am sending you naming convention which we followed in our project.
    Workflow Template & Standard Task:
    SAP/R3 Limitations:
    Workflow Template & Standard Task names are limited to 12 bytes.
    Standard:
    Bytes 1-3 of the Workflow Template & Standard Task (see following table) are intended to give an overview of general information regarding the Workflow Template & Standard Task.
    Characters 4-12 of the name should be chosen to impart some idea of the Workflow Template & Standard Tasku2019s use and/or contents.  (The portion of the Workflow Template & Standard Task name that forms the unique identifier may, or may not, contain underscores characters to enhance Workflow Template & Standard Task name readability.)
    Position     Description     Sample Values     Sample Meanings
    1     Table system life     Z/Y                Permanent/Temporary
    2     Application Type     *                    See Application Designators (Appendix B)
    3     OPCO/Region     *                    See OpCo Initial Chart (Appendix A) 
    4-12     Unique identifier     text                     Unique identifier; may include underscores
    Example: ZS7_IDEL9 (I:-Inbound, DEL: - OILDEL 9:- Original)
    Business Object:
    SAP/R3 Limitations:
    Business Object names are limited to 10 bytes.
    Standard:
    Bytes 1-3 of the Business Object (see following table) are intended to give an overview of general information regarding the Business Object.
    Characters 4-12 of the name should be chosen to impart some idea of the Business Objectu2019s use and/or contents.  (The portion of the Business Object name that forms the unique identifier may, or may not, contain underscores characters to enhance Business Object name readability.)
    Position     Description     Sample Values     Sample Meanings
    1     Table system life     Z
    Y     Permanent
    Temporary
    2     Application Type     *     See Application Designators (Appendix B)
    3     OPCO/Region     *     See OpCo Initial Chart (Appendix A) 
    4-12     Unique identifier     text     Unique identifier; may include underscores
    Example: ZS7_OILDEL (Business Object for OILDEL Message Type)
    Methods
    Method names should begin with a verb:
    Examples: GET_STATUS, CREATE_ORDER, DETERMINE_PRICE
    For Parameters:
    IMPORTING parameters     IM_<parameter name>
    EXPORTING parameters     EX_<parameter name>
    CHANGING parameters     CH_<parameter name>
    RESULT     RE_<result>
    Events
    Event names should have the form
    <noun>_<participle>:
    Examples: BUTTON_PUSHED, COMPANY_CODE_CHANGED, BUSINESS_PARTNER_PRINTED
    Note: There is no specific naming convention for Container Variables in workflow & for Key Fields & Attributes in Business Object. These variables name should be chosen to impart some idea of the variablesu2019 use and/or contents. 
    Appendix A
    ABAP Programming Standards:  OpCo/Region Initial Chart
    Old #     Company Name                               Proposed #     Accounting Location
    98     Common                                                     A              San Ramon
    95     FSC                                                     B              San Ramon
    80     Chevron Chemical Company                      C              San Ramon
    89     Chevron USA-Downstream & General     D     Walnut Creek
    75     Chevron Real Estate Management      E     San Francisco
    76     Chevron Information Technology Company      F     San Ramon
    77     Gulf Oil Great Britain                                    G     London
    85     Corporation (Acct. by Corp.)                    H     San Francisco
    83     Chevron International Oil company              J     San Ramon
    87     Chevron U. K. Limited                               K     England
    86     Corporation (Acct. - Local Office)                    L     Various
    96     P&M Coal & Mining Company                   M     Denver
    94     Corporation (New York)                   N     New York
    90     Chevron Pipeline Company                    P     San Ramon
    79     Chevron Canada Resources, Ltd.              R      Calgary
    92     Chevron Shipping Company                  S                     San Francisco
    81     Chevron Petroleum & Tech Co.                  T                     Houston
    91     Chevron USA Upstream                  U                     Concord
    78     Chevron Canada, Ltd.                              V                     Vancouver
    93     CUSA Warren Petroleum                  W     Tulsa
    84     Chevron Overseas Petroleum, Inc.            X                     San Ramon
    88     Chevron Research & Tech. Company        Y      Richmond
    -     Corp. GLX Common validations                   Z      San Ramon
    -     PCA                                                   3                     San Ramon
    -     Tax                                                   4                     San Ramon
    -     Audit                                                   5                     San Ramon
    -     Asia-Pacific                                   6                     Global
    -     Africa                                                   7                     Global
    -     Latin America                                   8                     Global
    Appendix B
    ABAP Programming Standards:  Application Designators
    A     Assets Accounting
    C     PPC
    D     DASS (control station)
    E     RIVA/IS-Oil
    F     Financial Accounting (incl. Joint Venture)
    G     General Ledger
    H     Human Resources Planning
    I     Plant Maintenance
    J     Publishing
    K     Cost Accounting
    L     Inventory Management
    M     Materials Management
    N     Hospital
    O     unassigned
    P     Human Resources
    Q     QSS (Quality assurance)
    R     PRA (Prod & Revenue Acctg)
    S     Basis
    T     Projects
    U     Enterprise Data Model
    V     Sales
    W     MMS (Merchandise mgt. System)
    X     unassigned
    Y     Customer head office
    Z     Customer branch
    <inappropriate content removed by moderator>
    Thanks
    Yogesh Sharma
    Edited by: Mike Pokraka on Jul 2, 2008 10:34 AM

  • 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

  • Question about Best Practices - Redwood Landscape/Object Naming Conventions

    Having reviewed documentation and posts, I find that there is not that much information available in regards to best practices for the Redwood Scheduler in a SAP environment. We are running the free version.
    1) The job scheduling for SAP reference book (SAP Press) recommends multiple Redwood installations and using export/import to move jobs and other redwood objects from say DEV->QAS->PROD. Presentations from the help.sap.com Web Site show the Redwood Scheduler linked to Solution Manager and handling job submissions for DEV-QAS-PROD. Point and Shoot (just be careful where you aim!) functionality is described as an advantage for the product. There is a SAP note (#895253) on making Redwood highly available. I am open to comments inputs and suggestions on this issue based on SAP client experiences.
    2) Related to 1), I have not seen much documentation on Redwood object naming conventions. I am interested in hearing how SAP clients have dealt with Redwood object naming (i.e. applications, job streams, scripts, events, locks). To date, I have seen in a presentation where customer objects are named starting with Z_. I like to include the object type in the name (e.g. EVT - Event, CHN - Job Chain, SCR - Script, LCK - Lock) keeping in mind the character length limitation of 30 characters. I also have an associated issue with Event naming given that we have 4 environments (DEV, QA, Staging, PROD). Assuming that we are not about to have one installation per environment, then we need to include the environment in the event name. The downside here is that we lose transportability for the job stream. We need to modify the job chain to wait for a different event name when running in a different environment. Comments?

    Hi Paul,
    As suggested in book u2018job scheduling for SAP from SAPu2019 press it is better to have multiple instances of Cronacle version (at least 2 u2013 one for development & quality and other separate one for production. This will have no confusion).
    Regarding transporting / replicating of the object definitions - it is really easy to import and export the objects like Events, Job Chain, Script, Locks etc. Also it is very easy and less time consuming to create a fresh in each system. Only complicated job chains creation can be time consuming.
    In normal cases the testing for background jobs mostly happens only in SAP quality instance and then the final scheduling in production. So it is very much possible to just export the verified script / job chain form Cronacle quality instance and import the same in Cronacle production instance (use of Cronacle shell is really recommended for fast processing)
    Regarding OSS note 895253 u2013 yes it is highly recommended to keep your central repository, processing server and licencing information on highly available clustered environment. This is very much required as Redwood Cronacle acts as central job scheduler in your SAP landscape (with OEM version).
    As you have confirmed, you are using OEM and hence you have only one process server.
    Regarding the conventions for names, it is recommended to create a centrally accessible naming convention document and then follow it. For example in my company we are using the naming convention for the jobs as Z_AAU_MM_ZCHGSTA2_AU01_LSV where A is for APAC region, AU is for Australia (country), MM is for Materials management and then ZCHGSTA2_AU01_LSV is the free text as provided by batch job requester.
    For other Redwood Cronacle specific objects also you can derive naming conventions based on SAP instances like if you want all the related scripts / job chains to be stored in one application, its name can be APPL_<logical name of the instance>.
    So in a nutshell, it is highly recommend
    Also the integration of SAP solution manager with redwood is to receive monitoring and alerting data and to pass the Redwood Cronacle information to SAP SOL MAN to create single point of control. You can find information on the purpose of XAL and XMW interfaces in Cronacle help (F1). 
    Hope this answers your queries. Please write if you need some more information / help in this regard.
    Best regards,
    Vithal

  • 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

Maybe you are looking for