Sie sind auf Seite 1von 13

Write Optimized DSO

The concept of Write Optimized DSO was introduced in BI-7.0. Write Optimized DSO unlike
Standard DSO has only one relational table, i.e. Active Table and moreover there is no SID
generated in Write Optimized DSO, and hence loading the data from Data Source to Write
Optimized DSO takes less time and acuires less disk space.
Business Case :
Require Data storage for storing detailed level of data with immediate reporting or further update
facility. No over write functionality required.
Limitation of Standard DSO
- A standard DSO allows to store detailed level of information, However, activation
process is mandatory.
- Reporting or further update is not possible until activation is completed.

Write Optimized DSO - Properties


- Primarily designed for initial staging of source system data
- Business rules are only applied when the data is updated to additional Info Providers.
- Stored in at most granular form
- Can be used for faster upload
- Records with the same key are not aggregated ,But inserted as new record, as every
record has new technical key
- Data is available in active version immediately for further Processing
- There is no change log table and activation queue in it.
- Data is saved quickly.
- Data is stored in it at request level, same as in PSA table.
- Every record has a new technical key, only inserts.
- It is Partitioned on request ID (automatic).
- It allows parallel load, which saves time for data loading.
- It can be included in Process chain, and we do not need activation step for it.
- It supports archiving.
Write-Optimized DSO - Semantic Keys
Semantic Key identifies error in incoming records or Duplicate records .
Semantic Keys protects Data Quality such that all subsequent Records with same key are written
into error stack along with incorrect Data Records.
To Process the error records or duplicate records , Semantic Group is defined in DTP.
Note : if we are sure there are no incoming duplicate or error records, Semantic Groups need not
be defined.

Write Optimized DSO- Data Flow


1. Construct Data Flow model.
2. Create Data source
3. Create Transformation
4. Create Info Package
5. Create DTP
Write-Optimized-Settings
If we do not check the Check Box "Do not Check Uniqueness of Data ", the data coming from
source is checked for duplication, i.e, if the same record (semantic keys) already exist in the
DSO, then the current load is terminated.
If we select the check box , Duplicate records are loaded as a new record. There is no relevance
of semantic keys in this case.

When Write Optimized DSO is Recommended ?


- For faster data load., DSOs can be configured to be Write optimized
- When the access for Source system is for a small duration.
- It can be used as a first Staging layer.
- In cases where delta in Data Source is not enabled, we first load data into Write
Optimized DSO and then delta load can be done to Standard DSO.
- When we need to load large volume of data into Info Providers, then WO DSO helps in
executing complex transformations.
- Write Optimized DSO can be used to fetch history at request level, instead of going to
PSA archive.
Write Optimised DSO - Functionality
- It contains only one table, i.e. active data table (DSO key: request ID, Packet No, and
Record No)
- It does not have any change log table and activation queue.
- Every record in Wrtite Optimized DSO has a new technical key, and delta in it works
record wise.
- In Wrtite Optimized DSO data is stored at request level like in PSA table.
- In Wrtite Optimized DSO SID is not generated.
- In Wrtite Optimized DSO Reporting is possible but it is not a good practice as it will
effect the performance of DSO.
- In Wrtite Optimized DSO BEx Reporting is switched off.
- Wrtite Optimized DSO can be included in Info Set or Multiprovider.
- Due to Wrtite Optimized DSO performance is better during data load as there is no
Activation step involved. The system generates a unique technical key
- The technical key in Wrtite Optimized DSO consists of the Request GUID field
(0REQUEST), the Data Package field (0DATAPAKID) and the Data Record Number field
(0RECORD).
Write-Optimized DSO-Points to Remember
Points to Remember :-
- Generally Write Optimized DSO is not prefered for reporting, but If we want to use it for
reporting then it is recommended to defina a semantic in order to ensure the uniqueness of the
data.
- Write-optimized DSOs can force a check of the semantic key for uniqueness when data is
stored.
- If this option is active and if duplicate records are loaded with regard to semantic key,
these are logged in the error stack of the Data Transfer Protocol (DTP) for further evaluation.
- If we need to use error stack in our flow then we need to define the semantic key in the
DSO level.
- Semantic group definition is necessary to do parallel loads.
Write-Optimized DSO - Reporting
If we want to use write-optimized DataStore object in BEx queries(not preferred):
it is recommended to
1. Have a semantic key and
2. Ensure that the data is unique.
Here the Technical key is not visible for reporting, so it looks like any regular DSO

Write-Optimized DSO-Useful OSS Notes


- OSS 1077308 : In a write-optimized DSO, 0FISCVARNT is treated as a key, even
though it is only a semantic key.
- OS

Write Optimized DSO


The concept of Write Optimized DSO was introduced in BI-7.0. Write Optimized DSO unlike
Standard DSO has only one relational table, i.e. Active Table and moreover there is no SID
generated in Write Optimized DSO, and hence loading the data from Data Source to Write
Optimized DSO takes less time and acuires less disk space.
Business Case :
Require Data storage for storing detailed level of data with immediate reporting or further update
facility. No over write functionality required.
Limitation of Standard DSO
- A standard DSO allows to store detailed level of information, However, activation
process is mandatory.
- Reporting or further update is not possible until activation is completed.

Write Optimized DSO - Properties


- Primarily designed for initial staging of source system data
- Business rules are only applied when the data is updated to additional Info Providers.
- Stored in at most granular form
- Can be used for faster upload
- Records with the same key are not aggregated ,But inserted as new record, as every
record has new technical key
- Data is available in active version immediately for further Processing
- There is no change log table and activation queue in it.
- Data is saved quickly.
- Data is stored in it at request level, same as in PSA table.
- Every record has a new technical key, only inserts.
- It is Partitioned on request ID (automatic).
- It allows parallel load, which saves time for data loading.
- It can be included in Process chain, and we do not need activation step for it.
- It supports archiving.
Write-Optimized DSO - Semantic Keys
Semantic Key identifies error in incoming records or Duplicate records .
Semantic Keys protects Data Quality such that all subsequent Records with same key are written
into error stack along with incorrect Data Records.
To Process the error records or duplicate records , Semantic Group is defined in DTP.
Note : if we are sure there are no incoming duplicate or error records, Semantic Groups need not
be defined.

Write Optimized DSO- Data Flow


1. Construct Data Flow model.
2. Create Data source
3. Create Transformation
4. Create Info Package
5. Create DTP
Write-Optimized-Settings
If we do not check the Check Box "Do not Check Uniqueness of Data ", the data coming from
source is checked for duplication, i.e, if the same record (semantic keys) already exist in the
DSO, then the current load is terminated.
If we select the check box , Duplicate records are loaded as a new record. There is no relevance
of semantic keys in this case.

When Write Optimized DSO is Recommended ?


- For faster data load., DSOs can be configured to be Write optimized
- When the access for Source system is for a small duration.
- It can be used as a first Staging layer.
- In cases where delta in Data Source is not enabled, we first load data into Write
Optimized DSO and then delta load can be done to Standard DSO.
- When we need to load large volume of data into Info Providers, then WO DSO helps in
executing complex transformations.
- Write Optimized DSO can be used to fetch history at request level, instead of going to
PSA archive.
Write Optimised DSO - Functionality
- It contains only one table, i.e. active data table (DSO key: request ID, Packet No, and
Record No)
- It does not have any change log table and activation queue.
- Every record in Wrtite Optimized DSO has a new technical key, and delta in it works
record wise.
- In Wrtite Optimized DSO data is stored at request level like in PSA table.
- In Wrtite Optimized DSO SID is not generated.
- In Wrtite Optimized DSO Reporting is possible but it is not a good practice as it will
effect the performance of DSO.
- In Wrtite Optimized DSO BEx Reporting is switched off.
- Wrtite Optimized DSO can be included in Info Set or Multiprovider.
- Due to Wrtite Optimized DSO performance is better during data load as there is no
Activation step involved. The system generates a unique technical key
- The technical key in Wrtite Optimized DSO consists of the Request GUID field
(0REQUEST), the Data Package field (0DATAPAKID) and the Data Record Number field
(0RECORD).
Write-Optimized DSO-Points to Remember
Points to Remember :-
- Generally Write Optimized DSO is not prefered for reporting, but If we want to use it for
reporting then it is recommended to defina a semantic in order to ensure the uniqueness of the
data.
- Write-optimized DSOs can force a check of the semantic key for uniqueness when data is
stored.
- If this option is active and if duplicate records are loaded with regard to semantic key,
these are logged in the error stack of the Data Transfer Protocol (DTP) for further evaluation.
- If we need to use error stack in our flow then we need to define the semantic key in the
DSO level.
- Semantic group definition is necessary to do parallel loads.
Write-Optimized DSO - Reporting
If we want to use write-optimized DataStore object in BEx queries(not preferred):
it is recommended to
1. Have a semantic key and
2. Ensure that the data is unique.
Here the Technical key is not visible for reporting, so it looks like any regular DSO

Write-Optimized DSO-Useful OSS Notes


- OSS 1077308 : In a write-optimized DSO, 0FISCVARNT is treated as a key, even
though it is only a semantic key.
- OSS 1007769 : Parallel updating in write-optimized DSO
- OSS 966002 : Integration of write-opt DSO in DTP error stack
- OSS 1054065 : Archiving supports.

List of all the important tables used in Sales and Distribution (SD) :

VTFA Flow shipping documents


VEPVG Delivery Due Index
Sales order :

VBAK Header data


VBAP Item data
VBPA Partners in sales order
VBKD Sales district data
VBEP Data related to delivery line items

Billing document :

VBRK header data


VBRP Item data

Shipping :

VTTK Shipment header


VTTP Shipment item
VTTS Stage in transport
VTSP Stage in transport per shipment item
VTPA Shipment partners
VEKP Handling Unit - Header Table
VEPO Packing: Handling Unit Item (Contents)

SD Delivery Documet :

LIKP Delivery header


LIPS Delivery item

Pricing :

KONH Conditions header


KONP Conditions items
KONV Procedure ( billing doc or sales order)
KOND

Contracts :

VEDA Contract data

Customers

KNA1 General Data


KNB1 Customer Master – Co. Code Data (payment method, reconciliation acct)
KNB4 Customer Payment History
KNB5 Customer Master – Dunning info
KNBK Customer Master Bank Data
KNKA Customer Master Credit Mgmt.
KNKK Customer Master Credit Control Area Data (credit limits)
KNVV Sales Area Data (terms, order probability)
KNVI Customer Master Tax Indicator
KNVP Partner Function key
KNVD Output type
KNVS Customer Master Ship Data
KLPA Customer/Vendor Link

Sales Documents

VBAKUK VBAK + VBUK


VBUK Header Status and Administrative Data
VBAK Sales Document - Header Data
VBKD Sales Document - Business Data
VBUP Item Status
VBAP Sales Document - Item Data
VBPA Partners
VBFA Document Flow
VBEP Sales Document Schedule Line
VBBE Sales Requirements: Individual Records

FAQ SAP BI/BW

1. Where do we used number range buffering? Codes SE27 and SNRO


2. what are the different cases in which update rules can be copied?
3. what are the different types of queries?
4. what is query view and query definition?
5. what is query template?
6. what is the difference between drill down and slice n dice?
7. what is result set query and infoset query?
8. what are jump queries?
9. what is drill up and drill across and how is drill across done?
10. what is an infoset and what the difference to it in BI 7?
11. what are the three scenarios for ods reporting?
12. what is an info catalog?
13. what are free characteristics and filters?
14. what are the difference between restricted key figures and filters?
15. what is the use of formula in BW?
16. what are advance query techniques in BW?
17. what is exception reporting?
18. what is reporting agent?
19. what is a variable and different types of variables and what is the use of variables?
20. at what times will currencies be translated?
21. what is the use of user exists?
22. what is query management?
23. what are the techniques to improve query performance?
24. what is query monitor? Is it useful for aggregates, if so how?
25. what are the query modes available in BW?
26. what is an aggregate and what is the use of it?
27. how are aggregated updated and when is it recommended to use aggregates?
28. what are the conditions and factors to be taken into account while creating aggregates?
29. what are the different strategies for creating an aggregate?
30. how aggregates can be optimized?
31. what is a profile generator and what is the use of it?
32. what is the difference between authorization and authorization objects?
33. what is Bex map?
34. what is web reporting and what are the benefits of using it?
35. what are the differences of bex and web reporting?
36. what is bex web application designer?
37. what type of servers are required to allow web reporting in SAP BW?
38. what is web reporting template?
39. what does data changes aggregates update program do?
40. what is the aim of aggregates and in what case can you not create aggregates?
41. where can data be filtered in SAP BW?
42. What are the variables used in Bex reporting?
43. What are the different Processing Types?
44. What is the replacing path Process Type? What is the input for Replacing path process type?
45. How do you create a Generic data source?
46. What are the function modules?
47. Types of Deltas?
48. what are the Generic delta types?
49. Explain V3 Update?
50. What is Cell definition?
51. How do you Transport objects from Development to Quality? IMP
52. What is Navigation Attribute? What are the tables will create while creating Navigational
attribute?
53. What are the tables for Master data in BW?
54. What are the tables will create while creating Info Object?
55. What are the tables will create while creating Info Cube?
56. Explain your Landscape? Examples?
57. Explain Implementation Methodologies?
58. ABAP reports?
59. What are the tables for SD in R/3?
60. how many Process Chains you are used?
61. What are the issues Faced while loading data?
62. What are the custom cubes you used?
63. How many users your company have?
64. What are the queries you have created?
65. What are the characteristics, key figures involved in query?
66. On what basis you assign Characteristics to Dimensions?
67. What is Plan data and where it will sit?
68.HOw to creat a report on one column where we stored both sales Report ?
69.How to strat & STOP PROCESS CHAIN
70: LOWER CASE & UPPER CASE ?
71: WHY WE GO FOR GENERIC EXTRACTION ? WHICH CASE ? IF THE DATA WILL
BE IN 3 TABLES & WE HAVE TO EXRTACT THE DATA FROM TWO FIELDS THEN
WHAT TO DO ?
72: ENHNACEMENT CASE WHICH LOGIC APPLY BY YOU ?
73: HOW MANY REPORTS /INFOCUBE /INFOSOURSE / DSO CREATED BY YOU ?
74: BASED OPEN 2LIS_11_VAHDR WHAT ARE THE REPORT U ARE CREATED ?
75: WHY WE GO FOR CEREATING INDEX ? HOW TO KNOW THAT IT'S THE TIME TO
CREAT THE INDEX ? why index not other Compress/ ?
76: HOW TO ROLE AUTHORIZEID SAP BI ?
77:WHAT IS EARLY INITIALZE DELTA ?
78: Wht is best for reporting Infocube or Dso ? why ?
79: How many tables are in dso ? standard dso / direct dso / write optimized dso ?
80: Selective Deletion /Repair full request / Repet delta /Reverse Posting /?
81: if the data is loaded in sapbw /sap bi & i want to serach the pericular year data ? where to
search ?
82 : Data is loading from sap bi/bw if in extraction stage it fails / How to rectify ? whr to
searchh ?

The typical procurement cycle for a service or material consists of the following phases:

1. Determination of Requirements

Materials requirements are identified either in the user departments or via materials planning and
control. (This can cover both MRP proper and the demand-based approach to inventory control.
The regular checking of stock levels of materials defined by master records, use of the order-
point method, and forecasting on the basis of past usage are important aspects of the latter.) You
can enter purchase requisitions yourself, or they can be generated automatically by the materials
planning and control system.

2. Source Determination

The Purchasing component helps you identify potential sources of supply based on past orders
and existing longer-term purchase agreements. This speeds the process of creating requests for
quotation (RFQs), which can be sent to vendors electronically via SAP EDI, if desired.

3. Vendor Selection and Comparison of Quotations

The system is capable of simulating pricing scenarios, allowing you to compare a number of
different quotations. Rejection letters can be sent automatically.

4. Purchase Order Processing

The Purchasing system adopts information from the requisition and the quotation to help you
create a purchase order. As with purchase requisitions, you can generate Pos yourself or have the
system generate them automatically. Vendor scheduling agreements and contracts (in the SAP
System, types of longer-term purchase agreement) are also supported.

5. Purchase Order Follow-Up

The system checks the reminder periods you have specified and - if necessary - automatically
prints reminders or expediters at the predefined intervals. It also provides you with an up-to-date
status of all purchase requisitions, quotations, and purchase orders.

6. Goods Receiving and Inventory Management

Goods Receiving personnel can confirm the receipt of goods simply by entering the Po number.
By specifying permissible tolerances, buyers can limit over- and under deliveries of ordered
goods.

7. Invoice Verification

The system supports the checking and matching of invoices. The accounts payable clerk is
notified of quantity and price variances because the system has access to PO and goods receipt
data. This speeds the process of auditing and clearing invoices for payment.

Purchasing (MM-PUR)
Purpose

The SAP System consists of a number of components that are completely integrated with one
another. This integration allows the various departments and units of an enterprise to share and
maintain the same information.
Purchasing is a component of Materials Management (MM). The Materials Management (MM)
module is fully integrated with the other modules of the SAP System. It supports all the phases
of materials management: materials planning and control, purchasing, goods receiving, inventory
management, and invoice verification.

The tasks of the MM Purchasing component are as follows:

● External procurement of materials and services

● Determination of possible sources of supply for a requirement identified by the materials


planning and control system or arising directly within a user department

● Monitoring of deliveries from and payments to vendors

Good communication between all participants in the procurement process is necessary for
Purchasing to function smoothly.

Integration

Purchasing communicates with other modules in the SAP System to ensure a constant flow of
information. For example, it works side by side with the following modules:

● Controlling (CO)

The interface to the cost accounting system (Controlling) can be seen above all in the case of
purchase orders for materials intended for direct consumption and for services, since these can be
directly assigned to a cost center or a production order.

● Financial Accounting (FI)

Purchasing maintains data on the vendors that are defined in the system jointly with Financial
Accounting. Information on each vendor is stored in a vendor master record, which contains both
accounting and procurement information. The vendor master record represents the creditor
account in financial accounting.

Through PO account assignment, Purchasing can also specify which G/L accounts are to be
charged in the financial accounting system.

● Sales and Distribution (SD)

Within the framework of materials planning and control, a requirement that has arisen in the
Sales area can be passed on to Purchasing. In addition, when a requisition is created, it can be
directly assigned to a sales order.

Materials Management Tables


MAKT Material Descriptions
MARA General Material Data
MARC Plant Data for Material
MARD Storage Location Data for Material
MAST Material to BOM Link
MBEW Material Valuation
MKPF Header- Material Document
MSEG Document Segment- Material
MVER Material Consumption
MVKE Sales Data for materials
RKPF Document Header- Reservation
T023 Mat. groups
T024 Purchasing Groups
T156 Movement Type
T157H Help Texts for Movement Types
MOFF Lists what views have not been created

Material document
MKPF material document
MSEG material document (item level)

PURCHASING Tables
A501 Plant/Material
VETVG Delivery Due Index for Stock Transfer
EKPV Shipping-Specific Data on Stock Tfr. for Purch. Doc. Item
EBAN Purchase Requisition
EBKN Purchase Requisition Account Assignment
EKAB Release Documentation
EKBE History per Purchasing Document
EKES Order Acceptance/Fulfillment Confirmations
EKAN Vendor address purchasing
EIPO Item export / import data
EORD Source list
EKPA Partner functions
EKET Scheduling Agreement Schedule Lines
EKKN Account Assignment in Purchasing Document
EKKO Purchasing Document Header
EKPO Purchasing Document Item
EINA Purchasing Info Record(Main Data)
EINE Purchasing Info Record(Organizational Data)
IKPF Header- Physical Inventory Document
ISEG Physical Inventory Document Items
LFA1 Vendor Master (General section)
LFB1 Vendor Master (Company Code)
NRIV Number range intervals
RESB Reservation/dependent requirements
T161T Texts for Purchasing Document Types

VENDOR
XEIP Number range maintenance: EXPIMP
XK01 Create vendor (centrally)
XK02 Change vendor (centrally)
XK03 Display vendor (centrally)
XK04 Vendor Changes (Centrally)
XK05 Block Vendor (Centrally)
XK06 Mark vendor for deletion (centrally)
XK07 Change vendor account group

CUSTOMER
VD01 Create customer master
VD02 Change customer master
VD03 Display customer master
VD04 Customer account changes
VD06 Customer deletion flag
XD01 Create Customer (Centrally)
XD02 Change Customer (Centrally)
XD03 Display Customer (Centrally)
XD04 Customer Changes (Centrally)
XD05 Block customer (centrally)
XD06 Mark customer for deletion (centr.)
XD07 Change Customer Account Group
XD99 Customer master mass maintenance
XDN1 Maintain Number Ranges (Customer)

SALES ORDER
VA00 Initial Sales Menu
VA01 Create Sales Order
VA02 Change Sales Order
VA03 Display Sales Order
VA05 List of Sales Orders
VA07 Compare Sales Purchasing (Order)

PRODUCTION PLANNING AND CONTROL


CO01 Create production order with material
CO01S Adding simulation order
CO02 Change Production Order
CO02S Change simulation order
CO03 Display Production Order
CO03S Display simulation order
CO04 Print Production Orders
CO05 Collective Release of Production Orders
CO06 Backorder Processing
CO07 Create order without a material
CO08 Create Production order with sales order
CO09 Availability Overview
CO1F Create confirmation of prod. order
CO1L Confirmation: List of requests
CO1P Predefined confirmation processes
CO1V Confirmation: Fast entry of time tick
CO10 Create Production order with project
CO11 Enter Time Ticket
CO11N Single Screen Entry of Confirmation
CO12 Collective Entry of Confirmations
CO13 Cancel confirmation of production order
CO14 Display confirmation of production order
CO15 Enter Production order Confirmation
CO16 Conf.: Post-processing error records
CO16N Reprocessing Confirmation
CO17 Enter confirmation with reference
CO19 Enter Time Event
CO20 Orders acc. to Order Numbers
CO21 Orders for Material
CO22 Orders for the MRP controller
CO23 Orders for the production scheduler
CO24 Missing Parts InfoSyst
CO26 Order information system
CO27 Picking list
CO28 Choose individual object lists
CO30 Standard trigger points
CO31 Create standard trigger point
CO32 Change standard trigger point
CO33 Display standard trigger point
CO40 Converting Planned Order
CO41 Collective Conversion of Planned Orders
CO42 Act. Overhead: Prod.Order Ind.Pro
CO43 Act. Overhead: Prod.Order Col.Pro
CO44 Mass processing of orders
CO46 Order progress report
CO47 Change comparison
CO51 Send Process Messages
CO52 Evaluate Process Data
CO53 Control Recipe Monitor
CO54 Message Monitor
CO55 Worklist for Maintaining PI Sheets
CO56 Display PI Sheet
CO57 Create Message Manually
CO58 Maintain PI Sheet
CO59 Delete PI Sheet
CO60 Find PI Sheet
CO62 Delete Process Messages
CO63 Evaluate Deletion Logs
CO64 Worklist for Completing PI Sheets
CO67 Worklist for Checking PI Sheets
CO68 MiniApp PI Sheet Mon -> List
CO69 Create Message Automatically
CO78 Archiving orders
CO8A Preset. Co-Products; Post-processing
CO8B Preset. Co-Products; Post-processing
CO80 Number range maintenance: AUF_RUECK
CO81 Number assignment: routing to order
CO82 Number ranges for orders
CO83 Number range maintenance: RESB
CO88 Act. Settlement: Prod./Process Order
CO99 Set Status "Closed"
MD04 Display Stock/Requirements Situation
MF65 Stock Transfer for Reservation (Goods Movement)
MF68 Log for Pull List (Goods Movement)
MB1A Goods Withdrawal (ie Goods issue)
MB1B Transfer Posting
MB1C Other Goods Receipts
MB31 Goods Receipt for Production Order
COHV Mass processing
COMAC Collective Availability Check
MATERIAL MASTER
IH09 Display Material
MM01 Create Material
MM02 Change Material
MM03 Display Material
MM04 Display Material Change Documents
MM06 Flag Material for Deletion
MM11 Schedule Creation of Material
MM12 Schedule Changing of Material
MM13 Activate Planned Changes
MM14 Display Planned Changes
MM15 Display Changes (Migration)
MM16 Schedule Material for Deletion
MM18 Activate Planned Changes
MM19 Display Material & at Key Date
MM50 List Extendable Materials
MMBE Stock Overview
MMI1 Create Operating Supplies
MMN1 Create Non-Stock Material
MMS1 Create Service
MMU1 Create Non-Valuated Material
MB21 Create Reservation
MB22 Change Reservation
MB23 Display Reservation
MB24 Reservations by Material
MB25 Reservations by Account Assignment
MB1C Other Goods Receipts
MB52 Warehouse Stock
MB90 Output Processing for Material Documents
MBRL Return Delivery per Material Document
MB1B Transfer Posting
MIBC ABC Analysis for Cycle Counting
MI03 Display Physical Inventory Document
MI06 Display Inventory Count

Das könnte Ihnen auch gefallen