SD Vertrieb

Transcription

SD Vertrieb
SD Vertrieb
SAP R/3 Enterprise
Release 4.70
Release-Informationen
© Copyright 2002 SAP AG. Alle Rechte vorbehalten.
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form
auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation
enthaltene Informationen können ohne vorherige Ankündigung geändert werden.
Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können Software-Komponenten auch anderer
Software-Hersteller enthalten.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® und SQL Server® sind eingetragene Marken der
Microsoft Corporation.
IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390® und
OS/400® sind eingetragene Marken der IBM Corporation.
ORACLE® ist eine eingetragene Marke der ORACLE Corporation.
INFORMIX®-OnLine for SAP und Informix® Dynamic Server
Incorporated.
TM
sind eingetragene Marken der Informix Software
UNIX®, X/Open®, OSF/1® und Motif® sind eingetragene Marken der Open Group.
Citrix®, das Citrix-Logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® und andere
hier erwähnte Namen von Citrix-Produkten sind Marken von Citrix Systems, Inc.
HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C®, World Wide Web Consortium,
Massachusetts Institute of Technology.
JAVA® ist eine eingetragene Marke der Sun Microsystems, Inc.
JAVASCRIPT® ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape
entwickelten und implementierten Technologie.
SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI,
SAPPHIRE, Management Cockpit, mySAP.com Logo und mySAP.com sind Marken oder eingetragene Marken der SAP AG
in Deutschland und vielen anderen Ländern weltweit. Alle anderen Produkte sind Marken oder eingetragene Marken der
jeweiligen Firmen.
Design: SAP Communications Media
SAP-System
Inhaltsverzeichnis
SAP AG
______________________________________________________________
12
12.1
12.2
12.3
12.4
12.5
12.6
12.6.1
12.6.1.1
12.6.1.2
12.7
12.7.1
12.7.1.1
12.7.2
12.7.2.1
12.8
12.8.1
12.8.2
12.8.2.1
12.8.2.2
12.9
12.9.1
12.9.1.1
12.9.1.1.1
12.9.1.1.2
12.9.1.1.3
12.9.1.1.4
SD Vertrieb
Country Version India in Standard R/3
System
Condition-Based Tax Calculation (New)
Changes to Structures for Country
Version India
Exports Under Excise Regulations (New)
Release Notes from Country Version India
Add-On (SD)
SD-MD Stammdaten
SD-MD-CM Konditionen
Löschen von Bonuskäufen
Neue Änderungszeiger für Konditionssätze
(WIND)
SD-BF Grundfunktionen
SD-BF-PR Konditionen und
Preisfindung
Condition-Based Excise Determination in
SD (New)
SD-BF-TX Steuern
Condition-Based Excise Determination in
SD (New)
SD-SLS Verkauf
Auswertung offener Verkaufsbelege nach
US-GAAP Richtlinie SFAS 133
SD-SLS-SO Kundenauftrag
Aus Kundenauftrag erzeugte
Bestellanforderungen im Haushaltsmanagemen
SD-Auftrag-Fortschreibung im
Haushaltsmanagement (HHM)
SD-BIL Fakturierung
SD-BIL-IV
Fakturabearbeitung
SD-BIL-IV-SM Aufwandsbezogene
Fakturierung
Aufwandsbezogene Faktura für
erlösführende Innenaufträge (neu)
Archivierung der CO-Einzelposten
(erweitert)
Belegflussauswertungen der
aufwandsbezogenen Faktura (neu)
DP-Prozessor (erweitert)
1
3
4
6
8
8
9
10
10
10
11
11
11
12
12
______________________________________________________________
SAP AG
iii
SAP-System
Inhaltsverzeichnis
SAP AG
______________________________________________________________
12.9.1.1.5
12.9.1.1.6
12.9.1.1.7
12.10
12.10.1
12.10.2
12.11
12.11.1
12.11.1.1
12.11.1.2
Fakturaanforderung für
Kundenauftragspositionen (erweitert)
Sammelverarbeitung aufwandsbezogene
Faktura (erweitert)
Statische Abwicklung aufwandsbezogene
Faktura (gelöscht)
SD-EDI Electronic Data
Interchange
BAdIs im Preiskatalog
Unterstützung von Staffeln im
Preiskatalog
SD-POS POS-Interface
SD-POS-OUT
POS-Interface-Ausgang
Neue Änderungszeiger für Konditionssätze
(WIND)
Neue Funktionen beim
POS-Interface-Ausgang
13
14
14
14
17
18
18
20
______________________________________________________________
SAP AG
iv
SAP-System
______________________________________________________________
12 SD
Vertrieb
12.1 Country Version India in Standard R/3 System
Verwendung
As of SAP R/3 Enterprise Core 4.70 (SAP_APPL 470), Country Version India is no longer delivered as
an add-on but as part of the standard R/3 System.
Integration of functions in the SAP Easy Access menu
The functions for withholding tax have been integrated into the SAP Easy Access menu, under
Accounting -> Financial Accounting -> Accounts Payable -> Withholding Tax -> India and
Accounting -> Financial Accounting -> Accounts Receivable -> Withholding Tax -> India.
You can access all other functions using the area menu J1ILN, which you can call from the SAP Easy
Access screen using the transaction code J1ILN.
Country Version India Implementation Guide
The Country Version India Implementation Guide (IMG) has been integrated into the standard Reference
IMG (see Changes to Structures for Country Version India).
Release Notes
You can access release notes from previous add-on releases using the links below.
SAP Library Documentation
The SAP Library documentation for Country Version India is also delivered on the standard SAP Library
documentation CD (see below).
New and Changed Functions
For information about new and changed functions for Country Version India, see the other release notes
for this release.
Auswirkungen auf den Datenbestand
You do not need to change any data.
Auswirkungen auf das Customizing
IMG activity
What to do
Activate Country Version India for Specific Fiscal Years Delete the entry ZIND and create a new
entry for IND.
Siehe auch
SAP Library -> Financials or Logistics -> Country Versions -> Asia-Pacific -> India.
Release Notes from Country Version India Add-On (FI)
Release Notes from Country Version India Add-On (SD)
Release Notes from Country Version India Add-On (MM)
______________________________________________________________
SAP AG
1
SAP-System
______________________________________________________________
12.2 Condition-Based Tax Calculation (New)
Verwendung
As of SAP R/3 Enterprise Core 4.70 (SAP_APPL 470), a new method for calculating taxes in Brazil
is available, which makes use of the standard condition technique. Tax rates, tax laws, and special
indicators that influence whether tax line items are included in the nota fiscal are all stored in the system
as condition records. An additional tax calculation procedure, TAXBRC, is delivered for this new
method, in addition to the existing one for Brazil, TAXBRJ.
Auswirkungen auf den Datenbestand
You can continue to calculate taxes using the former method: when the system processes the tax
procedure assigned to the country (TAXBRJ), it calculates the taxes externally by calling function
module J_1BCALCULATE_TAXES. We do, however, recommend that you assign the new procedure
TAXBRC and use the condition-based tax calculation functions, as it enables you to flexibly adapt the tax
calculation logic to cover new legal requirements or special customer needs.
You will need to migrate your existing tax rate table entries to condition records, which you can do
directly from the Tax Manager's Workplace described below. You can check all tables and subsequently
convert the entries, whereby the system generates condition records. After the initial migration, each time
you create or change a tax rate table entry, the system automatically generates a condition record as
needed.
Auswirkungen auf das Customizing
If you want to employ the new condition-based tax calculation, you need to activate it and carry out all
related Customizing activities, under Financial Accounting -> Financial Accounting Global Settings
-> Tax on Sales/Purchases -> Basic Settings -> Brazil -> Condition-Based Tax Calculation, all of
which are new:
o
Activate Condition-Based Tax Calculation
o
Map MM Tax Values to Nota Fiscal Fields
o
Map SD Tax Values to Nota Fiscal Fields
o
Map MM Tax Laws to Nota Fiscal Fields
o
Define Internal Codes for Tax Conditions
o
Assign Internal Codes for Tax Conditions to Condtion Types
o
Assign Tax Rate Tables to Condition Tables
In addition, you need to assign the new tax calculation procedure TAXBRC to the country in
Customizing, under Financial Accounting -> Financial Accounting Global Settings -> Tax on
Sales/Purchases -> Basic Settings -> Assign Country to Calculation Procedure.
A new Customizing tool called the Tax Manager's Workplace is available that enables you to make all
tax-related settings for Brazil. You access it under the same path as above through Tax on
Sales/Purchases, then Calculation -> Settings for Tax Calculation in Brazil -> Access Tax
Manager's Workplace , or alternatively by entering transaction J1BTAX. You can use the Tax Manager's
______________________________________________________________
SAP AG
2
SAP-System
______________________________________________________________
Workplace regardless if you use condition-based tax calculation; it simply brings all tax activities to a
single transaction (only the Migration, Nota-Fiscal Mapping, and Condition Mapping options under the
Condition Setup pulldown menu are relevant only for condition-based tax calculation).
12.3 Changes to Structures for Country Version India
Verwendung
As of SAP R/3 4.7, Country Version India is no longer delivered as an add-on, but forms part of the
standard system.
SAP has discontinued the Country Version India Implementation Guide (IMG) and has added its
activities have been added to the standard Reference IMG as follows:
Activities relating to withholding tax are now located in Customizing for Financial Accounting (FI),
under Financial Accounting Global Settings -> Withholding Tax.
Activities relating to excise duty and excise invoices are in Customizing for Logistics - General, under
Tax on Goods Movements -> India.
As far as the activities under Preparatory Activities are concerned, two of them (Activate Country
Version India for Accounting Interface and Activate Processes) are no longer relevant and have been
removed from the IMG entirely. The activity Execute Country Installation Program is already included in
the standard IMG under the name Localize Sample Organizational Units. And the other two activities
(Activate Country Version India for Specific Fiscal Years and Activate Business Transaction Events)
have been added to the standard IMG.
For information about other changes to the IMG relating to changes in the functions in Country Version
India, see the other release notes.
12.4 Exports Under Excise Regulations (New)
Verwendung
As of SAP R/3 Enterprise Core 4.70 (SAP_APPL 470), Country Version India allows you to process
exports and deemed exports under excise regulations. New functions for exports have been added as
follows:
o
You can create, change, display, and cancel excise bonds. When the bond is no longer of use, you
can also close it.
o
There are various transactions for creating and processing ARE-1s.
o
Reports include two statutory reports, the Running Bond Report and the Export Report.
o
To track bonds we have provided a Bond Summary Report. Another transaction, the ARE
Document Ageing Analysis, allows you to track ARE documents according to their current status.
The following new functions are also offered for deemed exports:
______________________________________________________________
SAP AG
3
SAP-System
______________________________________________________________
o
You can capture, change, display, cancel, and close licenses.
o
There are various transactions for creating and processing ARE-3s.
o
To track licenses, you can use the License Summary Report; and to track ARE-3s, use the ARE
Document Aging Analysis.
Finally, SAP has also provided a new role containing all excise bonding activities, Bonding Clerk
(technical name: SAP_CIN_BONDING_CLERK).
Auswirkungen auf das Customizing
To set up the solution, carry out the following IMG activities:
IMG activity
What to do
Make Settings for ARE-1 Procedure
Make the basic settings for processing exports.
Make Settings for ARE-3 Procedure
Make the basic settings for processing deemed
exports.
Maintain License Types
Maintain the various license types for when you come
to enter your customers' deemed export licenses.
Maintain Output Type
Check the output type supplied with the SAP System.
Specify Printers
Specify which printers to print out the ARE
documents on.
Maintain Postal Addresses
Enter the addresses of your local excise departments,
to be printed on the AREs.
Maintain Excise Groups
Enter each excise group's local excise department.
Maintain Series Groups
Enter a default customs department for each series
group.
Maintain Number Ranges
Maintain number ranges for bonds (number range
J_1IBOND), ARE-1s (J_1IARE1), licenses (J_1ILIC), and ARE-3s (J_1IARE3).
Siehe auch
SAP Library -> Logistics -> Country Versions -> Asia-Pacific -> India -> Sales and Distribution
(SD) -> Exports Under Excise Regulations.
12.5 Release Notes from Country Version India Add-On (SD)
Verwendung
The Release Notes from Releases 3.0A and 4.0A of Country Version India for Sales and Distribution
(SD) are listed below. For Release Notes from earlier releases, see the alias globalization in SAPNet,
and choose Media Center -> Country-Specific Documentation -> Country Version India - Release Notes.
Release 3.0A
o
Printing of Excise Invoice for Other Movements
Release 4.0A
______________________________________________________________
SAP AG
4
SAP-System
______________________________________________________________
o
CENVAT Payment Can Be Done Immediately at the Time of Removal
o
Item Level Accounting Postings for Excise Invoices
o
Performance Improvements
o
Authorization for Excise Invoice Creation
o
Excise Invoices Can Be Created Based on Intercompany Billing Documents
o
Posting of CENVAT to Profitability Segments
o
Business Area Postings of Fortnightly Payments
o
Text Entry During Fortnightly Payments
o
Printing of Annexure of Excise Invoices
o
Enhancements to Automatic Creation of Excise Invoices
o
Default of Purchase Order Details to Depot Receipts
o
Entry of Cess During Capture of Excise Invoices in Depots
o
CVD Indicators Can Be Maintained for Depot Receipt
o
Suppplementary Excise Invoices at Depots
o
Supplementary Excise Invoice Selection During Depot Selection
o
Depot Stock Display
12.6 SD-MD
Stammdaten
12.6.1 SD-MD-CM
Konditionen
12.6.1.1 Löschen von Bonuskäufen
Verwendung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) können Sie bereits angelegte Bonuskäufe
wieder aus dem System löschen.
Einmal angelegte Bonuskäufe sind zwar durch ihre Gültigkeitsdauer begrenzt, bleiben aber im System
vorhanden. Sie können Bonuskäufe jetzt nach bestimmten Kriterien selektieren und löschen.
1.
Das System zeigt Ihnen zunächst die vorhandenen Bonuskäufe anhand bestimmter Kriterien an.
Die Auswahl kann z.B. über eine Aktion, die diese Bonuskäufe verwendet, eine Rabattart, einen
Bonuskauftyp, eine Boniskaufart oder die Art des Konditionsziels erfolgen. Außerdem können Sie
über die Gültigkeitsdauer einschränken.
2.
Sie können auswählen, welche Bonuskäufe Sie löschen wollen.
Die Anzeige erfolgt als Baum, den Sie nach verschiednen Kriterien (z.B. nach Anleger, Rabattart,
Aktion und Bonuskauf) sortieren können.
______________________________________________________________
SAP AG
5
SAP-System
______________________________________________________________
3.
Das System gibt den Löschwunsch an die angeschlossenen Kassensysteme weiter.
Das System löscht die Bonuskauf-Einträge in allen relevanten Tabellen (KONBBYH,
KONBBYPRQ, KONBBYT, KONDN, KONDNS, KOTN*, STXH und STXL).
Sie können Bonuskäufe auch aus der Aktionspflege heraus löschen. Dabei belegt das System die
Bonuskaufnummern und die jeweilige Aktionsnummer im Selektionsbild des Löschprogramms vor.
Wenn Sie in der Aktion Bonuskäufe zum Löschen auswählen, prozessiert das System das Selektionsbild
des Löschprogramms dunkel, ansonsten durchläuft es das Selektionsbild hell.
Die Aktionspflege aktualisiert die entsprechenden Bildschirmdarstellungen selbständig.
Auswirkungen auf den Datenbestand
Das System protokolliert, welche Bonuskäufe bisher an welche Filialen verteilt wurden. Beim Löschen
eines Bonuskaufs wird das Löschkennzeichen für alle zugehörigen Einträge gesetzt. Mit Hilfe der
markierten Einträge können dann entsprechende Löschinformationen zielgerichtet an alle betroffenen
Filialen versendet werden.
Die Archivierung von Bonuskäufen ist nicht möglich.
Auswirkungen auf die Systemverwaltung
Beim Löschen von Bonuskäufen ist es erforderlich, die Datenbasis des SAP-Systems und der
angeschlossenen Kassensysteme konsistent zu halten und Datenschiefstände zu vermeiden.
SAP empfiehlt, das Programm BBY_POS_DELETE täglich im Hintergrund einzuplanen. Wenn das
erwartete Datenvolumen nicht zu groß ist, kann der Aufruf auch direkt aus dem Programm
BBY_DELETE erfolgen.
Siehe auch
Weitere Informationen finden Sie in der Dokumentation zu SAP Retail (SAP-Bibliothek -> Logistik ->
SAP Retail) unter Stammdaten -> Konditionen -> Bonuskauf.
12.6.1.2 Neue Änderungszeiger für Konditionssätze (WIND)
Verwendung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) stehen folgende zusätzliche Möglichkeiten im
Rahmen der Beleganpassung bei Konditionsänderungen zur Verfügung:
o
Direkte Erzeugung von Einträgen im Arbeitsvorrat nach Konditionsänderungen
o
Aufnahme zusätzlicher Daten für einen Eintrag im Arbeitsvorrat
Bei dem bisherigen Verfahren wurden die Einträge im Arbeitsvorrat auf der Basis der Änderungszeiger
für Konditionsänderungen (Nachrichtentyp CONDBI) im Rahmen der Arbeitsvorratserstellung
(Transaktion MEI4) erzeugt. Bei dem neuen Verfahren sind dagegen Änderungszeiger nicht mehr nötig.
Bei der Änderung einer Kondition werden nun Einträge im Arbeitsvorrat direkt erstellt. Dadurch entfällt
zum einen der bisherige performanceaufwendige Prozeßschritt der Arbeitsvorratserstellung aus
Änderungszeigern. Darüber hinaus kann auf die Erzeugung von Änderungszeigern für
Konditionsänderungen verzichtet werden, wenn diese nicht in anderen Prozessen verwendet werden.
Das für die bisherige Arbeitsvorratserstellung geltende Customizing, das festlegt, welche Konditionsarten
______________________________________________________________
SAP AG
6
SAP-System
______________________________________________________________
im Arbeitsvorrat aufgenommen werden sollen (Tabelle T6I1), ist auch für die direkte Erzeugung gültig.
Bei dem neuen Verfahren gibt es jedoch zusätzliche Filtermöglichkeiten. Zum einen kann pro Belegtyp
festgelegt werden, für welche Arten von Konditionsänderungen (Betragsänderung, Gültigkeit,
Kalkulationsrelevanz usw.) Arbeitsvorratseinträge erstellt werden sollen. Darüber hinaus existiert ein
vom Filterkriterium Belegtyp abhängiges BAdI, mit dem kundenindividuelle Filterkriterien realisiert
werden können.
Das folgende Beispiel erläutert die Möglichkeiten des BAdIs:
Aufgrund wechselnder Einkaufsbedingungen werden Frischeartikel in kurzen Abständen regelmäßig neu
kalkuliert, eine Aktualisierung von Verkaufspreisen über den Prozess des Kalkulationsvorrats wird daher
nicht benötigt. Verwenden Sie für die Anwendung Handelskalkulation (Belegtyp 10) in diesem Fall als
zusätzliches Filterkriterium die Materialart. Bei einer Änderung des Einkaufsgrundpreises für einen
Frischeartikel erzeugt das System dann aufgrund des eingerichteten Filterkriteriums keinen
Arbeitsvorratseintrag für diesen Belegtyp.
Die zusätzlichen Daten eines Arbeitsvorratseintrags bestehen zum einen aus Kopfdaten der Konditionen,
mit denen man eine Verbesserung der Performance bei der Folgeverarbeitung erreicht, sowie aus
variablen Kundenfeldern, mit denen eine selektive Folgeverarbeitung möglich wird. Das Füllen der
Kundenfelder wird im Customizing festgelegt (Tabelle T6I2S).
Auswirkungen auf den Datenbestand
Wenn auf Änderungszeiger für Konditionsänderungen verzichtet wird, dann reduziert sich der
Datenbestand der Änderungszeiger erheblich. Ein Änderungszeiger besteht i.d.R. aus mehreren Einträgen
in der Tabelle BDCP bzw. BDCP2.
Im einzelnen ergeben sich folgende Änderungen:
o
Die Tabellenbreite der Tabelle WIND erhöht sich durch die zusätzlichen Felder von 45 auf 262
Bytes.
o
Die Anzahl der Tabelleneinträge im Arbeitsvorrat kann sich aufgrund der zusätzlichen
Filterkriterien verringern.
o
Änderungszeiger für den Nachrichtentyp CONDBI werden ggf. nicht mehr benötigt.
Auswirkungen auf die Systemverwaltung
Der Prozeßschritt der Erzeugung des Arbeitsvorrats aus Änderungszeigern (Transaktion MEI4) ist bei
dem neuen Verfahren nicht mehr nötig.
Die Prüfung gegen bestehende Belegindizes (Tabelle S111), die bei der bisherigen
Arbeitsvorratserstellung möglich ist, muß nun im BAdI als zusätzliches Filterkriterium implementiert
werden (siehe Beispiel-Coding).
Die Migration des Arbeitssvorrats von den alten auf die neuen Arbeitsvorratseinträge wird mit dem
Report RMEBEMIG vorgenommen. Der Report ergänzt die vorhandenen Einträge mit Informationen aus
den Konditionssätzen.
Wenn von dem alten auf das neue Verfahren umgestellt wird, ist für jeden Belegtyp ein spezielles
Anpassungsverfahren notwendig. Dieses Verfahren ist jeweils in den Anwendungen beschrieben, die das
neue Verfahren nutzen.
Auswirkungen auf das Customizing
Stellen Sie zunächst das neue Customizing für die direkte Erzeugung von Arbeitsvorratseinträgen ein. Bei
______________________________________________________________
SAP AG
7
SAP-System
______________________________________________________________
einer Neuinstallation oder wenn Sie die Beleganpassung für einen bestimmten Belegtyp noch nicht
genutzt haben, setzen Sie das Kennzeichen für Migration und Direkteintrag manuell im Customizing. Bei
der Umstellung vom alten auf das neue Verfahren werden die Kennzeichen im Rahmen des
Migrationsverfahrens ggf. automatisch gesetzt.
Zusätzlich legen Sie pro Belegtyp als Filterkriterium die Arten der Konditionsänderungen fest, für die
Arbeitsvorratseinträge erstellt werden sollen, und wie die variablen Felder zu füllen sind.
Wenn für alle verwendeten Belegtypen die direkte Erzeugung von Arbeitsvorratseinträgen eingestellt ist,
kann ggf. auf die Erstellung von Änderungszeigern vom Nachrichtentyp CONDBI verzichtet werden.
Deaktivieren Sie dann den Nachrichtentyp CONDBI im ALE-Customizing.
Die Deaktivierung kann auch durch den Migrationsreport durchgeführt werden.
Siehe auch
Weitere Informationen finden Sie in der Dokumentation zu SAP Retail (SAP-Bibliothek -> Logistik ->
SAP Retail) unter Stammdaten -> Konditionen -> Automatische Aktualisierung von Belegen nach
Konditionsänderungen.
12.7 SD-BF
Grundfunktionen
12.7.1 SD-BF-PR
Konditionen und Preisfindung
12.7.1.1 Condition-Based Excise Determination in SD (New)
Verwendung
As of SAP R/3 Enterprise Core 4.70 (SAP_APPL 470), you can calculate excise duties and sales taxes
applicable in India in sales documents using standard pricing procedures (condition-based excise
determination).
All excise duties and sales taxes are included in the pricing procedures themselves (not in tax
procedures).
We recommend that new customers follow this procedure.
There are four new pricing procedures:
Pricing procedure
JINFAC
JINEXP
JINDEP
JINSTK
Use
Sales from manufacturing plants
Export sales
Sales from depots
Stock transfers
For more details about the procedures, including which condition types are supplied, see the
documentation mentioned below.
Auswirkungen auf den Datenbestand
______________________________________________________________
SAP AG
8
SAP-System
______________________________________________________________
Once you have made the Customizing settings below, assign the appropriate customer pricing procedures
to your customer master records.
Create condition records for all excise duties and sales taxes.
Auswirkungen auf das Customizing
IMG activity
What to do
Define and Assign Pricing Procedures
Copy the pricing procedures supplied, adjust them to
match your needs, and set up the pricing determination procedures.
Siehe auch
SAP Library -> Logistics -> Country Versions -> India -> Sales and Distribution (SD) -> Pricing.
12.7.2 SD-BF-TX
Steuern
12.7.2.1 Condition-Based Excise Determination in SD (New)
Verwendung
As of SAP R/3 Enterprise Core 4.70 (SAP_APPL 470), you can calculate excise duties and sales taxes
applicable in India in sales documents using standard pricing procedures (condition-based excise
determination).
All excise duties and sales taxes are included in the pricing procedures themselves (not in tax
procedures).
We recommend that new customers follow this procedure.
There are four new pricing procedures:
Pricing procedure
JINFAC
JINEXP
JINDEP
JINSTK
Use
Sales from manufacturing plants
Export sales
Sales from depots
Stock transfers
For more details about the procedures, including which condition types are supplied, see the
documentation mentioned below.
Auswirkungen auf den Datenbestand
Once you have made the Customizing settings below, assign the appropriate customer pricing procedures
to your customer master records.
Create condition records for all excise duties and sales taxes.
Auswirkungen auf das Customizing
______________________________________________________________
SAP AG
9
SAP-System
______________________________________________________________
IMG activity
What to do
Define and Assign Pricing Procedures
Copy the pricing procedures supplied, adjust them to
match your needs, and set up the pricing determination procedures.
Siehe auch
SAP Library -> Logistics -> Country Versions -> India -> Sales and Distribution (SD) -> Pricing.
12.8 SD-SLS
Verkauf
12.8.1 Auswertung offener Verkaufsbelege nach US-GAAP Richtlinie SFAS 133
Verwendung
Nach SFAS 133 - Accounting for Derivative Instruments and Hedging Activities - müssen die offenen
Werte bestimmter Verkaufsbelege zum Marktwert bilanziert werden. Hierbei sind die Änderungen des
Marktwertes erfolgswirksam im Ergebnis zu berücksichtigen.
Um die Selektion der betroffenen Belege zu unterstützen, stellt SAP den Report SDFAS133 zur
Verfügung.
Weitere Informationen:
Dokumentation des Reports SDFAS133
12.8.2 SD-SLS-SO
Kundenauftrag
12.8.2.1 Aus Kundenauftrag erzeugte Bestellanforderungen im
Haushaltsmanagement (geändert)
Verwendung
Ab dem Release SAP R/3 Enterprise Public Services 1.10, erzeugt eine Bestellanforderung, die aus einem
Kundenauftrag generiert wird, ein Obligo im Haushaltsmanagement (HHM). Bei der Fortschreibung von
Bestellanforderungen kann Budget verfügt werden.
Auswirkungen auf den Datenbestand
Vorhandene Bestellanforderungen werden nicht automatisch fortgeschrieben. Die neue Funktion wird nur
wirksam, wenn Sie in diesem Release mit neuen Kundenaufträge arbeiten.
Auswirkungen auf das Customizing
Die Bestellanforderungen werden im HHM als normale Bestellanforderungen angesehen. Daher ist kein
spezielles Customizing notwendig.
______________________________________________________________
SAP AG
10
SAP-System
______________________________________________________________
12.8.2.2 SD-Auftrag-Fortschreibung im Haushaltsmanagement (HHM)
Verwendung
Ab dem Release SAP R/3 Enterprise Public Services 1.10, schreiben fakturierungsrelevante SD-Aufträge
Obligo-Einzelposten im Haushaltsmanagement fort.
Auswirkungen auf den Datenbestand
Bestehende SD-Aufträge können mit dem Programm RFFMR07 nachgebucht werden. Wählen Sie hierzu
im Einführungsleitfaden Public Sector Management -> Haushaltsmanagement Öffenltiche Verwaltung ->
Ist- und Obligofortschreibung/Integration -> R/3 Interne Datenübernahme -> Nachbuchung -> HHM
Offene Posten für SD-Aufträge nachbuchen.
Auswirkungen auf das Customizing
Die Funktion ist in allen HHM-Fortschreibungsprofilen aktiv. Ein spezielles Customizing ist nicht
erforderlich.
12.9 SD-BIL
12.9.1 SD-BIL-IV
12.9.1.1 SD-BIL-IV-SM
Fakturierung
Fakturabearbeitung
Aufwandsbezogene Fakturierung
12.9.1.1.1 Aufwandsbezogene Faktura für erlösführende Innenaufträge (neu)
Verwendung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) kann die aufwandsbezogene Faktura direkt
erlösführende Innenaufträge verarbeiten.
Bisher war die aufwandsbezogene Faktura nur möglich für
o
Verkaufsbelege mit Kostensammler
o
Erlösführende Serviceaufträge
o
Erlösführende PSP-Elemente.
Die Kosten von Innenaufträgen konnten nur nach Abrechnung auf eines dieser Objekte in der
aufwandsbezogenen Faktura berücksichtigt werden.
Jetzt ist die aufwandsbezogene Faktura für erlösführende Innenaufträge direkt über einen Verkaufsbeleg
ohne Kostensammler möglich. Der Prozeß orientiert sich an der derzeitigen Lösung zur
aufwandsbezogenen Faktura von Projekten / PSP-Elementen.
Auswirkungen auf das Customizing
Zur Nutzung der neuen Funktion muß im Customizing der Verkaufsbelegpositionen die Kontierung auf
______________________________________________________________
SAP AG
11
SAP-System
______________________________________________________________
Innenaufträge erlaubt werden. Das tun Sie im Arbeitsschritt:
Steuerung Kundenauftragsfertigung / Kundenauftrags-Controlling
12.9.1.1.2 Archivierung der CO-Einzelposten (erweitert)
Verwendung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) können Sie die CO-Einzelposten zu Aufträgen
und Projekten auch dann archivieren, wenn Sie diese aufwandsbezogen fakturieren. Dadurch können Sie
die Performance Ihres Gesamtsystems erheblich verbessern.
Auswirkungen auf das Customizing
Um die erweiterte Archivierungsfunktion nutzen zu können, müssen Sie neben den Residenzzeiten für die
CO-Einzelposten auch Residenzzeiten für Dynamische-Posten-Prozessor-Quellen (DPP-Quellen)
eingeben. Verwenden Sie hierfür im IMG der Angebotserstellung und Fakturierung die Aktivität
Residenzzeiten der DPP-Quellen.
12.9.1.1.3 Belegflussauswertungen der aufwandsbezogenen Faktura (neu)
Verwendung
Auswertung des Belegflusses zum Auftrag
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) können Sie den Belegfluss der fakturierten
Aufwände zu einem Kundenauftrag, Serviceauftrag, Kontrakt oder Projekt über ein neues Programm
auswerten. Das Programm stellt die fakturierten, abgesagten und offenen Aufwände in einer
Strukturübersicht ähnlich der Aufwandssicht in der aufwandsbezogenen Faktura dar. Die Strukturierung
können Sie interaktiv ändern. Zu jedem Aufwandsposten werden die Fakturaanforderungen detailliert
aufgelistet. Sie können direkt aus der Ergebnisübersicht zur Fakturaanfoderung navigieren. Diverse
weitere Funktionen wie z. B. Filter ermöglichen eine flexible Auswertung.
Die Auswertung des Belegflusses können Sie über die Transaktionen DP99A, DP99B und DP99C
durchführen. Diese Transaktionen unterscheiden sich lediglich in Ihren Selektionsmöglichkeiten.
Auswertung des Belegflusses zur Fakturaanforderung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) können Sie sich ausgehend von einer
Fakturaanforderung oder auch einer Gutschriftsanforderung die über den Beleg fakturierten Aufwände
anzeigen lassen. Über die Transaktion DP98 erhalten Sie eine entsprechende Liste mit allen fakturierten
Aufwandsposten zur Fakturaanforderung.
12.9.1.1.4 DP-Prozessor (erweitert)
Verwendung
______________________________________________________________
SAP AG
12
SAP-System
______________________________________________________________
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) stehen Ihnen folgende Erweiterungen des
Dynamische-Posten-Prozessors (DP-Prozessors) zur Verfügung:
o
Neue Business Add-Ins (BAdI's):
Zu allen Kundenerweiterungen wurden Business Add-Ins (BAdIs) entwickelt. Diese BAdIs stehen
gleichberechtigt neben den Kundenerweiterungen, die weiterhin unterstützt werden. Lediglich die
Kundenerweiterung AD010006 wurde in das BAdI SMOD_AD010006 migriert und steht nur noch
als BAdI zur Verfügung.
Zusätzlich zu den BAdI's mit den Funktionen aus den Kundenerweiterungen werden auch neue
Business Add-Ins ausgeliefert.
o
Verbesserte Steuerungsmöglichkeiten zur Übernahme von Mengen und Kosten
Für die Übernahme von Mengen und Kosten in der Materialfindung des
Dynamische-Posten-Prozessorprofils (DPP-Profils) stehen Ihnen erweiterte
Einstellungsmöglichkeiten zur Verfügung. Das Kennzeichen Menge übernehmen ist deshalb
umbenannt worden in Menge/Kosten übernehmen. Sie können nun unter anderem festlegen, dass
ein Aufwandsposten nur dann in den Vertriebsbeleg übernommen wird, wenn die Kosten ungleich 0
sind, oder nur dann, wenn die Menge ungleich 0 ist.
o
Erhöhung der möglichen Materialfindungszeilen je DPP-Profil
Sie können nun im DPP-Profil mehr als 999 Materialfindungszeilen definieren.
o
Neues Analyseprogramm für DPP-Profile
Die bisherige Konsistenzprüfung für DPP-Profile wird durch ein neues Analyseprogramm ersetzt.
Das neue Programm führt ebenfalls eine Konsistenzprüfung für das Profil durch, kann allerdings
immer nur ein Profil pro Durchlauf prüfen. Dafür bietet es dem Anwender mehr Informationen und
erlaubt auch das Drucken des gesamten Profils und die Simulation der Materialfindung. Das neue
Programm können Sie über das Customizing oder die Transaktion ODP2 ausführen.
Wenn Sie die Konsistenzprüfung für mehrere Profile gleichzeitig ausführen wollen, steht Ihnen das
bisherige Programm über die Transaktion ODP2A weiterhin zur Verfügung.
Auswirkungen auf das Customizing
Die Einstellmöglichkeiten zu den neuen Funktionen finden Sie im Customizing des Projektsystems
unter den Aktivitäten Erlöse und Ergebnis --> Integration mit Vertriebsbelegen -->
Angebotserstellung und Fakturierung für Projekte --> Profile für Angebotserstellung und
Fakturierung pflegen und Profileinstellungen prüfen.
Siehe auch
o
Weitere Informationen über die Business Add-Ins finden Sie im Einführungsleitfaden (IMG) des
Projektsystems unter Erweiterungen Angebotserstellung/Fakturierung entwickeln.
o
Weitere Informationen zu den verbesserten Steuerungsmöglichkeiten zur Übernahme von Mengen
und Kosten finden Sie in der Dokumentation des Datenelements Menge und Kosten übernehmen.
12.9.1.1.5 Fakturaanforderung für Kundenauftragspositionen (erweitert)
Verwendung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) können Sie im Geschäftsprozess Fakturierung
______________________________________________________________
SAP AG
13
SAP-System
______________________________________________________________
von Auftragspositionen mit Serviceprodukt eine gemeinsame Fakturaanforderung für mehrere
Kundenauftragspositionen erstellen. Die einzelnen Positionen können dabei auch unterschiedliche
Fakturierformen haben.
12.9.1.1.6 Sammelverarbeitung aufwandsbezogene Faktura (erweitert)
Verwendung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) bietet Ihnen die Sammelverarbeitung der
aufwandsbezogenen Faktura zusätzliche Selektionsmöglichkeiten für Kundenaufträge oder
Serviceaufträge an. Die verbesserten Sammelverarbeitungen sind über folgende Programme verfügbar:
o
Die Transaktion DP96 ermöglicht eine verbesserte Selektion von Kundenaufträgen.
o
Die Transaktion DP97 erweitert die Selektionsoptionen für Serviceaufträge.
12.9.1.1.7 Statische Abwicklung aufwandsbezogene Faktura (gelöscht)
Verwendung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) steht die statische Abwicklung der
aufwandsbezogenen Faktura (Transaktion VA90), wie zu Release 4.5 angekündigt, nicht mehr zur
Verfügung. Stattdessen können Sie die dynamische Abwicklung (Transaktion DP90) nutzen, die Ihnen
alle nötigen Funktionen zur Verfügung stellt.
Auswirkungen auf den Datenbestand
Sie müssen Ihre existierenden Aufträge auf die dynamische Abwicklung umstellen.
Auswirkungen auf das Customizing
Sie müssen Ihr System auf die dynamische Abwicklung der aufwandsbezogenen Faktura umstellen. Dies
können Sie bereits vor der Umstellung auf SAP R/3 Enterprise für alle Releases ab 4.5B tun.
Weitere Informationen zur Umstellung auf die dynamische Abwicklung finden Sie im
Einführungsleitfaden (IMG) der Angebotserstellung und Faktura unter Statische Abwicklung (Verfahren
vor Release 4.5).
12.10 SD-EDI
Electronic Data Interchange
12.10.1 BAdIs im Preiskatalog
Verwendung
Ab SAP R/3 Enterprise Retail 1.10 (EA-RETAIL 110) stehen Ihnen im Preiskatalog folgende
Business Add-In (BAdIs) zur Verfügung:
______________________________________________________________
SAP AG
14
SAP-System
______________________________________________________________
BAdI PRIREADMATERIAL:
Das BAdI PRIREADMATERIAL wird in der Ausgangsverarbeitung des Preiskataloges aufgerufen.
Dieses BAdI erlaubt Ihnen, die Felder des Preiskatalogs mit eigenen Daten zu füllen. Sie können so
Katalogfelder im Preiskatalog füllen, die in der Standardauslieferung nicht versorgt werden können, für
die aber im System ggf. in kundeneigenen Tabellen oder Erweiterungen entsprechende Daten vorhanden
sind. Auch das Nachlesen von Konditionen oder Stücklisten nach einer anderen Logik als die, die im
Preiskatalog vorgesehen ist, und die Integration der so gewonnenen Daten in den Preiskatalog ist mit
Hilfe dieses BAdIs möglich.
Das BAdI besteht aus fünf Methoden:
o
Mit der Methode READ_MATERIAL erweitern Sie die Grunddaten.
o
Mit der Methode READ_BOM haben Sie die Möglichkeit, Erweiterungen zum Lesen von
Stücklisten. Die Methode wird für jedes Material gerufen, auch wenn für das Material im System
keine Stückliste gefunden wurde. Sie können so Stücklisteninfos individuell hinzulesen, um sie
ablegen zu können.
o
Mit der Methode READ_CONDITION können Sie Erweiterungen zum Lesen von Konditionen
implementieren.
o
Die Methode READ_CONDITION_COMPLETE erlaubt Ihnen, Konditionen zu ändern und zu
ergänzen. Im Unterschied zu READ_CONDITION hat diese Methode eine wesentlich erweiterte
Schnittstelle. Insbesondere stehen auch die Stücklisteninformationen zur Verfügung.
o
Die Methode READ_BOM_COMPONENTS wird innerhalb der Routine, die den Stücklistenzugriff
ausführt, gerufen und erlaubt Ihnen die direkte Bearbeitung der ermittelten Stücklistenkomponenten.
Der Aufruf erfolgt nur, wenn ein Material auch eine Stückliste hat. Die Methode ermöglicht die
Änderung der Stücklistenkomponenten
BAdI PRICHECKPOSITION:
Das BAdI PRICHECKPOSITION wird ebenfalls in der Ausgangsverarbeitung des Preiskataloges
aufgerufen.
Dieses BAdI ermöglicht Ihnen die Implementierung einer zusätzlichen Prüfung der Katalogposition.
Dadurch können zum Beispiel weitere Pflichtfelder innerhalb des Kataloges festgelegt werden oder
logische Abhängigkeiten geprüft werden.
Das BAdI beinhaltet fünf Methoden:
o
In der Methode CHECK_POSITION wird die komplette Katalogposition mit Ausnahme der
kundenspezifischen Konditionen geprüft.
o
In der Methode CHECK_CUSTOMER_PRICE können pro Kunde die Konditionen geprüft werden.
o
Die Methode CHECK_BOM erlaubt Ihnen, die Komponenten aus K007 zu einem Material zu
überprüfen und einen Returncode zu setzen. Der Returncode steuert das Verhalten nach Rückkehr
aus der Methode :
-
'0': keine weitere Aktion
-
'1': Statussatz (K003S) wird auf Fehler gesetzt, Transportflag in K003S wird auf 'kein
Transport' gesetzt.
-
'2' und alle anderen Werte außer 0 und 1: Statussatz wird auf Fehler gesetzt und Transportflag
______________________________________________________________
SAP AG
15
SAP-System
______________________________________________________________
auf 'zu transportieren'.
o
Mit der Methode CHECK_CUSTOMER_PRICES_ALL haben Sie die Möglichkeit, die
Konditionen im Zusammenhang zu überprüfen. So werden alle Konditionen aus der K008C
übergeben. Zusätzlich wird die aktuelle Materialposition übergeben. Sie können so die Konditionen
aller Kunden zum jeweils aktuellen Material betrachten. In der Tabelle IT_CUSTOMERS können
die Kunden eingetragen werden, bei denen ein Fehler aufgetreten ist. Diese Tabelle wird nach
Rückkehr aus der Methode interpretiert und die betroffenen Statussätze (K003S) werden auf Fehler
ohne Übertragung gesetzt.
o
Die Methode CHECK_POSITION_CUST erlaubt Ihnen eine Prüfung auf der Ebene
Kunden/Material und das Setzen des Transportflags in der übergebenen K003S .
BAdI PRISETPARTNER:
Das BAdI PRISETPARTNER wird ebenfalls in der Ausgangsverarbeitung des Preiskataloges aufgerufen.
Dieses BAdI bietet zwei Methoden an:
o
Die Methode ADJUST_K00C erlaubt Ihnen, in der Transaktion VPRICAT Felder der Tabelle
K000C (also kundenabhängige Preiskatalogfelder) zu ändern. Verwenden Sie diese Methode, um
die Partnerart und die Partnernummer zu setzen, die zur Versendung des IDocs an den jeweiligen
Kunden genutzt werden sollen. Damit kann die manuelle Pflege unterbleiben.
o
Die Methode SET_PARTNER_PARMS wird bei der Erstellung des IDocs PRICAT02 gerufen. Sie
erlaubt Ihnen, die Nachrichtenvariante und die Nachrichtenfunktion zum Zugriff auf die
Partnervereinbarung zu setzen. Nachrichtenvariante und Nachrichtenfunktion sind Schlüsselfelder
zur Partnervereinbarung. Wenn sie nicht über die Methode SET_PARTNER_PARMS gesetzt
werden, sind sie initial.
BAdI PRICAT_OUT_EXTIN:
Auch das BAdI PRICAT_OUT_EXTIN wird in der Ausgangsverarbeitung des Preiskataloges aufgerufen.
Dieses BAdI dient dazu, den ExtensionIn-Parameter des BAPIs
BAPI_PRICECATALOGUE_SAVREPLICA im Preiskatalogausgang zu füllen. Eine Tabelle
ExtensionIn im BAPI-Interface ist die Standard-Erweiterungstechnik für BAPIs.
Diese Schnittstelle ist relevant, wenn Preiskataloge über den Nachrichtentyp PRICECATALOGUE
verschickt werden. Der Parameter ExtensionIn gibt Ihnen die Möglichkeit. zusätzlich zum im Standard
definierten Datenumfang weitere Daten an das BAPI weiterzugeben und somit auch an das zu
versendende IDoc, das auf Basis der BAPI-Schnittstelle generiert wurde.
Die zusätzlichen Daten werden über eigene Segmente (E1BPAREX) im IDoc transportiert. Das BAPI
enthält ebenfalls BAdI-Methodenaufrufe, um diese Daten über kundenspezifisches Coding im
Preiskatalogeingang verarbeiten zu können. Wenn die Daten nicht zwischen zwei SAP R/3-Systemen
ausgetauscht werden, muß ein Konverter die anwenderspezifischen Segmente interpretieren.
Die Methode OUTBOUND_EXTENSIONIN importiert die komplette Schnittstelle des BAdIs. Der
Parameter RT_EXTENSIONIN ist ein Changing-Parameter. Somit kann diese Tabelle innerhalb der
Methode mit kundenspezifischen Daten gefüllt werden. Der Parameter ExtensionIn ist die in
Standardauslieferung unterstützte Erweiterungstechnik für BAPIs.
BAdI PRICAT_IN_EXTIN:
Das BAdI PRICAT_IN_EXTIN wird in der Eingangsverarbeitung des Preiskataloges aufgerufen.
Dieses BAdI kennt zwei Methoden:
______________________________________________________________
SAP AG
16
SAP-System
______________________________________________________________
o
Die Methode CHECK_INBOUND_EXTENSION erlaubt zu Beginn der Verarbeitung im BAPI
BAPI_PRICECATALOGUE_SAVREPLICA die Überprüfung der Parameter, die dem BAPI
übergeben wurden. Insbesondere kann der Parameter ExtensionIn überprüft werden. Über den
Parameter RV_SUBRC können Sie errreichen, daß die weitere Verarbeitung unterbleibt. Die
Systemnachrichtenfelder werden nach Aufruf der Methode im BAPI
BAPI_PRICECATALOGUE_SAVREPLICA ausgewertet, wenn RV_SUBRC ungleich 0 ist .
o
Die Methode UPDATE_INBOUND_EXTENSION erlaubt die Verarbeitung der Daten aus dem
Tabellenparameter ExtensionIn. Dieser Parameter enthält ggf. kundenspezifische Daten, die
entweder in die Standardtabellen des Preiskataloges integriert werden sollen, oder in kundeneigenen
Tabellen abgelegt werden sollen. Zur Integration in die Standardtabellen des Preiskataloges werden
sog. BAPI_Table_Extensions verwendet. Dies sind Objekte des Erweiterungskonzeptes für BAPIs.
Sie werden standardmäßig mit den Key-Bestandteilen ausgeliefert und um eigene Felder in Appends
erweitert. Diese Methode erhält die Table_Extensions über die Schnittstelle und kann sie dann
füllen. Für jede Tabelle des Preiskataloges wird eine entsprechende Table_Extension ausgeliefert.
Informieren Sie sich im Quelltext des Bausteins BAPI_PRICECATALOGUE_SAVREPLICA über
die Namen der Extensions. Es handelt sich um die Changing-Parameter der Methode
UPDATE_INBOUND_EXTENSION. Nach Rückkehr aus dem Methodenaufruf werden die
Einträge mit den Standardtabellen abgeglichen. Wenn Sie eigene Tabellen aktualisieren wollen,
können Sie innerhalb der Methode einen eigenen Verbuchungsbaustein aufrufen, der Ihre eigenen
Tabellen aktualisiert.
Die Changing-Parameter sind bei Aufruf leer. Sie werden ggf. innerhalb der Methode gefüllt. Sie
werden genutzt, um kundeneigene Felder innerhalb der Standardtabellen zu versorgen. Wenn
Einträge in diesen Strukturen und Tabellen vorgenommen werden, muß der Parameter
'entries_made' auf 'X' gesetzt werden, damit die Übertragung aus diesen Strukturen und Tabellen in
die Standardtabellen des Preiskataloges erfolgt. Es handelt sich bei diesen Parametern um
BAPI-table-extensions. Im Kundensystem können diese Strukturen mit APPENDS erweitert
werden. Diese Erweiterung entspricht genau der Erweiterung der entsprechenden Standardtabelle.
Mit einem MOVE_CORRESPONDING nach dem Methodenaufruf werden die kundenspezifischen
Felder in die Standardtabellentransxportiert. Es handelt sich hierbei um die im Standard unterstützte
Erweiterungstechnik für BAPIs.
BAdI PRISETTEXTPARMS:
Das BAdI PRISETTEXTPARMS wird wiederum in der Ausgangsverarbeitung des Preiskataloges
aufgerufen .
Dieses BAdI dient dazu, die Text-IDs und Sprachen für Materialtexte einzuschränken, die potentiell in
einen Preiskatalog aufgenommen werden sollen. Die Einschränkung kann aus Gründen der Übersicht im
Katalog sinnvoll sein. Ebenso ist es angebracht, aus Performancegründen nicht nach allen denkbaren
Materialtexten in allen Sprachen zu suchen.
Das BAdI unterstützt die Methode ADJUST_LANGUAGES_OUT. Diese Methode erhält über die
Schnittstelle die Text-IDs und Sprachen als Tabellen über zwei Changing-Parameter. Durch die
Implementierung dieser Methode können Sie nun diese Text-IDs und Sprachen einschränken, indem Sie
Einträge aus den Tabellen entfernen.
______________________________________________________________
SAP AG
17
SAP-System
______________________________________________________________
12.10.2 Unterstützung von Staffeln im Preiskatalog
Verwendung
Ab SAP R/3 Enterprise Retail 1.10 (EA-RETAIL 110) können Sie Staffeln im Preiskatalog ablegen.
Staffeln im Preiskatalogeingang:
Die Eingangsverarbeitung der logischen Nachrichten PRICECATALOGUE legt die Staffeln im
Eingangspreiskatalog ab.
Die Anzeige erfolgt jeweils über einen neuen Tabreiter auf EAN-Ebene (Transaktion PRICAT).
Staffeln im Preiskatalogausgang:
Bisher versendet der logische Nachrichtentyp PRICAT (IDocs PRICAT01 und PRICAT02)
Staffelinformationen. Dies erfolgt durch Nachlesen der Staffeln aus den Stammdaten (nicht aus dem
Preiskatalog) zum Zeitpunkt der IDoc-Erstellung.
Sie haben nun die Möglickeit, die Staffeln bei Erstellung im Preiskatalog abzulegen. Die Staffeln können
über die Transaktionen VPRICAT (Ausgang) und PRICAT (Eingang) angezeigt und geändert werden.
Der Änderungsdienst berücksichtigt die Änderungen an Staffeln ebenfalls. Anzeige und Pflege erfolgen
jeweils über einen neuen Tabreiter auf EAN-Ebene.
Die Nachricht PRICECATALOGUE (über den neuen IDoc-Typ PRICECATALOGUE02) versendet die
Staffeln aus den Katalogdaten heraus.
Die Funktionalität des logischen Nachrichtentyps PRICAT (IDocs PRICAT01 und PRICAT02) ist
unverändert.
IDoc-Erweiterungen für die Nachricht PRICECATALOGUE02:
Bisher konnten für die Nachricht PRICECATALOGUE keine kundeneigenen Segmente eingefügt
werden, da das BAPI, auf dem diese Nachricht beruht (BAPI_PRICECATALOGUE_SAVREPLICA),
bisher keine Kundenerweiterungen unterstützt. Dieses BAPI ist nun in seiner Schnittstelle um den
Parameter EXTENSIONIN erweitert. Dieser Parameter erlaubt die Übergabe kundenspezifischer Daten
an das BAPI. Innerhalb des BAPIs wird die Verarbeitung dieser Daten über zwei Methoden des neuen
BAdI PRICAT_IN_EXTIN mit Hilfe von Table-Extensions unterstützt. Da die Nachricht
PRICECATALOGUE technisch (durch Generierung der Nachricht aus der BAPI-Schnittstelle) auf dem
BAPI beruht, enthält der neue IDoc-Typ PRICECATALOGUE02 ein neues Segment zum Transport der
Kundenerweiterungen. Auf der Ausgangsseite wird das Befüllen dieses Segmentes durch das BAdI
PRICAT_OUT_EXTIN unterstützt.
12.11 SD-POS
POS-Interface
12.11.1 SD-POS-OUT
POS-Interface-Ausgang
______________________________________________________________
SAP AG
18
SAP-System
______________________________________________________________
12.11.1.1 Neue Änderungszeiger für Konditionssätze (WIND)
Verwendung
Ab SAP R/3 Enterprise Core 4.70 (SAP_APPL 470) stehen folgende zusätzliche Möglichkeiten im
Rahmen der Beleganpassung bei Konditionsänderungen zur Verfügung:
o
Direkte Erzeugung von Einträgen im Arbeitsvorrat nach Konditionsänderungen
o
Aufnahme zusätzlicher Daten für einen Eintrag im Arbeitsvorrat
Bei dem bisherigen Verfahren wurden die Einträge im Arbeitsvorrat auf der Basis der Änderungszeiger
für Konditionsänderungen (Nachrichtentyp CONDBI) im Rahmen der Arbeitsvorratserstellung
(Transaktion MEI4) erzeugt. Bei dem neuen Verfahren sind dagegen Änderungszeiger nicht mehr nötig.
Bei der Änderung einer Kondition werden nun Einträge im Arbeitsvorrat direkt erstellt. Dadurch entfällt
zum einen der bisherige performanceaufwendige Prozeßschritt der Arbeitsvorratserstellung aus
Änderungszeigern. Darüber hinaus kann auf die Erzeugung von Änderungszeigern für
Konditionsänderungen verzichtet werden, wenn diese nicht in anderen Prozessen verwendet werden.
Das für die bisherige Arbeitsvorratserstellung geltende Customizing, das festlegt, welche Konditionsarten
im Arbeitsvorrat aufgenommen werden sollen (Tabelle T6I1), ist auch für die direkte Erzeugung gültig.
Bei dem neuen Verfahren gibt es jedoch zusätzliche Filtermöglichkeiten. Zum einen kann pro Belegtyp
festgelegt werden, für welche Arten von Konditionsänderungen (Betragsänderung, Gültigkeit,
Kalkulationsrelevanz usw.) Arbeitsvorratseinträge erstellt werden sollen. Darüber hinaus existiert ein
vom Filterkriterium Belegtyp abhängiges BAdI, mit dem kundenindividuelle Filterkriterien realisiert
werden können.
Das folgende Beispiel erläutert die Möglichkeiten des BAdIs:
Aufgrund wechselnder Einkaufsbedingungen werden Frischeartikel in kurzen Abständen regelmäßig neu
kalkuliert, eine Aktualisierung von Verkaufspreisen über den Prozess des Kalkulationsvorrats wird daher
nicht benötigt. Verwenden Sie für die Anwendung Handelskalkulation (Belegtyp 10) in diesem Fall als
zusätzliches Filterkriterium die Materialart. Bei einer Änderung des Einkaufsgrundpreises für einen
Frischeartikel erzeugt das System dann aufgrund des eingerichteten Filterkriteriums keinen
Arbeitsvorratseintrag für diesen Belegtyp.
Die zusätzlichen Daten eines Arbeitsvorratseintrags bestehen zum einen aus Kopfdaten der Konditionen,
mit denen man eine Verbesserung der Performance bei der Folgeverarbeitung erreicht, sowie aus
variablen Kundenfeldern, mit denen eine selektive Folgeverarbeitung möglich wird. Das Füllen der
Kundenfelder wird im Customizing festgelegt (Tabelle T6I2S).
Auswirkungen auf den Datenbestand
Wenn auf Änderungszeiger für Konditionsänderungen verzichtet wird, dann reduziert sich der
Datenbestand der Änderungszeiger erheblich. Ein Änderungszeiger besteht i.d.R. aus mehreren Einträgen
in der Tabelle BDCP bzw. BDCP2.
Im einzelnen ergeben sich folgende Änderungen:
o
Die Tabellenbreite der Tabelle WIND erhöht sich durch die zusätzlichen Felder von 45 auf 262
Bytes.
o
Die Anzahl der Tabelleneinträge im Arbeitsvorrat kann sich aufgrund der zusätzlichen
Filterkriterien verringern.
______________________________________________________________
SAP AG
19
SAP-System
______________________________________________________________
o
Änderungszeiger für den Nachrichtentyp CONDBI werden ggf. nicht mehr benötigt.
Auswirkungen auf die Systemverwaltung
Der Prozeßschritt der Erzeugung des Arbeitsvorrats aus Änderungszeigern (Transaktion MEI4) ist bei
dem neuen Verfahren nicht mehr nötig.
Die Prüfung gegen bestehende Belegindizes (Tabelle S111), die bei der bisherigen
Arbeitsvorratserstellung möglich ist, muß nun im BAdI als zusätzliches Filterkriterium implementiert
werden (siehe Beispiel-Coding).
Die Migration des Arbeitssvorrats von den alten auf die neuen Arbeitsvorratseinträge wird mit dem
Report RMEBEMIG vorgenommen. Der Report ergänzt die vorhandenen Einträge mit Informationen aus
den Konditionssätzen.
Wenn von dem alten auf das neue Verfahren umgestellt wird, ist für jeden Belegtyp ein spezielles
Anpassungsverfahren notwendig. Dieses Verfahren ist jeweils in den Anwendungen beschrieben, die das
neue Verfahren nutzen.
Auswirkungen auf das Customizing
Stellen Sie zunächst das neue Customizing für die direkte Erzeugung von Arbeitsvorratseinträgen ein. Bei
einer Neuinstallation oder wenn Sie die Beleganpassung für einen bestimmten Belegtyp noch nicht
genutzt haben, setzen Sie das Kennzeichen für Migration und Direkteintrag manuell im Customizing. Bei
der Umstellung vom alten auf das neue Verfahren werden die Kennzeichen im Rahmen des
Migrationsverfahrens ggf. automatisch gesetzt.
Zusätzlich legen Sie pro Belegtyp als Filterkriterium die Arten der Konditionsänderungen fest, für die
Arbeitsvorratseinträge erstellt werden sollen, und wie die variablen Felder zu füllen sind.
Wenn für alle verwendeten Belegtypen die direkte Erzeugung von Arbeitsvorratseinträgen eingestellt ist,
kann ggf. auf die Erstellung von Änderungszeigern vom Nachrichtentyp CONDBI verzichtet werden.
Deaktivieren Sie dann den Nachrichtentyp CONDBI im ALE-Customizing.
Die Deaktivierung kann auch durch den Migrationsreport durchgeführt werden.
Siehe auch
Weitere Informationen finden Sie in der Dokumentation zu SAP Retail (SAP-Bibliothek -> Logistik ->
SAP Retail) unter Stammdaten -> Konditionen -> Automatische Aktualisierung von Belegen nach
Konditionsänderungen.
12.11.1.2 Neue Funktionen beim POS-Interface-Ausgang
Verwendung
Ab SAP R/3 Enterprise Retail 1.10 (EA-RETAIL 110) enthält der POS-Ausgang folgende
Neuerungen:
o
Bei der POS-Ausgangsverarbeitung gibt es jetzt eine zusätzliche Parallelisierungsstufe. Dadurch
wird nur noch ein Hintergrund-Job pro Vertriebslinie benötigt und es entstehen Synergien bei der
Änderungszeigerselektion.
o
Im POS-Ausgangsprofil kann jetzt mit dem Kennzeichen "Preise direkt lesen" die Performance der
______________________________________________________________
SAP AG
20
SAP-System
______________________________________________________________
Preisfindung erhoeht werden. Voraussetzung ist eine bestimmte Datenstruktur.
o
Mit dem neuen Kennzeichen "Preise filialunabhaengig" kann die Performance der Preisfindung
erhöht werden Voraussetzung ist, dass keine filialabhängigen Preise vorhanden sind.
o
Mit dem Kennzeichen "filialabh. Preise in A071" koennen Sie die Performance der Preisfindung
weiter erhöhen. Voraussetzung ist, dass alle filialabhängigen Preise ausschließlich in Tabelle A071
abgelegt sind und es nur relativ wenige davon gibt.
o
Ein neuer IDoc-Typ WPDREB01 (Aktionsrabatte) kann jetzt über den POS-Ausgang erzeugt
werden. Damit können Rabattinformation auf höheren Ebenen als Artikel an die Nachgelagerten
Systeme (in der Regel Filialwarenwirtschaftssysteme) verteilt werden (z.B. 5% Rabatt auf das ganze
Sortiment oder eine bestimmte Warengruppe).
o
Der erweiterte Konditionsbelegindex kann vom POS-Ausgang genutzt werden.
o
Das Abspeichern der Änderungszeiger wurde geändert und erlaubt eine Performance-Steigerung des
POS-Ausgangs. Voraussetzung ist eine vorherige Migration der alten Aenderungszeiger.
o
Der Zugriff auf Konditionsintervalle wurde weiter optimiert.
o
Die Implementierung des Intervallscanners wurde geändert. Dies erlaubt eine schnellere Analyse
von Konditionsintervallen.
o
Bei Neulistungen wird jetzt berücksichtigt, dass der Name des Sortiments nicht zwangsläufig mit
dem Namen der Filiale übereinstimmen muss.
o
Die Konditionszugriffe im Funktionsbaustein WWS_CONDITION_INTERVALS_GET wurden
optimiert. Dies führt zu Performance-Gewinnen.
o
Die Abarbeitung von Änderungszeigern erfolgt jetzt effizienter. Dies führt zu
Performance-Gewinnen.
o
Das (physikalische) Löschen von Konditionen kann jetzt von der Änderungsnachricht erkannt
werden. Damit wird in den meisten Fällen auch das Löschen von Aktions- und Normalkonditionen
unterstützt. Teilintervall-Löschungen von vorher gesplitteten Konditionssätzen können allerdings
auch weiterhin nicht erkannt werden.
o
Wenn das Kennzeichen "Steuerkennzeichen bei Varianten kopieren" nicht markiert ist, wird die
Preiskopie für Varianten abgeschaltet. Dies ist jedoch nur notwendig, wenn für die Varianten eines
Sammelartikels unterschiedliche Steuerkennzeichen verwendet werden.
o
Parallelpreise werden jetzt berücksichtigt.
o
Grund- bzw. Vergleichspreise werden jetzt berücksichtigt.
o
Die neue Funktionalitaet "m:n-Zuordnungen" bei Sortimenten wird unterstützt.
o
Das Erzeugen eines Triggerfiles kann jetzt explizit über das POS-Ausgangsprofil unterdrückt
werden.
o
Bonuskäufe können jetzt automatisch gelöscht werden.
Siehe auch
Weitere Informationen finden Sie in der Dokumentation zu SAP Retail (SAP-Bibliothek -> Logistik ->
SAP Retail) unter Verteilte Datenverarbeitung -> POS-Interface -> POS-Interface-Ausgang.
______________________________________________________________
SAP AG
21