Archive for the ‘B2B’ Category

Thought vomit

Posted: April 26, 2016 in B2B, Family, music
Tags: , , ,

The last couple of months have been a bit chaotic.  From work to home projects to music it seems that while there has been forward motion, there just continues to be an unending number of tasks popping up.  I’m moving forward but the sidewalk is moving the opposite direction under me and keeping pace!  In addition my wife got a new job after 10+ years at her last one.  So my plan is just to puke it all out here quickly as an update.  Hold on, here we go.

Work – If anyone has any experience with manifesting in Oracle, I’m all ears.  It seems like it should be straight forward, but apparently nobody has actually done it before.  Or at least they aren’t talking. 🙂  Between that and XML Gateway I have found a lot of what it is, but not a whole lot of actual practical knowledge of how to make it actually function.

Music – I’ve been taking lessons and that has been great to talk through and learn more about the instrument.  I feel like I am starting to take strides again and move off the plateau I seem to have found myself upon.  So while I have ideas in place for a new EP, I have not spent a ton of time fleshing them out as I try to incorporate what I am learning.  I am looking to get more serious about writing again very soon. If you are on the mailing list you heard a bit of one of the songs.  I went out and saw the Intervals show, which included a ton of artists (Rest Repose, Save us From the Archon, Angel Vivaldi, and Plini).  It was amazing to see such talented artists up close and to feel the music.  I can definitely see a gap between them and where I am, but not so much that is wasn’t also inspiring.  Here is a shot from where I saw the show.

20160406_220039

Home – This winter was not kind to the house.  We had a 25 foot tree blow down, the fence continuously try to fall over, and the usual assortment of yard work that spring brings.  Plus the carpet on our 15+ year old carpet (4 kids & 2 dogs) had to go.  So we got to learn all about the parts of the stairs and how to add skirting so that we didn’t have to pay for 48″ (they come in two sizes, 48″ and 36″) worth of board for 38″ of tread.  Though I have to admit I think it will look pretty good, it is taking awhile so I don’t ruin anything.  Each tread is $30 and that was inexpensive!  Here is a peek (not sure why it went sideways, it isn’t like that on my PC).

IMG_20160423_131223

Office/Studio – I had last posted about the studio retrospective and course as soon as I posted that I ended up changing a ton of stuff, including building out rack space on my desktop.  Between this and the house project I find myself doing more woodwork than I ever thought possible, but I am finally getting better at it.  It of course started with a Youtube video of a desk I didn’t know existed and another Youtube video of an alternate monitor arrangement.  I just finished the left rack, so now you can get an idea of what it will look like (picture them painted black).  Switching to two SSD drives and an upgrade to Windows 10 meant a total rebuild of the PC software.  Changes everywhere!  Here is what it looks like from my perspective.

20160426_000158

There you go.  3 1/2 months of life in 5 paragraphs!  Now maybe I will be able to finish off some of these projects…

Testing Ariba POA Scenarios

Posted: April 14, 2009 in B2B
Tags: , ,

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.

Testing Ariba Punch-out Scenarios

Posted: March 15, 2009 in B2B
Tags: , ,

I’ve finally had some time to work on the punch-out scenarios.  If you’re not familiar with what a punch-out is, it basically is a way for suppliers to give buyers real time catalog information without the hassle of catalog file going back and forth.  How real time is that?  When a buyer is interested in making a purchase a punch-out session is initiated and the suppliers punch-out site comes up.  Your site essentially is the catalog.  The end result when the buyer is done shopping, a quote sent back to the buyer for them to be able to turn it into a PO.  I’ll tackle the quote, or OrderMessage in cxml speak at a later time.  For now here are my punch-out scenarios:

Create punch-out session – like the PO scenarios this is the best one to start with as it is the most common and if this one does not work, there is not much point in going on.  With it you want to make sure the site comes up and is shoppable.

Inspect punch-out session – want to make sure that nothing can be edited in the cart.  No addition, subtractions, or quantity changes.  You also want to make sure that the buyer cannot navigate the site in other ways, like browsing products.

Edit punch-out session – want to make sure that items can be added and removed from the cart and that quantities can be changed.  This means the site must be navigable.

Create punch-out session with product specified – this is the same as the first scenario, but instead of a generic landing page, you should be directed to the detail page of the product specified.  Part of this should be what happens if a product is specified that does not exist.

Again the important part here is that both you and the trading company can feel confident that the system works for the expected scenarios.  Since Ariba does not keep track of these documents it can be even more important.  If your trading partner cannot even start the buying process they cannot buy your product.  Am I missing anything from these scenarios?

Testing Ariba PO Scenarios

Posted: March 10, 2009 in B2B
Tags: , ,

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?

Testing Documents with Ariba

Posted: March 8, 2009 in B2B
Tags: ,

I’ve seen a lot of stuff about how Ariba can help you control your spend and how great it is for managers to see the information about where they are spending money.  What I haven’t seen is how Ariba, and by extension CXML, can use technology to help actually drive down the cost of transactions.  More importantly, given that automation should be the end goal, where is the documentation for helping people understand better what makes a good implemention using a solution with Ariba/cxml.

Yes, there is the users guide.  That does provide insight into what is cxml and how Ariba does use it.  However, it seems weird to me that there doesn’t seem to be any real worlddocumentation or best practices around how one should test the various document scenarios to ensure the system is solid between Ariba and the supplier/buyer.   If you’re constantly troubleshooting, it really isn’t saving that much money and you are just annoying the buyers.

I see the basic document path like the following:  punch-out -> quote (order message) -> purchase order -> PO acknowledgment -> ASN -> invoice

Question that I’d be very interested in seeing some answers would be along these lines. I realize these are open ended but I’ve got to start somewhere.

As I’m doing an implementation what are some specific concerns with each document?  What are the common pitfalls?  How do I articulate that I both understand those pitfalls and my system can handle them to my next trading partner?  How do we both know when we’re really ready to move into production?

In the next little bit I’ll be trying to throw out what answers I have and maybe it’ll start something.