Skip to main content

Good Morning Everyone,

I was curious to know about pre-posting on inventory transactions. As you may know, you can affect purchase requisitions and purchase orders to a speicific project / cost center / site /BU. However, when receiving the products (register arrivals) or create a manual supplier invoice from these POs, if they are linked to inventory parts, they do not consider pre-posting on postings M10 and M18. You have to set these up manually because business events say they do not consider pre-posting :

However, these cannot be changed as system events hardcoded. My questions are the follwoing ones :

  • Why would the system prevent us to keep track of pre-posting on inventory transactions whilst we are allowed to do so on non-inveotry ones ? 
  • How can we by-pass that and what is the best practice to keep track of pre-posting ? Because control types on M10 and M18 are rather poor.

Thanks in advance for your help and answers

Max

Hi, 
In general, Preposting is intended to be used on cost and revenue-related entries.

M10 and M18 are related to Goods Received Not Invoiced (Balance sheet) and normally do not require cost centers and similar prelposted elements. And in case of M18, we could have conflict between invoice preposting and order line preposting leading to inconsistent accounting information. 

Accounting scheme for non-inventory item is different, M92 and M93 are cost-related postings and preposting is applicable there.

In various cases I have set up a system, GRNI accounts details were driven by supplier or part information only (accounting group etc.) and nobody needed preposting details. What would it be used for, if M18 entry closes M10 GRNI balance? 
If you look for GRNI details by buyer department, you can use buyer, requisitioner or coordinator from PO as control type (use one of C38, C41, C42 or C43).

Hello Adam,
Thanks a lot for taking the time to answer. The issue is the following one : in France we do not use a balance sheet account but a cost one (hence the need). Unfortunately we cannot book code part values consistently and the control types are not enough since a buyer / requisitionner can work on different projects / BUs. 

Eventually I found out that preposting was able on IP1 but not on M18 which I found confusing since IP1 is restricted to ledger account. Do you have any suggestion to by pass-it ? Use WTISS after the invoice maybe ? But would not that be too late for the booking if the parts are stored for a while ?
Thanks

Hi,
What are you saying is interesting for me - can you explain briefly the French accounting scheme for inventory receipt and invoice match? I am not familiar with the pattern.

If we are talking about usually preposted code parts like cost center, OK, M10 and M18 postings could  theoretically use the preposting - I can see no consequences. But even assuming that M18 goes to purchase cost account and M10 to some revenue/inventory variation costs, I am not sure if we can gain something from using preposted cost center. What kind of added value / useful information can it bring compared to posting driven by buyer code? I cannot see how could it improve e.g. budget control.

But in case of project and project activity it is a little bit different story: M18 generates an entry on credit side of the account. If it contains project code and activity, and you use project inventory feature, your project gets charged on both debit and credit side - so impact is neutral, and in case of regular inventory, only credit entry affects project costs/revenue, effectively DECREASING project costs. It does not look natural for me - buying something for specific project should increase costs of the project as soon as you take the ownership of purchased item (i.e. at receipt). In case of regular general-purpose inventory stock,. project costs are increased on inventory issue operation.

I would rather keep it segregated. If you need to use P&L accounts for inventory procurement and you need project code there, I think you can define automatic posting rule triggered by M10/M18 posting with  dedicated procurement project code and activity fixed in the rule definition. 

 

 

 

Reply


Terms & ConditionsCookie settings