| Summary: | DCC - Overhead-Aufruf DCC-Kennzahlenaufbau - parallele Workprozesse funktionieren nicht | ||
|---|---|---|---|
| Product: | [SCX/Suite] Controlling | Reporter: | cbr |
| Component: | Datenaufbau | Assignee: | Bertelmann, Marc <Marc.Bertelmann> |
| Status: | RESOLVED FIXED | QA Contact: | cbr |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | Janina.Niedermark, Marc.Bertelmann |
| Version: | 18.0 | Keywords: | Orion, Vorabkorrektur |
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Kundennummer: | Bestellnummer: | ||
| PV Übergabe: | --- | Phase Roadmap: | --- |
| Erledigt mit: | Orion | SAP Release: | --- |
| Transport: | M38K902025, M48K901967, M39K901216, M49K901220 | CRM-ID/Ticket: | 017343 |
|
Description
cbr
2019-05-08 23:47:20 CEST
Vorab möchte ich zwei wichtige Erkenntnisse mit euch teilen: 1. Es ist nicht möglich innerhalb eines ausgelagerten WP mit MEMORY IDs zu arbeiten 2. Es ist nicht möglich innerhalb eines ausgelagerten WP mit DIRTY ASSIG zu arbeiten Der Grund dafür scheint zu sein, dass nur innerhalb einer Session auf die M-ID zugegriffen werden kann. Der WP ist in einer anderen Session unterwegs. Auch bekommt der WP einen eigenen Stack, weshalb auch auf keine Variabeln von aufrufenden Programmen zugegriffen werden kann. Lösung: Meine Idee war es innerhalb des WP nochmal die Lagerorte pro Materialblock nachzulesen. Damit ich weiß, dass ich im ARFC unterwegs bin, habe ich noch einen versteckten Parameter PA_ARFC angelegt. In diesem Fall lesen wir nicht mehr die CB_MAT Tabelle via MEMORY, sondern nehmen direkt die SO_MATNER des ARFC SUBMITS. Die Vorselektion übergibt bereits ausschließlich CB_MATS an den ARFC Baustein. Gelöst auf E74/FE0 Orion. Das Programm /GIB/DCC_HISTORY_KFCB ist nun der neue Kennzahlenaufbau und wird freigegeben. Das Programm ist über das GIB ADMIN Tool aus erreichbar. |