mm

Lt. Hinweis 2398371 - Verwendung von Feldern auf Positionsebene (z.B. Werk) für die Nachrichtenfindung, ist es zwar grundsätzlich möglich, Felder aus der Bestellposition in die Zugriffsfolgen der Nachrichtenfindung einzufügen, jedoch werden diese nicht befüllt und sind somit zur Findung von Nachrichtenkonditionen unbrauchbar. 

Auszug aus HW 2398371:

Symptom

für die Nachrichtenfindung im MM-Einkaufsbereich möchten Sie Felder auf Positionsebene verwenden, z.B. Werk, Warengruppe usw. Sie fügen das entsprechende Feld zur Zugriffsfolge hinzu und pflegen dafür einen Konditionssatz, aber der Nachrichtensatz wird weiterhin nicht gefunden.

Ursache

Bei der Nachrichtenfindung wird nicht auf die Daten der einzelnen Positionen des Einkaufsbelegs (z.B. Tabelle EKPO oder EKET) zugegriffen, da die Werte in den positionsbezogenen Tabellenfeldern (z.B. EKPO-WERKS) von Position zu Position unterschiedlich sein können. Daher füllt das System das Feld auf Positionsebene (z.B. Werk usw.) nicht, so dass es den darauf basierenden Konditionssatz nicht finden kann.

Auflösung

In der SAP-Standardsoftware gibt es keine direkt unterstützte Lösung. 

Bei der Lösung handelt es sich um ein Beratungsthema. Die folgenden Informationen sollen Ihnen die Richtung geben, aber keine konkrete Beratungslösung bereitstellen und diese für Ihre eigene Verantwortung verwenden:

Folgen Sie z.B. einer ähnlichen Logik wie im SAP-Hinweis 39462 erwähnt und RVCOMFZZ FORM USEREXIT_KOMKBEA_FILL für benutzerdefiniertes ABAP-Coding, z.B. Speicherzuordnung ( '(SAPLMEPO)POT[]' ) oder ein direktes SQL-Lesen von EKPO-Daten aus der Datenbank.

Eine solche "Beraterlösung" soll im folgenden kurz vorgestellt werden. Folgendes Szenario sei gegeben:

Die Nachrichtenfindung soll in Abhängigkeit des Lieferwerkes erfolgen. Da dieses - wie richtig im o.g. Hinweis beschrieben - von Position zu Position unterschiedlich sein kann, soll es explizit aus der ersten Position der Bestellung gezogen werden.

Eine entsprechende Zugriffsfolge inkl. Nachrichten-Konditionstabelle sei bereits im Customizing angelegt worden und das Feld in der für die Bestellnachrichten relevanten Kommunikationsstruktur KOMKBEA heiße WERKS.

Das Customizing zur Nachrichtenfindung in der Bestellung findet sich im IMG unter Materialwirtschaft - Einkauf - Nachrichten - Ausgabesteuerung

Um nun das Feld WERKS in der Kommunikationsstruktur KOMKBEA im Rahmen der Nachrichtenfindung zu befüllen, muss es über einen Userexit versorgt werden. Hierzu sind gewisse Grundkenntnisse in der ABAP/4-Entwicklung vonnöten. Der entsprechende Userexit befindet sich im Programm RVCOMFZZ, Form USEREXIT_KOMKBEA_FILL.

Ein Mustercoding zur Bedienung der oben beschriebenen Anforderung könnte so aussehen:

*---------------------------------------------------------------------*
*       FORM USEREXIT_KOMKBEA_FILL                                    *
*---------------------------------------------------------------------*
*       This userexit can be used to move additional fields into the  *
*       communication table which is used for application EA          *
*---------------------------------------------------------------------*
FORM userexit_komkbea_fill.

* Werk aus der ersten Bestell-Position holen und in

* passendes Feld in Struktur KOMKBEA abfüllen

SELECT WERKS FROM EKPO INTO COM_KBEA-WERKS  "Feldname aus Zugriffsfolge

        WHERE EBELN = COM_EKKO-EBELN UP TO 1 ROWS

        ORDER BY EBELP ASCENDING.

ENDSELECT.

*  COM_KBEA-ZZFIELD1 = COM_EKKO-field.
ENDFORM.

Im Ergebnis wird das Feld WERKS im Zuge der Nachrichtenfindung befüllt und der Zugriff auf werksabhängige Nachrichtenkonditionen ist möglich.

Sind die Anforderungen an die WE/RE-Kontenfindung durch das Standardcustomizing (Vorgang ‚WRX’) nicht zu bedienen, kann eine sog. Kontomodifikation verwendet werden, die über die SAP-Erweiterung LMR1M002 (User Exit) bestelldatenabhängig gesetzt werden kann. Im Customizing werden dann die WE/RE-Konten in Abhängigkeit von der im Userexit versorgten Kontomodifikation in folgender Form gesetzt:

Kontomodifikation - WE/RE-Konto

IMG: Finanzwesen > Hauptbuch > Geschäftsvorfälle > Integration > Materialwirtschaft > Konten für Materialwirtschaft hinterlegen (Vorgang WRX)

Ein konkreter Anwendungsfall könnte z.B. sein, dass im Rahmen der buchungskreisübergreifenden Umlagerung (Szenario ‚Cross Company Nachschub') für die internen Wareneingänge und Rechnungen ein separates WE/RE-Konto gefunden werden soll:

Beispielcoding:

Funktionsbaustein EXIT_SAPLKONT_011, Include ZXM08U18

Symptom:

Beim Öffnen der Werthilfe (z.B. für Kreditoren in der FB60) hängt das System und erst Minuten später wird einem der Werthilfe-Dialog angezeigt.

Abhilfe schafft hier der Hinweis 2571623 - S/4HANA - F4 Search Help is very slow

In diesem wird als eine Möglichkeit zur Behebung des Problems aufgeführt, die Enterprise Search auf die Initialkonfiguration zurückzusetzen. Hierzu dient die Aufgabenliste SAP_ESH_RESET, die mithilfe der Transaktion STC01 ausgeführt werden kann. Allerdings ist die Transaktion nicht gerade ein Ausbund an Benutzerfreundlichkeit, zumindest habe ich einen Moment gebraucht, um mit dem Ding zurechtzukommen.

Zunächst muss über das Icon (1.) der Parameter "Zurücksetzen des Mandanten bestätigen" gesetzt werden. Anschließend wird der so geänderte Parameter in eine Variante gespeichert (2.) und zum Schluss die Ausführung der Aufgabenliste als Job eingeplant (3.). Eine Ausführung im Dialog schließt das System aus.

Der Job läuft nicht lange und danach ist die Performance der Werthilfe wieder wie gewohnt.

Nachfolgend ein Link von der Tricktresor-Seite, welcher zwei Reports vorstellt, die die Entwicklung des GLDs darstellen. Als MMler steht man oft vor der Frage, wie sich der GLD eines Materials bzw. Artikels im SAP Retail so (falsch) entwickeln konnte. Den "Übeltäter-Vorgang" zu entlarven ist nicht immer einfach - die beiden im Artikel genannten Reports können helfen, dem Spuk auf die Schliche zu kommen...

Bei bestellbezogener Rechnungsprüfung ist das Standardverhalten im Rahmen der logistischen Rechnungsprüfung im Dialog (Transaktionen MIRO bzw. MIR7) so, dass bei Eingabe der Bestellinformationen die Positionen zwar vorgeblendet werden, jedoch die Eingabefelder Menge und Wert leer bleiben. 

D.h. ohne weiteres Zutun müssten die Werte und Mengen aus der Rechnung manuell in die Felder der Tabelle eingetragen werden. Vielfach sind jedoch zwischen Rechnung und Bestellung nur wenig Abweichungen, so dass es wünschenswert wäre, die Daten aus der Bestellung wenigstens als Vorschlagswerte einzufüllen, um so die Rechnungserfassung zu erleichtern.

Über den Erweiterungsspot MRM_PROPOSAL_DETERMINE kann auf das Systemverhalten Einfluss genommen werden. 

Hierzu kann eine geeignete Implementierung zur Methode AMNT_QUANT_PROPOSAL_DETERMINE angelegt werden, die bspw. im Fall von bestellbezogener Rechnungsprüfung die Mengen und Werte aus den Bestellpositionen nachliest und als Vorschlagswerte ins Tableau einfüllt.

Beispielcoding:

METHOD if_ex_mrm_proposal_determine~amnt_quant_proposal_determine.

     DATA: l_amount   TYPE ekpo-netwr,
           l_quantity type ekpo-menge,
           l_webre    type ekpo-webre.

     SELECT SINGLE netwr menge webre FROM ekpo
            INTO (l_amount, l_quantity, l_webre)
            WHERE ebeln = i_drseg-ebeln
              AND ebelp = i_drseg-ebelp.
     CHECK sy-subrc = 0.
     CHECK l_webre IS INITIAL. "nur bei bestellbezogener RePrü !!!!

     e_propose_item-amount   = l_amount.
     e_propose_item-quantity = l_quantity.
     e_xchange = abap_true.

  ENDMETHOD.                    "IF_EX_MRM_PROPOSAL_DETERMINE~AMNT_QUANT_PROPOSAL_DETERMINE

Im Ergebnis werden im Rahmen der Rechnungserfassung die Informationen aus der Bestellposition als Vorschlagswerte eingefüllt. Dies erfolgt genau dann einmal, wenn die Bestellpositionen vom Anwender zugeordnet werden. Die Vorschlagswerte sind natürlich vom Rechnungsprüfer überschreibbar. Das BadI wird nur dann erneut durchlaufen, wenn eine neue Bestellzuordnung getroffen wurde.

In der Bewertungspraxis des Handels wird zur Jahresendbewertung häufig das Verfahren der ‚verlustfreien Bewertung’ angewendet. Dabei wird dem Bewertungspreis eines Artikels (z.B. dem gleitenden Durchschnittspreis) zum Bewertungsstichtag ein sog. Vergleichswert gegenüber gestellt, dem üblicherweise ein realer oder fiktiver Verkaufspreis zugrunde liegt. Dabei werden in vielen Fällen vom Verkaufspreis noch im Rahmen der Warenveräußerung anfallende Kostenbestandteile abgezogen. Der hieraus resultierende Wertansatz wird als beizulegender Wert bezeichnet.

Das hier skizzierte Verfahren findet insbesondere in solchen Branchen Anwendung, bei denen im Verlauf des Betrachtungszeitraums erhebliche Preisreduktionen der angebotenen Artikel, z.B. im Rahmen von Ausverkäufen stattfinden (Saisonware, Mode, Möbel). Die Grundannahme bzw. -idee ist hierbei, dass in bestimmten Fällen der Verkaufspreis eines Artikels während seines Lebenszyklus so weit reduziert wird/werden muss, dass beim Verkauf die Selbstkosten nicht mehr gedeckt werden. Dies bedeutete, dass beim jedem Verkauf eines solchen Artikels ein Verlust entstünde, der durch die vorzunehmende Abwertung jedoch ‚antizipiert‘ wird und die Bewertung somit auch bei derartigen Preisnachlässen ‚verlustfrei‘ bleibt.

Zur Ermittlung des Vergleichswerts gibt es in SAP kein Standardverfahren, die gewünschte Logik muss komplett als Eigenentwicklung implementiert werden. Hierzu stellt SAP die Erweiterung NIWE0003 (Funktionsexit EXIT_SAPLNIW3_001) zur Verfügung. In neueren Releases ist die vorgenannte Erweiterung auslieferungsseitig bereits in die BAdI-Definition SMOD_NIWE0003 migriert worden.

Maßgeblich für sinnvolle Anwendbarkeit dieses Verfahrens ist demnach die Ermittlung des Vergleichspreises, also des beizulegenden Wertes. Ausgangsbasis ist dabei der voraussichtliche Verkaufserlös, d.h., bezogen auf einen Artikel, der zum Bewertungsstichtag anzusetzende Verkaufspreis. Oft liegt dieser bereits als Verkaufspreiskondition vor, wenn die Preisreduzierungen in Form von Aktionen oder geplant (Stichwort ‚Preisplanung‘) stattfinden. In diesen Fällen könnte der Verkaufspreis mithilfe der im System abgelegten Konditionen (z.B. mit Funktionsbaustein SALES_PRICE_READ) ermittelt werden. Im Sinne des sog. Wertaufhellungsprinzips kann dabei das Preisdatum entscheidend sein. Wenn bspw. der Bewertungsstichtag der 31.12. ist, jedoch der Bewertungslauf im Rahmen der Abschlusserstellung erst Anfang Februar erfolgt, könnte der Verkaufspreis Im Januar nochmals angepasst worden sein. Es empfiehlt sich daher, immer den aktuell gültigen Konditionssatz heranzuziehen.

Bei der Bewertung nach den Verhältnissen vom Absatzmarkt wird der mit den Anschaffungs- oder Herstellungskosten der fertigen und unfertigen Erzeugnisse und der Waren zu vergleichende Wert retrograd ermittelt. Hierbei wird also vom späteren Erlös ausgegangen. Deshalb wird diese Bewertungsmethode als retrograde Bewertung bezeichnet

Es wird von folgendem Schema ausgegangen:

Retrograde Bewertung

voraussichtlicher Verkaufserlös

./.

Erlösschmälerungen

./.

Verpackungskosten und Ausgangsfrachten

./.

allgemeine Vertriebskosten

./.

Verwaltungskosten

./.

Kapitaldienstkosten (für Lagerung bis zum Verkauf)

=

am Abschlussstichtag beizulegender Wert

Hierbei werden die für den Verkauf bestimmten Vorräte so bewertet, dass nach dem Abschlussstichtag kein Verlust mehr entsteht. Ein beim Verkauf voraussichtlich entstehender Verlust wird durch die Bewertung zum Abschlussstichtag in die Periode vorgezogen.

Nach der Rechtsprechung des BFH ist der Wert anzusetzen, der von dem voraussichtlich erzielbaren Veräußerungserlös nach Abzug des nach dem Bilanzstichtag noch anfallenden betrieblichen Aufwands und des durchschnittlichen Unternehmergewinns verbleibt.

Verkaufserlös:
Der voraussichtlich nach dem Bilanzstichtag zu erzielende Erlös. Dabei dürfen auch konkret zu erwartende Preissteigerungen berücksichtigt werden.

Erlösschmälerungen:
Preisnachlässe wie z.B. Skonti und Mengenrabatte.

Allgemeine Vertriebskosten:
Provisionen und Lizenzgebühren, die beim Verkauf entstehen. Vertriebsgemeinkosten, spätere Montage- und Aufstellungskosten, Garantierisiken.

Verwaltungskosten:
Kosten der Lagerhaltung und -verwaltung, Abrechnungskosten sowie Kosten für Zahlungseingang. Auch Zinsverluste in Form von Fremdkapitalkosten wegen voraussichtlich längerer Lagerung der Bestände sind einzubeziehen.

Allgemein:
Die zukünftigen Kosten sind nach der Vollkostenmethode bei Normalbeschäftigung zu ermitteln, also Einzelkosten und anteilige Gemeinkosten.

Der jeweils niedrigere Ansatz wird im Sinne des Niederstwertprinzips als Bewertungspreis herangezogen.

Das nachfolgende Coding stellt einen Beispielaufruf für das o.g. BAPI dar: 

REPORT ytestbapi.
* test / sample report for BAPI_GOODSMVT_CREATE
* S.ROHDE WNRC 12/2011
 

PARAMETERS: pa_test AS CHECKBOX DEFAULT 'X'.

DATA: gs_goodsmvt_header TYPE bapi2017_gm_head_01.
DATA: git_return         TYPE TABLE OF bapiret2.
DATA: git_items          TYPE TABLE OF bapi2017_gm_item_create.
DATA: gs_item            LIKE LINE OF git_items.
DATA: g_materialdocument TYPE bapi2017_gm_head_ret-mat_doc.
DATA: g_matdocumentyear  TYPE bapi2017_gm_head_ret-doc_year.
DATA: g_goodsmvt_code    TYPE bapi2017_gm_code VALUE '06'.  "MB11

* All supported transactions can be found in table T158G

* header
CLEAR: gs_goodsmvt_header.

gs_goodsmvt_header-pstng_date  = sy-datum.    "Posting date
gs_goodsmvt_header-doc_date    = sy-datum.    "Document date
gs_goodsmvt_header-ref_doc_no  = '4711'.      "Reference No
gs_goodsmvt_header-pr_uname    = sy-uname.    "User name
gs_goodsmvt_header-header_txt  = 'Test BAPI'. "Header text

* item(s)
CLEAR git_items[].
CLEAR gs_item.

* caution: give article/mat. no. with leading zeroes!!!
gs_item-material = '000000000000002002'.      "Art./Mat.No
gs_item-plant = 'C302'.                       "plant/site
gs_item-stge_loc = '0001'.                    "Storage loc.
gs_item-move_type = 'Z01'.                    "Movement type (BwA)
gs_item-entry_qnt = 5.                        "Quantity
gs_item-entry_uom = 'ST'.                     "Unit
APPEND gs_item TO git_items.

* call bapi
CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
  EXPORTING
    goodsmvt_header  = gs_goodsmvt_header
    goodsmvt_code    = g_goodsmvt_code
    testrun          = pa_test
  IMPORTING
    materialdocument = g_materialdocument
    matdocumentyear  = g_matdocumentyear
  TABLES
    goodsmvt_item    = git_items
    return           = git_return.

* commit work.
IF pa_test IS INITIAL.
  COMMIT WORK.
  WRITE: / 'Document posted:',
           g_materialdocument,
           '/',
           g_matdocumentyear,
           '    Returncode:',
           sy-subrc.
ENDIF.

* display messages from bapi, if necessary
IF NOT git_return[] IS INITIAL.
  CALL FUNCTION 'C14ALD_BAPIRET2_SHOW'
    TABLES
      i_bapiret2_tab = git_return.
ELSE.
  MESSAGE s600(fr) WITH 'no messages occured'
                        'while BAPI processed'.
ENDIF.

Steuerfindung in der Bestellung

Der Bestellung selbst liegt kein steuerpflichtiger Vorgang im Sinne des UStG zugrunde, jedoch fußen etliche Folgebelege auf ihr, die durchaus steuerliche Relevanz haben, z.B. die Rechnungsbelege aus der logistischen Rechnungsprüfung / ERS-Abrechnung, nachträgliche Vergütung usw. Die erwähnten Folgebelege gründen ihrerseits den Steuerausweis auf dem zuvor in der Bestellung ermittelten Steuerkennzeichen. Im SAP-Standard (Einkaufskalkulationsschema RM0000) ist keine Steuerkonditionsart vorhanden, abgesehen von NAVS (‚nicht abzugsfähige Vorsteuer’), die ja eben durch ihre Eigenschaft der ‚Nichtabzugsfähigkeit’ den Einstandspreis einer Ware tatsächlich erhöht. Details zur Steuerfindung in Bestellbelegen finden sich im Beratungshinweis 501054. Unter Pkt 1. im genannten Hinweis finden sich alle Möglichkeiten, das Steuerkennzeichen innerhalb der Bestellung zu ermitteln. U.a. lässt es sich mithilfe von Konditionssätzen automatisiert bestimmen. Hierzu werden geeignete Konditionssätze zur Konditionsart NAVS hinterlegt.

Der Konditionsart NAVS ist im Auslieferungszustand die Zugriffsfolge 0003 zugeordnet:

IMG: Materialwirtschaft > Einkauf > Konditionen > Preisfindung festlegen > Konditionsarten festlegen

Die Zugriffsfolge 0003 sieht im SAP-Standard folgende Zugriffe vor:

IMG: Materialwirtschaft > Einkauf > Konditionen > Preisfindung festlegen > Zugriffsfolgen festlegen

In aller Regel lassen sich sämtliche steuerfindungsrelevanten Konstellationen mithilfe der Tabelle 86 (s.o.) darstellen. Diese beinhaltet folgende Merkmale:

Steuerrelevante Indikatoren für Bestellung

Die Zuordnung eines Artikels zum entsprechenden Steuerindikator wird in der Tabelle MLAN gespeichert. Diese Tabelle hat neben der Artikelnummer lediglich das Lieferland als Schlüssel, wird aber im Rahmen der Artikelstammpflege (Transaktion MM42) bei den werksabhängigen Daten hinterlegt. Zur vollständigen Pflege in den relevanten Ländern genügt es somit, den Steuerindikator in einer Filiale eines Landes einzutragen.

Die Werte zur Konditionsart NAVS werden in der Anwendung mithilfe der Transaktionen MEK1 bzw. MEK2 hinterlegt.

Beispiel:

Beispieleinträge zur Kondition NAVS

Hinweise: Da mit jeder gesetzlichen Änderung des Steuersatzes neue Steuerschlüssel angelegt werden müssen, sind die aktuell gültigen Steuerkennzeichen ggf. bei der entsprechenden Fachabteilung zu erfragen. Nicht in jedem Land gibt es die Unterscheidung zwischen ermäßigtem und vollem Steuersatz (z.B. Belgien).

Bei den Debitoren- und Kreditorenstammdaten existieren die Zahlungsbedingungen sowohl in der FI-Sicht als auch in der jeweiligen Einkaufs- bzw. Vertriebssicht. Bei der Stammdatenanlage ist also ggf. darauf zu achten, dass die Zahlungsbedingungen gleichlautend eingegeben werden. Der nachfolgende, kleine Prüfreport listet Abweichungen auf und vereinfacht somit die Fehlersuche und ggf. Nachbearbeitung der Stammsätze

*&---------------------------------------------------------------------*
*& Report  YYZTERM01
*&
*&---------------------------------------------------------------------*
*& Der Report prüft die Zahlungsbedingungen im FI gegen die
*& Zahlungsbedingungen im SD bzw. MM
*&---------------------------------------------------------------------*

REPORT  yyzterm01.

TABLES: knb1, lfb1, lfm1, knvv.
SELECT-OPTIONS: so_bukrs FOR knb1-bukrs OBLIGATORY.
SELECTION-SCREEN SKIP.
PARAMETERS: p_mm RADIOBUTTON GROUP r1 DEFAULT 'X'.
SELECT-OPTIONS: so_lifnr FOR lfb1-lifnr,
                so_ekorg FOR lfm1-ekorg.
SELECTION-SCREEN SKIP.
PARAMETERS: p_sd RADIOBUTTON GROUP r1.
SELECT-OPTIONS: so_kunnr FOR knb1-kunnr,
                so_vkorg FOR knvv-vkorg,
                so_vtweg FOR knvv-vtweg,
                so_spart FOR knvv-spart.

START-OF-SELECTION.
  IF p_mm = 'X'.
    PERFORM zterm_mm.
  ELSE.
    PERFORM zterm_sd.
  ENDIF.

*&---------------------------------------------------------------------*
*&      Form  ZTERM_MM
*&---------------------------------------------------------------------*
*       Ableich Zahlungsbed. FI/MM
*----------------------------------------------------------------------*
FORM zterm_mm .
  SELECT * FROM lfb1 WHERE lifnr IN so_lifnr
                       AND bukrs IN so_bukrs.
    SELECT * FROM lfm1 WHERE lifnr = lfb1-lifnr
                         AND ekorg IN so_ekorg.
      IF lfm1-zterm NE lfb1-zterm.
        WRITE: / 'Lief.', lfb1-lifnr,
                 'Bukrs', lfb1-bukrs,
                 'Z-Bed FI', lfb1-zterm,
                 'EK-Org', lfm1-ekorg,
                 'Z-Bed MM', lfm1-zterm.
      ENDIF.
    ENDSELECT.
  ENDSELECT.

ENDFORM.                    " ZTERM_MM

*&---------------------------------------------------------------------*
*&      Form  ZTERM_SD
*&---------------------------------------------------------------------*
*       Ableich Zahlungsbed. FI/SD
*----------------------------------------------------------------------*

FORM zterm_sd .
  SELECT * FROM knb1 WHERE kunnr IN so_kunnr
                       AND bukrs IN so_bukrs.
    SELECT * FROM knvv WHERE kunnr = knb1-kunnr
                         AND vkorg IN so_vkorg
                         AND vtweg IN so_vtweg
                         AND spart IN so_spart.
      IF knvv-zterm NE knb1-zterm.
        WRITE: / 'Kunde', knb1-kunnr,
                 'Bukrs', knb1-bukrs,
                 'Z-Bed FI', knb1-zterm,
                 'Vetr.bereich', knvv-vkorg, knvv-vtweg, knvv-spart,
                 'Z-Bed SD', knvv-zterm.
      ENDIF.
    ENDSELECT.
  ENDSELECT.
ENDFORM.                    " ZTERM_SD