Author Archives: Troy Lunt

To Web Services and Beyond…

The recent smash hit, Web Services, has played from coast to coast on the business “Hypo-Tronic Gizmo” for several years now.  One might even suggest that if DJ-Bob had a weekly Top 10 countdown featuring the most prolific debuts in business-hype history, Web Services would be at or near the top (clouds are also floating fairly high these days).  This Hypo-Tronic Gizmo (or HG device) is extremely unique because it plays only what the listener wishes to hear.  For top-level executives the device delivers a simple, “Cha-Ching”.  For mid-level managers it renders a more subtle, “Here we go again”, reprise.  But, for those in the trenches – the technical implementers and end users – it screams, “Fire in the hole!”  Yet, surprisingly, to those who have lived through the budget-blowing and non-committing trends of the past, Web Services has actually delivered a Certified Platinum hit that many advocates had hoped it would achieve. Continue reading

Stay the Course and Avoid the Bling

I was recently driving while listening intently to a radio program as a woman described her inability to survive each day without her Blackberry.  I recalled how years earlier I was able to enjoy my twenty-seventh consecutive year of attending the first round of NCAA’s “March Madness” because I had implemented similar survival techniques and had email available at my fingertips.

This year I returned to the phone outlet and found my Blackberry to be far outdated.  There were phones with a “bling” for this…and a “jingle” for that.  These were electronic office assistants that also doubled as high quality cameras.  Storage capacities were available that rivaled hardware ten times their size, perfect for catching that otherwise useless video moment.  As if my favorite 250 songs weren’t enough, I had an option to carry them all.  I was certain at some point I would be approached by a stranger asking if I might just have Tiny Tim’s, “Tiptoe Through the Tulips” available for immediate play. Continue reading

Assessing the Intermediate Database

The types of databases employed can often determine whether a secondary database is necessary.  This secondary database is typically referred to as a staging or intermediate database, because it resides outside the base application.

Should the company “Enterprise Resource Planning” (“ERP”) application support all required business transactions – both inbound and outbound with customers – then the need to have an intermediate database is lessened.  However, the company ERP might provide support for “core” business transactions but might be limited for “extended” business transactions.  This creates a business problem – where to store the extended business transaction data. Continue reading

Using Spreadsheets to Automate Supply Chain Integration

Many Business-to-Business (B2B) relationships choose to initiate transaction exchanges at the point a buyer sends an electronic purchase order to a supplier.  This Purchase Order is often in the form of an EDI 850 document.  This Purchase Order often then triggers the supplier to send the buyer an electronic Invoice (EDI 810) and an electronic Ship Notice (EDI 856), for the goods ordered.  This “business process” represents the minimum number of transactions required to maintain this successful model.  Moreover, there exists an abundance of data in support of this process, although it may often fail to be included in the production model.  The cost of integration may exceed the return and, as a result, this data either isn’t shared between the two organizations or it fails to be integrated to a usable state.

For example, at the suppliers’ front end is Catalog data (EDI 832).  This provides an opportunity for a supplier to identify the attributes of their products to the buyer, creating a more-efficient ordering process.  At the buyers’ backend is Product Activity / Point of Sale data (EDI 852).  This provides an opportunity for buyers to report their sales activity, aiding in the ability to forecast the production of goods.  While this data is not essential to the “Purchase Order <-> Invoice” model, it provides the ability to “enhance” production processes.  Additional transactions, such as Purchase Order Acknowledgment (EDI 855), Purchase Order Change (EDI 860), and Payment Advice (EDI 820), are a few of the many electronic formats capable of improving and furthering the overall business process integration. Continue reading

Too Many EDI Segment Occurrences? Table Them!

The problem: Often, EDI data elements of the same type may occur multiple times.  One common example is “Dates”.  The number of Dates needed (or sent) is generally limited [only] to the number of Dates required by the business application of the party who “calls the shots”.  If the customer expects to retain a trading partner’s business, they will make every attempt to comply with that trading partner’s requirements.  The trading partner might send the supplier Dates such as “Scheduled Shipment Date”, “Expected Delivery Date”, “Cancel Date”, or a host of other possible dates.  The same is true for Reference Numbers, Notes/Comments, Product Item Numbers, Addresses, and so on…they all represent EDI data that could be sent in abundance.  The question is, “what is the most efficient way to configure the EDI system to accommodate these repeating (and sometimes redundant) pieces of data?” Continue reading