on 2019 Sep 03 4:23 AM
Dears,
By standard design of SNP, which Purchase Order document types are included when I activate the CIF model for purchase orders?
Secondly in which key figure should I see it? i.e. what category group and category does e.g. a Purchase order document type PF1 or SBC map to?
a) Distribution Receipts / Demand Confirmed
b) Distribution Receipts TLB Confirmed.
Thanks
Amit
Request clarification before answering.
Thanks Rupesh,
These PO's are not blocked documents in my case. The case is that of external procurement from a vendor abroad. That vendor needs profoma purchase order with value $ and quantity. So the user creates the PFI PO document type to effect this. The supplier than sends the goods as per this PO. This is a certain supply source.
In future we would like to convert purchase requisitions created wrt an inforecord to create the PFI PO document. That is the process we are trying to implement. For this to happen the PFI PO (among other POs like NB, SBC, STO etc) and PR BOTH should be CIFd to APO (notice there is only one integration model for both PReq and PO). The PO is created in ECC but the Preq is created in APO. Without considering existing confirmed supplies we cannot plan such purchases. The reduced PReq then updates APO. or it is also possible that these Preqs are deleted in ECC by the users once the PO is created. They just need an idea how much to buy and when to buy. APO is supposed to tell them that subject to a capacity restriction we have modeled for this source of supply in APO.
Thanks
Amit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
When PO is created by converting the PR , you will not have this PR in ECC as well as APO. It will be there in EBAN table but not in MD04. As it would be double the supply. And PO should be there in MD04 and RRP3 so I don't know why you want Pro Forma invoice too. May be you can check CIF enhachecment to CIF to APO.
Best Regards,
R.Brahmankar
amit.makkad
Please add all your responses under "Comment" and not under "Answer", as you were not suggesting a solution but sharing additional informations as asked by the member. Also, when you respond under "Comment", it will be notified to the person to whom you were responding but in the case of Answer, the member would not be notified.
Hi Rupesh
Hi Rupesh
The PROFORMA PO with document type PFI is a
Purchase Order. Functionally and technically. It has a number starting
with standard number range of PO...48*. This is just the document type
used to issue the Purchase Order to the external vendor who needs to
make arrangements to ship the goods and get a letter of credit from his
bank and perhaps show it to whoever needs it for whatever purpose. This
Proforma PO shows the precise schedule lines, quantity and precise
amount that the goods recipient (the creator of proforma PO) will pay.
It is a legally binding document and is also used by the firms clearing
and forward agents to follow up with the vendor, gets goods loaded, pay
import duties and other things. Hence it is a Proforma PO instead of
Proforma Invoice.
Then there is a final invoice that the Vendor sends to the
company. This only mentions the amount citing the Proforma PO as a
reference. This amount may be slightly higher or lower than the amount
in Proforma PO. That depends on claims and disputes of myriad kinds that
firms may have.
I see this is quite a normal thing.
Elsewhere they use Proforma Invoice to indicate the approximate amount that the receiving customer needs for a variety of reasons. This does not necessarily lead to placement of an order. So a proforma invoice is a not a document of supply. A proforma PO is.
Moreover PO and Preq has a single integration model. I cannot send PReqs and POs separately from ECC to APO and vice versa. We create PReq's in APO and send to ECC. We expect POs' created in ECC to come to APO. We also expect the PReq quantity to accordingly reduce if PO is created wrt resp PReq. If a PO is created without reference to PReq, we expect SNP to delete this PR in the next SNP run.
Thanks
Amit
Also note that if it is not planning relevant, then MD04 should not show it as a receipt. but it shows. Which means I were to plan this material in ECC, I can consider this proforma invoice PO (if you see table EKKO this is indeed a PO doc category.. so why make a doc type a big deal)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
Below KBA will help to address your query.
1941601 - Non released purchase order and scheduling agreements appear in MD04
SAP Note 189172 is responsible for this system behavior.
As a result of the change in this note, the blocked Purchase Order item and scheduling lines of blocked Scheduling Agreement items are displayed in transaction MD04 and are also MRP-relevant. This means that they are taken into account in the net invoice of the planning run and are treated as unblocked Purchase Orders / Scheduling Agreements.
Best Regards,
R.Brahmankar
Right but apparently it is a document of supply. Actually import from another country via a valid purchase info-record and it is a standard PO document type.
So if I need to get this to APO, I need to force it with an outbound exit?
The irony is Purchase Requisition and Purchases Orders is a SINGLE object for CIF. But planned orders and production orders are distinct. Either I plan based on full awareness of supply - planned and confirmed or I don't. Because to begin with the material is entirely planned in APO.
So why SAP didn't offer to filter integration models by document type? Purchase, Sales, Production...(they should have)
Thanks
Amit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There is PO document type PFI and that is not coming to APO. It is called PO-Proforma Invoice. Its there in MD04 but not in RRP3. CIF model has it. CCR does not show any mismatch. Leading me to believe this document type is not coming to APO. I check all key figures in the standard book we use.
I also checked in RRP2 using system as R/3 but APO does not find any such document. This document has a number starting with 40xxxxxxx
What is happening?
Thanks
Amit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Rupesh,
Thats what I also assumed. It should be all Purchase Order Documents but I do NOT see several purchase orders in SNP. The integration model is active. These are R3 purchase orders. The int model shows the mat x locs for which PO and Preq 'will be' CIFd to APO but I do not see it there. Tried RRP2 and tried all SNP standard books. None seen. No CIF queues. Did CFM9.
What could be the issue?
Thanks
Amit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
CIF of purchase requisitions and orders is based on Material and Plant not on document type.
If material MRP Type with X* planned in external system and you activate CIF IM for PR and PO than all purchase documents are transfer to APO system.
In APO you distribution definition /n/sapapo/cp1 - 21 External Procurement which is also based on location.
New purchasing document (purchase order, purchase requisition, confirmation) is created in APO by CIF integration from R/3 where it determine the document type, also which will be in PPDS application not in SNP.
IMG ---> Materials Management ---> Purchasing ----> Purchase orders -----> Document types ---->
Here mentioned document type, as per assigned item categories will be used for order type determination.
Please refer SAP KBA 1921398 - Create SNP purchasing document by CIF.
Best Regards,
R.Brahmankar
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 8 | |
| 7 | |
| 3 | |
| 2 | |
| 1 | |
| 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.