We’re experiencing critical issues with our asset depreciation workflow during month-end closing. The workflow consistently hangs when processing around 15,000 assets, specifically during the OASV posting step. We’ve configured RFC parallel processing with 5 background work processes, but the workflow still times out after 3 hours.
Our current batch size is set to 1000 assets per job, and we’re seeing work process allocation bottlenecks in SM50. The depreciation posting configuration in AFAB shows no obvious errors, but the workflow never completes the FAG integration posting.
Error in OASV: TIME_OUT
RFC destination PARALLEL_GEN not responding
Work process allocation: 5/5 occupied
This is blocking our financial close process completely. Has anyone resolved similar workflow hanging issues with asset depreciation in 1809?
This solution worked perfectly! After implementing all the changes - especially increasing work processes to 10, reducing batch size to 350, and enabling capacity caching - our depreciation run completed in 72 minutes for all 15,000 assets. The RFC connection optimization was crucial; we were definitely hitting connection limits before.
The workflow container timeout adjustment in SWDD also eliminated the hanging issue. We monitored SM50 throughout and work process utilization stayed around 70%, leaving enough headroom for other operations.
One additional note: we also applied SAP Note 2847193 which included some ABAP code optimizations for parallel asset processing that further improved performance. The capacity caching in CR01 made a massive difference - we hadn’t realized how much overhead those repeated capacity checks were adding.
Month-end close completed on time for the first time in 6 months. Thanks everyone for the guidance, especially the comprehensive solution that addressed all four focus areas systematically!
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check your RFC destination configuration first. PARALLEL_GEN might be hitting connection limits. Go to SM59 and verify the maximum number of dialog processes allowed. We had similar timeout issues and found our RFC was capped at 3 connections while trying to run 5 parallel jobs.
Your batch size of 1000 is too aggressive for 1809 with that asset volume. We reduced ours to 500 assets per batch and staggered the execution. Also check transaction OPPQ to see if capacity checks are enabled - they can significantly slow down depreciation runs. The work process allocation shows all 5 processes occupied, which suggests you need to either increase available work processes or reduce parallel job count to 3. Monitor transaction SM50 during the next run to see which processes are actually waiting versus actively processing.
Thanks for the suggestions. I checked SM59 and the RFC destination was indeed limited to 3 connections. I’ve increased it to 6, but I’m concerned about the batch size recommendation. Won’t reducing from 1000 to 500 just make the process take longer overall? We’re already timing out at 3 hours.
Actually, smaller batches often complete faster in total because they prevent memory bottlenecks and work process contention. Each batch commits independently, so if one fails, you don’t lose the entire run. I’d recommend 300-400 assets per batch for your volume. Also verify your shift calendar in CM01 - if depreciation posting is trying to run outside defined shift periods, it can cause unexpected delays.
One thing nobody mentioned yet - check your capacity caching strategy in CR01. If caching is disabled or poorly configured, each depreciation calculation triggers a fresh capacity check, multiplying processing time exponentially. We enabled capacity caching with a 24-hour refresh window and saw our depreciation run time drop from 4 hours to 45 minutes. The workflow definition in SWDD should also have proper error handling branches - if OASV times out, the workflow should retry with exponential backoff rather than just hanging. Review your workflow container elements to ensure timeout values are properly passed through the RFC calls.
I see several configuration issues that need addressing together. Your current setup is creating a perfect storm of bottlenecks. Let me walk through the complete solution based on the focus areas:
1. Depreciation Posting Configuration (AFAB/FAG)
First, verify your posting configuration allows for parallel posting. In AFAB, check that “Parallel Processing” flag is enabled for your depreciation areas. The FAG integration must be configured for asynchronous posting:
AFAB Settings:
Parallel Processing: Active
Commit Work Interval: 100
Dialog Work Process Reserve: 2
2. RFC Parallel Processing Setup
Your PARALLEL_GEN RFC destination needs optimization. Increase max connections to 8 (not 6) and configure proper resource management:
SM59: Set Max Connections = 8
Set Connection Type = 3 (Start on Application Server)
Enable “Load Balancing” to distribute across available app servers
Configure timeout to 7200 seconds (2 hours per batch)
3. Work Process Allocation
Your current 5/5 allocation is the core problem. Reserve work processes specifically for depreciation:
RZ04: Increase background work processes from 5 to 10
SICF: Configure 2 dedicated work processes for asset management
SM50: Monitor to ensure at least 2 processes remain free during peak
4. Batch Size Optimization
Reduce batch size to 350 assets with intelligent chunking:
// Pseudocode - Batch processing logic:
1. Query total assets needing depreciation
2. Calculate optimal chunks: TOTAL_ASSETS / 350
3. For each chunk, spawn RFC call with:
- Start_Asset_ID and End_Asset_ID range
- Commit interval = 50 (commit every 50 assets)
4. Implement RFC callback to track completion
5. Aggregate results only after ALL batches complete
// Reference: SAP Note 2847193 - Asset Parallel Processing
Additional Critical Steps:
Enable capacity caching in CR01 with 12-hour refresh
Verify shift calendar in CM01 covers your processing window
Check OPPQ to disable unnecessary capacity checks during depreciation
Review workflow definition in SWDD to add retry logic for RFC timeouts
Set workflow container element WF_TIMEOUT to 7200 seconds
Monitoring Strategy:
During next run, monitor:
SM50: Work process utilization (should stay below 80%)
SM37: Background job status for each parallel batch
ST22: Short dumps (should be zero)
SM21: System log for RFC connection errors
This configuration should reduce your processing time to under 90 minutes for 15,000 assets. Test with 5,000 assets first to validate the settings before running full month-end.