For the next set of scenarios, it’s a little look back to the PO scenarios. Since purchase order acknowledgements (POA) are essentially the “answer” to a PO it makes sense that the PO scenarios are the road map. I know that the CXML specification calls them a ConfirmationRequest, but I liken them to EDI 856 documents, so I tend to use that description. It seems to fit rather well I think, since you are acknowledging the fact you got the order request and what you will be doing with their order. I also realize it will date me a little, but that what experience is!
For testing purposes I find that if you create the appropriate POAs with the PO tests you will be covering the vast majority of possible scenarios. So we’ll revisit those and what I look for with the POA.
- One line – As with the PO just want to get an easy one out of the way to make sure the connection is being made and that the related PO is being found on Ariba.
- Multiple line – At least 3 lines for checking any line assumptions that make have been made.
- One line with backordered product – The POA should let the client know that while the order was processed, it may take some time. Also makes sure that the a status other than “accept” is working.
- One line with discontinued product – First POA where the full order is being rejected.
- Multiple line order with a backordered product – making sure that lines with different statuses are being processed correctly. Depending on your system this may be the first place where you are specifying allDetail and calling out lines individually.
- Multiple line order with discontinued product – again making sure individual line statuses are processing correctly especially with a rejected product.
Next comes multiple location POAs. Basically, if your system creates multiple sales orders for multiple locations, or really for any reason, then you will want to make sure you are processing multiple POAs for one PO correctly. Again you’ll want to be checking Ariba to make sure the linkage between POA and PO is good.
- 2 location one line each – simplest case just to ensure it works
- 2 location 2 lines each – making sure no line assumptions are being made
- 3 location order – again making sure no assumptions are being made about how the POA is being tied to the PO.
- 3 location order with the same product – this one will probably depend on how your system processes the order. If it combines them then you’ll want to make sure the POA gets applied to the correct lines. If your system doesn’t combine like products, it essentially becomes the same test as the one above.
- 2 location with non-sequential locations – once again confirming that all lines are getting confirmed, regardless of their order within the PO.
Having the Ariba network really does help with these scenarios, because they are essentially double checking your work. If you do it wrong there is no linkage. Once it is correct it helps because the site will then show the line status in the UI along with any messages. For me I usually do the POA checks once I do a good pass with the PO tests. In that way I’m doing even more PO tests and I don’t have to worry about POAs until after I know the orders are processing correctly.
I’m getting through the various CXML transactions, probably next up would be the ShipNoticeRequest or what I call the Advanced Ship Notice (ASN). Unfortunately showing my age once again! I’ll be skipping the PunchOutOrderMessage (Order Quote) as that one is just a collection of line items. After that, I’m not sure. Maybe I’ll start hunting through the DTD to get deeper into the CXML specification. I’ll have to admit that at this point I know a lot about the common uses, but haven’t done much else beyond that and this could be just the excuse to do that very thing.