VA01/02: Eingabebereite Felder ermitteln

VA01/02: Eingabebereite Felder ermitteln

Moin moin,

ich suche gerade nach einem Weg, zu ermitteln, welche Felder der VA01 oder VA02 eingabebereit auf den entsprechenden Dynpros vorhanden sind. Sowas wie der Feldstatuskram im FI.

Hintergrund ist ein Batch-Input, bei dem ich Fehler a la "Feld x ist auf Dynpro y nicht vorhanden" von vornherein ausschließen möchte.


Gruß

Ralf

Re: VA01/02: Eingabebereite Felder ermitteln

Ja, gibt es. Der Anwender soll vor dem Sichern nochmal draufgucken. Außerdem kann es sein, dass "Müll" in den Aufträgen steht. Nehme ich den BAPI, brauche ich Dynpros zum Ändern der Daten.

Re: VA01/02: Eingabebereite Felder ermitteln

ewx hat geschrieben:Zumindest zum Anlegen gibt es eine Alternative: BAPI_SALESDOCU_CREATEWITHDIA

Die anderen BAPIs haben ein Simulationsflag; vielleicht ist das noch eine Option?

Das Problem beim BAPI_SALESDOCU_CREATEWITHDIA ist, dass wir zu viele "Spezialitäten" haben (eine davon: Der Auftrag muss zuerst ohne Positionen angelegt und dann gesichert werden, damit ich eine Belegnummer habe, unter der ich die Langtexte speichern kann - sodann wird die VA02 aufgerufen, der Rest der Daten wird eingespielt, damit der Anwender vor dem Sichern (das macht er dann selbst) den ganzen Auftrag so sieht, wie er gebucht wird, eben inkl. Langtexte. Ich sehe keine Möglichkeit, die Langtexte dem Funktionsbaustein mitzugeben).

Das Simulationsflag reicht leider nicht, weil ich dann zwar dem Anwender sagen kann, was an dem Auftrag nicht stimmt, aber dann eine Möglichkeit schaffen müsste, wie er die Auftragsdaten ändern kann, ehe er sie nochmal einspielt. Und ich will keine Nachverbuchungstransaktion schreiben. Da ist die Variante mit dem Batch-Input die einfachste - das Ding hält bei einem Fehler von selbst an, der Anwender korrigiert und das Programm läuft weiter.

Ich bin wahrlich kein Freund von Batch-Inputs, aber in diesem Falle ist das wirklich die einfachste Möglichkeit.

Der Grund, warum ich frage, ist folgender:

Ich würde gern nicht jedes Feld einzeln codieren wenn ich die Batch-Input-Tabelle aufbaue, sondern anhand Programm/Dynpro feststellen, ob das Feld auf dem Dynpro eingabebereit zur Verfügung steht. Dann und wenn das Feld nicht initial ist, soll es in die Mappe geschrieben werden. Im Ergebnis würde ich einfach die Dynpros durchlaufen und per ASSIGN COMPONENT alle Felder füllen, die mir als auf diesem Dynpro eingabebereit bekannt sind.

Dazu gibt es zwei Möglichkeiten:

1. Ich hinterlege eine Tabelle Programm/Dynpro/Feld, in der alle Felder gepflegt sind, die versorgt werden sollen. Das Schöne dabei ist: Soll ein Feld neuerdings oder nicht mehr versorgt werden, reicht eine Tabellenänderung aus, um das zu veranlassen. Das Programm muss nicht geändert werden. Sprich: Das kann der Anwender selbst machen.

2. Es ist irgendwo hinterlegt, welches Feld eingabebereit auf welchem Dynpro steht, dann kann ich mir die eigene Tabelle schenken und kann mich danach richten, was ich auf diese Weise ermittle.

3. Man könnte diese beiden Varianten auch kombinieren, indem man aus der ermittelten Menge der eingabebereiten Felder (siehe 2) noch Felder ausnimmt, indem man sie in einer Tabelle pflegt (siehe 1).

Das würde den Batch-Input erheblich vereinfachen, weil ich nur noch für jedes Bild den ASSIGN COMPONENT machen würde, ohne explizit jedes einzelne Feld mit einem Wert aus meinen Übergabedaten zu füllen.

Hintergrund ist dabei folgender: Ich habe hier einen Batch-Input, der mit der Zeit enorm gewachsen ist und langsam unübersichtlich wird. Darum soll er überarbeitet werden, wobei die überarbeitete Version exakt dieselbe Funktionalität hat wie die jetzige (alte) Version (wow, welcher Kunde bezahlt schon ein rein technisch begründetes Neuentwickeln eines Programmes?). Die Überarbeitung betrifft zwar eigentlich ganz andere Programmstellen, aber wenn ich einmal dran bin, kann ich das Ding auch komplett überarbeiten - im Zuge dieser Neuentwicklung des bestehenden Programmes habe ich daher insbesondere vor, den Batch-Input deutlich zu minimieren - eben dahingehend, dass ich nicht jedes Feld einzeln versorge, sondern die Mappenerstellung erheblich dynamisiere.

Daher meine Frage: Kann ich irgendwie ermitteln, welche Felder in der VA02 eingabebereit auf welchem Dynpro stehen. Allerdings habe ich inzwischen gesehen, dass die Bildnummer und das Programm für alle Kopfdatenreiter (Versand, Verkauf, Faktura, ....) identisch sind - ich müsste das also eher über die Subscreens definieren bzw. ermitteln, ob ein Feld vorhanden ist oder nicht.

Die Frage ist, ob mir die Angaben im screen-Painter da weiterhelfen - da gibt's etliche numerische Einträge für SCREEN-GROUPs (in allen vier Feldern), Einträge zum Switch-Framework, etc. - aber natürlich steht nirgends, ob ich daraus schließen kann, welche Felder für mich eingabebereit sind

Re: VA01/02: Eingabebereite Felder ermitteln

ewx hat geschrieben:

Code: Alles auswählen.

DATA: BEGIN OF gt_bapi_header_texts OCCURS 0.
        INCLUDE STRUCTURE tlinekom.
DATA: msgfn LIKE bapisdtext-function.
DATA: END OF gt_bapi_header_texts.

EXPORT bapi_header_texts FROM gt_bapi_header_texts TO MEMORY ID 'SDBAPITEXTHD'.

Bei jeder SAP-Veranstaltung höre ich die Oberlehrer von der SAP über die Qualität des Codings bei Kunden meckern - und dann bauen die sowas ein??? Nirgends dokumentiert, saubere Leistung.

Naja, jedenfalls sind die Langtexte nicht die einzige Spezialität, die wir überwinden müssen, daher gibt es zum Batch-Input leider keine Alternative.

Re: VA01/02: Eingabebereite Felder ermitteln

Mir ist gerade ein Lösungsansatz über den Weg gelaufen:
BAPI im Simulationsmodus aufrufen und in einem Userexit den Baustein SD_FIELD_INPUT_CHECK für alle benötigten Felder aufrufen. Ergebnis in interne Tabelle und per EXPORT TO MEMORY für den Aufrufer bereit stellen.
Nach Ende Simulation die itab per IMPORT FROM MEMORY abfragen.

Allerdings steht in der Doku zu dem Fuba:

SAP Doku hat geschrieben:Vorsicht!!!
Es können damit nicht tatsächlich alle Fälle abgedeckt werden, sondern nur die allgemeingültigen!

Also ggfs. auch keine befriedigende Lösung...