Since POs are the main document in the punch-out process, I figured I’d start with that one. The fact that it is also the one I’ve done the most work on so far has nothing to do with it at all. Please keep in mind that while I’m specifically calling out Ariba and cxml in these scenarios, the underlying xml format is not really the focus. I’ve used these for implmentations with no VAN and the EBP xml format with just as good an efffect. What I hope to do is just show that if the following scenarios pass, that I have a certain level of confidence my system will handle what is thrown at it. I can’t imagine I’m alone in doing this type of work.
If you’re still reading, thanks! I’ve broken the PO tests into subcategories to make it more organized and because some subcategories are unnecessary in some implementations. They are: single location scenarios, multiple location scenarios, override scenarios, and exception scenarios. For each scenario I try to set up actual data in a table in my document. It includes addresses and products. That way as the trading partner and I work through them I can keep a record of what has passed or not. By the way, these are catalog orders so we have part numbers to go against. Onward!
Single location scenarios:
- One line order – just want to get the easiest one out of the way. If this doesn’t work, not much point in moving on.
- Multiple line order – at least 3 line items, want to make sure any line rules work.
- One line order with backordered product – want to make sure there are no issue with a product not immediately shipping and it helps verify correct information in the POA.
- One line order with discontinued product – want to make sure a PO in which all lines will be rejected still processes correctly. Also helps verify correct behavior with the POA.
- Multiple line order with a backordered line – verify a product that won’t be shipped immediately doesn’t block. POA information a factor as well.
- Multiple line order with discontinued product – verifying that an invalid line won’t block ordering of valid product. POA information a factor as well.
Multiple location scenarios – because the cxml can differ in these situations as well as the ERP systems behind them:
- 2 location one line each – again setting the baseline
- 2 location 2 lines each – checking that line rules are still in effect even with multiple locations.
- 2 location one backordered line – checking processing and POA
- 2 location one discontinued line – checking processing and POA, I will typically do one with the discontinued product in the first location and one in the second.
- 3 location order – just making sure no assumptions with 2 locations. If this passes theoretically it will process as many as necessary.
- 3 location order with the same product on each line – checking processing of the same product, some systems might combine them on one line potentially causing invoice issues later on.
- 2 location order with non-sequential locations – typically do line 1 to a location, line 2 to a different location, and then line 3 to the same location as the first. Making sure everything gets put together correctly.
Override scenarios – making sure things we have defaults for can be changed by the customer. Will also check the below with multiple locations if necessary:
- Ship method override – ensuring the PO can set the correct shipping method.
- Ship complete override – ensuring the PO can set the correct ship complete option.
Exception scenarios – of course every order comes through perfectly!:
- Duplicate orders – ensure they are handled according to company policy.
- Change/delete orders – ensure they are handled according to company policy.
- City/State/Zip combos – ensure they are handled according to company policy.
- International orders – this might be a stretch to call them exceptions, but depending on the business these might be far and few between. Ensure they are handled according to company policy.
- Custom business rule check – every company has specific rules and quirks that need to be handled appropriately.
Once the trading partner sends in tests and we process them correctly we should now feel confident moving this document into production. It doesn’t mean problems won’t happen, but I’m finding by doing this at a minimum the doh! problems are avoided and the implementation goes quicker and smoother.
To be honest, this is the kind of thing I’m a little surprised not to find in Ariba documentation or at least on the web somewhere. Tons of these implementations must be happening and it seems like the easier they are the faster both partners can get on with the actual business instead of fussing over the little details. Am I crazy or just searching on the wrong thing?