2. ORGANIZATION IN MATERIALS MANAGEMENT...................................................................32.1 PLANT OR STORAGE LOCATION? .............................................................................................3
3. MATERIAL MASTER.................................................................................................................6
4. INTEGRATION AUTOMATIC POSTINGS.................................................................................74.1 ALGEMENE TOELICHTING BIJ DE REKENINGBEPALING ..................................................................74.2 CUSTOMIZING AUTOMATIC ACCOUNT ASSIGNMENTS .................................................................10
5. MM TERMINOLOGY...............................................................................................................14
6. Versie- en Configuratiebeheer..................................................................................................15
Conventies<< Algemene opmerking >>
Pagina 1 van 16
document.doc Gemaakt door: GVollebregt
1 Overview
Materials Management
MM-IV Invoice VerificationLO Logistiek
MM Materials Management)
Artikelbeheer (MM-ART)
Inkoop (MM-PUR Purchase)Requesition - ATB (Aanvraag tot bestellen) Invoice verification
LeveranciersbeheerVoorraadbeheerInventarisatieFactuurcontrole (organisatorisch bij boekhouding)
Warehousemanagement (WM) (Materiaaltypes)
(Factuurblokkeringen, vrijgavebevoegdheden voor geblokkeerde facturen, documentsoorten indien afwijkend van de standaard)
MM-BEWVoorraadwaarderingService entry sheet
Materiaal planningInventarisatieMilieu beheer
Pagina 2 van 16
document.doc Gemaakt door: GVollebregt
2 Organization in Materials Management
Eenheid: - Plant (Vestiging) (Productielokatie of groep opslaglocaties)
- Storage Location (Differentatie in voorraden, opslag plaatsen)
- Purchasing Organisation (Inkoopafspraken met leveranciers)
Rapportage: - Voorraad beheer;- Planning
Codering: - Plants (N4, uniek per client);- Storage loc (N4, uniek per plant).
Cross company purchase is normaal gesproken niet mogelijk. (er is wel een manier voor).
Plant: Productie lokatie, Groep van (storage) lokaties.Level voor planning en voorraadbeheer en basis entiteit in MM maar ook SD maakt er gebruik van.-> Organisatie inrichting: logistics general
Elke plant kan slechts aan één company code toegewezen worden. Maar wel aan meerdere purchasing en sales organizations.
Storage locations zijn onderverdelingen per plant.
2.1 Plant or Storage Location?
One of the most important decisions that you have to make in a MM implementation is whether to use a Plant or a Storage Location. One of the biggest problems is that either will work for most situations BUT and it is a BIG but, your choice will dramatically affect the functionality that will be available to the users. There is one obvious problem with using Plants and that is, the more Plants that you have, the more Material Master data you have to maintain. It is purely because of this problem that many sites are implemented with a very poor organization structure that severely limits the functionality of the system.
To put it simply, if you use storage locations your master data will be easier to manage, however your functionality will be very limited. If you use Plants you will have more master data to maintain, but you will have much better functionality.
If I had to make a choice, I would rather have full functionality and more master data, than have easy master data and poor functionality. It is because of the affect on master data that many organizations go with an over simplified structure. It is very easy to work out the effect, just multiply the number of materials by the number of Plants. BUT it is not easy to convince the users of the lost functionality, they probably do not yet realize how powerful SAP can be if configured correctly.
To illustrate this I have created some examples of structures so that you can see the advantages of having Plants at a lower level than can appear appropriate. I have not indicated which is right and
Pagina 3 van 16
Client
Company code (FI)
0001 Purchasing organization (MM)
0002 Purchasing organization (MM)
Plant0001
Plant0002
Plant0003
Storage location
Storage location
Storage location
Storage location
document.doc Gemaakt door: GVollebregt
which is wrong, because it is not that simple. It is just that some are better than others. It all depends on what the organization wants out of the system.
Example one· Plant is used for the United Kingdom. · Storage locations are created for London and Liverpool. With this set-up:· You cannot indicate that Liverpool and London have different lead times from the Vendor.
(The Vendor may be based in London and take one day to deliver to your London Plant and three days to deliver to Liverpool which is 250 miles away.)
· You cannot have different material values (STD price, MAP) for each city. · You cannot have one MRP type for Liverpool and a different one for London etc. These problems arise because the data for this is stored on the Plant specific views not the storage view.The advantage is that master data is only required for one Plant.
Example two· Plant is used for a London. · Storage locations are created for Warehouse and Production. With this set-up:· You can now indicate that Liverpool and London have different lead times. (By using the
Planned delivery period on the MRP screen, or Plant specific Info record.) · You can now have different material values (STD price, MAP) for each city. (Plant specific
Accounting view). If the Vendor has to send the materials to Liverpool there may well be delivery costs involved and these should be reflected in the MAP or STD price. The vendor is based in London and so may not charge the same amount, it could be necessary to retain this level of accuracy.
· You can now have one MRP type for Liverpool and a different one for London etc. The disadvantage is that master data is now required for two Plants. (Not a major problem, but it should be taken into account when designing the Organization structure).
SummaryThis structure is the most common, it is a good balance between master data and functionality, BUT it is still not completely correct for many situations. One example of this is the Factory calendar, this is linked to the Plant. If the Warehouse works 5 days and the Production area work 7 days, you cannot link two calendars to one Plant. This is not a 'show stopper' but you have to bear this in mind.
Example three· Plant is used for a London production. · Storage locations are created for Production Stores and Production Lines. With this set-up:· You can now indicate that the warehouse and Production Plant have different working days. · You also now have an extra "level" of Storage Locations that can be used to identify what is
in the Production stores, what is on each Production line etc. · MRP for the Production Plant will now not take the stock of components in the warehouse as
being available. This can be seen as a disadvantage, but it can be more of an advantage. If you try to look at what really happens in this business process, the main stock of components are not normally stored in the Production area, they are stored in the warehouse. If this is the case, someone somehow has to know how many of each material is to be moved into the Production area and when. With the above structure this can be done automatically by MRP. You would use Special Procurement key 40 (correctly configured) on all of the production Plant material masters for the components. When MRP runs and finds a shortage of stock, the correct type of requisition is created (Stock transfer) for the correct qty of components on the correct date. This saves a lot of time (and valuable storage space in the Production area), by moving materials only when required. This functionality may not be required, but if the Production area was a Storage Location instead of a Plant, it would not be possible to do it in the standard SAP system.
The disadvantage is that master data is now required.
Pagina 4 van 16
document.doc Gemaakt door: GVollebregt
Example four· Plant is used for a Sales Person. · Storage locations are created for Loan Stock and Demo Stock. This option would be far too much for many Organizations, but others may need to consider it. Basically it is a Plant for each Salesman (Saleswoman). It at first appears to be a crazy choice, but used with MRP it can be used to ensure that the Sales people have sufficient stocks of Loan or Demo items, sales order pads etc.With this set-up:· You can now see clearly where loan or demo stock is, how much is needed to replenish and
when (Using MRP and Special Procurement keys) this would be ideal for "van sales" (where the vehicle is more of a mobile shop).
· The requirements can be fed back to the warehouse via the Special Procurement keys and the sales person can therefore be sure that his/her stock will be available from the warehouse on the next visit (without manual intervention if configured correctly).
The disadvantage is that master data is now required for many Plants, one for each Sales person.
Pagina 5 van 16
document.doc Gemaakt door: GVollebregt
3 Material master
LO, MM, Material master
Create (special) trading goods (MMH1)
ViewsAccounting- Valution class: Waarderingsgroep o.a. te gebruiken in de MM rekeningsturing.- Price control: Standard of Moving averige.
Pagina 6 van 16
document.doc Gemaakt door: GVollebregt
4 Integration automatic postings
4.1 Algemene toelichting bij de rekeningbepaling
Many people expect the configuration of Automatic Account Assignment (AAA) to be the responsibility of FI. (This is normally the MM consultant hoping that the FI consultants will do it!). It does appear to be a financial responsibility, but only a MM consultant can be expected to know the range of transactions and Movement types involved. In fact it is one of the few areas that is very much a joint responsibility. The MM consultant needs to be able to understand the MM functions involved and the FI consultant needs to be able to understand what G/L accounts need to be updated in various circumstances. So to succeed, it really must be configured jointly, it is not a function to be tackled in isolation.
The most important thing to realise is that you are not configuring the way that the system carries out the accounting, you are merely configuring the numbers of the G/L accounts that the system should use in different circumstances. This leaves us with the task of deciding which general ledger accounts should be used when values are affected by MM transactions.
Basic principlesEvery time the value of a material is affected upwards OR downwards, a value is posted to the General Ledger accounts. When this happens, an Accounting Document is always created, this is the "audit trail" and lists the values and account numbers used.
Values are affected by many MM functions, but the most common ones are receipts, issues and transfers (others include Invoice Verification, Stock revaluation and GR/IR reconciliation.).
To determine which account to post to, the system needs to know three basic things: · What is happening: this could be a posting to the stock account following a 101 Movement
type receipt or a 201 goods issue, both update the stock account but one increases it the other reduces it. (Controlled by the Transaction/Event Key)
· Where is it happening: gives you the ability to use different stock account numbers for each Plant used. (controlled by the Valuation Area)
· What is it happening to: gives you the ability to use different stock account numbers for different materials. (Controlled by the Valuation Class)
The Transaction/Event Key is derived from the SAP transaction (and Movement type, where appropriate). The Valuation Area is normally equal to the Plant (or group of Plants). The Valuation Class is derived from the Material Master record (Accounting View).
The Transaction/Event Key, presents the biggest challenge when trying to understand the functionality. The best way to treat this, is to accept that the system "knows" which ones are to be used and in which circumstances. This is not exactly true, but few people ever need to change this area and it is far easier to understand the whole process, if you accept that it is almost hardcoded. (There will be more than one Transaction Event Key for each SAP transaction)
BSX (Voorraadrekening) is the Inventory Posting, in other words the stock account posting. It is the most common key that is used, it is posted to for every receipt, issue or transfer, to and from stock.
PRD (Prijsverschillen) is the Cost price Differences Posting, in other words the Price Variance accounts postings. It is used to post the differences between the actual price and the standard price, or any differences in transfer values (e.g. £10 in one Plant £15 in another).
WRX (GR/IR) is the GR/IR Clearing Posting. It is used to post the value due to the Vendor upon receipt of the Goods or Invoice. (Goods receipt will post a negative value to this account, Invoice
Pagina 7 van 16
document.doc Gemaakt door: GVollebregt
Verification will post a positive value to this account. (Therefore, if the values match, the account is self-clearing).
GBB is one of the trickiest to set-up, it is the Offsetting Entry For Inventory Posting. It sounds very strange, but it is exactly what it says. It is the account used whenever you post directly to or from the Stock account, without a P.O.. It includes movement types 501, 561, 201, 261, etc., etc. Because every posting has to have an equal and opposite posting, you need this account. So if you Scrap some stock, the system will reduce the Stock account by the correct value and then post this value to the account indicated in the GBB posting (The offsetting posting). This is normally made more complex because it uses something called the Account Modifier (also known as the Account Grouping Code. Both will be explained in later sections and should only be considered when the basics have been understood) There are many other Transaction Event Keys but the ones mentioned here are the most common, we can cover the others later.
The Valuation Area (Chart of Accounts) can also be called the Valuation Area Group. It is most common for the grouping option to be used. It groups together Plants (Or Company codes if the Valuation Level has been set to Company code, not normally set to Company code with MM or PP implementations). All Plants in the group must belong to the same Chart of Accounts, but they can belong to different Company codes. You should group together all Plants that are treated the same way. as far as accounting is concerned. The FI consultant should be able to decide how many groups are required by asking the users in the financial department. It is then easy to setup the groups in Config. Some examples may be a group of Warehouses, a group of Production Plants and a group for Plants that are merely offices, another example might be a group of Plants in one country and a separate group of Plants for another country.
The Valuation Class is also a type of grouping, as it groups together Materials that are treated in the same way, as far as accounting is concerned. Again, the FI consultant should be able to decide how many Valuation Classes are required, by asking the Financial department, "How many different Materials are there, as far as the accounting department is concerned?". This may well relate directly to material types, but it does not have to. For example, you could group together some of the Raw Materials with some of the Finished Materials by giving each of the materials the same Valuation Class.
The Valuation Classes are linked to the Material Types, via the Account Category Reference. This link is quite a strange one, there can only be one Account Category Reference for each Valuation Class, there can only be one Account Category Reference for each Material Type. However, you can have more than one Valuation Class linked to an Account Category Reference and you can have more than one Material Type linked to an Account Category Reference. This leads to the relationship between Material Type and Valuation Class being a many to many relationship. What is also strange is that in effect, the Account Category Reference and the Material Type do not directly affect Automatic Account assignment. The main use of the Account Category Reference is purely for validation of the Valuation Class at Material Master maintenance and nothing else. In fact you could allocate a Valuation Class to a material then change the link of that Valuation class to the A/c Cat. Ref. and this will NOT affect the AAA. The Valuation Class determines which accounts are updated and this has not changed.
Rules. On the screen where you enter the Account Numbers in AAA, you will see a function box marked "RULES". It is important to not "play with" they rules to see what they do, because if you change them you will lose the entries in any of the rules that you have switched off. In the rules you can set the Valuation Class and the Account Modifier on or off for maintenance.
Why do we have the option of switching columns off? If you take the example of WRX (The GR/IR Clearing account). The reason that the Valuation Class column is switched off is that this type of posting is not affected by the material causing the posting. Without the ability to switch the column off, you would have to enter all of the valuation classes with the same account number.
Pagina 8 van 16
document.doc Gemaakt door: GVollebregt
Account Modifier (also known as the Account Grouping Code or account group) column used for. (Switched on in GBB in the standard system). Firstly lets have a look at what GBB is. It is the "Offsetting entry for Inventory Posting" and it is the account used to post the value to when the stock account is updated in most movements other than those related to a PO. If there is no PO, then you cannot use the WRX (GR/IR Clearing Account) to offset the value posted to or from the stock account and so it has to be posted somewhere, the GBB posting. Examples:
· The 201 movement type, it removes stock to go to a Cost Centre, so one posting will be a reduction to stock (BSX), the other is the offsetting posting (GBB).
· Another example is the "scrapping" movement type, this also reduces stock (BSX) and posts an offsetting entry (GBB).
How then can we ensure that the two use different accounts for the offsetting entry? It is the Account Modifier that solves this problem. The best way to think of the Account modifier is to imagine it as a grouping function for Movements (Movement Types). To find out which Account Modifier is used on each movement type, you can either look at the config of movement types or look at the "Account Grouping for movement types" configuration path in AAA. It is not as obvious as you would expect as you will find many Account Modifiers for each Movement type. This is because the key to the entry includes things like the QTY and Value flags, Consumption Indicator, Special Stock type etc. Each different combination of these can be linked to a different account Modifier (Also you will see which Transaction Event Key is listed).
Another area that contains the Account Modifier is the Account Assignment Category, used on the PO item line. Each A/C Ass Cat can have a different Account modifier, this is how the system is able to suggest the account to be used when entering the PO. It does not know what movement type will be used in the receipt (If there is a receipt), so it needs to pick up the A/C Modifier from the A/C Ass Cat. (you can create new A/C Ass Cats if you want to, you can therefore get the system to post to different accounts depending on the AAC. You could therefore have 2 or more AACs for Cost Centre purchases, using different accounts per entry.
Praktisch
Stap 1. Check with the FI team/Users to see how many different groups of Plants you will need. Set them up in the Config (Activate the Valuation Grouping and then just allocate a group Id to each of the valuation areas). This sets up the Valuation Area Groups.
Stap 2.Then Check with the FI team/Users to see how many different groups of materials you will need. Set these up in Config by creating new Valuation Classes and Accunt Category References and link them to the correct Material Types (this last step, the link to Material Type can either be done in the same area where you create the Valuation Classes or in the config of Material Types).
There is no function within the system that can help in this task, but there is one option that is almost hidden. If you use the "SIMULATION" function within AAA (any valid combination), when the results are displayed click on the leftmost menu option and you will see an option to produce a report. When you run this report you can leave some of the settings blank or use ranges, this will produce a very large report, so be careful. But within this report will be all of the possible combinations of Movement Type, Valuation Area Group and Valuation Class.
If you are having problems with error messages that indicate that the AAA is not set up for this combination then this is really easy to solve. Just click on the message itself and the full message will tell you the Chart of Accounts, Trans Event Key, Valuation Area Group and Valuation Class involved.
An option when starting from scratch, is to configure the most common Trans Event Keys first BSX, PRD, WRX and GBB. This should enable many standard transactions to function, you can then configure the rest as they occur.
Pagina 9 van 16
document.doc Gemaakt door: GVollebregt
Pagina 10 van 16
document.doc Gemaakt door: GVollebregt
4.2 Customizing automatic account assignments
Via FI (IMG, FI, Grootboek, Zakelijke transacties, Integratie, ...)Via MM (IMG, Materiaal beheer, Waardering en rubricering, rekeningbepaling)
Tabel: Rekeningtoewijzingen liggen vast in groepen met operatie codes. Elke groep is via een transactie code te benaderen. Dit ligt vast in de tabel T030A. Totale rekeningsturing voor MM ligt vast in tabel T030.
period closing programLogistics Basic Data (LO-MD)Program that is run at the start of every new period. It ensures that:þ5 certain data is updated in the correct period þ6 goods movements are always posted to the correct period
(begin juli) Probleem periode variant VNU en MM artikelinstelling
MMPV “periode verschuiving artikel” geeft de melding MARV niet gevuld.
Tabel T009B perioden
In FI gaat het goedIn logistiek alg, artikelstam, basisinstellingen, bedrijfsnummer artikelstam (OMSY) verschijnt de melding “ Een ongeldige periode voor bedrijfsnr. Xxx op gegeven”.
þ7 note 0023502 dit is op te lossen door de perioden van het voorgaande jaar in te vullen
Vervolgens in OMSY de melding “De vorige periode kan niet bepaald worden”.
Werkvolgorde logistiekOMSY - bedrijfsnummer en periodes invoerenMMPV - periode verschuiving artikel ingeven
Oplossing heeft Leon gevonden in customer base. Ook periode variant 1999 diende ingevoerd te worden.
Pagina 14 van 16
document.doc Gemaakt door: GVollebregt
5 MM Terminology
Pagina 15 van 16
document.doc Gemaakt door: GVollebregt
6 Versie- en Configuratiebeheer
Configuratie historieVersie nr. Datum Aangebrachte wijzigingen Auteur0.1 Origineel document GVollebregt1.0 Aanpassing Tekst 1.1 Update Hoofdtekst1.2 Update Hoofdtekst
