Flag Dropdown Button

What is cProjects?
SAP cProject Suite supports you in project management and collaborative engineering by enabling you to exchange information such as project plans, documents, and product structures between virtual project teams via the Web. SAP cProject Suite consists of two parts:
· Design Collaboration with cFolders (cFolders)
· Collaboration Projects (cProjects)

cFolders is the Web-based collaboration platform for the PLM area. The application enables teams that work in product development in cross-enterprise scenarios to communicate and cooperate with each other. cFolders makes it possible for teams to exchange structured information as bills of material, data sheets, or customer-defined structures.

cFolders is integrated in SAP document management (DMS). It is also possible to use cFolders in the SAP Bidding Engine as a container for technical specifications.

Requirement at VS:

Since the product data starts in cProjects then flows to SAP RD(Recipe Development) and from there to the post development systems; if the data is transferred incorrectly to RD, there would be a break in the information chain and it would negatively affect downstream systems.
Current Functionality:
Currently, projects are created in cProjects to represent styles, and upon release, an interface creates or updates an Optiva program object. Each time the released project is updated in cProjects, the interface updates the corresponding program in Optiva. In addition, whenever the program in Optiva gets updated with cProjects data, the updates are pushed to the generics and variant BOMs in Optiva as necessary.

Desired Functionality:

Capability to automatically create and link a project to the finished good; and transfer certain attributes from SAP cProjects to the finished good object.

A cProjects project represents a style and should be mapped to one generic finished good.

The interface should automatically create or update the finished good based on certain cProjects attributes. The interface should automatically determine if there is an existing finished good or if a new one is needed. The identifier is the style number.

The following attributes are to be passed to the generic finished good:

– Project Description: generic finished good description plus “ – GENERIC”
– Style Type
– Article Type
– Article Category
– Season Year
– Theme
– Season
– Pricing Strategy
– Seasonal Product? (Yes/No)

• Capability to automatically create and link all of a project’s choice tasks to the variant finished goods.
• A cProjects project may contain one or more choices; each choice should be mapped to one variant finished good
• A cProjects project may contain one or more choice-specific tasks. All tasks need to be linked to the variant.

The following cProjects attributes define a variant:
– Style #
– Choice code (color/fragrance code)
– Packaging Type

The interface should automatically create or update the finished good based on these cProjects attributes. The interface should automatically determine if there is an existing finished good or if a new one is needed.

The following cProjects task attributes are to be synced to the variant:

– Color/Fragrance
– Packaging Type
– Working Name
– Expected Available for Distribution date
– Expected Available for Sale date

The variant finished good description is to be set as: <description of the generic minus “ – GENERIC”> plus <|> plus <color/fragrance description>. For example:
GENERIC DESC: VSCW_SPREV14TRAVEL_CASE- GENERIC
COLOR DESC: BLACK
VARIANT DESC: VSCW_SPREV14TRAVEL_CASE|BLACK

• Capability to automatically create and link the variant formula.
• Capability to automatically synchronize cProjects data with PLM data. Synchronization of data is one way for this interface – from cProjects to PLM. Each time a released project is saved, data for the corresponding finished goods (generic and variants) are to be updated with cProjects data.
• Capability allowing users to self-manage the transfer of data between cProjects and PLM. Users need to be able to view the status of the interfacing of data. Any errors should be made visible with user-friendly error messages to allow the possibility of users to correct the errors.

Proposed Functionality:

Overview:

All product development of finished goods (and gift sets) will start with a creation of project in SAP cProjects and then the information of this project is transferred to SAP RD upon release of the project. The interface will primarily perform the following main activities.

• Initial creation of specification and recipe shells as defined below
• Synchronization of relevant data fields from cProjects to RD
• Creation of an object link between cProjects (project definition & task level) and Specification
• Develop the Specification object link (covered as a separate FIRECW)
• Update Task status and actual finish dates in cProjects from PLM-RD if an existing approved Spec.is assigned as object link

The interface will automatically create a Specification and associated Recipe object in PLM and pass the following cProject fields to the Spec upon initial release of a project. If a change is made to a Released project, it should update objects with existing links upon each change.

This functionality should only occur when the project type = “Commercialization – Sub Project”:

Auto-Creation:

A generic specification/recipe will be created for each project for a new style, a variant specific specification/recipe will be created for each new choice contained in the project, and each Specification will have an object linked to the project definition and relevant tasks. System shall object link same Specification automatically to all relevant choice tasks for the same choice.

If the existing Style & Choice combination already exists in the system, the program should not create a new specification/recipe but rather assign the object links for Specification to the project task items. No Object link will be made to Recipes.

Future State Recommendation: using a task hierarchy to avoid the need to enter choice information for each task. For example, a define a task type “choice” which will always be a summary task which will be utilized for integration purposes. Optionally make the custom fields tab task type dependent.

Project (Managed – Article Type=FINISHED_GOOD?) with 1 style and 3 choices. The following PLM objects will be created
• Generic FG Specification & Recipe (1)
• Variant FG Specification & Recipe (3)
• Article for the Variant FG
• Article for the Variant Formula
• Assign a inheritance relationship from the Generic Finished Good to each Variant Finished Good where the inheritance template is defined by environment parameter ZPLM_GEN_VAR_TEMPLATE

Variant Formula Specification & Recipe (3) – Field: “Create variant formula spec/recipe” with a “YES” or Blank value on task level to be developed/added and will indicate if new variant formula spec/recipe is needed. Default value will be Blank. Value selected for this field on 1 task will be copied to remaining tasks in same Choice on save.
If existing variant formula is to be used, user will manually object link existing variant formula to choice task .

Validation logic will be programmed to ensure that the user either selects and saves “YES” or Blank for “Create variant formula spec/recipe” OR a variant formula spec is object linked to a choice task. The validation will be performed when the project is released and a warning message will be displayed in case validation finds that value is Blank. Message -“Please add Variant Formula Specification as Object Link on Task <Description> if applicable or to auto-create it choose YES in the field ‘Create variant formula spec/recipe’”.

If the value is “YES”, program will check if there are Specification/Recipe objects linked. If Variant Formula Spec. is already present as Object Link on identified task, display warning message on save “Variant Formula Specification already present as Object Link on Task <Description>’”

Project (3rd Party HAWA – Article Type=TRADING_GOOD) with 1 style and 3 choices. The following PLM objects will be created
• Generic FG Specification (1)
• Variant FG Specification (3)
• Article for the Variant FG Specification
• Assign a inheritance relationship from the Generic Finished Good to each Variant Finished Good where the inheritance template is defined by environment parameter ZPLM_GEN_VAR_TEMPLATE

Assumption is that Formula Specifications and Recipes will not be created but the choice level ability to create or not to create will be available via the Field: “Create variant formula spec/recipe” with a “YES” or Blank value
Automatic creation of specs and update of data only applies to project with “Article Type” mentioned above.

Project (Gift Set – Product Sector = GIFT SETS) with 1 style and 3 choices.
• Generic Gift Set Specification (1) & Recipe (1)
• Assign a inheritance relationship from the Generic Finished Good to each Gift Set where the inheritance template is defined by environment parameter ZPLM_GEN_VAR_TEMPLATE
• Variant Gift Set Specification (3) & Recipe (3)
• Generic Giftset Article
• Variant Gift Set Article


The choice level ability to create or not to create will be available via the Field: “Create variant formula spec/recipe” with a “YES” or Blank value
Articles will not be automatically created for Gift Set Specifications through this object on status 170.
When recipes are created, the following logic will be used:
If Recipe Type = ZVAR_FG (Variant FG) or ZGS_FG (Gift Set), then output quantity and UoM = 1 EA
If Recipe Type = ZFRM (Variant Formula), then output quantity and UoM = 100 KG

These values will be maintained in ZXPARAM table instead of hardcoded in the program.
KEY3 = Recipe Type
VALUE1 = quantity
VALUE2 = UoM

Object Links:

Object links are needed for the Specification object in order to support this development object.
Note: The system must automatically assign the object links to tasks when a new project is created if the Style+Choice combination already exists.

For Specification object link the 0PLMCORERCP object link can be used as reference and modified to link to Specification instead of Recipe. The functional requirements are for both object links are as follows.

Note: screenshots show recipe object link, similar functionality will be needed for specification object.
With the cProjects upgrade to 6.1, object link to the recipe is out of the box and we need the interface to attach the recipe number to the project as well as the task level when a project is released.
See below screen shots on how to create a recipe as an object link.
The ability to find and create an object link from cProjects.

Scroll to Top