cancel
Showing results for 
Search instead for 
Did you mean: 

Unexpected behaviour of system in sale order with 653 movement.

moazzam_ali
Active Contributor
0 Kudos

Dear All

Currently I am testing a scenario for order to cash. By mistake I assigned a schedule line category with sale item category which has movement type 653 which is sale return movement type. The scenario is order to cash with normal MTS sale but mistakenly movement type is mapped 653. When I completed the process I checked document flow and surprised to see that system allowed PGI and invoice. Now In PGI following is the accounting document.

Dont get confuse with Stock in transit GL as it is only a test GL which is COGS in actual.

Following is the entry at the time of billing document.

and following is the document flow.

I am not posting this as a question as this is not a question but only a point which I want to highlight that why SAP is allowing this? Item category is of debit nature and system is allowing a movement type which is credit nature. In my opinion this is a loop hole in system. What do you think????

CC:

Thank$

Accepted Solutions (0)

Answers (4)

Answers (4)

moazzam_ali
Active Contributor
0 Kudos

Thank you all experts. I just wanted to bring this in your and every reader's notice that system can allow this even this is illogical to have return movement type for sales item category.

I have already opened a ticket to SAP and waiting for solution from last one n half month. SAP's response is slow and we just asked SAP support to check why it is taking so long. That is some other issue related to valuated sales order stock in MTO and log_mm_sit business function.

Opening a ticket to SAP also requires some approvals mechanism here in my company so I can't open ticket for this where I am not facing any issue. It was just an observation which I shared to get your expert opinions on it. May be some SAP guy check this thread and bring this in SAP's notice

Thank$

former_member182378
Active Contributor
0 Kudos

Moazzam,

Thanks for this thread! As we become more experienced, we need to think about the various ways of combination (right and wrong) and the possible impacts. This will help us in mapping business needs in SAP. From an experienced analyst, the customer expects more work related to design and communication with customer's staff (managers, BPEs) about design options and the reason for selecting the final option.

TW

Lakshmipathi
Active Contributor
0 Kudos

As long as you assign the schedule line category to item category and item category to order type in configuration, system will allow you to that settings and this is correct from system point of view but logically, as you said, it is wrong.  May be, as suggested by Jelena, you can raise a low priority ticket with SAP and get their concurrence as to how this could happen.

G. Lakshmipathi

Jelena
Active Contributor
0 Kudos

I agree with TW - it just relies on the configuration to be done correctly (and tested, I guess).

But if you feel it's an error then feel free to open a low priority incident with SAP. We had a somewhat similar case with FI configuration. In a previous release a consultant assigned a "dummy" bank account somewhere in the company config. It was allowed by the system at the time. However, after upgrade to EHP6 we found that SAP made some changes in EDI invoices that caused a short dump (later they fixed it to be an error instead) when we tried to trigger EDI output for an invoice.

We traced down the issue to that "dummy" bank account in the configuration (and it was not even for the same company code!). IMHO the code SAP added should not have been triggered in the first place (it's some kind of EU requirement and we're in the US), but after some back and forth I was able to convince them that since this has changed then at least it should no longer be allowed to create such configuration with "dummy" accounts.

former_member182378
Active Contributor
0 Kudos

Moazzam,

For the particular type of movement of goods, the correct movement type needs to be setup (in schedule line category) SAP does not have any inherent intelligence to permit or restrict this looking in to the item category or the sales document type. Take an example of third party sale, CS should not have any movement type, but you could assign a movement type there.

Please check the MMBE update, the stock should increase in unrestricted because of 653, even though the process is OTC (forward cycle).

What are the item category and schedule line category used by you?

The process design is setup by the document category, for order type, forward cycle with C and return cycle with H.similarly for delivery and billing process steps too.

TW

moazzam_ali
Active Contributor
0 Kudos

Hi TW

Thank you for responding so quickly

This is order to cash with C category of document. Item category is also with Debit indicator in it.

You are right that SAP does not have any check or link between movement type and item category settings. In my opinion it must have a link or check. If we use movement type 651 and assign special stock indicator E in sale return item system gives error when we PGR the return delivery. If we do this same with movement type 653 system won't give error. Here system checks this link but on a later stage i,e PGR but I think system should restrict at the time of assigning movement type to schedule line or at the time of assigning schedule line to item category.

Thank$

former_member182378
Active Contributor
0 Kudos

Moazzam,

In standard SAP there is a nomenclature for schedule line category C for order, D for returns and maybe with coding some movement types can be permitted and some restricted. But many companies work with custom schedule line categories and custom movement types, in these there is no nomenclature for permitting and restricting.

I agree with you that there could be more intelligence created but these are building blocks and these need to be arranged in a coherent way.

One can have order type OR and determine REN item category to it. Now you could think of having some intelligence there...but where do you to draw the line? And this will only be beneficial for businesses using standard objects which has its own drawbacks.

TW