on 09-01-2011 3:55 AM
Hi Gurus,
We have an issue wherein when TLB is executed, transfer orders are created wven if there are no stock.
The settings in ATD Receipts is it should only consider unrestricted use stock. However there are open Purchase orders in the past which are not yet received. Does this cause the system to propose TLB Orders?
Thanks,
Raymond
Raymond,
If the category for purchase orders is considered TLB-eligible then past-due PO's will be included in the calculation for ATD Receipts. I know you've said that the settings are such that ATD Receipts will only include unrestricted stock, but I'd challenge this notion in your case. Check the location master and the product master, as well as the Planning Book itself to determine if ATD Receipts is indeed including only "CC" or may it also be including Purchase Orders or "BF"??
From SAP help regarding ATD Receipt category group: You can specify this field in both the location product master and the location master. When Deployment is carried out, the system first checks whether the category group has been specified for the location product. If not, the system checks the entry at location level. If no category group has been defined for the location either, the system uses the standard category group ATR.
So, if nothing is assigned in the product-location or location master, then ATR is used (which by standard has BF). Also, remember that the product-location master "trumps" the location master per above.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The system should not consider PO's as available at all, past or future, if the ATD Receipts category group excludes them. So you are saying that you have a category group assigned in the location master and NOT the product location master? What does the ATD receipts KF say in the planning book? Does it have the quantity from the open PO?
Deployment and TLB will not generate an order unless a value is present in the ATD Receipts key figure. SOH is not relevant to the Deployment/TLB calculations. The reason I was asking if the PO was included is because if PO's were actually being considered as available-to-deploy, then the quantity would appear in this key figure. The standard Deployment heuristic and TLB run processes consider this key figure as the "source of truth" for this information.
The only other possible conclusion is that stock was present during the run and has since been removed/decremented. Or, that a calendar inconsistency caused the TLB to double-count existing stock. This can occur when deployment and TLB are run inconsistently (for example, TLB doesn't "respect" the period factor whereas deployment does). If this is the case, you can run at the daily level to mitigate future inconsistencies.
Hi,
Thanks for the inputs. We are running the deployment daily. However we have a period factor of 0.5.
Based on the goodsmovement in ECC, there is a stock on August 15,2011 which is monday(Start of the weekly period). The stock is 1,350. However on the same date, Aug. 15, the stock is already moved to a different location (DC). SO my stock is 0.
when the deployment is run on Aug. 16 (Tuesday) and Aug 17 (Wednesday), 2011, the log says it has an ATD (Available to deploy) of 1350.
However, the deployment run on Aug. 18 (Wednesday), the ATD is 0.
There are no goodsmovement from Aug 16 to 20 as per the material documents.
I do not know if the period factor affects the Deployment run.
Thanks,
Raymond
Two possibilities I see. Since this doesn't seem to be occurring in a "loop" even despite the continued existence of the past-due PO, the stock GI that was recorded on 8/15 was most likely not communicated correctly to APO. Option 1 is that this was a genuine inconsistency in CIF, later resolved by running the /SAPAPO/CCR reconciliation process (perhaps there was a blocked queue, etc.). Or Option 2 is that the integration model for stock was deactivated for some time due to an error in refreshing CIF or regen/reactivate via RIMODGEN and RIMODAC2.
Once again, sorry I'm not able to provide better detail but those are my best guesses given your fact-set. Hope this helps!
User | Count |
---|---|
13 | |
4 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.