Initial thoughts on sobees beta

I’m trying out the sobees beta on my home computer and thought I’d get my initial thoughts down.

Pros: It looks pretty cool.  This is the first time I think I’ve used a WPF app and the ribbon across the top is very clean.  The amount of functionality they have put in is pretty sweet, along with the different windowing layout possibilities.  The search has some intriguing possibilities, because you enter a keyword and it gets back hits from twitter, flickr, and others.  Another benefit is that this is the first one that gets all my networks in one place (friendfeed, facebook, twitter).

Cons: It takes a ton of memory, though I’m not sure if that’s because it’s beta or not.  The data is confusing as it pulls out different information from facebook than say seesmic desktop and I’m not sure why that is.  Also I’m unable to comment on the friendfeed portion and that is the main benefit of friendfeed.  It could be that I just can’t find it.  One other issue is that media isn’t displayed, so if a photo is posted in friendfeed it shows up as a gray bar instead.

Overall, I want to like it, but there are still some things that need to be addressed before it would become my view into my social world.  Until then it’s sessmic desktop and a browser window pointed at friendfeed.

Testing Ariba POA Scenarios

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.

Music Musings

First thing, and I know I’ve touched on this before, but it is still very irritating.  Why do music labels make it so hard to buy their music?  I have the Zune pass and was trying to get Derek Sherinian’s new album with my monthly allotment.  But alas, my credits aren’t valid for that album.  I can’t even download it to listen with the Zune pass.  So I figured o.k., it’s a new album, I’ll get an older one instead to at least support the artist.  Nope, same thing, though I can download it for listening.  That’s two albums, not songs, albums worth of material I couldn’t buy that I wanted to and the labels continue to complain about piracy and low CD sales.

Second, I’m curious if the labels/musicians check out zune marketplace for listeners of their music.  I’m not sure how iTunes works so the same thing might apply.  Seems like it makes sense that they should.  They could use those metrics to help build listeners or maybe even reward those who like them.  Could be as simple as recognition on the artist’s website or maybe first dibs on tickets when they tour.  Obviously I’m not an insider, but these types of things seem like easy things to embrace and musician and fan closer instead of making the fans work so hard and then berate them at each turn.  End of the rant…for now.

Sonic Assault Studio

Okay so it sounds more impressive than it really is, but still I’m pretty psyched about it.   I’d been playing lots of Guitar Hero and Rock Band with (and without) the kids and I just kept thinking about getting out my real guitar and playing.  Some of the songs are actually easier to play for real than they are in the game.  So around July of last year, I went digging for my guitar in the back of the closet, and started trying to remember the scales and the other stuff I used to be able to play.  It was a blast and even though the fingers complained for the first couple of weeks I kept on playing, trying to get back into some kind of playing shape.  I just played on the guitar without any amplification.

Then around August I decided it was time to hear what I was playing and maybe be able to record.  I didn’t want to shell out for a real amp, which would just annoy the rest of the family.  So I spent 90 bucks to get the Line 6 Toneport UX1 and the “studio” was born.    The amp modeling in the Toneport is great and since I was in the family room I could totally crank up the volume and rock out without driving anyone crazy.  I tried both the Riffworks demo and the free Kristal audio engine as my DAW.  I used both, but not a whole lot since there wasn’t much to record as I was trying to relearn what I’d forgotten from my bass playing days in the the early nineties and figuring out what was possible to do with the Toneport.

At the beginning of October I was still enjoying playing and starting to understand the basics of recording.  I had also experimented with Reaper and Ableton Live as my DAW, but decided that if I were going to get serious and actually buy something, I wanted what the pros use even if realistically I won’t ever be a pro.  So I got a Protools mini in a package that came with studio monitors and a condensor microphone for my birthday.  Yes there are tons of other just as capable DAWs available, but that’s what I decided to go with and it’s been great.  Of course, now I’ve had lots to learn with playing the guitar and figuring out Protools, but that’s all part of the fun.  So now I had the pieces for the studio even though it was in the family room.

Then in January, the oldest daughter moved out.  After the musical chairs with the rooms was settled, I ended up with a room to double as my office and a home studio.  After some cleaning, new paint, and a trip to Ikea I was able to start settleing into my new digs.  The family was a big help with that!  This past month my wife and I have been able to find stuff to get on the walls and start to make it feel more homey.  Now that it’s pretty close to finished, I figured I better have a name, but I wasn’t sure would be a good one.  Then I remembered telling somebody after I’d been to a Tool concert that what I had heard was a sonic assuault on my body.  That stuck in my mind and seemed to be a perfect fit.  Now to the business of actually creating music!

In the raw

You can always check out the rest of the set on my flickr page.

Testing Ariba Punch-out Scenarios

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

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?

Some updates

I’m realizing it’s been practically a year since I really actively posted, so thought I’d throw out some updates.

The Mazda 3:  Still absolutely loving it!  I’ve been relentless in trying to keep it clean, though Seattle winters make it tough to really keep it clean.  Mostly been annoying the kids and the wife about what they do when they’re in and around it.  No, it’s not weird to watch where your feet are going when you get in the car and for me to panic every time they open a door!

The Zune:  Also still loving it!  I have everything we own ripped now and on the Zune.  Gotta be careful though about letting the daughter play Kidz Bop since it shows up on the recently played list.  However, what’s made it even better are the changes to the Zune pass.  I didn’t even think about that until they allowed you to keep 10 songs per month.  I have done more music exploration since November than anytime I can remember in my life.  I know everyone raves about the iPod, but I wouldn’t give up my Zune now.  Extra bonus, the Mariners flagship radio station KIRO has now moved to the FM dial so I’ve been able to listen to the spring training games at work.  Try that iPod!

Testing Documents with Ariba

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.

Car Update

Well, called the financing company today and it looks like they just aren’t wording their letter very well.  My payment is actually going down!  Ok, by 95 cents a month, but hey down is down.  Still a little bit puzzled though, one would think the contract couldn’t be changed either way without a lot of new paperwork.  I guess mine is so new they haven’t got all the documentation on record, so I’ll call next week just to make sure everything is correct.  Craziness.  Back to enjoyment!

New car!

I can’t believe it! Unfortunatley, the old Mazda B2200 truck was getting down to it’s last legs.  I don’t blame it after 207,000 miles it was probably getting pretty tired.  Did some looking/research and settled on getting a Mazda 3.  A week ago Monday the wife and I decided to drop by the dealership and low and behold there it was.  A black mica 2008 Mazda 3 with the spoiler, leather seats, 17″ alloy wheels, and 6 disc changer with the auxillary port.  Some minor negations later and we were driving it off the lot.

I’m absolutely loving it!  Trying to remember how to keep it clean and shiny!  I haven’t been this excited about a car since my first one, a ‘75 Chevy Luv.  I’ll have to post pics at some point, but the weather hasn’t been that great to get it really shiny.

Only bummer is that I just got a snail mail stating the monthly payments were “wrong”.  They should be higher.  Contacted the dealership and they said my original pricing was correct, so I’ll have to contact the financing company.  Guess I’ll see how that goes.

Other than that zoom, zoom, zoom!