We are having discussions with XCHANGEIT now about their new systems coming soon. We need shortly to do some tests on the new XchangeIT Link with some newsagents.

To fill in more details on the previous entry, without much warning Fairfax have made some changes to the way they manage subscriptions in Victoria.

These affect

1) The way you set up your deliveries as Fairfax will no longer be supplying an end date for their subscriptions

2) How you order on Connect Online

3) The account numbers you currently have for subscribers

4) The auditing processes you will need to put in place to manage your deliveries.

To help you out we have created a comprehensive instruction guide telling you how to deal with these changes in the PosBrowser system. These you should have now.

If you have any questions about the above, please contact us

Regards

Garth

Sometimes newsagencies are terrible gossipers!

Does our databases with more history cause users slower speeds? No, no and no.

Over the last few days the rumours have been flying around that one of our competitors’ can only store three months of data before the system runs slow. Him being the person he is, automatically assumed the rumour started with us. He then abused me. When I asked him to prove any of this allegation, thinking once done I could issue a denial to fix this problem I was told bluntly “It was none of my business!” Which got me wondering if it is none of my business, why contact me at all? Anyway it appears today he is still upset about this issue as he has decided to blog about it. Like me he wants to put it to rest. In a way I can understand that as it is an important issue.

If you do not understand what is the problem let me explain. Every system has two sections, one is the program which does the work and the other is the database which stores the data. The program asks the database say for stock item “NEW IDEA”, the database takes some time to wake up say X time. It then looks at its index to finds the stock item and then goes to the needed information. Obviously the more information you store the longer it takes to find the information. To simplify the problem say you have one month of history it will take X time to wake up plus Y time to find the NEW IDEA the time taken = X+Y. If you have two months it takes X time to wake up plus twice Y times to find it the time taken here = X +2 x Y. If you have three months it takes X time to wake up plus three Y times to find it the time taken here = X +3 x Y. Eventually in a retail environment where speed is so critical, you might reach a point where it just takes too long. All systems have this problem. Obviously if you are going to keep history you need to lessen Y time to the absolute minimum.

Still I suspect that this rumour has some truth to it as I do recall someone complaining here that to get a decent speed on my competitor’s system they could not store much sales history. I do know a developer that did some work on the same database. He stated that it was good but it was extremely delicate and to get decent speeds they continually fine-tuning the database otherwise the speed degradation was significant as conditions changed. Every system needed a different set up.

Since there are always two sides to a story it may not be the database! There could be many reasons that have nothing to do with the system at all. Maybe viruses or spyware. Maybe this complainer’s system ran slow with more data because the computers hard disk were fragmented and needed a defrag. Another possibility is that it was set up badly at the start with no plans for future growth. Maybe the data was full of errors. Another issue might be that his network was not properly tuned. I do not know all I can say it was the same complaint.

Anyway today I got clients contacting me with comments like “Does our system too slow down like that?” This is why I am writing this entry because obviously this rumour has spread to our clients.

Well the good news for our clients is that our software was designed to store large quantities of data from the start. That is partially why we adopted Microsoft SQL. This database was made by a huge development team. You just cannot match that effort. I could just go on and on about the advantages of this product. It was made to work in a huge organisation like government departments and banks. We are talking of the “Rolls Royce” database. The only product that I think comes close is Oracle. If someone said to me money is not an issue on a project what database would you use, I would say Microsoft SQL.

Another good piece of news because we often use servers, we simply send it to the server and your machine is ready to do the tasks you need now. Also we often scheduled many things of to run automatically at night when no-one is around. Effectively most the daily tasks take no time for you. Lastly as I stated Microsoft SQL is fast. That is why our databases can be so large.

However our old DOS system cannot do these automatic functions. On that we use an old Microsoft database which is extremely fast. On top of that we have added a QTREE. Knowing our clients often have large databases we set everything we could on that system to maximum for speed at the start. We wanted it to run fast.

With an average machine stand alone, a P4 with Windows 2000 with a database of six years of history with a large newsagency. I looked up a NEW IDEA history in less then a second. I did in the cash register sale of a “NEW IDEA” in a second. I processed 1300 customer statements in 15 seconds. I did a run sheet with 200 deliveries in fewer then 5 seconds. I processed an automatic order for a supplier with over 2000 items in fewer then 70 seconds. We do not clear old sales history from a client’s site to get faster processing speed. No-one wants to sit around waiting while the machine churns out, no-one.

So to reassure our clients we have already looked into this issue extensively.

Because of the news corporation latest requirements we have been today working on information sheets for modems and routers.

They are now here in a hardware information section.
 

So we have received a number of support calls from clients on how they should handle it. To help explain it we have put together some information sheets and sent out newsletters to our clients with information on how to handle it.

This work, of course, is important but frustrating. Consider the problem from the newsagency industry say it is just 10 minutes a site to answer this question, that is 10 minutes wasted on one site now multiple it for more sites. One would imagine that some process should be put in place that could automate the whole process.

One such approach would be if newspaper suppliers adopted Xchangeit DDO standard for invoicing. They do not have to use the Xchangeit system just use email. Then our clients, when they imported in the invoices, would have among other benefits a system that could automatically update the price. As long as they import the invoices they would not have to worry about price rises.

The second approach that we are working on is an automatic scripting system. Using these we would be sent to our clients' scrips. If the clients' system allowed the scrips to function these could do updating of item prices but it could do much more such as stop a publication on a holiday, create bumper papers etc. The idea is that the program is as automated as possible. This is similar to what many software packages and some companies like 7-Eleven do now so their operator does as little such maintenance as possible.

What we want is to speed up the back office work while assuring pricing accuracy!

Many of you trying to get into the ACP Emerald Club, will discover that one major factor is sending sales data on time - it is called timeliness on the Dartboard.

The easiest way to check to see what time the sales data is being sent out is, on the machine that sends the sales data, go to the directory:

C:\Program files\POSBrowser\Archive

In this directory, you are looking for the newest files with the extension *.sl2.

If you right click on the newest of these files and select properties it will have a created date and time. It will most probably be about 11:35 pm.

We will then need to check the time that XchangeIT is sending the files back to the suppliers.

If you open the XchangeIT interface, then go View, Configuration

Now click on the Timer tab. You will get the screen you see below (page two). What is needed is a time after the files are created by pos but before midnight for XchangeIT to automatically dial and send the sales data to the suppliers.

If you are a newsagent, do deliveries for News Corp and have posbrowser please do the following immediately. If you have problems in setting up any of this up please contact our help desk AS SOON AS POSSIBLE.

Firstly you should have already the task scheduler set up for your XChangeIT sales data collection this is done so proceed. If you don't please go to the document on installing XChangeIT sales data in the help section in Posbrowser or call our support desk.

Now click on

Customers
Customer Reports
Data Transfer Tab

Click the Automate Values tab and set these options

 

More details are available on request
 

Regards

Regards,
Phil Doensen
National Support Manager
POS Solutions Australia Pty Ltd
Ph. (03) 9597 7222
Fax. (03) 9532 2778

Xchangeit sales data is to us both positive and negative.

It is bad that a significant number of our clients are not sending sales data! There is no technical problem, it is just a high percentage are either not bothering or deciding not to send the sales data. I intend to check on everyone of my relevant clients this week to find out why they are not sending data.

On the other hand, the good news is our sales data is extremely good. It has been described to me as the best. This is clearly an excellent result.

As I stated earlier according to my calculations we now have enough sites sending good sales data that magazine producers could send every day reliable estimated daily sales with just Pos Solutions clients.

That Xchangeit is not doing it now is hurting the entire industry. It should be a priority in the industry to send each one of these publishers free this data AS SOON AS POSSIBLE.

I put together a slideshow of some types of premium chocolates.

I hope you like it.

Let me know if you want to send me some pictures of your shop to merge into this slide show or if you want some original pictures to put into your advertisement.

If you are serious about the book industry, you have heard all this before, so you can probably stop reading it now.

For the rest, please pick up a paperback or hardcover book. Now look at the back cover. You will see a 10-digit ISBN printed near the barcode. This ISBN has been around for over 35 years. As the last digit is a check digit, we have nine numbers. This is no small number, as a billion books can be listed using this. That is enough to cover every book ever published and every book that will be published for a long time. The problem is that these numbers have been divided into many different categories. Some categories are getting full.

A similar problem occurs if you go into a supermarket. Sometimes, what you see is some shelves empty and some packed. What has happened is that in one category, there is not enough stock to fill the shelf, but in the other category, there is too much, and it cannot fit. So some of the shelves are full, and some are empty.

The book industry decided, rather than spreading the numbers from the empty categories to the full ones, to use a barcode, turning a 10-digit code into a 13-digit code. They then looked at their current electronic data exchange standard, BISAC. They quickly saw that BISAC cannot handle a 13-digit number and should offer more information. Also, they noted that technology has moved in 35 years. The rest of the world is going XML, a format recommended by the World Wide Web Consortium, which is the closest body we have that governs the World Wide Web.

The book industry has always been progressive, so it decided to bite the bullet and fix many problems together. It would go to 13 numbers and modernise the BISAC file. So, it came up with the ONIX file, which is built with 21st-century technology.

They then turned around and gave everyone years of warning. The industry date set was January 1, 2007, which was years away at the time.

As many other software suppliers did, we booked industry meetings and discussed the proposed changes with them.

We brought up the details that many DOS users could not handle the ONIX files for those trying to understand what is involved in handling ONIX in our DOS system. First, we would have to write a link to the internet and XML. Something possible but not trivial, then significant file changes and probably almost every screen and report with stock. Changes of this extent would probably cause bugs for everyone who uses our system until we work them out. So it would have to be a new system separate from the newsagency system.

Many of the book suppliers stated they understood and that they would continue the BISAC file until mid-2008. To them, it is just another choice in their software, ONIX or BISAC.

For engaging PowerPoint presentations discussing what is happening, check out the following

<removed>

So well briefed, we worked on resolving these issues in our software. Our clients in the book industry helped us out considerably, and we got it working.

So what is the problem? Well, nothing and plenty, depending on what you want from the book and your retail software.

If you have a recent copy of our software, POS Browser, then it is not a problem.

If all you want to do is sell books, then there is no problem either. Just enter the stock as you do now and sell it. The retail systems can handle barcodes. If you want a special order, just quote the barcodes to the supplier.

In March 2007, if you want to use BISAC, I will get several different stories from book suppliers, some of which are saying,
1) We have a cutoff date for this data, and from this date, we only have ONIX
2) Our software has been updated, and we cannot send out the BISAC now.
3) We don’t know how to handle BISAC. (This is true with the frequent changes in staff and people invoicing in the book industry. New staff do not know the choices for BISAC, and it is too hard for them to remember who gets BISAC.)
4) Industry standard is ONIX, and BISAC cannot handle the new book codes. (This is not strictly true.)

Some book suppliers have stated that they are looking at the ECG committee DDO files, which are DOS-compatible. The problem here is that POS Solutions originally designed this standard for cigarettes. It was generalised for any stock item in a POS newsagency management system. Later, the ECG committee adapted it for their magazines and cards. It is not designed for books. More importantly, it is not an easy standard to use.

So what has happened is that a book supplier has a consultant look into it. The consultant gives a quote. The book company thinks about it. You ring up a month later, still thinking. Another month later, well, in one case, I rang up and expected to hear that they are still thinking about it. Still, now the company manager stated, “Now after so many years people are complaining. This proves the need for booksellers to keep upgrading their software and systems…... It is not our problem…..We are not picking up the tab”. I suppose it depends on how essential newsagents are to that supplier. The reality is that no book supplier has gone to DDO files.

So now what happens?

Well, for almost 90% of our users, probably nothing needs to happen. Most of those serious in-book problems are on Posbrowser. Years ago, they heard of the problem and started talking to us about it.

Overall, I suspect that only a few of our DOS users are affected. When I went over the list with some book suppliers, I found that very few are getting the BISAC now.

Some may seriously think of updating their system. If so, give us a call ASAP.