SAP Community - SAP HANA

SAP partners supporting BACKINT/SPLITINT interface

2026-07-03T18:30:32.208000+02:00

Hello,

I am trying to verify if this is true but I am unable to access this note

SAP Note: 83792 - SAP partners supporting BACKINT/SPLITINT interface stating that SAP is not supporting this interface anymore: no SAP support is available for problems, malfunctions, or failures in connection with the use of such external backup or storage solutions.

This is the link AI provided but doesn't work - https://service.sap.com/sap/support/notes/83792

VAT registration number in billing document

2026-07-06T09:39:42.196000+02:00

Hi i have an BP customer where VAT number is updated to new one, after change of VAT in BP its still picking old VAT number in new billing documents and printing the old VAT number in pdf too.

All partners are same Ship to, sold to , payer and bill to, payer is getting printed with correct new VAT, but ship to is still picking old VAT in both billing doc and pdf

PR Email Notification Issues Incorrect Deadline Date/Time & Missing Decision Note in Rejection Email

2026-07-07T15:17:34.647000+02:00

We are facing two issues with the standard SAP email templates used for Purchase Requisition (PR) and Purchase Order (PO) approvals and would appreciate your help.

Issue 1: Incorrect Deadline Date and Time in Email Notifications

We have noticed that the approval deadline shown in the email notification is displaying zeros instead of the actual due date and time.

Example:

PR created on 07-Jul-2026 at 2:00 PM
Approval deadline configured for 2 hours

Based on this, the email should show the deadline as 07-Jul-2026 at 4:00 PM.

However, the deadline field in the email is showing an incorrect value (all zeros) instead of the calculated due date and time.

Has anyone faced a similar issue? Is there any standard configuration or data source that controls this value in the email template?

Issue 2: Decision Note Not Available in PR Rejection Emails

When an approver approves or rejects a PR or PO, SAP provides two fields:

Decision Reason
Decision Note

For PO rejection emails, both the Decision Reason and Decision Note are included in the email notification.

However, for PR header-level rejection emails, only the Decision Reason is available in the standard email template. The Decision Note entered by the approver is not displayed.

We would like to understand:

Where is the Decision Note stored for PR header-level approvals/rejections?
Is this information available in any standard CDS view, workflow container, or business object?
Has anyone successfully added the Decision Note to the PR rejection email notification?

Any guidance, examples, or suggestions would be greatly appreciated.

Thank you in advance for your support.

HANA Storage Issue

2026-07-09T08:34:31.460000+02:00

I have cleaned up the *** pointer data via transaction BD22 by removing all records from *** . The table volume has decreased from *** million entries to *** million entries.

When checking large tables and disk consumption via transaction DB02, the table size did not shrink immediately (I noticed the table size was reduced the next day).
However, the database disk usage overview still shows *** GB occupied with no reduction.
Is it safe to purge all data from table *** entirely?

------------------------------------------------------------------------------------------------------------------------------------------------
Learn more about the SAP Support user and program here.

Why Your SAP HANA System Replication Failover Works in Testing but Fails in Production

2026-07-12T19:18:00.310000+02:00

Why Your SAP HANA System Replication Failover Works in Testing but Fails in Production

Somewhere around my third or fourth HANA project, I started noticing something in the DR design docs: they almost all say some version of the same thing — System Replication gives you near-zero RPO and RTO under a minute. It's not a lie. I've run takeovers in sandbox and QA that finished in under sixty seconds more times than I can count. Green dashboard, clean logs, everyone nods, the document gets its sign-off.

Then the real thing happens. Not on a nice quiet Saturday morning either — usually it's 2am, half the bridge call is still finding their laptop, and the "sub-60-second" failover somehow eats forty minutes. Or HANA comes up primary just fine and nobody can actually log in. Or, worse, someone notices a batch of committed transactions that just aren't there anymore.

None of that is HANA's fault, by the way. In every case I've dug into afterward, the database did precisely what it was told to do. The mess was always somewhere else — a stale DNS cache, a connection pool that never learned to reconnect, an app server quietly queueing requests instead of failing over. I've hit this same pattern often enough across on-prem, RISE, and hyperscaler-hosted HANA that it seemed worth actually writing down, rather than re-explaining it from scratch on every new project.

Why bother writing about this

System Replication underpins nearly every HANA HA/DR strategy out there, whatever infrastructure it's sitting on. Cloud ALM assumes it's configured correctly. Your DR runbook assumes it's been tested. But "tested" in most shops means one clean, scheduled failover, run when nobody's actually using the system. That tells you almost nothing about the messy version — a primary that hangs instead of crashing outright, app servers with cached DNS entries that don't expire for several minutes, a secondary whose memory was never warmed up so takeover turns into a long cold start, or MDC tenants that drifted out of sync while SYSTEMDB looked perfectly fine the whole time.

Get any of that wrong once and it's not just an SLA miss. It's the next six months spent explaining to leadership why the expensive DR setup didn't behave the way the slide deck promised.

Quick thing worth knowing: systemReplicationStatus.py only reports what the primary believes is happening. If the primary itself has gone dark, which is sort of the whole point of building HA in the first place, that script tells you nothing at all. Your failover logic has to rely on something that doesn't depend on the primary being reachable — an external HA/DR provider hook, not a person SSHing in to run a query after the fact.

The setup, roughly

Most enterprise landscapes I work with run a fairly standard three-tier layout — sync to a local secondary, async out to a DR site somewhere else entirely:

                 ┌───────────────────────────┐
                 │        PRIMARY (Site A)    │
                 │  HANA DB : Active/Primary  │
                 │  Mode: SYNC / SYNCMEM       │
                 └──────────────┬──────────────┘
                                │  Log Shipping (sync)
                                ▼
                 ┌───────────────────────────┐
                 │      SECONDARY (Site B)    │
                 │  HANA DB : Hot Standby     │
                 │  Mode: SYNC / SYNCMEM       │
                 │  Operation Mode: logreplay  │
                 └──────────────┬──────────────┘
                                │  Log Shipping (async)
                                ▼
                 ┌───────────────────────────┐
                 │       TERTIARY (Site C)    │
                 │  HANA DB : DR Standby      │
                 │  Mode: ASYNC                │
                 │  Operation Mode: logreplay  │
                 └───────────────────────────┘

That picture is fine, as far as it goes. But it's also usually where the architecture conversation ends, and that's the actual problem. What decides your real RTO isn't really pictured above at all — it's the replication mode you picked, whether the operation mode is logreplay or something lazier, whether Pacemaker or your cloud's native HA tooling is actually watching things closely enough, whether there's a virtual IP or DNS entry that will converge fast, whether your app servers are configured to fail fast and retry instead of queue, and whether anyone's actually watching the business-visible side of things through something like Cloud ALM.

I've started telling people: if it's not on the diagram, it doesn't get tested. So draw it all the way up to the logon group and whatever's doing health checks on your load balancer. Every failed production failover I've had to pick apart afterward turned out to be a network or application problem, never a HANA problem.

The one that stuck with me

There was a financial services customer — I won't get into which one — running what looked like a textbook setup. Sync secondary in the same availability zone, async DR site about 400km away, quarterly failover tests that always came in under 90 seconds. Everyone, understandably, felt good about it.

Then a storage controller firmware bug caused the primary host to hang. Not crash — hang. It kept answering pings, but any actual SQL call just sat there timing out. Pacemaker's resource agent caught it and triggered a takeover to the sync secondary, which was open and accepting connections in 45 seconds. Genuinely a good number.

Except the core switch's ARP cache took almost four minutes to let go of the old virtual IP, because the dying host was still intermittently answering at Layer 2. The ABAP application servers had rdisp/wait_for_rfc set at 300 seconds, so instead of failing and retrying against the new primary, they just sat there queueing work. And a custom Java interface on the SAP JDBC driver had a connection pool with no reconnect logic at all — it kept retrying the dead IP for a solid ten minutes before someone on the call finally just bounced the service by hand.

Total business-visible downtime ended up around 27 minutes against a contractual RTO of five. HANA did its part in under a minute. The other 26 minutes belonged entirely to pieces nobody had thought to include in the test plan. That's the project that convinced me to push, on every engagement since, for at least one unannounced failover test with real connection load, not just the polite Saturday version everyone's expecting.

Getting it right in practice

Here's roughly the sequence I walk through now, which goes further than the standard SAP guide precisely because it covers the parts that keep causing the actual damage.

Start by baselining where replication actually stands:

# Run as <sid>adm on the primary
python systemReplicationStatus.py

# For MDC systems, check tenant-level registration explicitly
hdbsql -i 00 -u SYSTEM -d SYSTEMDB "SELECT DATABASE_NAME, SECONDARY_HOST, REPLICATION_STATUS, REPLICATION_MODE FROM SYS.M_DATABASE_REPLICATION"

On MDC systems, always check tenant-level status separately. I've seen SYSTEMDB report ACTIVE while a tenant quietly fell out of sync after an unrelated restart, and nobody noticed for weeks.

Next, check whether the operation mode actually matches what you're promising for RTO:

SELECT SITE_NAME, SECONDARY_ACTIVE_STATUS, REPLICATION_MODE, OPERATION_MODE
FROM SYS.M_SERVICE_REPLICATION;

If this comes back delta_datashipping instead of logreplay, the secondary isn't continuously preloading data, so it'll cold-load at takeover time. On a small QA box that barely matters. On a large production system it's often the single biggest reason a failover that took forty seconds in the lab takes twenty-plus minutes for real.

Then the cluster layer:

crm_mon -1 -Af
cibadmin -Q | grep -A 20 "rsc_SAPHana"
grep -A 3 "\[ha_dr_provider_SAPHanaSR\]" /hana/shared/<SID>/global/hdb/custom/config/global.ini

Confirm the hook is actually registered and reporting — hdbnsutil -sr_state should agree with what Pacemaker thinks. A misconfigured hook is a nasty failure mode because everything looks fine right up until it isn't.

The step almost everyone skips is testing network convergence on its own, separately from the database entirely:

watch -n 1 "arp -n | grep <virtual_ip>"

# Cloud example (Azure route table)
az network route-table route show --resource-group <rg> --route-table-name <rt> --name <route-name>

Time how long it takes for the network, specifically, to converge on the new primary. On more than one project this number was bigger than the database takeover — which tells you something about where the DR budget probably should have gone in the first place.

Then check whether the application layer is actually going to reconnect rather than just sit there waiting:

grep -E "rdisp/wait_for_rfc|rsdb/reco" $DIR_PROFILE/DEFAULT.PFL

Worth checking SMLG too, to confirm logon groups actually route users somewhere useful once things move. Application servers using HANA's DBSL will reconnect on their own once DNS/vIP converges, but only if dbs/hdb/timeout_reconnect is tuned for what you're actually promising — the out-of-the-box setting tends to be more conservative than most RTO targets can afford.

And last, put real monitoring on top of all of it through Cloud ALM — a lightweight synthetic transaction, something that tells you when the business can actually work again, not just when the database says it's open. That's the number worth reporting up the chain, not the green checkmark from a script.

Commands and config in one place, since I always end up looking these up anyway

Purpose Command / transaction

Replication status (primary side)	`python systemReplicationStatus.py`
Per-tenant replication status	`SELECT * FROM SYS.M_DATABASE_REPLICATION`
Service-level replication mode	`SELECT * FROM SYS.M_SERVICE_REPLICATION`
Manual takeover	`hdbnsutil -sr_takeover`
Local SR state	`hdbnsutil -sr_state`
Re-register old primary as secondary	`hdbnsutil -sr_register --remoteHost=<host> --remoteInstance=<nr> --replicationMode=sync --name=<siteName>`
Cluster status	`crm_mon -1 -Af`
Resource location	`crm_resource --resource rsc_SAPHana_<SID>_HDB<NR> --locate`
Logon group config	`SMLG`
Profile parameters	`RZ11`
Replication dashboard	HANA Cockpit → System Replication
Synthetic business monitoring	Cloud ALM → Business Process Monitoring

[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/srHook
execution_order = 1

[trace]
ha_dr_saphanasr = info

The mistakes I keep seeing, project after project

The most common one, by far, is leaving the operation mode on delta_datashipping and not realizing it until a large production failover runs long. Second is only checking SYSTEMDB and assuming the tenants are fine — they're often not, and nothing will tell you unless you specifically go looking. DNS TTLs left too high are another classic; app servers keep hammering an address that's already dead. Default reconnect timeouts are almost always too generous for anyone with a serious RTO. And a lot of teams simply never run an unannounced test — everything's scheduled, everything's calm, and then reality doesn't cooperate.

I'd also add: check the tertiary site. Multi-target replication chains have a way of quietly breaking somewhere in the middle and nobody notices for months, because everyone's watching primary-to-secondary and the DR-of-the-DR gets forgotten.

When a takeover technically "succeeds" but people still can't work, here's roughly the order I check things:

New primary actually accepting connections (hdbsql ... SELECT * FROM DUMMY)
Virtual IP or DNS genuinely converged, from the app server's point of view, not the database's
Work processes reconnecting instead of queueing — worth a look at the dev_w* traces
Logon groups routing correctly through SMLG
Any custom middleware connection pools actually reconnected, not just retrying forever
Cloud ALM synthetic transaction back to green

A few performance things worth knowing

Log buffer sizing gets overlooked more than it should. Undersized buffers mean more frequent segment switches, which can momentarily stall sync replication under real load — size for peak throughput, not the average day. For an async tertiary, keep an eye on available bandwidth; if it's not enough, the log backlog just quietly grows and your real RPO ends up worse than the configuration implies, and you won't know until you check SHIPPED_LOG_BUFFERS_COUNT and the backlog size directly. After a takeover, M_CS_TABLES will show you what's actually loaded — a system can report itself open while the tables people actually need are still cold. And don't schedule a delta merge to land during your DR test window; it'll throw your numbers off in one direction or another and you'll never quite know which.

Small thing that catches people out: logreplay_readaccess lets you run reporting against the secondary, which sounds great for getting some use out of otherwise idle hardware. But it also means more stays warm in memory over there, so the secondary needs sizing like it's doing real work — not a passive standby. I've seen this missed during the original sizing exercise more than once, and it's an awkward conversation to have after the fact.

And a bit on security

Turn on enable_ssl for replication traffic, especially anything crossing to a DR site outside the trusted network, and actually own certificate renewal somewhere central — an expired cert breaks replication with an error message that gives you almost no hint what actually went wrong. Don't assume the secondary inherits the same authorizations and audit configuration as the primary; verify it, particularly anything hardcoded like hdbuserstore entries pointing at a physical hostname rather than the logical one. And check audit logging continuity after a takeover — a failover shouldn't quietly create a gap in your compliance trail just because the secondary's config drifted from the primary's.

What I'd actually tell a team building this today

Default to logreplay unless there's a specific cost reason not to. Let cluster software drive the takeover — manual hdbnsutil -sr_takeover should be the backup plan, never the plan. Put the network and application layers on the same architecture diagram as the database and hold them to the same testing standard. Run at least one unannounced failover a year under real load, not just the scheduled kind. Report recovery time the way the business experiences it, through Cloud ALM, rather than the database-only number. And take reintegration — putting the old primary back as a secondary via hdbnsutil -sr_register — just as seriously as the takeover itself, because that's where I've watched teams get burned a second time.

Before go-live, I'd want to see the operation mode matched to the actual RTO target, tenant-level replication validated on any MDC system, the cluster tested against a genuine hard failure and not just a graceful stop, network convergence measured on its own, app server reconnect settings actually tuned and tested, Cloud ALM monitoring live, SSL enabled with someone clearly owning renewal, an unannounced test on the calendar, and failback documented and rehearsed — not just written down somewhere nobody's opened since go-live.

What I've taken away from doing this a few times now

A green replication status is necessary, but it's nowhere near sufficient — I treat it as one data point among several these days, not the whole story. Application teams are often nowhere near the room when HA/DR gets planned, and yet their connection pool settings are frequently what actually determines the real recovery time; getting them involved early is worth the awkward extra meeting. Planned drills build a kind of false confidence — every genuinely surprising production failover I've been pulled into had passed several scheduled tests beforehand, which tells you the tests weren't measuring the right thing. Sizing the secondary like a full production peer, not a scaled-down afterthought, pays for itself the first time logreplay actually has to keep pace with real throughput. And reintegration is where the second outage tends to happen — more than one customer I've supported failed over cleanly, then broke replication again during failback because nobody rehearsed that half with the same care as the first half.

The short version, if you're skimming

HANA System Replication itself is solid. Most of the pain in a real failover comes from what's built around it, not the database engine. Use logreplay when RTO actually matters. Test under real, unannounced conditions at least once a year — a quiet Saturday morning tells you very little about a 2am incident. Measure recovery the way the business experiences it, not the way the database reports it. And give reintegration the same respect as the takeover.

References

SAP HANA Administration Guide — System Replication chapter, SAP Help Portal
SAP Note 1999880 – FAQ: SAP HANA System Replication
SAP Note 2407186 – How-To Guides & Whitepapers for SAP HANA High Availability
SAP HANA SR cluster guides for SUSE/Red Hat, via SAP's HA/DR partner documentation
Cloud ALM Help Portal — Business Process Monitoring

A few questions people usually ask me

Does logreplay mean there's no cold-load impact at all? Not quite. It keeps replicated tables continuously loaded on the secondary, which helps enormously, but anything not yet loaded on the primary at the moment of replication won't be preloaded on the secondary either. Full parity still depends on what the primary itself has loaded.

Should the local secondary always be SYNC? For most Tier-1 systems, yes, if zero RPO is genuinely the requirement. Just know it makes write latency sensitive to network conditions between the sites, so test it under real peak load rather than an idle system where everything looks fast.

Can Cloud ALM trigger the failover itself? No — it's monitoring and alerting, including synthetic business checks. The actual failover mechanics should stay with cluster software or your cloud provider's native HA service.

How often is often enough for testing? Quarterly planned tests at a minimum, plus at least one unannounced test a year under something resembling real load. If there's a tertiary DR site, test it on the same schedule — it's easy to let that one slide for months without anyone noticing.

Curious whether others have run into this same pattern — a takeover that was clean at the database level but still cost real downtime because of something in the network or application layer. What's in your unannounced-test runbook, and how do you get the application teams into the room early enough for it to matter? Would genuinely like to hear what's out there.

page orientation landscape zebra printer

2026-07-13T11:53:22.554000+02:00

Hi expert,

please help how to set zebra printer for landscape oriented.

Our current printer configuration:
1. Printer driver version 10 is installed as 300dpi printer model
2. The label size is set correctly as 100mm wide x 50mm height
3. From SAP side the device type is selected correctly which is 300dpi

the print result still portrait when print using smartforms

Thank you

Workflow Requirement within ICMR Period close

2026-07-13T15:28:53.918000+02:00

Hi Experts,

We have a requirement to enable workflow to 2 set of approvers during closure of the Reconciliation period within ICMR.

1. The workflow should be triggered to first set of approvers in case the difference exist between company and trading partner balance, but the difference is within tolerance.

2.The workflow should be triggered to second set of approvers in case the difference between company and trading partner balance, exceed the tolerance limit set for the reconciliation case.

While trying to configure this, SAP has provided to select only one of the available option against a matching method- 1. No workflow, 2. Workflow when differences exist, 3. Workflow when difference exceed the set tolerance limit. We have selected option 2 as SAP doesn't allow to select both option 2 and 3 for a single matching method.

We have also tried to create a step within a single workflow to trigger it to second set of approvers in case differences exceed set tolerance limit. However, there is no precondition or amount limit that can be set in the manage workflow app.

Kindly, suggest if there are any existing solution which can be used to achieve this. We want to go for standard SAP solution if possible.

Thanks in Advance.

Has any one written the SAP HANA project management certification?

2026-07-14T12:52:50.731000+02:00

Has any one written the SAP HANA project management certification?

How easy was it and are there some HANA books that you could share to come up to speed on this?

As the major part of my experience has been focused on Manufacturing it would be good to study other resources if available.

How to handle special characters and space in the standard database table in S/4 HANA 2023 SP02

2026-07-15T14:38:32.071000+02:00

Special characters and unwanted spaces are being stored in text fields within the standard database table. We are encountering issues when retrieving records containing these special characters, as they are not visible at the database level. However, when the extracted data is transmitted to an external system, the presence of these hidden special characters causes the interface processing to fail.

Does SAP have any existing tool or app or program that can help identify the special characters in the database and potential remove that special character from the database?

Data Cleansing of SAP Standard Tables by Removing Special Characters and Spaces in S/4HANA 2023 SP02

2026-07-15T19:41:38.334000+02:00

Special characters and unintended whitespace are currently being stored in text fields within standard database tables. These non-printable or hidden characters are not readily visible at the database level, making them difficult to identify during data validation and analysis.

However, when records containing these characters are extracted and transmitted to external systems, they cause interface processing failures and data integration issues.

Do SAP provide any tools or app's or programs that can detect hidden special characters within database fields and support their removal or cleansing?

SOC3N Data Not Deleted as per SAP Note 3382503

2026-07-16T11:02:32.702000+02:00

Dear Team,

The data in table SOC3N has not been deleted as expected after implementing SAP Note 3382503.

Could you please suggest the recommended procedure to delete the existing data from table SOC3N? We have reviewed the note; however, the records are still present in the table.

Kindly advise on:

Any additional reports or cleanup programs that need to be executed.
Whether there are any prerequisites or follow-up SAP Notes required.
The recommended SAP-supported approach to remove the data from SOC3N.

How to transport COPA characteristic descriptions and Values from Dev to prod

2026-07-17T09:42:16.269000+02:00

Dear SAP Support Team,

How to transport chaanges of COPA characteristic descriptions (KEA5) and Values (KES1) from development system to production system.

Could you pleaes provide step by step process. Our current system SAP S/4 Hana 2023 on Premise. S/4 Hana 1909 was implemented in 2022. later in 2025 it was upgraded to S/4 Hana 2023.

Could you please provide what options I have to select while generating transport request KE3I.
This TR movement should not impact COPA derivation strategy steps (KEDR)

Thanks,

Srinu Mummidi

SAP Business One Service Layer returns HTTP 500 code 299 when calling a parameterized

2026-07-17T19:22:42.059000+02:00

Hello everyone,

I am working with SAP Business One on SAP HANA and Service Layer.

I created and exposed a HANA calculation view. The view is correctly published in the SL metadata:

GET /b1s/v2/sml.svc/$metadata

I am calling the view using the following URL:

GET /b1s/v2/sml.svc/VIEWParameters(IP_FECHAFIN=2026-07-31,IP_FECHAINI=2026-07-01)/VIEW

However, Service Layer returns:

{
"error": {
"code": "299",
"details": [
{
"code": "",
"message": ""
}
],
"message": "Internal server error."
}
}

The HTTP status code is: 500 Internal Server Error

Tests already performed

The Service Layer session is valid. Other Service Layer endpoints work correctly.
Other custom SL views without parameters work correctly.
The parameterized calculation view executes correctly directly in SAP HANA Studio using the same date range.
The HANA user has the required permissions.
The view is present in $metadata, including the parameter entity and navigation property.
Both /b1s/v1/sml.svc and /b1s/v2/sml.svc were tested, with the same result.

Additional observation

The SAP Business One Analytics Platform administration page is also showing:

CPU: undefined
Memory: undefined
Disk: undefined
License Server: undefined
Status: 500

The System Logs section of the Analytics administration console displays: Internal Error

Questions

Is the URL syntax correct for a SL calculation view with two Edm.Date parameters?
Is there a known Service Layer issue with HANA calculation-view parameters of type DATE?
Should the parameters be changed from DATE to NVARCHAR and converted with TO_DATE() inside the calculation view?
Could the Analytics Platform status 500 affect parameterized Semantic Layer views?
Which Service Layer or Analytics log contains the actual HANA exception behind Service Layer error code 299?
Is there a known SAP Note or patch related to this behavior?

Thank you.

Relatório desvios lista técnica

2026-07-20T16:14:00.485000+02:00

preciso de um relatório para analisar os desvios de lista técnica padrão e real por m²

released price already exists for material // Without CKR1

2026-07-20T16:20:38.564000+02:00

Hi SAP Team,

We want to re-cost the material (change in BOM has been performed), which cost estimate is released for the current period. We have locked the CKR1. hence, we cannot use it and also tries with "No Transfer of Cost Estimates" flag in CK40n, but still facing the error:

Material TFBKGUPTDPDNSUSGNN07486F0900629 in plant T213 has a released cost
estimate

Message no. CK171

Do we have any other tcode for this? also please note the costing was initially done via CK11/ CK24

Delta merge was not executed in HANA

2026-07-21T00:03:03.318000+02:00

Hi Team,

we could see the below alert, Delta Merge was not executed successfully for table CS_AUDIT_LOG_ in schema _SYS_AUDIT for 1 occurrences in the last 24 . Kindly let us know the root cause and to fix the issue.

File-based S/4HANA migration tool: Interoperability Review or Integration Certification?

2026-07-21T12:49:44.750000+02:00

I'm building an ISV solution and want to understand which certification track applies before I lock the architecture.

What it does: migrates financial data (balance sheet, P&L, WIP) from SAP R/3 to S/4HANA — reads a customer's own extract (e.g. CJI3), applies a customer-specific mapping, and generates journal-entry load files plus a validation report evidencing a zero delta.

Runs as a stateless multi-tenant SaaS on AWS, not on SAP BTP.
Read-only towards the source — no ABAP transport, no code in the customer landscape.
Today it produces files; it does not call SAP APIs directly.

It has already been used on a real enterprise migration; I'm now bringing it to market as a product.

Questions:

Under the Jan-2026 framework, would a file-based tool like this fall under Interoperability Review rather than Integration Certification?
If we switched the output to the released Journal Entry – Bulk Create API, would that on its own qualify us for Integration Certification — or does that track also require running on SAP BTP?

Pointers to documentation I may have missed are just as welcome as an answer.

待機系の/hana/data領域の使用率増加要因について

2026-07-22T01:49:40.696000+02:00

ご担当者様

待機系の/hana/data領域の使用率が増加する要因を教えてください。

/hana/data領域は1196GBあり先月（2026/6）約11GB増加しております。

前提条件として下記２点となります。
・フェイルオーバーは行われていない。
・不要なファイルは格納していない。

最低でも一年以上微増・微減はありましたが大きく増えたことがなく
回答の程お願いします。

CKM3 - Good receipt value is not showing in actual value

2026-07-22T14:12:40.403000+02:00

Good receipt are showing in contract cost instead on spliting as per cost compenent more details are added in attached word document.

SAP HANA - hdbsql -I vs Ansible Module to execute HANA SQL (community.sap_libs.sap_hdbsql)

2026-07-22T17:45:48.429000+02:00

Hi,

When executing SQL statements with SAP HANA hdbsql with -I <file> option, the execution continues with the next SQL statements when an error occurs.
When executing SQL statements with the Ansible Module to execute SAP HANA SQL (community.sap_libs.sap_hdbsql), the execution stops when an error occurs.

How to make the execution continue when an error occurs with the SAP HANA Ansible Module (community.sap_libs.sap_hdbsql) ?

Thanks for your help