Delivery and Shipment handling units

Business Requirement:

1. Creation of Delivery Handling unit for over packing and master cartons even if over packing is not required.
2. Creation of Shipment Handling Unit for boxes packed in Deliveries to allow receipt by HU# in the receiving plants.

Challenges: While creating shipment handling unit, all the delivery handling units are automatically attached to the shipment handling unit and they are deleted from deliveries when the BAPI (BAPI_HU_CREATE) is used. BAPI_HU_CREATE has the parameter LOWER_LEVEL_EXID is present in tables parameter (BAPIHUITEM), however after using this parameter to attach the delivery handling units to Shipment, these handling units are deleted from delivery.

Solution – In order to avoid above issue we had gone ahead of different approach and able to attach the delivery handling units to shipment with correct hierarchy. we need to call the below bapi’s in sequence to achieve the above functionality

head_proposal-hu_status_init = Pass 'A' ."Planned.
head_proposal-pack_mat = Pass Packaging Material
"Call the below function module to create an Unassigned HU object.
CALL FUNCTION 'BAPI_HU_CREATE'
EXPORTING
headerproposal = _head_proposal
IMPORTING
huheader = hu_header
hukey = hu_key
TABLES
return = return.
IF hu_key IS NOT INITIAL.
"Call the below function module to Commit the data
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = 'X'
IMPORTING
return = return.
" Assign to a Shipment
hu_header-pack_mat_object = '04'. "04-HU Type for Shipment
hu_header-pack_mat_obj_key = Shipment number "Shipment #
hu_header-lenght = Pass Pallet length
hu_header-width = Pass Pallet Width
hu_header-height = Pass Pallet Height
hu_header-total_wght = Pass Pallet weight
hu_header-unit_dim = Pass Pallet Uom for dimensions
hu_header-unit_of_wt = Pallet Uom
hu_header-max_unit_of_wght = Pallet Uom.
ENDIF.
"Call the below function module to assign the handling unit to shipment
CALL FUNCTION 'BAPI_HU_CHANGE_HEADER'
EXPORTING
hukey = hu_key
huchanged = hu_header
TABLES
return = change_return.
IF change_return[] IS INITIAL.
"Call the below function module to commit the data by assigning Shipment to Handling Unit
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = 'X'
IMPORTING
return = return.
" Get the Internal Handling unit based on external handling unit and prepare the handling unit numbers (Box_pallet_venum) which needsto be passed to below function module.
" The below function module is called for filling the global memory
CALL FUNCTION 'HU_GET_HUS'
EXPORTING
if_lock_hus = co_x
if_no_loop = co_x
it_venum = box_pallet_venum
EXCEPTIONS
hus_locked = 1
no_hu_found = 2
fatal_error = 3
OTHERS = 4.
"Each and every Internal handling unit (Boxes) to be attached to shipment and the below function module should be called in a loop.
packing_request-venum = Hu_header-hu_id.
packing_request-exidv = hu_key.
packing_request-velin = '3'.
packing_request-sub_hu_venum = vekp-venum.
packing_request-quantity = '1'.
Packing_request-veanz = '1'.
" The below function module is called to Repack the deliveries in the shipment which is required for hierarchy in shipment
CALL FUNCTION 'HU_PACKING_AND_UNPACKING'
EXPORTING
if_repack = 'X'
is_packing_request = packing_request
IMPORTING
ef_rcode = return_code
CHANGING
cs_header = cs_header
EXCEPTIONS
missing_data = 1
hu_not_changeable = 2
not_possible = 3
customizing = 4
weight = 5
volume = 6
serial_nr = 7
fatal_error = 8
OTHERS = 9.
IF sy-subrc EQ 0.
" Call the below function module to commit the data by assigning Shipment to Handling Unit
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = 'X'
"If the Pallet packing is successful then only call the below function module
" The below function module commits the data to database.
CALL FUNCTION 'HU_POST'
EXPORTING
if_commit = 'X'
ENDIF.

Negative  results – ( when the Bapi  Function module (BAPI_HU_CREATE) is used and passing the parameter  LOWER_LEVEL_EXID), the output as follows

1. Delivery handling units are correctly packed and the hierarchy is correct

2. However when we pack the  delivery boxes to shipment the hierarchy is off as shown below. The hierarchy should be ‘0’ for Shipment  handling unit,’1′ for delivery handling unit  and ‘2’ for material.

Positive results – ( when the Function modules are called in sequence as suggested in the blog)

1.The handling units for delivery are shown below which was successfully attached to delivery

2. HUPAST tcode for handling units with respect to delivery.

3. Handling units with respect to delivery shown below and the important element is the hierarchy (Shipment handling unit comes first , then delivery handling unit and then the packaging materials.

------------------------------------------------------------------------------------------------

Note : The above usage of FM’S and Bapi’s needs to be called sequentially as shown above to achieve the functionality. The high level code is provided as solution.

------------------------------------------------------------------------------------------------

Follow: Facebook, Google+, Twitter, Pinterest, Linkedin

Continue reading

SRM UI5 Boosting and Ranking

SRM UI5 boosting and ranking functionality is released with SRM 7.0 EhP4 on the HANA database.  Available with Implementation note 2383392(SRMNXP01 150).

1. Activate Boosting and Ranking Functionality for Users

After collecting the approval or rejection from end users, administrator has to first set the user settings by running the report ESH_ENG_PS_MAIN_SWITCH as shown in Figure 1.

Figure 1. User setting report for Boosting and Ranking framework

Description for the radio buttons in Figure 1:

◉ Label 1 – Disable Boosting and Ranking framework for all users

◉ Label 2 – Enable Boosting and Ranking framework for all users

◉ Label 3 – Boosting and Ranking framework is enabled for a specific user after the user is added to the user list in label 5 area

◉ Label 4 – Boosting and Ranking framework is disabled for a specific user after the user is added to the user list in label 5 area.

2. Boosting Configuration for Standard Request Attributes

You can configure the boosting of standard request attributes. For example, you are searching with the term “laptop” to find all laptops from available manufacturers. If you prefer laptops from Apple manufacturer to be displayed on the top of the result list, you can create a ranking factor ‘Z_MANUFACTURER_NAME’ and configure it so that manufacturer Apple weighs more heavily in the calculation of ranking scores. This way, the ranking factor influences the ranking scores and certain group of search results are boosted to the top.

Manual Steps for Boosting Configuration of Standard Request Attributes

You must create your own ranking factors to boost standard attributes which are marked as freestyle search in the search result model. For example, to ensure that laptops from Apple manufacturer are displayed in the top results, configure the manufacturer with value “Apple” as follows:

1. Create a new customer ranking factor

1.1 Run the report ESH_PS_ESPROV_CREATE_DIM, choosing Owing ES-software Component – SRMNXP01. Enter the name of the ranking factor (Ranking Dimension ID), short description, and attributes. These are mandatory inputs, which defines a ranking factor. In Figure 2, ranking factor Z_MANUFACTURER_NAME is created.

Figure 2. Create a ranking factor

1.2 Execute the report to finish the creation.

2. Assign the newly created ranking factor to the search connector

2.1 Go to transaction ESH_COCKPIT to open the connector administration cockpit in SRM application server.

2.2 Select the connector Search Result Model SRMNXP02_CATALOG.

2.3 On the tab Ranking Dimension, click on Add button and Select the customer created ranking factor through F4 search help.

Figure 3. Assign a ranking factor in ESH_COCKPIT

2.4 Assign the standard Request Attribute in the search model to the ranking factor through F4 search help. In our example, the corresponding request attribute MANUFACTNAME is mapped to the ranking factor Z_MANUFACTURER_NAME in Figure 4.

Figure 4. Map the request attribute to the ranking factor

2.5 Click Save to finish the assignment.

3. Create a boost to set significance for the ranking factor

3.1 Run the report ESH_PS_ESPROV_MAINT_SIG to create a boost with significance manually. The boost entry is required to boost a specific manufacturer above others.

3.2 Choose the Dimension ID Z_MANUFACTURER_NAME through F4 search help in Figure 5. The User field is optional for a user-dependent ranking factor. For a user-independent ranking factor, leave this field empty. In our example, ranking factor Z_MANUFACTURER_NAME is created as user-dependent. Therefore, the created boost entry will take effect only for the user whoever is entered in this field. On the other hand, the created boost entry will apply to all users if this field is left empty.

3.3 Execute the report.

Figure 5. Execute the report to create a boost

3.4 In the next screen, click + to create a new boost entry. Enter the value ‘Apple’. This value should be valid in the product items, that is, this value must be found in the report ESH_TEST_SEARCH for example. Choose a significant weight between 0 and 1. This is how you can decide the priority among different manufacturers. Click on Execute button to complete the boost entry.

Figure 6. Maintain significances

3.5 Click Save to save the settings in the system.

To view enterprise search results boosted by the relevance ranking factor, do the following:

◉ Ensure that the end user has been activated for the Boosting and Ranking functionality in the report ESH_ENG_PS_MAIN_SWITCH.

◉ Navigate to the SRM UI Add-On portal and refresh it. Use the same search term ‘laptop’. The order of the search result list is now according to the relevance ranking factor. The product item with manufacturer name ‘Apple’ has been boosted to the top in Figure 7.

◉ To see the actual ranking scores, perform the same search in the report ESH_TEST_SEARCH.

Figure 7. UI search results with the boost applied

3. Ranking Configuration based on the Click Counter

Whenever user clicks ‘Add to Cart’ on a product item and add it to the temparory cart, system catches this event, transfers this click to a boost with a significance weight, and stores the boost in the system automatically. After refreshing the UI, the newly clicked product item will be boosted in the search result list. Product items that are clicked often have higher ranking scores than the ones that are clicked less often.

Manual Steps of Ranking Configuration

SAP provides the standard ranking factor to configure boosting based on the click counter – SRMNXP_ADD_CART_EVENT. To enable the ranking functionality, assign the standard ranking factor to the ESH_COCKPIT and link it to the key request attribute of the search model. Do the following manual steps:

1. Go to transaction ESH_COCKPIT to open the connector administration cockpit in SRM application server.

2. Select the connector Name Search Result Model for SRMNXP02_CATALOG. This connector must be activated.

3. On the tab Ranking Dimension, click Add button and Select the standard ranking factor SRMNXP_ADD_CART_EVENT through F4 search help.

4. Assign the key Request attribute PRODUCTKEY of the search model to the ranking factor through F4 search help.

5. Save.

Figure 8. Assign standard ranking factor in the ESH_COCKPIT

Now user can test the ranking results based on the click counter. Double check the setting of the user in the personalized search main switch by the report ESH_ENG_PS_MAIN_SWITCH. The user must be activated as a prerequisite.

In SRM UI Add-on search portal, go back to the search result list and add one product item to the temporary cart by clicking on ‘Add to Cart’ button. After refreshing the portal and doing the same search, the order of result items should be different – the clicked item should have been boosted. To see the actual ranking scores, perform the same search in the report ESH_TEST_SEARCH.

BAdI for Ranking Functionality

A Business Add-In (BAdI) is provided to filter a search item for the ranking functionality, which means without translating the click action for this item into a boost in the system. Customer has flexibility to filter certain items for the ranking according to the organization requirements by implementing this BAdI.

Enhancement Spot: /SRMNXP/BD_FILTER_RANKING

BAdI Definition: /SRMNXP/BD_FILTER_RANKING

Interface Method FILTER_ITEM provides access to the tempory cart shopping cart item.

Continue reading

Difference in COGI and CO1P

I have been searching and reading all the documents regarding COGI and CO1P, to know why some goods movements are held in COGI, while some in CO1P. I would like to share my knowledge on where I started and ended in learning about these transactions. Hope this document will be final stop if you are also searching for this topic.

Let us consider that auto goods movement is setup for confirmations of production orders in the below scenarios.

Confirmation is saved but goods movements are failed?

To find out the reason for this we have to go to transaction code:

COGI - Postprocessing of Error Records from Automatic Goods Movements

As the name suggests, we can process failed goods movements from here after correcting the errors.

Give the order number and execute

For example, error here is due to deficit in stock of goods posted. Until stock is updated in the system this posting will be held in COGI, from where we can post the goods later.

Now after updating the stock open COGI again, select the required line items and click on save to post the goods. If the confirmation details have to be changed double click on the line item or select the line item and click on change details button, and then post the goods by clicking on save button.

How to configure system to stop the confirmation process, when error occurs in Goods Movements?

This can be configured under the IMG node “Define Confirmation Parameters”

This indicator specifies that if you save a confirmation with goods movement errors (that is, backflushing or automatic goods receipt), then the system displays an error log before saving.

Confirmation saved and no goods movements failed, still stock is not updated in production order?

In this case you may have to go to transaction code:

CO1P – Predefined Confirmation Process

As the name suggests, this is an already defined step in configuration to process all goods movements of that day at later point of time. For example, to improve system performance all goods movements of an hour can be held and processed through CO1P in one go. This is setup in decoupled confirmation settings.

Give the order number and execute

Select the required line items and click on save to post the goods.

What is decoupled confirmation? How can it be setup?

To avoid the issues with response time of confirmation process, we can decouple the steps taking place during confirmation. Following are the processes which can be decoupled

◉ Automatic Goods Receipt

◉ Backflush

◉ Actual cost determination

The execution time of above processes can be defined under IMG node “Define Time for Confirmation Processes”.

Which means above three tasks can be configured to be processed immediately at the time of confirmation itself or else later in background. This setup is known as decoupled confirmation.

This process control key can be maintained under the node “Confirmation Parameters” for required order type.

Then the goods movements related to this confirmation will be held in CO1P, until they are processed manually or by a background job.

When the option “Later in Background Job” is selected, system saves the confirmation data in below tables :

◉ AFRP1 – Auto GR confirmation records

◉ AFRP2 – Backflush confirmation records

◉ AFRP3 – Actual costs confirmation records

Stock is not updated against the order even after processing the entries from CO1P?

In this case you may have to look into COGI, if there are any further errors which are to be resolved.

Ex: Stock Deficit, Authorization issue, Production order status etc.

Why does system post entries sometimes into COGI and sometimes into CO1P?

So coming to the point, if there are any errors due to which system is not able to post the goods movements then such items are held in COGI. On the other hand stock postings will be held in CO1P when configuration is predefined as mentioned in above steps.

There is one exception for this, when load on system is huge and if locks occur during the time of confirmation no error record is generated in COGI, but instead a request is generated for a later update because the system assumes that the lock is only temporary. These requests can be found in CO1P.

What are the programs to run COGI, CO1P in background?

CORUPROC, CORUAFWP and CORUAFW0 are the reports which can be scheduled in background, to clear the postings that are held in COGI/CO1P at regular intervals.

But they have limitation when working with COGI entries, as these cannot be cleared until respective error is resolved. For example if the entry is due to stock deficit, then it cannot be cleared by these reports until stock is updated in system.

All these entries are stored in table AFFW. At the start of any of above programs, a global lock is set for all entries in table AFFW as well as a global process lock for goods issue and goods receipt. So it is advisable, not to run these reports in parallel as it may lead to job cancellations. So maintain some time gap while scheduling the jobs with different reports. Also we can differentiate the errors in table AFFW with error message numbers, if there is no error message number against a line item then it can be seen in CO1P.

What are CO16N and COFC used for?

CO16N - Postprocessing incorrect confirmations

This transaction deals with failed confirmations, whereas COGI/COPI deals with failed goods movement.

Confirmations with errors can arise if they were entered in one of the following ways:

◉ Upload from a PDC system

◉ Online entry ( Fast Entry or Mass Processing )

◉ Entry via BAPI interface

Errors might be like Order does not exist, Order was locked, Order already confirmed etc.

COFC - Postprocessing of confirmations with errors in calculation of actual costs

The errors in cost calculations during confirmations will be updated in the Transaction COFC. So this is not related to posting of goods movements we discussed above.

Continue reading

Production Planning in a cross plant set-up

This document explains the steps required to configure a system for Production planning in a cross plant set-up. It has been observed that many members post questions with a bit of variation regarding this scenario. Hopefully this blog will address any current and future queries regarding this topic.

Scenario:

Cross plant production is one of the key parts of SAP – Production Planning, it is also know as production in alternative plant. In this document we will use Special procurement types 70 and 80 to address this scenario, thus eliminating the need of doing any transfer postings.

Prerequisites – Create Master Data i.e.
Material Master (FERT, HALB and ROH)
BOM                  (FERT and HALB)
Routing              (FERT and HALB)
Work Centers

HALB will be created in 3350 plant, while FERT and ROH will exist in both plants by extending them to the other plant through MM01.
We will be working on MTS – Make to Stock strategy.

Only configuration required in this scenario is to configure special procurement types 70 and 80.

For plant 3300 we will use special procurement type 80. We will mention plant 3350 in special procurement section of [ Prod. Other plant ].

For plant 3350 we will use special procurement type 70. We will mention plant 3300 as issuing plant in the ‘As BOM component’ section. Make sure there’s a tick at the box of withdr.altern.plant (withdrawal from alternate plant).

Special procurement 70 will be assigned to HALB’s BOM component. We will select ROH material in the BOM and click on item (or press F7). T.Code CS02

Special procurement 80 will be assigned in FERT’s MRP 2 view in plant 3300. T.Code MM02

After completing all of the above tasks we will proceed with a real time test. For FERT material, stock of 50 already exists thus we will have to add this in our future calculations.

Now we will go to PIR planning table T.code MD61, and enter the value of 100. Make sure the date is not on a holiday.

You can double check the planned qty and its date in Schedule lines tab.

After running the MRP (T.Code MD02) we will go to stock requirement list of FERT material. Here you can see IndReq of 100 and planned order of 50 quantity. Reason being that 50 qty of FERT is already available in unrestricted stock, so that stock will be consumed first. You can also see supplying plant as 3350 because FERT material will be manufactured in plant 3350.

For FERT Material in plant 3350 (T.code MD04) you can see Planned order for 50 qty while 3300 plant is showing as planning plant.

For HALB Material in plant 3350 you can see a planned order of quantity 50.

For ROH Material you can see DepReq of 100 and PurRqs of 100. That’s because in one HALB material 2 ROH materials are consumed.

Convert Purchase requisition of ROH to purchase order and do GR in plant 3300.

Convert planned order of HALB to production order.

In component overview of HALB’s production order you can see 3300 plant for ROH material.

Now we will do goods issuance (Movement type 261) on the production order of HALB material.

Before Goods issuance, ROH material stock is 100.

After Goods issuance, ROH material stock reduces to zero. Point to notice is that there were no transfer postings done.

After doing Confirmation of HALB’s production order we will do Goods Receipt of HALB material.

Before GR of HALB

After GR of HALB. 50 quantity has been added to stock.

After GR of HALB material, we will convert planned order of FERT to Production order. Note supplying plant is 3350.

Planning plant and MRP area for FERT’s production order is coming as 3300

Now we will do goods issuance to FERT’s production order. 261 movement type is done.

Now we will do goods issuance to FERT’s production order. 261 movement type is done.

In FERT material’s Production order HALB’s withdrawal quantity is coming as 50

After confirmation of production order we will do GR of FERT material.

But before that you can see for plant 3300, FERT’s material Stock/requirement list is showing 3350 as supplying plant while for plant 3350 Stock/requirement list is showing 3300 as planning plant.

We will go to MIGO and do GR of FERT’s production order. It will be done directly to 3300 plant 0001 Sloc without the need of any transfer postings.

After GR, stock in 3300 plant has increased from 50 to 100

After GR, stock in 3350 plant has decreased to zero.

You can see in Stock overview list (T.Code MMBE) that stock in ‘unrestricted use’ is 100 for plant 3300 in 0001 Sloc, while stock is Zero for plant 3350. Production Cost will be collected in production plant 3350.

Continue reading