In this blog will try to understand the use of LTMOM(Migration Object Modeler)
In order to upload Data SAP has provided a tool which will save time and make a smooth transition in LTMC.
By using LTMC we can upload master data and open transactional data during Implementations such as Greenfield and Brownfield or even for day-to-day business activities.
Here are links to know more about LTMC if you wanted to know more.
So with an example, I would like to explain the process of LTMOM.
Let’s say a business wants a new field to add in the material master like any “Z” Field. But in LTMC only standard fields of Material master will be available, So LTMOM comes to rescue you to address your business requirements to make a customized upload function.
Below is the Template of LTMC for uploading material master, So business wants a new field to be adopted after “Batch management Requirement indicator” to address this requirement
Steps to make changes to LTMC Template
Open LTMOM Transaction.
Give the project name in which you want to make changes and select the Migration object
3. Once you select the required project and object which need to be customized, will be able to see in the source structure of exact Template sheet wise structure.
4.Select under which structure changes required.
5. Select the line item after to which new field to be placed and click on insert field.
6. Maintain the Z field which you have created with the following details,
Data Type
Length
Decimal places
Column header
Group text
Once “Z” field has been added custom field indicator will be enabled.
Once the required changes have been made. Save the changes and generate the LTMOM to get the updated Template.
Changes made to the object will overwrite the existing/standard LTMC template and generate a new updated template where you have added “Z” Fields,
While the new template is generating you can see below messages
10. Now open LTMC and go to project and download template.
11. You can see new fields which you added.
Key points.
Changes which have been made are only at project level it will not apply to total LTMC Object.
While making changes in LTMOM don’t open Project in LTMC which will cause locking
Once changes are completed and LTMOM generated refresh LTMC or reopen the project to get an updated template.
By using the same method we can add fields or remove fields
Please share, Like and Comment anything else you want to share or add points.
The SAP Handling Unit Management (HUM) module was created to facilitate operations with stock units as they are moved around warehouses and supply chains. In the logistics process of an organization, the individual unit of each material is not moved. Instead of that, the materials are packed together with packing materials like cartons, pallets, containers, etc., and moved together within the supply chain or stored in an inventory as a group. This group of material and packaging material is called a handling unit (HU) and managing the HU movement across the supply chain and in an inventory is called Handling Unit Management (HUM).
The HU requires a unique identification number called the Serial Shipping Container Code number (SSCC) which is generated for each HU. Once the HU is generated with the SSCC number, this can be stored in the inventory at the storage location or bin level and can also pass them to respective partners throughout the supply chain. The HU can be moved within or outside of the organization, can be deleted or repacked.
Structure of Handling Unit
Structure of Handling Unit
The “Handling Unit” contains parameters like the identification number which is the SSCC number, dimensions such as weight and volume in a configured unit of measure, products and quantities as per the packed items, and packaging material used to wrap the HU. This is further categorized in a handling unit header and handling unit items. The header data of a handling unit consists of dimensions and spots where the HU is stored while the item level consists of products, batches, quantities, and packaging material.
Handling Unit
Usage
The HU (Handling Unit) is the goods packed with packaging material in the logistics and supply chain area. It is designed and developed to allow auto-generation of HU number after production receipt based on the pallet quantity, it can be stored in the inventory as HU for HU managed storage location. The handling units’ functionalities are also used in delivery transactions to pack the delivery products in HUs, used in WM (Warehouse Management) and EWM (Extended Warehouse Management) transactions for HU movements within the warehouse, and store the inventory at the HU level in storage bins. All the information contained in the material such as batches, serial numbers, quantity are stored in the handling units. Handling Units can also be proposed in the sales order by packing proposal and determined during delivery creation.
SAP Inventory Management (IM)
Inventory Management in SAP enables managing the product inventory at the storage location level. To have HUM activated at the IM level, we need to activate the same at the storage location level in configuration. The handling unit in a non-HU managed storage location functions differently from the handling unit in the HU managed storage location, in the sense that it does not control the inventory but still can move HU across the supply chain by packing the delivery. This is mostly applicable when there no need to keep HU level inventory in the plant but only the need for shipping the goods wrapped with packaging material.
The handling unit in an HU storage location means that the HU numbers are visible in the inventory. The handling units are then packed in the delivery for shipment to the customer.
Inventory Management
The following goods movements transactions are supported when we use the HUM at the IM level:
Goods receipts
Goods issues
Transfer postings
Stock transfers
Production Orders
In the area of production orders, handling units (HUs) can be used in the following cases:
Goods issuance for the withdrawal of components – We can issue the components required for the production as per BOM, that are already being managed in HUs.
Goods receipts for materials produced – While posting the receipt of the goods for the Finished Goods (FG) regarding production order, we can pack the FGs and generate the HU number after every receipt. In the case of make-to-stock production, the HUM can handle partial quantities of stock individually with differently packaged handling units (example: packaging variations for different customer groups).
HU labels – HU labels are generated at each production receipt and then the same will be scanned through RF devices for movement within the warehouse and then shipping out to the customer.
HU Label
SAP Handling Unit Management Transactions
The following transactions are mostly used in SAP S/4HANA and SAP ECC for handling units:
HU01 – Creation of Handling Unit
HU02 – Change of Handling Unit
HU03 – Display HU
HUMO – Monitor Handling Units
SAP Handling Unit in Extended Warehouse Management (EWM)
In EWM, handling units are always stored in storage bins within the storage section/storage types. To activate the HUM in SAP EWM, we need to maintain the indicator of HUs permitted in storage type in the configuration of storage types. The stock of HUs in each bin can be checked in transaction /SCWM/MON. The same transaction can be used to manually print the HU labels.
HU types are configured in EWM to classify packaging materials and handling units with the same characteristics. These HU types are then grouped together in HU type groups. The HU types are assigned to each storage type as per the business requirement and accordingly determined during various processes in EWM like Putaway, Deconsolidation, etc. There are several HU types like boxes, cartons, wire baskets, pallets, containers, crates, etc. In EWM as well the HUs are managed in inventory at bin level and can be moved within the supply chain.
The pallet storage put away strategy in EWM controls the storage functionalities of HUs. This takes into consideration the size of the HU and determines the most suitable bin in the storage type for that HU. In the configuration, HU types are assigned to the bin types and pallet storage is enabled at the storage type level.
During put away, the system uses the HU type for the HU to put away and the bin type of the main storage bin, to find a storage bin section and thus storages the HU there, as shown in the figure below.
Handling Unit in EWM
Conclusion
SAP Handling Unit Management is an important tool for the warehouse to minimize errors, improve stock management and traceability. This can be implemented throughout the logistics supply chain right from producers to the end-user. By applying HUM in the ERP, businesses can improve productivity, accuracy in the shipping process and thus resulting in an overall increased efficiency.
—
Did you like this tutorial? Have any questions or comments? We would love to hear your feedback in the comments section below. It’d be a big help for us, and hopefully, it’s something we can address for you in the improvement of our free SAP EWM tutorials.
Assumption is, reader is aware of basic integration concepts of different modules in SAP.
As different SAP modules are closely integrated, reconciliation is one of the most important and critical period end activity in Financial reporting.
Usually, reconciliation is done as part of the month end closure process.
In this blog, I would explain how to do SD-FI-COPA reconciliation and find without running through configurations.
SD-COPA and SD-FI are tightly integrated in SAP. As you all know, below is the integration of SD-FI-COPA.
SD is integrated to COPA via linking of SD pricing conditions to COPA value fields
FI/MM is integrated to COPA via PA transfer structure (Via linking of cost elements/cost element group to COPA value field)
SPRO path:
In an usual production scenario, amount/quantity fields updated in SD/FI/MM are immediately flown to COPA as well. Sometimes, users face the issues due to mismatch of the figures shown between SD-COPA and SD-FI. The reports used here might be standalone reports of respective module.
As the number of documents posted in a live production system is quite high and one value field might receive the data from multiple sources from SD/FI/MM, It is really tough to dig back to particular document which is causing the mismatch.
But, SAP folks are well thought of this critical activity at earlier stages of the design and t-code KEAT was delivered for this .
I would like to share the little knowledge I have on this topic with our community.
Let us see how to find if there are any reconciliation differences exist and if exist, which documents are causing such difference.
Below is the selection screen of KEAT. Enter the maximum selection screen fields that are known to us and execute the report. Currency type 10 can be used which is company code currency.
Below is the sample output of the report
Output show the values recorded in SD, FI, PCA and COPA for each value field and respective delta values between the modules.
Even though SD-FI-COPA integration happens on real time basis, sometimes it is possible that minor differences arises due to various reasons.
One common reason is due to different currencies of company code and controlling area. Minor exchange rate/rounding differences occurs between
SD-FI-COPA. Some times, values in SD itself may not flow to FI/COPA.
This article covers a simple example of Invoice List in SD-BIL area.
Overview
Invoice lists are mostly used to provide some benefits for payer when possible. Some benefits are the following:
To be able to consolidate/print several invoices into one.
Having billing date of invoices changed once it is consolidated. Customer may required submission of consolidated invoices by date.
Factory discount is applicable.
It is also benefitial to the seller while organizing the billing documents a invoices are grouped into one invoice list. It simplifies the control once there is only one payment which means that accounting document of invoice list takes place of all its invoices' account documents.
Depending on the payer's country the payer may pay tax for the discount provided. The condition type for factory discount is RL00 while its tax is MW15 (optional).
Settings
There are some settings before creating Invoice List, here they are:
In Billing Document Types make sure that Invoice List Type (LR) is assigned to the invoice to group (E.g: F2).
Make sure that copy control make use of requirement 016 from F2 to LR ( VTFF transaction ).
Set a calendar for Invoicing List Dates ( XD00 transaction ) to the related customer/payer.
4. Set RL00 (statistical) in the pricing procedure, for example:
5. Set condition record for RL00 ( VK11 transaction ).
You may want to set also in pricing procedure the tax MW15 (optional) and also to determine LR00 (invoice list header) to create printing papers output automatically.
Invoice List Creation Steps
It is simple flow of SD transactions before creating Invoice List (transaction VF21), like VA01, VL01N and VF01.
Create more than one sales order for a same payer.
Creates respective delivery orders.
Create respectives invoices.
Now you create the invoice list (VF21).
5. Hit Execute button and check discount as per defined in condition records:
After hit save buttong notice that when you release the invoice list to account then accounting document has the final data.
6. Setting Output Type:
Standard program for LR00 will print the invoice list with each invoice data per page.
![](data:image/svg+xml;charset=utf-8,<svg height="328px" width="400px" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
![](data:image/svg+xml;charset=utf-8,<svg height="293px" width="548px" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
