Follow these steps to activate the archiving information structure:
Archiving in SAP are executed using transaction SARA t-code.
When i started to join the implementation team for archiving project, there were several important SAP notes we used such as Note no 70547 - Data Archiving: General Information, SAP Note 157944 – Archiving Object-Specific Information and SAP Note 430886 – Archiving in SAP ERP
I come accross this question during my project last time in SAP erp archiving and In SAP, how do I archive financial documents?
The Object: FI DOCUMNT (For archiving FI Documents) in the SARA tcode. Select the Customize button but more analysis required
Object: FI DOCUMNT for archiving FI documents (For archive FI Documents) Choose the Write Option. Put a name for the version and click keep it.
Object: FI DOCUMNT is now used to remove the documents. Select Delete.
The above only helps if you know the fundamental about archiving in SAP , We had integration team who help in this activity.
I notice whenever when archive are being scoped, important tables needs to be identified and when i was searching the below table it was interesting as i could and had gotten it from Early watch alerts documents and also by some guru's in some forums long time ago and can't really remember now.
But In SAP, how can I get a list of tables?
Using the t-code SE16, press f4 on the table name, then click on info system and type * in the table name. I don't have access to SAP right now, however I believe the table DD02T has a list of all the tables. Look at the table with SE16.
These are the SAP Material Management tables
S/4HANA MIGRATION
When I was working on our S/4HANA migration, one of the key tools I leaned on was the Migration Cockpit. At first, I thought data migration would just be about “moving stuff over,” but the reality is much more complex—different structures, mappings, and business objects all need to line up. The cockpit made that manageable.
It’s SAP’s built-in tool for moving data from old SAP systems (or even non-SAP systems) into S/4HANA.
It uses migration objects—basically templates that define how data should be transferred into business objects like customers, vendors, or materials.
Each migration object knows the source and target structures, plus the mapping rules. That saved me from reinventing the wheel.
Simplification Database → I downloaded the ZIP from SAP Marketplace and uploaded it with SYCM_UPLOAD_SIMPLIFIC_INFO. This gave the cockpit the knowledge of what’s changed in S/4.
Custom Code Analyzer → I ran it and uploaded results with SYCM_UPLOAD_REPOSITORY_INFO. That way, the cockpit could cross-check our custom code against the simplification items.
Worklist Output → The ALV-style report was gold. It showed obsolete objects, modified ones, and linked directly to SAP Notes explaining what needed fixing.
SAP says migrations usually take 10–15 months, and from my experience that’s about right. It depends on system size, complexity, and how much custom code you’ve got. The cockpit doesn’t magically shorten the timeline, but it does cut down the manual analysis work.
Here’s the consultant-level takeaway:
Without the cockpit, you’re guessing. You’d have to manually map data fields, check compatibility, and hope you didn’t miss anything.
With the cockpit, you get structure, automation, and confidence. It flags issues early, gives you SAP Notes for fixes, and keeps the migration organized.
For me, the lesson was: data migration isn’t just technical—it’s business-critical. If you mess it up, you risk losing key records or breaking processes. The cockpit gave us a way to plan, prioritize, and execute without drowning in complexity. It turned what could have been chaos into a structured project.
Often we think about how SAP Fiori are being license throughout the use of various SAP products. Well for instance Solution Manager has fiori access, SAP Marketing has Fiori access, SAP One Launchpad in SAP Public domain as Fiori user interface.
Now coming to straight to the facts:
It took me a while to understand how the license works and for my environment i managed to find it out but for the rest of component software which uses fiori it might be packaged differently. You may want to check with your SAP contract or account manager.
SAP Fiori is included as part of SAP Gateway license in general that comes along when a customer sign up SAP Netweaver products.
However not only that Fiori access are also bundled in different ways maybe you need to explore with super admin access in SAP one launch pad on LIC tab to see how SAP fiori intergrated and to which product.
SAP LICENSE
When I was asked to confirm what SAP products we were actually licensed for versus what we were using, I went straight to the License Utilization Information (LUI) application. It’s basically SAP’s cockpit for license visibility, and it saved me from digging through contracts manually.
First thing I realized: LUI isn’t open to everyone. Only Super Admins can access it directly.
For other S-users in the company to see it, the Super Admin has to assign the right profiles in the SAP ONE Support Launchpad. So I had to coordinate with our admin team to make sure the right people got access.
Logged into the SAP ONE Support Launchpad and opened LUI.
Reviewed the overview screen—it showed our current license consumption against entitlements.
Broke it down by on-premises access licenses and cloud access licenses, since we’re running a hybrid setup.
Exported the data so I could share it with management and compare against what we thought we had in our contracts.
Here’s the thing: license checks aren’t just a technical exercise. They’re about money and compliance.
If we’re over-consuming, SAP can hit us with penalties during audits.
If we’re under-utilizing, we’re wasting budget on licenses we don’t need.
Having visibility means we can plan migrations (like moving more workloads to cloud) without surprises.
For me, the big takeaway was: LUI gives you confidence. Instead of guessing or relying on outdated spreadsheets, you get a real-time view of entitlements versus usage. That’s critical when you’re advising management or preparing for an audit.
SAP IS-RETAIL
So I was trying to understand how SAP IS-Retail actually gets installed. At first, I thought there might be a separate installer just for IS-Retail, but turns out that’s not how it works.
IS-Retail isn’t a standalone product—it’s built on top of SAP ERP.
That means you don’t go hunting for some special “IS-Retail installer.” You start by installing the right release of SAP ERP.
Once ERP is in place, you don’t magically get retail features until you switch them on. That’s where the switch framework comes in.
Basically, IS-Retail is like an add-on layer that you activate inside ERP rather than something you install separately.
Install SAP ERP with the release your project requires.
After ERP is up, enable IS-Retail in the switch framework.
SAP has a note (FAQ on setting the retail switch) that explains how to do this.
Once the switch is active, the retail-specific functions become available.
The tricky part is realizing there’s no separate “IS-Retail installation software.” It’s all about ERP first, then flipping the right switches. Easy to miss if you’re expecting a dedicated installer.
CCMSIDB
When our company decided to move to S/4HANA, I got the job of checking our custom ABAP code. Honestly, I thought it would be a nightmare—years of legacy code, half of it written before I even joined. But SAP gives us tools that make the whole process way less painful: the Custom Code Migration Worklist (CCMSIDB) and the Simplification Database.
Think of CCMSIDB as the “code detective.” It compares our custom programs against the Simplification Database and flags anything that won’t play nicely in S/4HANA. Without it, we’d be manually combing through thousands of lines of code, which is… not fun.
I grabbed the ZIP file from SAP Marketplace and uploaded it with SYCM_UPLOAD_SIMPLIFIC_INFO. That gave the analyzer the brains it needed to know what’s obsolete or changed in S/4.
Next, I fed in our code references and usage data using SYCM_UPLOAD_REPOSITORY_INFO. The output was an ALV-style report showing:
Objects that were obsolete
Objects that had been modified
Direct links to SAP Notes explaining what needed fixing
It was basically a “to-do list” for our migration.
We didn’t try to fix everything at once. Instead, we prioritized high-impact objects—the stuff that would break business processes if left untouched. Developers worked through them, and we validated changes with ATC checks.
Here’s the thing: moving to S/4HANA isn’t just about shiny new features. If your custom code isn’t ready, you risk downtime, broken processes, and frustrated users. CCMSIDB saved us weeks of guesswork and gave us confidence that we weren’t walking blind into the migration.
For me, the biggest lesson was that tools like CCMSIDB aren’t optional—they’re survival gear. They make sure you’re not dragging broken legacy code into a modern system. And honestly, having that automated worklist felt like someone handing me a cheat sheet before an exam.
