Should V_BBP_DET_ACCT be maintained per client or transported?

[dean_hinson2]

Hello,

We have discovered that the GUID for the categories replicated are not the same between systems. So when the entries in V_BBP_DET_ACCT are transported, the GUIDs do not match those in COMM_CATEGORY.

Is this something that must be maintained on each client or can transports work?

Regards, Dean.

[Former Member]

Hi

<u><b>See this SAP Release Indenpendent SAP OSS Notes -></b></u>

<u>Note 338588 - GUIDs in the master data of different systems</u>

--->>You can copy product categories from one system to another system using a transport under the following conditions:

the back-end systems and related master data are identical (in this case, the name of the logical system must simply be the same) no product categories were created locally in the EBP source system.

--->>>If you want to copy products from one system to another system by means of a transport, you must check whether the back-end system is actually the same. This is necessary because the product GUID is already generated in the back-end system. If these prerequisites are not met, the master data from the back-end system must be replicated again and the application tables must be manually implemented.

(As of CRM/EBP 3.0, two reports for preparing a material download are provided for when entries are transported from Customizing tables and product categories between 2 EBP systems. These reports are assigned to the following two IMG activities: CRM - Master Data - Product - Product Category Assign Logical Systems and 'Transport Categories'. The exact procedure is described in the attached documentation for the IMG activities. )

<u>Note 444528 - Assgnmnt target system + account assgnmnt to product categry</u>

[When you execute Customizing activities 'Define Backend System for Product Category' and 'Define G/L Account for Product Category and Account Assignment Category', the system does not update the product category GUID if you use the copy function.]

<u>Note 523213 - Set maintenance view in production system to changeable</u>

<b>Q-> Why does the additional account assignment in the detail view remain unchanged even though the account assignment category has changed?</b>

-> SRM does not hold any metaknowledge about FI/CO objects in the back end. For this reason, additional account assignments remain unchanged after the account assignment category is changed. If necessary, you can use BBP_DOC_CHANGE_BADI to change these additional account assignments.

-> Defaults are set only once after a shopping cart is initially created. Afterwards, only the G/L account is read from Customizing. As a prerequisite, the IMG table V_BBP_DET_ACCT has been maintained. In all other cases, users must make the relevant system entries or use the BBP_DOC_CHANGE_BADI implementation to ensure that the account assignment is adjusted.

<u>(See SAP OSS Note 815849 - FAQ: Account assignment system response for more details)</u>

Hope this will anser all your queries.

Regards

- Atul

[dean_hinson2]

Atul,

I saw al of these but I wanted to find out what the 'real' world was doing. Our consultants did not name the logical system the same. So I think this means that only maintenance in the instance is the only solution. Is that correct?

Please let me know.

Dean.

[Former Member]

Hi

Yes.. please go ahead with Logical system name change in your case, if feasible ..

A production system is set to non-changeable. Hence, settings can only be maintained via the transport system. However, sometimes you want that e.g. settings for logical systems or product categories are not transported from the test system. You want to be able to maintain the data directly in the production system. This procedure may become necessary for the following maintenance views among others:

V_BBP_DET_ACCT Default G/L account for product category

V_BBP_DET_LOGSYS Logical system for the product category

V_BBP_TARGET_OBJ Back-end documents for product category and purchasing group

V_BBP_CAT Catalogs

V_BBP_CAT_VALUES Call structure for catalog applications

V_BBP_CAT_VAL_FR Internal call structure for catalogs (in frame)

V_TBDLS Logical system

A way of maintaining maintenance views for Customizing tables in the production system. Transaction SE54 -> Enter above-mentioned views -> "Generated Objects" radio button -> Create/Change -> Environment -> Maintenance Objects -> Change.

Call Transaction SOBJ. The 'Current settings' indicator must be set for the corresponding maintenance view. This setting causes that the maintenance views are changeable in the production system.

It must be noted that transports are also created for the maintenance views set to changeable in the test system, from which you usually transport. If you do not want this, these must not be transported to the production system. Thus change the 'Transport' indicator from 'automatic transport' to 'no transport' in this case. To prevent that a Customizing order is created in Transaciton SE54 due to the change of the table views, also consider Note 351041

<u>See Related SAP OSS Note -></u>

Note 872533 - FAQ - Middleware

Note 354912 - Customizing of accnt assignmt of product categories

--> Guids are just used as unique identifier, they have no signification, only property is to be unique. They are generated by function GUID_CREATE. The same guid can be displayed and used in different format (RAW16, CHAR32, CHAR22). You can convert them with a "move" statement or function GUID_CONVERT.

--> GUIDs are system generated unique keys which identifies CRM and SRM objects (Shopping Carts, Invoices, business partners, products , category ID etc.). SRM & CRM & MSA works on GUIDs. Most of the table relationships are defined on GUIDs.

Guid – Globally Unique Identifier

Used as primary keys in SRM tables.

All transactions are uniquely identified by their guids internally

Transaction numbers are not unique

<u>Another reasoning:</u>

--> GUIDs (Globally Unique Identifiers) serve as primary keys for all tables in the CRM. A GUID is generated by a special algorithm using as input data certain hardware information of the host computer, the current system time, and a randomly generated number. The GUID can be represented in two formats: a 32-byte character field or a 16-byte raw sequence. It is globally unique in the sense that two GUIDs produced on any two computers (or even on the same one) at any time can never be the same.

<u>Some related links -></u>

Hope this will help. Do let me know.

Regards

- Atul

[dean_hinson2]

To All Concerned,

We have decided to maintain the entries in the instance since naming the logical system the same on all systems (DEV, Q/A, PRD) is not an option. It solves the problem and having the logical system named diferrently helps prevent the 'oops' syndrome.

Thanks to all.