Where can I see the Force-Move-out field?

[Former Member]

Hi ,

Can anyone tell me in which table and field the Forced Move-Out. I know I can find the move-out at EVER-AUSZDAT. But I want to know the table and field for forced moved and dunning move-out.

Thanks

Dan

[Former Member]

Have a look at the table EAUSV.There u can find the field OHNEEINZ which has forced move out as one of the reasons.You can find forced moved out contracts from it.

Hopefully this might help.

Thanks.

[Former Member · Accepted solution]

Hi DanRyan,

Forced Move Out is a concept used with the Park Documents.

Table - ECAMIOPRCI

Fiels - XMOVEOUTPRED

Hope this resolves your query.

Regards,

Manish

[Former Member]

Thanks guys I'll that. The field OHNEEINZ looks more plausible to me. I'll try that.

Dan

[Former Member]

Hi DanRyan,

Forced Move-Out happens when a customer has not moved out and Moved in a new customer to the same service. In this case, system will create a Move Out for old customer and create a Move in for the new customer.

This new feature is available when we create Move In through T-Code EC70 (which creates a park Document) and the forced Moved In field is available in table ECAMIOPRCI.

Any doubt, please let me know.

Regards,

Manish

[Former Member]

Thanks Manish. Your answer helped me. That is definitely the forced move-out field.

But strangely my company uses some other logic for the forced move-out. When I go to SE11 and check the number of entries for XMOVEOUTPRED is shows "0". Where the users just gave me a list of BPs which they consider as a force move-out.

Anyways thanks for your help!

Dan

[Former Member]

Hi Manish - Here in our company they do not use EC70. and the table ECAMIOPRCI is not populated.

I checked with an end-user they say a workflow is triggered when a customer calls for a move-in the Customer Interaction Center.

Dan

[Former Member]

Hi DanRyan,

We save Forced Move Out field at installation level. So, if they are sending you a list of BPs, then you should know the installtions.

Regards,

Manish