GR/IR postings from MIGO (good receipt)

[former_member1036319]

Hello,

It would be possible to avoid GR/IR postings from MIGO (good receipt) during certain periods, but at the same time not to stop logistics processes?,

so apparently one of this users that run in between material document and posting document would do, (maybe combined with FI settings or substitutions), and we cannot control this through OB52 since all company codes are assigned to 1 posting variant - 1000.

There is a standar transaction (solution), for this?

Regards

Francisco

[amitbakshi3 · Accepted solution]

Hi,

Please explain the Business Scenario in detail to analyze further. There could be many questions related to this :

Why would you want to Block the MIGO Transaction...Is there a backlog of work needed to be completed... What Transactions you want to perform in MIGO other than GR, Do you simply want to block Movement Type 101 (GR against PO) etc..

One way would be take the help of Basis to Block the Transaction Code with User Authorization, other would be to Block the 101 Mvt type.. Like I said before, Please list out the scenario to give you a solution.

Best regards

Amit Bakshi

[former_member1036319 · Accepted solution]

Hi,

What I know at the moment is that users would be able to maintain which periods GR/IR is open for their company codes. And they want control that if we try to GR attempts to post to a closed period, then an error message will be generated. May be the easier way is with OB52 or similar and the corresponding authorizations by user.

Rgs.

Francisco

[former_member187989 · Accepted solution]

Have you tried in demo client using OB52 by user authorization ?

[former_member1036319 · Accepted solution]

Hi,

But with OB52 I can control the movements type.

I mean, we need to stop goods receipt postings(101) and reversals(102) when we are performing the GRIR month end process.

Once AP accounts close we start the GRIR process e.g. F.13 clearing during this time the GRIR accounts remain open, therefore should an entity post a goods receipt or reversal for the closing period we will have a balance in the GRIR accounts after we have performed F.19, (according to the GRM GRIR accounts should be at zero at month end). Therefore to avoid these postings we need to stop GRu2019s being posted at the time AP closes.

If I want to control or to close any posting in good receipt with OB52 I will need to define accounts groups but will works if I have many company codes with the same posting period variant?. I think wil work if I have one variant by company codes.

Regards

Francisco

[former_member1036319 · Accepted solution]

Hi,

We are currently using OB52, but as this transaction is used globally we are not able to close the accounts until all the FI Companys have completed F.13. This is where we have the issue as some entities are completed earlier than others and as the accounts are still open then the markets are still able to process GRs.

It is possible solution in this case with OB52 tr.?

B.Regards

[rafael_zaragatzky · Accepted solution]

Hi Francisco,

The month closing of the GR/IR accounts (F.13) normally starts after the month end, e.g. the closing of May will start on about 3rd of June when all the logistics transactions considering May have been completed and you want only accountants to continue working on May.

The way to do it is to block posting to previous period (trs MMRV). Then these will be allowed again when the next month starts.

BR

Raf

[former_member1036319 · Accepted solution]

Hi Raf,

Thanks for answering,

The MMRV is from the MM side and with this tr. I will block (or allow postings), ALL the postings in the previous month.

I only need to control the GR/IR accts, so I only need to control postings in 246010, 246012 and 246014 accts. (in my case , and all the companies), so would not it be easier to block movements of GR/IR.(101 or 102)?

B.Regards

Francisco

[rafael_zaragatzky · Accepted solution]

Hi Francisco,

I don't see how you can restrict 101/102 in the previous period only. You can disallow this mvt types in general, but not per period (unless in a user exit).

On the other hand, I don't see why anybody on the logistics side would like to post other transactions to the previous month after the month-end process started (about the 3rd of the next month as I mentioned). Logistics people don't normally care about the posting date of the transactions, unless explicitly instructed by accountants to post to previous period.

So I can't see a problem with blocking all the movements to the previous period after the month-end process started.

BR

Raf

[former_member1036319 · Accepted solution]

Hi Raf,

The question is that we try to avoid these postings during month end because some entities are completed earlier than others( F.13 tr.) as the accounts are still open then the markets are still able to process GRs.

This is because we need to stop GRu2019s being posted at the time AP closes also wewill have a balance in the GRIR accounts after we have performed F.19, (according to the GRM GRIR accounts should be at zero at month end).

From FI side you can block postings with OB52 tr. but we have the same variant for all companies.

From MM side (stock) we can do it with MMRV, but I think we stil have the goods receipt issue.

B. Regards

Francisco

[rafael_zaragatzky · Accepted solution]

Hi Francisco,

No, I don't understand. I don't see a need for logistics people to post to previous period later than maybe on the 1st workday of the month. After that there shouldn't be any logistical need to post to the previous month. Then you close backposting in MMRV and don't reopen it until it is automatically reopened at the next month. Then there's no danger that some logistics trs will hit the GR/IR acct.

However, if the accounting people have to post invoices/credit memos and do acct maintenance (trs MR11), then this appoach will not help you, since these transactions will be blocked too.

The other solution with blocking the GR/IR account in OB52 I don't really understand. In OB52 you can allow or disallow all postings to an account - no matter if they come from logistics trs or from accounting...

BR

Raf

[former_member1036319 · Accepted solution]

Hi Raf,

Sorry for delay, I was traying to look for a BADI or User Exist that could apply in the Investm.Management MIGO

Related with the standar solution that I try to apply , the problem is that during the month closing:(GR/IR)

Once AP accounts close we start the GRIR process

Steps:

1. F.13 (automatic clearing)--> We can´t close (block) accounts until the company have completed F.13

--> Here is where I have the issue, because some entities (company), are completed earlier than others and as the accounts are still open the the markets are still able to process GRs and then we will have a balance in the GRIR accounts after we have performed F.19, (according to the GRM GRIR accounts should be at zero at month end).

This is because we need to stop GRu2019s being posted at the time AP closes

2. F.19 "Analyce GR/IR Clearing Accounts"

Now is clear the process?

Regards and thanks

Francisco

[rafael_zaragatzky · Accepted solution]

Sorry Francisco,

Still not clear! What I am saying is close the MM posting to the previous period before your step 1 (trs MMRV). This only blocks transactions in MM (GR and MM invoices) - the accountants still can go on with their job in F.13.

Anyhow, if you are looking for a user exit to block GR, here are some candidates:

- Include RVCOMFZ2, form USEREXIT_KOMPBME_FILL

- Enhancement MB_CF001 which is equivalent to the BAdI MB_DOCUMENT_BADI, method MB_DOCUMENT_BEFORE_UPDATE

The problem with all these user exits is that they are called when the user tries to save the document, i.e. all the entry work has been done and then during saving the user gets the message that he's not allowed to save.

The BAdI MB_MIGO_BADI has some methods that are called earlier and can suit your purpose (e.g. LINE_MODIFY and CHECK_ITEM), but this BAdI is only active in trs MIGO, i.e. if you have GR's entering some other way to SAP (MB01, IDoc, BAPI_GOODSMVT_CREATE, etc.) then your check will be bypassed. Unless of course there's another user exit in the method that you use for GR.

BR

Raf

[former_member187989]

Can you explain briefly about requirement ?

Have you look at user authorization group field in OB52 ?,Check it !

[former_member1036319]

Hi,

Here is an explanation of why we need to stop goods receipt postings(101) and reversals(102) when we are performing the GRIR month end process.

Once AP accounts close we start the GRIR process e.g. F.13 clearing during this time the GRIR accounts remain open, therefore should an entity post a goods receipt or reversal for the closing period we will have a balance in the GRIR accounts after we have performed F.19, (according to the GRM GRIR accounts should be at zero at month end). Therefore to avoid these postings we need to stop GRu2019s being posted at the time AP closes.

Regards

Francisco