Overblog Folge diesem Blog
Administration Create my blog
SAPManDoo - SAP Resource

Posts mit #mm tag

Bestelldatenvorschlag bei bestellbezogener Rechnungsprüfung

17. Juli 2017 , Geschrieben von sapmandoo Veröffentlicht in #MM

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. 

MIRO - bestellbezogene Rechnungsprüfung im Standard

MIRO - bestellbezogene Rechnungsprüfung im Standard

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.

     DATAl_amount   TYPE ekpo-netwr,
           l_quantity type ekpo-menge,
           l_webre    type ekpo-webre.

     SELECT SINGLE netwr menge webre FROM ekpo
            INTO (l_amountl_quantityl_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

MIRO bestellbezogene Rechnungsprüfung mit obenstehender Implementierung

MIRO bestellbezogene Rechnungsprüfung mit obenstehender Implementierung

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.

Weiterlesen

Verlustfreie Bewertung (under construction...)

10. Februar 2015 , Geschrieben von sapmandoo Veröffentlicht in #MM

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.

Weiterlesen

BAPI-Aufruf BAPI_GOODSMVT_CREATE

13. Dezember 2011 , Geschrieben von sapmandoo Veröffentlicht in #MM

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.

Weiterlesen

Steuerfindung in MM-Belegen

23. März 2011 , Geschrieben von sapmandoo Veröffentlicht in #MM

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.

 

Customizing

Der Konditionsart NAVS ist im Auslieferungszustand die Zugriffsfolge 0003 zugeordnet:

 

Konditionsart NAVS Nicht abz. Vorsteuer  Zugriffsfolge 0003 Steuerkennzeichen

 

 

Kond.Klasse   D Steuern                                Vorzeichen      positiv und negativ

Rechenregel   B Fester Betrag

Konditionstyp N Vorsteuer nicht abzugsfähig

Rundungsregel   Kaufmännisch

Strukturkond.

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

 

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

 

LfdNr.

Tab.

Bezeichnung

Bedingung

Exklusiv

10

88

Steuern: Artikel, Betrieb, Kontierung, Herkunft und Region

 

X

20

94

Steuern: Artikel, Betrieb, Herkunft und Region

 

X

30

87

Steuern: Betrieb, Kontierung, Herkunft und Region

 

X

40

86

Steuern: Artikel, Betrieb und Herkunft

 

X

50

80

Steuern: Artikel

 

X

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:

 

Feld

Bezeichnung

Erläuterung / Werte

Customizing

LAND1

Empfangsland

Leitet sich aus bestellendem Betrieb ab (s. Tab. T005)

./.

TAXIM

Steuerind. Artikel

0 = steuerfreier Artikel (z.B. Telefonkarten, Briefmarken)

1 = volle Steuer

2 = halbe Steuer (z.B. Bücher, neuerdings auch Hotelübernachtungen J)

Materialwirtschaft à Einkauf à Steuern à Steuerindikator für Artikel einstellen

 

Siehe nachf. Kap.

TAXIW

Steuerind. Betrieb

0 = steuerbefreit

1 = steuerpflichtig

Materialwirtschaft à Einkauf à Steuern à Steuerindikator für Betrieb einstellen / …Steuerindikatoren für Betriebe zuordnen

TAXIL

Steuerind. Import

Der Wert wird vom System in der Bestellung anhand der Korrelation ‚Empfangsland / Lieferland (Land des Lieferanten)’ gesetzt:

0 = kein Import -> Empfangsland = Lieferland

1 = Import -> Lieferland ungleich Empfängerland und mindestens eines der beiden beteiligten Länder ist kein EU-Land[1]

2 = EU-Import -> Lieferland ungleich Empfängerland, wobei beide beteiligten Länder der EU angehören.

./.

Steuerrelevante Indikatoren für Bestellung

 

Zuordnung Artikel -> Steuerindikator

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.

 

Konditionspflege

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

 

Beispiel:

 

Empfangs-land

St.-Ind. Artikel

St. Ind. Btrb.

St.ind. Import

Steuer-Kz.

Bezeichnung

DE

0

1

0

V0

Vorsteuer Inland (keine Steuer)

DE

0

1

1

V9

Vorsteuer 0% Drittland

DE

0

1

2

V0

Vorsteuer Inland (keine Steuer)

DE

1

1

0

V1

Vorsteuer Inland (volle Steuer)

DE

1

1

1

V9

Vorsteuer 0% Drittland

DE

1

1

2

E1

Erwerbssteuer EG-Warenlieferung (voller Steuersatz)

DE

2

1

0

V2

Vorsteuer Inland (halbe Steuer)

DE

2

1

1

V9

Vorsteuer 0% Drittland

DE

2

1

2

E2

Erwerbssteuer EG-Warenlieferung (halber Steuersatz)

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).



[1] Die Kennzeichnung, ob ein Land zur EU gehört, findet sich in der Ländertabelle T005, Feld XEGLD

Weiterlesen

Abgleich Zahlungsbedingungen FI - MM/SD

21. Februar 2011 , Geschrieben von sapmandoo Veröffentlicht in #MM

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

 

Weiterlesen