Ad-Hoc Technology Committee Meeting
Nashville Renaissance Hotel – Jazz Room
June 22, 2008
Present from NAMM: Dan Kessler, Pat Martin
Present from Committee: Paul Ward (Roland), Amy Pearson (Sweetwater), Maryanne Delmundo (Guitar Center), Jerry (Hal Leonard) Ryan (West, Robin Walenta (West Music) Eric Cranley, (Willis Music), Pat Murphy (Tri-technical) …… (Korg USA) Jason Berry (Musicians Friend) Bill…. ( )
Group discusses tentative agenda. Is there a need to change any items on the agenda?
Use present agenda.
Party Document
Review the party document to date to assure consistency. (Paul’s draft is on the screen.)
Goal is to take notes all have brought to discuss this document.
Structure of document (XML) – does this look appropriate?
GLN from UCC ??? OR NAMM ID number?
We need to standardize to one set of numbers. Set a standard.
First is UCC number and if you do not have one….use NAMM ID Member as base number.
NAMM1(location #, 1,2, etc) ID. 000# (identifying unique #).
Group wants to get a volume of small dealers to use this.
Distributors do not have GLN numbers. Mfg. has to assign GL numbers to Distributors.
NAMM numbers are 12 digits, with leading zeros.
Group wants to see both document with NAMM ID, and UCC used.
Expense to secure a GLN number from UCC is approx $5K, or based on dollar volume.
Dan brings up the UCC registration page from the web site. People can register their GLN on this site as a directory of GLN/Company assignment.
***NAMM could capitalize on this as a Membership tool for NAMM.
Large companies would have GLN
Others would be NAMM Members
Let’s not worry about smaller non-Member dealers at this writing.
Is there a purpose for keeping the leading zeros in the NAMM Number? Yes, for consistency.
Do we refer to field as GLN or Trading Document Number? Specify primary number request as GLN #)
Specify as ID NUMBER? Leave as is for now…possibly revisit later.
When we reconcile documents…we will need to reference document field names.
Let’s decide what needs to be in the document vs. what we name fields.
Do we just want to create an address type that standardizes itself for consistency's sake?
Either works well according to committee.
Add “location(s)” under location… Billing and Shipping locations may be different.
Explain the hierarchy and definition fields in the document.
REMOVE hierarchy and CHANGE definition to description.
Do we leave DBA in? Yes agreed that this should be left in. Yes, leave it in, but make it optional.
Do we need any other information on this document? Email addresses – Fax numbers…web address???
Guitar Center needs to see who the sender and receiver are on the Party Document. Discussed that this could be addressed on the “envelope” or other transaction document and not on the Party document.
Discussion on effective dates…reference to the address. Do we add a date field to location entities? Need Start and End date fields…but make them optional.
Drop all corporate address information…need only ship to address. (not a high priority to address). Transaction documents define the business transaction only.
Add above “Trading Partner” line item that we add Document Revision/Version date
Remove “currency code”. (leave or remove?)
Is the Party document we have now a good basic start? No disagreements in room.
Lunch Discussion
Let’s get vision or mission statement from THIS committee to push out to the industry the specific focus of this committee, electronic documents. One for the current project and one for the long-term committee mission. Use NAMM Marketing component to get messaging to industry.
Possibly recorded testimonials for placing on the web site.
Dan talks about rotating folks off the committee who are not active participants and replacing them with people that could participate more frequently. All committee participants agree that we cannot grow the committee (not to become too large to avoid accomplishment). We lost rep from Kaman and look forward to replacing that spot with a representative from Fender. Robin suggests we include Bill Mendello in this discussion. Forward any suggestions to Dan Kessler.
Data synchronization…Guitar Center is currently in the process of selecting a master data communications solution. Going to happen …will be a consolidation of efforts between Guitar Center and Musicians Friend. Will be up in early 2009, roll out (pilot program) with continuous updates. Vendor portal? Much input on concepts. Select vendors may have entire product line on the site…all data in one place. GC/MF will host data. Dan indicates that this should try to be a collaborated effort for GC/MF and to industry. Need to be easy to understand and use for all.
Next Release
Looking to tie this in to Trade Press and involving industry. Later in the fall, announcing what will be announced in January.
Part of the committee work needs to focus on engaging the community.
What do we call this Next Release? What will it include?
If we get our four documents ready, perhaps we should discuss the “how to” implementation tools and the marketing aspect of it.
January 2009.1 could be the Next Release.
Need all to keep notes of what is not working as we move forward to implement…updates.
Need repository on web site to log all of these.
Dan offers up the outsourcing of the development of an SEK. Use UCC as structure document. NAMM will investigate the cost and see if NAMM is willing to offset this expense.
NAMM Members could “brag” that they are NAMMb2b certified. (Guitar Center indicated that this would make it easier to do business with these customers.)
ADD to FUTURE MEETING Agenda’s ….Mission Statement development/
Reviewing and Tweaking
Amy began using column A to define the use of the field.
Field names…how many are required.. and.. legal values. Three Tasks we need to resolve.
One of the large issues they wanted to work with was “sets”….like drum sets. Furniture industry had the same difficulty with sets (tables/chairs). GC indicates that they don’t use sets…but build “kits” with individual pieces or product.
Amy lists multiple fields that have an inconsistency in the field naming …not using the complex element.
We revisit the invoice document to review the source. Example: address. (instead of supplier address). Bar code IDs are inconsistent. (create a not so flat item file?)
Discuss descriptive term…bar code. We change to “Bar Code Type”
Group weighs in on renaming of fields.
Invoice is fixed.
We continue on PO for remainder of afternoon. Decision is made to spend additional time on clarifying document field names prior to starting detailed acknowledgement discussion. All agree to change GLN Party ID to Party ID or Party ID type.
Tonight (Sunday night)…Dan will create a repository for the group documents.
Amy reviews on second day the changes added and the description information on the document . Suggests that some areas are inconsistent and that the documents should be routed to all and reviewed at their convenience for inconsistencies and “discussed” prior to the January show. Change on invoice the buyer’s description to supplier’s item description.
How about creating a master sheet on what each detail is called for easy reference? (Pat’s suggestion only)
Amy brings up PO discrepancies with wrap arounds on the PO.
Detailed Acknowledgement
One of Dan’s action items was to find old notes. But located nothing.
Did Dana take notes from this meeting? We will check when we return back to the office.
Does the acknowledgement match the invoice…or is it a stand alone document. Hall Leonard uses to validate order or reject detail. Acknowledgment detail…Acknowledgement detail and change…Acknowledgment detail and rejection.
Acknowledge each item and indicate if they are on backorder or available.
Detail level on acknowledgement? Is this a one-sided document? Have to review business process vs. purpose of this document.
How often is the entire order accepted as transmitted. GC needs a response for every update to PO. West Music requires a response within 48 hours…otherwise it is considered a contract. What is supplier response? Amy guesses that 50% of their POs are fine and others face discrepancies…price, quantities, etc. Per Robin Walenta, average discrepancies is 8.6%
Focus on acknowledgement and not PO change.
GC provides BMS on how to respond to problems, along with Sue's case description.
Respond to quantity, unit of measures…verifies the line transaction. How do you articulate in the document short shipments.? NO…simply and acknowledgement of the items ordered and the price.
At the item level you would have 4 (four) codes that are ACCEPTED, MODIFIED or REJECTED and MODIFIED DETAIL W/CHANGES ONLY. Should there be combinations of them. What could change….price, quantity…? Combinations?
Amy provides a mock up. PO accepted as is….if there is a change, need a node for all the possibilities of everything that could have a change to it. (Let’s get a copy of this document from Amy to post on the repository).
GC suggests that we make this Optional.
Header level have code for modification of term codes.
Need “Change codes” at all of the levels.
Accepted (no detail) Modified (show all) Modified (show changed), Rejected. (suggested by Amy)
Did we develop the shipment terms table?
Hal Leonard has tables of reasons for rejections. MORE CODES needed for reasons of rejections.
The retail representation need to know what is being shipped and when it is being shipped.
Ship date is estimate only…but not confirmation of shipping.
Let’s go through document and discuss the placement/level of codes for the acknowledgement. (Amy has sample document that we should get from her and place in the repository)
Need a two-step process…………
Receipt of PO generates a total acceptance or rejection of PO. (PO is essentially and inquiry)
Once PO is accepted, then acknowledgement is generated???????
Hal Leonard has separate codes and standards for each trading partner.
Should manufacturers fill partial orders or changed order or changed pricing prior to final acceptance? All agreed that NO is a appropriate. If the order is not perfect…it should not be processed.
Since Internet connection was sporadic, we move on Monday to using a single copy of the document (Amy on thumb drive) while group reviews on screen for detail.
We move to the Acceptance PO document…
GC is switching to Vendor Net
Acknowledgement needs to feature estimated ship date BASED on final acceptance of PO.
Field document needs to feature estimated ship date???
Supplier ID should be an optional field.
Add PO order date to the acknowledgement (Amy added)
Add begin and end ship dates. (Amy added)
Add buyer name in the acknowledgement/human name (Amy added)
Should there be a time stamp in the document? (Amy added)
Version, Buyer ID, are these covered in the document? Do they need to be?
Dan will send all of these current documents to group via email this week.
Eric Cranley agreed to …..????
Minutes