SD functions

[Former Member]

Hi,

Can anyone give me information regarding the following SD functions as to what their purpose is. Please be very descriptive.

SD_PARTNER_SINGLE_MODIFY,

SD_PARTNER_DATAGET,

SD_SHIPMENTS_SAVE,

SD_SHIPMENT_STATUS_PLANNED,

SD_SHIPMENT_PROCESS

your inputs are higly appreciated

[Former Member]

Hi !

Documentation is only availiable in german. You may translate it if you want.

The not listed functions don't have any documentation !

Regards

Rainer

Some points would be nice if that helped a bit.

FU SD_PARTNER_SINGLE_MODIFY

____________________________________________________

Kurztext

Add, change and remove of a Partner

Funktionalität

Funktionsbaustein zum Hinzufügen/Ändern oder Löschen eines einzelnen Partners

Der Baustein verwendet hierzu das lokale Gedächtnis der Funktionsgruppe V09A (siehe hierzu FB SD_PARTNER_OBJECT_CREATE) . Zur Identifiezierung dient der Objekttyp sowie der Objektschlüssel.

Die durchzuführende Aktion wird aus der Kombination der alten/neuen Kundennummer ermittelt:

alte Kundennummer neue Kundennummer Aktion

-

-

---

X Y Austauschen

X X Keine

Y Hinzufügen

Y Löschen

Keine

Es wird die Durchführbarkeit einer Aktion bzgl. des übergebenen Partnerschemas geprüft.

Durch übergabe der Aktion mit Hilfe des Parameters FIF_INITIAL_VALUE kann das Belegen eines Pflichtpartners mit dem Wert '0' bzw. ' ' erreicht werden (die Werte würden sonst als initial angesehen werden uns somit ggf. zum Löschen eines Partners führen).

Der Parameter FIF_DIALOG muß mit 'X' besetzt werden, wenn der Aufruf aufgrund einer Dialogaktion mit dem Benutzer erfolgt (z.B. der Benutzer hat einen Partner auf einem Dynpro verändert). Dies ist notwending, um Prüfungen, die nur im Dialog ausgeführt werden sollen, steuern zu können.

Mit Hilfe der Parameter FIF_NO_MESSAGES bzw. FIF_LISTPROCESSING kann die Auslösung von Fehlermeldungen unterdrückt bzw. Warnungen, die im Reporting zu problemen führen würden, in Informationen umgewandelt werden.

Mit dem Parameter FIF_CLEAR_APPL_LOG kann eine Löschung des Fehlerprotokolls verhindert werden. Dieser Parameter ist standardmäßig auf "X" gesetzt.

Durch den Parameter FIF_HARD_DELETION kann erreicht werden, daß ein Partner, ungeachtet des Partnerschematas, gelöscht wird. Dieser Parameter sollte nur in seltenen Fällen Verwendung finden und nur dann, wenn die Konsistenz der Partnerverarbeitung auf andere Weise (z.B. anschließende Hinzufügung) sichergestellt werden kann.

Der Parameter FIF_PARTIAL_NEW_DETERMINATION führt nach der erfolgreichen Hinzufügung/Änderung eines Partners eine neue Partnerfindung für die abhängigen Partnerrollen durch. Dieser Parameter ist derzeit zur Verwendung NICHT FREIGEGEBEN!

Der Export-Parameter FEV_ACTION_DONE gibt Auskunft darüber, welche Aktion durchgeführt wurde ("D","I","U" oder "E" für Löschen, Hinzufügen oder Ändern eines Partners sowie "E" im Fehlerfall). Dies ist der einzige Parameter, der zuverlässig Auskunft über die dürchgeführte Aktion gibt. Der SY-SUBRC kann null sein, obwohl die gewünschte Aktion nicht durchgeführt wurde.

Der Export-Parameter FRF_LOG_COUNT gibt Auskunft über die Anzahl der sich im Application Log (Objekt "SDBFPD", Subobjekt "ERRORS") befindlichen Fehlermeldungen.

Mit dem Parameter FIF_KNREF_PARNR läßt sich ein Debitor bestimmen, aus dessen Geschäftspartnerbeziehungen die KNREF Werte (Kundeneigene Bezeichnungen) entnommen werden sollen.

Beispiel

call function 'SD_PARTNER_SINGLE_MODIFY'

exporting

fic_objecttype = 'X'

fic_objectkey = 'Y'

fis_sdorgdata = sdorgdata

fif_pargr ='TA'

fif_parvw ='WE'

fif_posnr ='000000'

fif_kunnr_old = 'SEMMLER '

fif_kunnr_new = 'BACH '

importing

fev_action_done = action_done

exceptions

parameter_incomplete = 1

object_not_found = 2

check_error = 3

others = 4.

Das Beispiel tauscht den Warenempfänger 'SEMMLER' im Kopf des Beleges gegen den Warenempfänger 'BACH' aus.

FU SD_SHIPMENT_STATUS_PLANNED

____________________________________________________

Kurztext

Funktionen bei Setzen des Status 'Disponiert' im Transportkopf

Funktionalität

Bei Aufruf dieses Funktionsbausteins passiert genau das, was in der Transaktion VT01 bei Drücken des Status-Pushbuttons 'Disponiert' passiert.

Ist der Status schon gesetzt, wird dieser wieder zurückgenommen. Uhrzeit und Datum werden zurückgesetzt.

Ist der Status noch nicht gesetzt, dann wird dieser gesetzt. Datum und Uhrzeit werden mit Datum und Uhrzeit gefüllt (entweder aus den Vorgaben I_NEW_STATUS_DATE und I_NEW_STATUS_TIME, oder -- falls diese leer sind -- mit SY-DATLO und SY-TIMLO) Das Setzen des Status kann auch durch Angabe des Datums erfolgen.

Wenn der Status sich geändert hat, dann wird ein USER-EXIT angesprungen.

Wenn der Status sich von ' ' auf 'X' geändert hat, dann werden verschieden Funktionen durchgeführt:

Daten werden aus der Lieferung kopiert (siehe Doku zum Funktionsbaustein SD_SHIPMENT_COPY_DELIVERY_DATA)

Streckenermittlung wird durchgeführt (siehe Doku zum Funktionsbaustein SD_SHIPMENT_LEG_DETERMINATION)

Parameter und Tabellen:

I_TVTK enthält die Customizing-Daten der Transportart

(z.B. Route aus Lieferungen übernehmen: ja oder nein ?)

C_XVTTK ist der Transportkopf

Die folgenden Parameter und Tabellen sind für die Streckenermittlung wichtig und werden an den Funktionsbaustein 'SD_SHIPMENT_LEG_DETERMINATION' weitergegeben (Doku siehe dort)

I_DESTINATION

I_DEPARTURE

OPT_DIALOG

I_DEPARTURE_SEQUENCE

Hinweise

Sortierung der Transporttabellen

Die Tabellen der Transportbearbeitung sind zu jeder Zeit sortiert nach den Schlüsseln der Datenbank, um mit 'READ TABLE ... BINARY SEARCH' auf schnelle Weise zugreifen zu können.

Diese Tabellen enthalten Einträge für mehrere Transporte, somit stehen die Einträge eines Transport beieinander.

Es handelt sich um die folgenden Tabellen:

XVTTK, YVTTK Transportköpfe Sort: MANDT,TKNUM

XVTTP, YVTTP Transportpositionen Sort: MANDT,TKNUM,TPNUM,VBELN

XVTTS, YVTTS Transportabschnitte Sort: MANDT,TKNUM,TSNUM

XVTSP, YVTSP Zuordnungen Abschn./Pos. Sort: MANDT,TKNUM,TSNUM,TPNUM

XVBPA, YVBPA Partner Sort: MANDT,VBELN,POSNR,PARVW

XVTFA, YVTFA Belegfluss Sort: Datenbank-Key

XVBADR,YVBADR Anschriften Nicht sortiert

Inhalt der Transporttabellen

Die Tabelle Xtttt enthält hierbei den aktuellen Stand nach der Änderung,die Tabelle Ytttt enthält den alten Stand, wie er vor der Änderung auf der Datenbank stand.

Der Inhalt des Kennzeichens UPDKZ zeigt den Änderungszustand an.

Im INCLUDE RVDIREKT sind die Konstanten für das Kennzeichen definiert:

updkz_old(1) value ' ' - Keine Veränderung

updkz_new(1) value 'I' - Neuer Eintrag

updkz_update(1) value 'U' - Geänderter Eintrag

updkz_delete(1) value 'D' - Eintrag löschen

Die Tabelle XVTTP enthält sowohl die Einträge der zu einem Transport gehörenden Lieferungen (TKNUM, TPNUM sind gefüllt), als auch die Einträge für Lieferungen, die zu keinem Transport gehören (TKNUM, TPNUM initial).

Änderungen

Wenn Sie Änderungen vornehmen sollten oder neue Einträge aufnehmen wollen, dann müssen Sie dafür sorgen, daß die Sortierung erhalten bleibt.

Wenn Sie auf die Einträge eines Transports in einer der Tabellen zugreifen wollen, so sollten Sie zunächst auf den ersten Eintrag positionieren und per 'LOOP' den entsprechenden Ausschnitt der Einträge zu diesem Transport lesen:

read table xvttp with key mandt = sy-mandt

tknum = i_tknum

binary search.

if sy-subrc = 0.

loop at xvttp from sy-tabix.

if xvttp-tknum ne i_tknum. exit. endif.

...

endloop.

endif.

Weiterführende Informationen

Dieser Funktionsbaustein nutzt -- wie viele andere Funktionsbausteine in der Transportbearbeitung auch -- die Funktionsbausteine zur Protokollführung.

Das heißt, an strategisch wichtigen Stellen wie:

Fehlermeldungen und Warnungen

Beginn oder Ende einer bestimmten Funktion

Progammstellen, die über den Fortgang der Funktion informieren

werden Meldungen abgesetzt mittels des Funktionsbausteins SD_SHIPMENT_PROTOCOL_APPEND.

Diese Protokolleinträge werden im Gedächtnis der Funktionsgruppe V56P gespeichert und können bei Bedarf über den Funktionsbaustein SD_SHIPMENT_PROTOCOL_GET abgeholt und mit SD_SHIPMENT_PROTOCOL_OUTPUT ausgegeben werden.

Voraussetzung ist, daß die Protokollierung zuvor mit dem Funktionsbaustein SD_SHIPMENT_PROTOCOL_START aktiviert wurde.

Die Protokollierung kann mit SD_SHIPMENT_PROTOCOL_STOP wieder deaktiviert werden. Die Protokoll-Datei kann mit SD_SHIPMENT_PROTOCOL_REFRESH wieder initialisiert werden.

[Former Member]

Hi thanks for your reply, unfortunately I can't understand german, but please do require a response that I may give you reward points

[Former Member]

HI

Please find the English translation

RH: SD functions Posted: May 15, 2006 12:49 AT the Reply E-Mail this post office Rear one! Documentation is only availiable in German. You May translate it if you want. The emergency listed functions don't have any documentation! Regards Rainer Some POINTs would nice if that helped A bit. FU SD_PARTNER_SINGLE_MODIFY ____________________________________________________ Summary ADD, CHANGE and remove OF A partner Functionality Functional module for adding/changing or deletion of an individual partner The component uses for this the local memory of the function group V09A (see for this FB SD_PARTNER_OBJECT_CREATE). For the Identifiezierung the type of object as well as the object key serve. The action which can be accomplished is determined from the combination of the old/new customer number: old customer number new customer number action -

-

---

X Y exchange X X none Y adding Y deletion None The feasibility of an action is examined concerning the handed over partner pattern. By delivery of the action with the help of the parameter FIF_INITIAL_VALUE occupying an obligation partner with the value “0” can be achieved and/or ''(the values would be initially regarded otherwise as us thus if necessary to the deletion of a partner to lead). The parameter FIF_DIALOG must be occupied with “X”, if the call due to a dialogue action with the user effected (e.g. the user has a partner on a Dynpro changed). This is emergency whom thing, in order examinations, which are to be implemented only in the dialogue, steers to be able. With the help of the parameters FIF_NO_MESSAGES and/or FIF_LISTPROCESSING can suppressed the release from error messages and/or convert warnings, which would lead in the reporting to problems, into information. With the parameter FIF_CLEAR_APPL_LOG a deletion of the error log can be prevented. This parameter is set according to standard on “X”. By the parameter FIF_HARD_DELETION it can be achieved that a partner, regardless of the Partnerschematas, is deleted. This parameter should find only in rare cases use and then only if the consistency of the partner processing can be guaranteed in other way (adding e.g. following). The parameter FIF_PARTIAL_NEW_DETERMINATION accomplishes a new partner identification for the dependent partner roles after successful adding/change of a partner. This parameter is not at present APPROVED for use! The export parameter FEV_ACTION_DONE gives information over it, which action was accomplished (“D”, “I”, “U” or “E” for deletion, adding or changing a partner as well as “E” in the event of an error). This is the only parameter, which gives information reliably over the dürchgeführte action. The SYSTEM-SUBRC can be zero, although the desired action was not accomplished. The export parameter FRF_LOG_COUNT gives itself information over the number of error messages in the Application log (object “SDBFPD”, Subobjekt “ERROR”). With the parameter FIF_KNREF_PARNR a debtor lets itself be determined, out of whose business partner relations the KNREF of values (user designations) is to be taken. Example call function “SD_PARTNER_SINGLE_MODIFY” exporting fic_objecttype = “X” fic_objectkey = “Y” fis_sdorgdata = sdorgdata fif_pargr = ' TA' fif_parvw = ' WE' fif_posnr = ' 000000 ' fif_kunnr_old = “SEMMLER” fif_kunnr_new = “BROOK” importing fev_action_done = action_done exception parameter_incomplete = 1 object_not_found = 2 check_error = 3 others = 4. The example exchanges the consignee “SEMMLER” in the head of the voucher against the consignee “BROOK”. FU SD_SHIPMENT_STATUS_PLANNED ____________________________________________________ Summary Functions when setting the status “disposes” in the transportation head Functionality With call of this functional module happens exactly what happens in the transaction VT01 with pressures of the status Pushbuttons “disposed”. If the status is already set, this is again taken back. Time and date are put back. If the status is not yet set, then this is set. Date and time are filled with date and time (either from the defaults I_NEW_STATUS_DATE and I_NEW_STATUS_TIME, or -- if these are empty -- with SYSTEM-DATLO and SYSTEM-TIMLO) setting the status can take place also via indication of the date. If the status changed, then a USER EXIT is started. If the status changed of ''on “X”, then differently functions are accomplished: Data are copied from the supply (see Doku to the functional module SD_SHIPMENT_COPY_DELIVERY_DATA) Distance determination is accomplished (see Doku to the functional module SD_SHIPMENT_LEG_DETERMINATION) Parameter and tables: I_TVTK contains the customizing data of the mode of conveyance e.g. take over (route from supplies: yes or no?) C_XVTTK is the transportation head The following parameters and tables are important for the distance determination and to the functional module “SD_SHIPMENT_LEG_DETERMINATION” are passed on (Doku see there) I_DESTINATION I_DEPARTURE OPT_DIALOG I_DEPARTURE_SEQUENCE References Assortment of the transportation tables The tables of the treatment of transportation are sorted at each time according to the keys of the data base, in order to be able to access with “READ TABLE… BINARY SEARCH” in fast way. These tables contain entries for several transportation, thus stand the entries transport together. This concerns the following tables: XVTTK, YVTTK of transportation heads Sort: MANDT, TKNUM XVTTP, YVTTP transportation positions Sort: MANDT, TKNUM, TPNUM, VBELN XVTTS, YVTTS of transportation sections Sort: MANDT, TKNUM, TSNUM XVTSP, YVTSP allocations sect./position Sort: MANDT, TKNUM, TSNUM, TPNUM XVBPA, YVBPA partner Sort: MANDT, VBELN, POSNR, PARVW XVTFA, YVTFA document flow Sort: Data base key XVBADR, YVBADR addresses does not sort Contents of the transportation tables The table Xtttt contains here the current conditions after the change, the table Ytttt contains the old conditions, as it stood before the change on the data base. Contents of the characteristic UPDKZ indicate status of revision. In the INCLUDE RVDIREKT the constants for the characteristic are defined: updkz_old (1) VALUE ''- no change updkz_new (1) VALUE “I” - new entry updkz_update (1) VALUE “U” - changed entry updkz_delete (1) VALUE “D” - entry delete The table XVTTP contains both the entries of the supplies belonging to a transport (TKNUM, TPNUM are filled), and the entries for supplies, those to no transport belongs (TKNUM, TPNUM initially). Changes If you should to make or new entries to take up want changes, then you must ensure that the assortment remains. If you want to access the entries of a transport in one of the tables, then you should position first on the first entry and read by “LOOP” the appropriate cutout of the entries to this transport: READ table xvttp with keys mandt = system-mandt tknum = i_tknum binary search. if system-subrc = 0. loop RK xvttp from system-tabix. if xvttp tknum ne i_tknum. exit. endif. … final loop. endif. Resuming information This functional module uses -- like many other functional modules in the treatment of transportation also -- the functional modules to minutes. That is, in strategically important places how: Error messages and warnings Beginning or end of a certain function Progammstellen, which inform about the continuation of the function messages set off by means of the functional module SD_SHIPMENT_PROTOCOL_APPEND. These minutes entries are stored in the memory of the function group V56P and can be fetched if necessary over the functional module SD_SHIPMENT_PROTOCOL_GET and spent with SD_SHIPMENT_PROTOCOL_OUTPUT. A condition is that the logging was sd_shipment_protocol_start activated before with the functional module. The logging can be deactivated with SD_SHIPMENT_PROTOCOL_STOP again. The log file can be initialized with SD_SHIPMENT_PROTOCOL_REFRESH again.