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