Crossover storyline in Item Description

Diamond has more frequently included storyline data or crossover codes in the item description field in the last few months. As this "pollutes" the Item Description field so that it is not the same each month, it cause these comics to not be found during the Auto-Pull process of CBPF. There are a few ways to handle this in CBPF, but I did it a new way this month which seemed to work well so I'm passing it on to you.

This month there were a plethora of Batman titles not found in the Reconciliation form. So I noticed at the bottom of the Reconciliation Form that Batman was titled as 'BATMAN (FOE)'. I went to the Diamond All form and typed the following in the filter fields at the top of the form

1. 'NOV08' in the First BatchNo,
   
2. '(FOE)' in the Item Description
3. clicked the Item Description Contains radio button.
4. click the ReQuery button
   

This limits the results to the November Previews, looking for the extraneous info which I want to get rid of from anywhere within the Item Description field.

From this point, you simply click the mouse pointer in the Item Description field at the end of the '(FOE)' and backspace over the '(FOE)'. It is important to remove the space in front of the '(FOE)' also. Do this for each offending record (row). Note: you may not want to do this for TPs, T-shirts, etc.

At this point you have the file in the format which Diamond used to use. Close the Reconciliation form (if you haven't already). Then you can return to do button '1. Find Monthly Items' over again. Do button '2. Reconcile Not Found Items' again and the items which were not found previously, should now be found. Remember that button one can be done multiple times, so if you make corrections in the Diamond All form, button one can be done again.

Removing the '(FOE)' from the Item Description field has the drawback of you not being able to search for all '(FOE)' items quickly within the Diamond All form. However, you can accomplish the same search by using 'faces of evil' in the Previews Description filter field. This searches the Previews catalog data for the crossovers. You must import the Previews DB file each month from Diamonds' website to be able to search the Previews Catalog data.

HTH,
James

If you come up with a tip you'd like to share with the CBPF community, leave a response here, or better yet, write up an article like this one and I'll post it here. Make sure you are very clear on each step (not everyone is as smart as you are). Also, proofread what you've written, before sending it to me. I may edit the article before posting if I think I can make it more clear.

The Diamond Extended File Format Fiasco Part 2

Here is a summary of events after a mammoth posting of 53 messages on a forum. (In this blog the word "Diamond", is referencing Cheryl Sleboda. She was the voice of Diamond to the technically minded in this matter).

Diamond announces a format change to its weekly extended format file to be implemented in 3 weeks.

I and another software programmer (or two) quickly scramble to do damage control, ask clarifications, and respond with suggestions.
Diamond responds with a 3 week postponement before implementation, for a total of 6 weeks between announcement and implementation.

The change to the file takes the Discount Code (which is attached to the Item Code) and makes its own field from it. The new format is actually proper database design. The problem is that hundreds of stores are already using it the way it is. The new format doesn't provide any new data, only the same data moved over a few spaces. The format is what is known as a .csv file, meaning that there is a comma separating each piece of data.
The old format looks like this -
25,"APR080190D ","BATMA (etc.)
The new format (I think!) looks like this -
25,"APR080190","D","BATMA (etc.)
Same data, insert a couple of quotes and a comma.

These are some of the brainstorming suggestions made to Diamond, and the responses given.

• Produce a test file of the new format so that software can be tested using the new format.
• Diamond said it wasn't possible. (This is either a lie, or Diamond should upgrade from their Commodore 64s, Vic 20s, TRS 80s, Altairs, and whatever else they are using).
  
• Instead of inserting the discount code field in the middle, and shifting all other fields over one, place the discount code at the end of the row. This serves a couple of purposes. First, the fields didn't change location, therefore some software in the field may continue to work without modification. The second advantage is that the field order between the regular format and the extended format files stays the same up to the point that there are extra fields which is what makes the extended format entended. This would allow software to be file agnostic, not knowing which file is being imported, but importing either because the fields are in the same order. The next problem is that there is no way for a store to see their setup on the Diamond website or to make a change between the regular and extended format (or vice versa). Therefore, when programs begin to break, it'll be speculation as to which file is actually being received from Diamond without opening and looking at the file (which I assume many store owners are hesitant to do, and wouldn't know a csv from a xml file). Up through CBPF 1.10, I've been able to import either file without any kind of setup options being set. This is a good thing as it eliminates some of the possibilities for errors. With CBPF 1.11, I've now added a checkbox in the setup to choose which file format you are importing. This is just one more thing that can be accidentally set wrong or changed.
  
• Diamond refused - No explanation given, no counter suggestions made as to how to deal with the problems.
• Produce both versions (old and new) of the extended format file for a few weeks so that if there is a problem, stores aren't hung out to dry. If the file format turns out to look differently than thought by the programmer, or if Diamond incorrectly generates the files, there will be about 3-4 days for every piece of software being used in the country and Diamond to get things corrected or stores aren't going to be generating their pull lists on Wednesday.
• Diamond refused - no counter suggestions made as to how to deal with the problem.
  
• Someone (not I) suggests that Diamond may be doing this to break others programs and sell more of their own, since the ComicSuite was rolling out the door. Diamond is offended, several moderators jump in, and the thread is closed to posting. It was better than a cage match.
  

Who knows? Maybe all will go well. Unfortunately computer programmers and users have to assume that things will break and have a plan of action in place before hand. I'm at a loss on what the plan of action is in this case if something doesn't work

At this point I'd like to acknowledge my disagreement with the method which Diamond chose to release this file change.

I'd also like to leave you with a definition by Abrose Bierce.
ACKNOWLEDGE, v.t. To confess. Acknowledgement of one another's
faults is the highest duty imposed by our love of truth.

James

New Diamond extended file format

This blog is in reference to the new extended file format which Diamond is releasing June 2008.

This is the announcement from the Diamond Daily.
*****************************
Important Announcement Regarding Upcoming Improvement to Extended Invoice Data Files

Acting on retailer suggestions, and effective beginning the week of June 1, Diamond will begin separating the Item Code from the Discount Code – which will now be noted in its own, separate field – in the extended versions of its weekly Invoice Data File.

Once this improvement is implemented, all additional fields in the Extended Invoice Data File will shift one space to the right. As a result, Diamond customers who utilize the Extended Invoice Data File are advised to adjust their inventory systems accordingly before the week of June 1.
*****************************

This response was written by me and posted at a forum for software developers who use Diamonds files in response to the previous announcement. The purpose of informing the CBPF users is so they will have a heads up on what will happen in June.

-------------------------

Cheryl,

Does this change accomplish anything for any of the readers of this forum? I'm sure all the programs out there have already made the correction within their software. Who requested this? How can making this change for two stores who are writing their own software, but causing problems for myriads (100s?) of stores which already have their software written, be a good thing?

If this was in the works before this forum was set up, it should have been announced as soon as the forum began so that the programmers could discuss the repercussions.

There ought to be a minimum standard announcement period for making file format changes. In reality 3 weeks is not sufficient. It should be in the neighborhood of 3 months minimum. It's possible that Moby, or ComTrac or CBPF or Hijinx has just come out with an update. It's also possible that one of the programs is in the middle of development towards its next update and 3 weeks is not sufficient time to make the change and complete the current updates and test.

It's also inconsiderate to expect a business which is in the middle of making updates to halt software production; go back to the last update; make the change; test; and release an update because of a change like this which accomplishes nothing, then make the change again in the update which the programmer is in the middle of.

The problem I see is that you are making the change to the extended file, but not the regular file. I encourage all CBPF users to sign up for the extended format, but I'm not sure if they have. Currently both formats are compatible from my viewpoint, but the extended provides the user just a little extra. But the new extended format will not be compatible with the regular format, therefore I'm about 90% sure some CBPF users will have problems whether I make the change or not. Am I to begin supporting two formats because Diamond decided to do something which should have been done when the file format was designed? Where are the test files containing the new format which I can use to test an update against?

If you're going to do this, you ought to also make the extended format an option which the user can choose from your site. That way, when a CBPF program isn't working, I can walk them through correcting the problem. The way it is now, they (or I) have to call you and get you to change the file format. It also obscures whether that is the problem as the user can't see on your site which format they are set up to receive.

My 4 cents.

And by the way, I will make more money from this change, but I'm against it because it hurts the comic stores. Their job is to help customers and sell more comics, not to spend time fighting a computer program which used to work, and now doesn't (and the change serves no purpose).

If this goes through and I don't have time to make the change and adequately test the update (which might be hard without a test file - Cheryl would you be able to provide one?), I'll have to post on my website to contact Diamond and request removal from the extended data file format to correct the problem. I know how many paying users I have, but I have no idea how many are using the free version of CBPF.

This comment is not meant to apply pressure. It is meant to inform of the issues at hand involved in this change with short notice.

(heads up) I will post this response on my site blog as a way of informing CBPF users so they know there may be problems in June and what the options are.

James
--------------------------------------------------------------

I look forward to any responses to this post.

Diamond Summit 2008 in Las Vegas

It will be great for the 2008 Diamond Summit to be in Las Vegas. I'll be able to meet several stores which I've only talked to on the phone. It would have been better if they'd kept the Baltimore Summit and dropped Ft. Wayne (but Alliance might feel left out).

If you're going to be there, let me know.

James

CBPF version 1.09

Here are some of the items coming in CBPF 1.09.

1. Override selection of customers on the weekly report (when supply doesn't meet demand).
   
2. Weekly support of e-mail attachments for customers who use ComicBase.
3. Cycle sheet importing capability (from POS system most likely).
4. Cycle sheet form is able to jump to next/previous item or series without exiting the cycle sheet and re-entering from the Diamond All form.
5. Switchboard contains the number of days left to the online order deadline.
6. Ability to send a newsletter without sending the customer and store data in the e-mail.

These are not all of the changes, but a good selection of the changes.
These changes are DONE, so barring testing problems they are a "for sure" change.
If you have input on any of them, please let me know.

I'll be in Baltimore at the Diamond Summit, so look me up if you are going to be there.

thanks,

James Deckert

ComicBook Pull File

Designed by Retailers for Retailers

james@comicbookpullfile.com

785-827-1133

CBPF 1.08 feedback

Some early feedback about CBPF 1.08.

It seems to get better every time so I'm looking forward to an even better experience, although I'm not complaining about the previous program. I go home four hours earlier, three days a week now!

Charlie

Charlie's Comic Books
Tucson, AZ



The Truncate File Names Utility is awesome! Saved me hours of work! Thanks!

From some of my customers about the new email format...


- I love the new format of listing by publisher! Much more managable.

- I like this new format, much easier to see what is comics and other stuff.

- Really like the way the list is divided up now.

- Stacy
Comic Fusion - New Jersey

I'm glad I FINALLY got this version out to you. I just kept finding more to add to it and I finally just had to stop. Keep me informed on how you like the new versions, and if you have any ideas which would help you (and other retailers) out.

James

The Diamond POS system

Good news all comic book retailers!

In the Diamond Dialogue (March 07) issue on page 48 Diamond is announcing their POS solution for its customers. On the face of it, this sounds like great news. What could be better than for your distributor to also be your POS provider.

As the CBPF is not a POS system I'm not in direct competition with this POS system, but it will contain a pull list system which would be in the CBPF territory.

I'd like to list some pros and cons of Diamond providing a POS system.

Pros

1. Probably more consistent data in the files which Diamond provides. It is relatively common for Diamond to change the Item Description for a series from one issue to the next (the most recent example would be Dark Tower, which became Stephen Kings Dark Tower, then issue 3 was titled Dark Tower again). Series code also erratically changes occasionally. There were several titles which this occurred with in the last 2-3 months. The series code is supposed to keep a link to all issues in a series, so when the series code changes, the series is broken. The Diamond Previews on Windows program uses the series code to show the history of the stores ordering for each issue of a series. Another common error is for the issue number to appear in the Item Description field.
2. Seamless integration between the Diamond website and your POS system in the store. As long as they can change/modify/update both ends of the communication, there should rarely be failures. (This however will play havoc with any other system which uses the same method of retrieving data from Diamond. Unless Diamond announces the changes to the retailer community through some standard procedure, which will then partially negate the Diamond advantage.)

Cons

1. The tendency for the operating system provider who is a monopoly (in this case Diamond) to release inferior software because they can (and it's much cheaper to develop than competitive software). This can be seen throughout history by looking at Microsoft. Microsoft has traditionally waited for innovation to happen in the arena of software (e.g. Word Processor, Spreadsheet, Database, Internet Browser, etc.), then they will release their (usually) inferior version which copies others. But since many of us own Microsoft Windows, we will often purchase Microsoft products under the false assumption that it is better than others. However, after several years and many upgrades, Microsoft products become very good products. If Diamond is going down this road, will they commit the resources to continue the evolution of the product?

Questions to ask Diamond before trying out the Diamond POS system. (FYI - I don't know the answers to these questions, so the answer may or may not be in the favor of Diamond.)

1. Is the POS system programmed by the same people who programmed the website?
2. Will there be a dedicated team of programmers which will support (part or full time) and upgrade the Diamond POS system on a regular basis? If this answer is "yes", then why wasn't this done with POD, POW, and the Diamond website?
3. How often can we expect updates, corrections, and enhancements?
4. How long has it been in Beta testing?
5. Where is it being Beta tested?
6. When did development begin as it seemed that Diamond was just in the beginning stages at the Baltimore Retailer Summit 2006. One of the programmers was asking for some basic input just a month ago on the CBIA forum.
7. Why weren't the file formats and protocols for the DPOS made available to the comic book retailer community so that retailers who aren't interested in the Diamond POS but used another system or wanted to develop their own POS forced to wait until Diamond finished their POS? (This question assumes that Diamond isn't using the POW file, which I don't believe they are.)
8. Have the files gone through a normalization process this time? Previews on DOS, Previews on Windows, and the weekly invoice file have elements which are considered poor database design.
9. What happened to Previews on Windows 2.0 which was announced at the Diamond Retailer Summit 2005?

This blog is in no way intended to be a gripe towards Diamond. Instead it is intended to help the comic book retailers be informed. I happily would solicit feedback (both positive and negative) towards my comments. If you know of other Pros or Cons, by all means let the retailers know.

Disclaimer - I would be considered knowledgeable in the area of pull lists, but I'm not very knowledgeable in the area of POS usage. Therefore if I've stuck my foot in my mouth at some point above, please correct me gently.

As I see it,

James Deckert