Transaction set variants in the Amazon 850 Purchase Order

My goal isn’t to come up with a solution, but to understand the problem. I’ll take an implementation guide that describes some transaction set variants and then I’ll try to come up with a strategy to deal with them. I don’t want to build a full implementation; I want to get a feel of what it takes to handle this in practice.

Understanding the variants

I don’t sell directly to the consumer; I leave that to Amazon, so they need my product in their warehouse. That’s why they send me an 850 Purchase Order. How do I know that I have to deal with transaction set variants? The implementation guide from Amazon doesn’t contain any preamble. It goes straight into the default information.

That generic description of the transaction set doesn’t do me any good. Fortunately, I know to keep an eye out for transaction set variants, thanks to my colleague. The first segment of the transaction set (I’m not counting the envelopes) seems to contain what I’m looking for.

If I understand correctly, with a normal order, Amazon buys a product from me, puts it in their warehouse, and can then do whatever they want with it, although presumably they’ll try to sell it. With a consigned order, Amazon puts the product in their warehouse, but it still belongs to me until Amazon sells it. At that point, Amazon handles the transaction with the customer and they forward me the money, minus a transaction fee they keep for their work. If the product doesn’t sell, that’s my loss and Amazon can ship it back to me to free up some shelfspace.

Handling the variants

Now that I have an idea of the variants, I need to decide how to deal with them. That’s not a technical issue; it depends on the business needs. Since this exercise takes place in a fictitious context, there’s no one I can ask questions about the business. No matter, I might not be able to get answers, but I still should be able to figure out the questions.

A rush order may be a simple boolean flag in the system, or it may have to kick off its own, separate flow, depending on how the business operates. Does the business need me to do something special in this case? If there’s a separate flow, can we kick that off based on the simple boolean flag? That seems reasonable to me and it means that we can map the message regardless of the impact a rush order has on the business. I might need to route it somewhere else if there’s a special department handling rush orders, though.

The considerations for a new product introduction are similar to those for rush orders. If there’s a special flow, can we kick it off based on a boolean flag? Because that would make mapping simple. If we need to inform specific people of a new product introduction, we can do that based on the flag as well.

A minimal mapping

I’ll come up with my own custom target JSON based on the implementation guide. Yes, this is cheating, because typically you have a defined JSON shape you need to map to, but the principle is the same.

Inspector doesn’t like that single segment very much. I guess I should tell it which transaction set it’s dealing with.

Hey, I just noticed that the Amazon implementation guide provides sample data for each individual segment, so I didn’t have to type it by hand. That’s marvelous.

The purchase order is trivial to map, because it’s a one-to-one copy of a specific field.

The date isn’t much harder. It just requires a minimal bit of conversion, because I like dashes in my date.

Will the flags be more challenging?

Now that I know that, the mapping expressions for the flags will be simple.

That’s it?

The whole exercise was less of a hassle than I expected to be honest. Granted, I made things easy on myself by assuming only a single transaction set in the EDI message and by mapping only a single segment, but why would I want to make things hard for myself?

That’s not the real reason it was easier than expected, though. The real reason is that the variants of the Amazon 850 purchase order are all pretty much the same. I was able to handle them with nothing more than two flags. Most transaction sets that have variants will be more difficult to handle. If you’re disappointed by the lack of suffering I had to go through this time, then you can take comfort in the fact that the next transaction set with variants is bound to cause me more of a headache.