re-ATP for field catalog update.

[Former Member]

Hi Experts,

How can we update the new field catalog for the existing sales orders & STOs? As part of gATP, we created a new field catalog (for product allocation) and it is getting updated for the new orders or while doing the re-ATP of existing orders (from R/3 side). We are facing challenges while recording the LSMW for ME22N (re-ATP of existing STOs). As per my understanding product allocation do not work with ME22. Is there any other alternate way to do this task apart from going for a custom program?

Regards,

Surya.

[Former Member · Accepted solution]

Surya,

I have never tried to mass re-ATP STOs which are subject to product allocation.  However, the easiest way I know to mass re-ATP STOs in general is with BOP.

Likewise, if you wish to mass re-ATP your sales orders, against the new allocation, you would also create a BOP.

If you have changed your CIF with an enhancement, and you now wish to send additional fields over to SCM for orders that already exist in SCM, you would normally just re-CIF the appropriate orders by using ERP program RIMODINI.

It is not clear to me why you need to re-atp all the orders anyway.  Normally, if you have created a new or changed product allocation, and you need to adjust or rebuild the allocation of orders that were previously confirmed, you would use one of the standard allocation consistency programs.  I would start with SCM transaction /SAPAPO/ATPQ_KCGRP_U.

Best regards,

DB49

[Former Member · Accepted solution]

Hi DB49,

Thank you very much for your reply.

Actually we are adding 3 New Z fields to gATP field catalog like SBU, Customer group etc (to the structure /SAPAPO/KOMGOZ). These new Z fields we are using for product allocations. These values are getting filled during run time of order creation or change mode. For the existing orders... even BOP is not able to update these fields... hence BOP is not able to confirm the product allocations and showing these orders in UNCHECKED status only.So only after re-ATP of orders, BOP is doing the rescheduling/checking as per the product allocations.

Apart from the re-ATP/order change, is there any other way to fill these fields. In my opinion there might be some solution like exit/BADI which can be used during the intial data transfer through integration models.

Hope I clarified my requirement. If not please let me know.

Regards,

Surya.

[Former Member · Accepted solution]

Surya,

Running RIMODINI should send all required data over to SCM.

Best Regards,

DB49

[Former Member · Accepted solution]

I think that field catalogue is only send after an ATP check

If rimodini does not work, you may try a couple of options:

• Create a legacy that marks the complete delivey indicator in sales order if is empty, or hat it umarked it if is filled. That will force the ATP check. Then reset the fields with another legacy that leaves the fields in is original state

If you do not like this option (I personally don't, but it is easier than the next one)

• implement  user- exit FV45VFZY_USEREXIT_APO_UPDTRIG and assign 'X' to ef_apoupd . That will make that any change in the sales order resends the field catalogue again to APO. Once implemented the user exit, change any other field (for example, max number of deliveries )in the sales order using a legacy.Afterwards reset the value to the field to its original value.

[babu_kilari4 · Accepted solution]

Hi Surya.

As explained by DB49, you need to run RIMODINI to get the data re-transferred from ECC to APO. This program would actually pull out the entire order information including the field catalog development that you had done to consider 3 new fields for product allocation. The reason why BOP would not be able to consider this information is due to the fact that the newly added field information is not stored in APO ( to be precise //SDFIELD DB table is not updated ).

You can also, try to delete the order information using //SDORDER_DEL program and run //CCR to CIF  the data again into APO. But, I recommend RIMODINI over this option.

Thanks,

Babu Kilari