Privacy Policy for fungtionstrategy.blogspot.com/
If you require any more information or have any questions about our privacy policy, please feel free to contact us by email at kh.umarmasud@gmail.com.
At fungtionstrategy.blogspot.com/, the privacy of our visitors is of extreme importance to us. This privacy policy document outlines the types of personal information is received and collected by fungtionstrategy.blogspot.com/ and how it is used.
Log Files
Like many other Web sites, fungtionstrategy.blogspot.com/ makes use of log files. The information inside the log files includes internet protocol ( IP ) addresses, type of browser, Internet Service Provider ( ISP ), date/time stamp, referring/exit pages, and number of clicks to analyze trends, administer the site, track user’s movement around the site, and gather demographic information. IP addresses, and other such information are not linked to any information that is personally identifiable.
Cookies and Web Beacons
fungtionstrategy.blogspot.com/ does use cookies to store information about visitors preferences, record user-specific information on which pages the user access or visit, customize Web page content based on visitors browser type or other information that the visitor sends via their browser.
DoubleClick DART Cookie
.:: Google, as a third party vendor, uses cookies to serve ads on fungtionstrategy.blogspot.com/.
.:: Google's use of the DART cookie enables it to serve ads to users based on their visit to fungtionstrategy.blogspot.com/ and other sites on the Internet.
.:: Users may opt out of the use of the DART cookie by visiting the Google ad and content network privacy policy at the following URL - http://www.google.com/privacy_ads.html
Some of our advertising partners may use cookies and web beacons on our site. Our advertising partners include ....
Google Adsense
These third-party ad servers or ad networks use technology to the advertisements and links that appear on fungtionstrategy.blogspot.com/ send directly to your browsers. They automatically receive your IP address when this occurs. Other technologies ( such as cookies, JavaScript, or Web Beacons ) may also be used by the third-party ad networks to measure the effectiveness of their advertisements and / or to personalize the advertising content that you see.
fungtionstrategy.blogspot.com/ has no access to or control over these cookies that are used by third-party advertisers.
You should consult the respective privacy policies of these third-party ad servers for more detailed information on their practices as well as for instructions about how to opt-out of certain practices. fungtionstrategy.blogspot.com/'s privacy policy does not apply to, and we cannot control the activities of, such other advertisers or web sites.
If you wish to disable cookies, you may do so through your individual browser options. More detailed information about cookie management with specific web browsers can be found at the browsers' respective websites.
Tuesday, October 12, 2010
Supply chain organization structure Supplier organization (Business Edition)
The supplier organization does not subscribe directly to any policy groups. As a result it inherits the management and administration policy group from the root organization. These policies apply to the supplier organization, the supplier A organizations that it owns, and the supplier A administrators.
The B2B direct organization subscribes directly to the management and administration, the common shopping, B2B and supplier profile policy groups. These policies apply to all stores owned by the B2B direct organization.
The Supplier profile policy group contains the following policies:
* AllUsersForSupplierExecuteSupplierAllUsersViews
* RegisteredCustomersForOrgForSupplierExecuteSupplierRegisteredCustomerViews
Buyers are customers that place orders in a B2B store. All buyers must be owned by a buyer organization. Typically, buyer organizations do not subscribe to any policy groups, since management and administration policies inherited from the root organization are sufficient.
The B2B direct organization subscribes directly to the management and administration, the common shopping, B2B and supplier profile policy groups. These policies apply to all stores owned by the B2B direct organization.
The Supplier profile policy group contains the following policies:
* AllUsersForSupplierExecuteSupplierAllUsersViews
* RegisteredCustomersForOrgForSupplierExecuteSupplierRegisteredCustomerViews
Buyers are customers that place orders in a B2B store. All buyers must be owned by a buyer organization. Typically, buyer organizations do not subscribe to any policy groups, since management and administration policies inherited from the root organization are sufficient.
Supply chain organization structure Asset store (Business Edition)
The asset store organization does not subscribe directly to any policy groups. As a result it inherits the management and administration policy group from the root organization. These policies apply to the asset store organization and the asset stores that it owns. The asset store organization owns the supplier profile policy group, but does not subscribe to it.
Note: The individual supplier's B2B direct organization will subscribe to the supplier profile policy group when the supplier store is created.
Note: The individual supplier's B2B direct organization will subscribe to the supplier profile policy group when the supplier store is created.
Supply chain organization structure Supplier hub (Business Edition)
In these diagrams, describing a basic supply chain organization structure, the root organization owns and subscribes to the default policy groups as described in Access control policies and policy group structure.
Supplier hub
Supplier hub
The supplier hub organization subscribes directly to the management and administration policy group, the common shopping policy group, the B2B policy group and owns and subscribes to the Supplier hub policy group. As a result, these policies apply to the channel administrators, who are directly under the supplier hub organization, as well as to the supplier hub.
The Supplier hub policy group contains the following policies:
* AllUsersForSupplierHubExecuteSupplierHubAllUsersViews
* RegisteredCustomersForOrgForSupplierHubExecuteSupplierHubRegisteredCustomerViews
* ContractAdministratorsForChannelOrgExecuteCreateCommandsOnMemberResource
* ContractAdministratorsForChannelOrgExecuteContractDeployCommandsOnContractResource
* ContractAdministratorsForChannelOrgDisplayContractDatabeanResourceGroup
Organization structure
In order to allow customers or buyers to access your site, browse your catalog, and place orders; or to allow employees to administer the site, including updating the catalog, creating new promotions, or managing orders; or to allow resellers or other business partners to complete transactions on your site, all actors in your business scenario must be assigned a position in the WebSphere Commerce organization structure.
The WebSphere Commerce organization structure provides a framework for the actors, or entities, in your business scenario. This framework is organized in a hierarchical structure, which mimics typical organizational hierarchies with entries for organizations and organizational units and users. The organizations and organizational units in the framework act as owners for the parts of your business. All parts of your business, including customers, administrators, stores, catalogs and distributors, must be owned by an organization or organizational unit.
The organization structure and the access control model, are closely related, in that the access control model applies access control policies to organizations rather than to individual entities (stores, customers, administrators and so on). The policies that apply to an entity (or resource) are applied to the organizations that own the entity or resource.
The following diagram outlines the basic WebSphere Commerce organization structure. The basic organization structure is installed during instance creation, regardless of the business model.
The WebSphere Commerce organization structure provides a framework for the actors, or entities, in your business scenario. This framework is organized in a hierarchical structure, which mimics typical organizational hierarchies with entries for organizations and organizational units and users. The organizations and organizational units in the framework act as owners for the parts of your business. All parts of your business, including customers, administrators, stores, catalogs and distributors, must be owned by an organization or organizational unit.
The organization structure and the access control model, are closely related, in that the access control model applies access control policies to organizations rather than to individual entities (stores, customers, administrators and so on). The policies that apply to an entity (or resource) are applied to the organizations that own the entity or resource.
The following diagram outlines the basic WebSphere Commerce organization structure. The basic organization structure is installed during instance creation, regardless of the business model.
Root organization
The root organization is the top level organization and is its own parent. All organizations in the WebSphere Commerce organization structure are descendents of the root organization. The site administrators are owned by the root organization.
Default organization
The default organization is owned by the root organization. All guest customers and all customers in a consumer direct scenario belong to the default organization. Customers in a B2B direct and value chain scenario can belong to either the default organization, or other organizations.
One or more other levels of organizational entities can exist beneath the parent organizational entities. You can add as many child organizational entities as necessary to support your business.
Sample organization structures
WebSphere Commerce provides sample organizations structures for each supported business model. These sample organization structures are available on their own (as component store archives) allowing you to use the sample organization structure as starting point for your own site, or as part of the sample businesses.
Creating organization structures
Rather than create new organization structures for your site, it is recommended that you begin by publishing one of the sample organization structures provided with WebSphere Commerce, and then make changes to that organization structure as necessary.
The root organization is the top level organization and is its own parent. All organizations in the WebSphere Commerce organization structure are descendents of the root organization. The site administrators are owned by the root organization.
Default organization
The default organization is owned by the root organization. All guest customers and all customers in a consumer direct scenario belong to the default organization. Customers in a B2B direct and value chain scenario can belong to either the default organization, or other organizations.
One or more other levels of organizational entities can exist beneath the parent organizational entities. You can add as many child organizational entities as necessary to support your business.
Sample organization structures
WebSphere Commerce provides sample organizations structures for each supported business model. These sample organization structures are available on their own (as component store archives) allowing you to use the sample organization structure as starting point for your own site, or as part of the sample businesses.
Creating organization structures
Rather than create new organization structures for your site, it is recommended that you begin by publishing one of the sample organization structures provided with WebSphere Commerce, and then make changes to that organization structure as necessary.
Asset stores (Business Edition)
In order to facilitate the creation and management of multiple stores such as customer-facing stores and proxy stores, WebSphere Commerce implements asset stores. Asset stores contain collections of sharable resources (business artifacts, business processes and storefront assets) that can be leveraged in other stores. For example, instead of creating a catalog as part of the hub, a hub may leverage a catalog asset store, which can also be shared by the hub's channels or partners. As a result, a simple catalog can be used by hundreds or thousands of stores, thereby reducing data management needs. An asset store is usually composed of the assets that can be used by multiple stores, but is in itself not a fully functional store and does not conduct business transactions.
WebSphere Commerce provides sample catalog asset stores and storefront asset stores. The following diagram illustrates the relationship between stores and a catalog asset store.
WebSphere Commerce provides sample catalog asset stores and storefront asset stores. The following diagram illustrates the relationship between stores and a catalog asset store.
Proxy stores (Business Edition)
WebSphere Commerce also supports entities known as proxy stores. A proxy store is a store that represents a business partner's operational assets and provides the business logic that allows the WebSphere Commerce site to interact with an external business partner. The proxy store also contains operational data that gets updated in interaction with the business proxy site. For example, a proxy store may capture the orders transferred to a remote order capture system, as well as capturing the suppliers' inventory information or the information sent to a supplier's fulfillment centers. Unlike a customer-facing store, a proxy store does not include a storefront and cannot be accessed by users.
Creating proxy stores
Creating a proxy store is very similar to creating a store in an extended site, in that the majority of the proxy store assets are provided from existing stores (including asset stores). As implemented in the samples provided with WebSphere Commerce, the proxy store does not include a storefront. The following diagram illustrates the distributor proxy stores using the assets from the distributor asset store and the catalog asset store.
Creating proxy stores
Creating a proxy store is very similar to creating a store in an extended site, in that the majority of the proxy store assets are provided from existing stores (including asset stores). As implemented in the samples provided with WebSphere Commerce, the proxy store does not include a storefront. The following diagram illustrates the distributor proxy stores using the assets from the distributor asset store and the catalog asset store.
Rather than providing a user interface wizard to create a proxy store, WebSphere Commerce implements proxy stores through service agreements, which are then imported via a user interface, into WebSphere Commerce, creating the proxy store. The service agreement is governed by a template, which determines what information you need to create. The template for creating proxy stores (TemplateReferralContract.xml) is available in the following directory:
Subscribe to:
Posts (Atom)