As my progress on Pieces of Eight moves forward I seem to have adopted a pirate themed naming convention. Why call a class “ComparisonOrchestrator” when you can call it “ComparisonCaptain”?
More of the basic functionality has been added, the program can now;
- Hold a company file through the GUI – as before.
- Hold a single competitor.
- Iterate through each product in the company and compare it to any products with the same SKU held in the competitor.
- Report the selling price difference between the company and competitor.
- Report the percentage margin the competitor has on the product*.
*Using the assumption that the competitor has the same cost price as us.
Next Steps Graphical User Interface & File IOMy plan next is to add functionality in the GUI to add a competitor and read the data from a file (currently hard-coded for testing).
The great thing about OOP (Object Oriented Programming) is that most of this functionality is already there, I just need to alter the methods slightly.
Test, Test & then Test one more time for luckAs I’m going through each component of the program I test as much as possible whether it be reading a price in a file or printing a single word to the screen. This just makes good sense rather than getting to the end and running the program only to find there is a little mistake hidden somewhere in the hundreds (or thousands) of lines of code.
As this is an ongoing methodology, there can be lines left in that are unneeded and although most IDE’s do a great job of pointing out unused bits of code I’m also constantly checking for them myself as well as refactoring algorithms and method calls.
Matching productsAs in my last post where I briefly mentioned matching SKUs and the many, many pitfalls and challenges that could arise; I so far, have been “exact-matching” SKUs.
So if I have a company product with the SKU: “ABC”, the program will look for a product with exactly that SKU in the competitor prices. Great!
What, though, if the SKU the competitor is using is actually “ABC-1” or “ACME-ABC” because of some obscure naming convention? What if we don’t know what SKU the competitors are using and only have a name to go off? E.G: “ACME ABC Garden Gnome”.
My thoughts on a solution have bought me to this so far;
- Look for an exact match – if found, done!
- else look for the SKU as a sub-string of the name, if found, done!
- else use some kind of process to;
- a) add ‘-‘, ‘/’, ‘_’ etc. characters sequentially at different positions within the SKU to then check for that variation or
- b) simply store that in a separate list to be walked through manually.
I see caveats to the second two bullet points – it may provide false positives which can be a nightmare to find and sort out. I’d love to use machine learning to train the program but I feel that is a bit ambitious for such a small program.
Company prices? Check. Competitor prices? Check. Comparison data? Check. What now?Aside from the other problems with large spreadsheets, filtering data adds even more processing to the pile meaning it is not a realistic method of garnering helpful data.
The whole purpose of the process is so that we can see if we are selling a product too cheaply or for too much (and probably not actually selling it as a result).
Therefore, I would like to add some kind of filtering criteria, so that the program can show you, for example;
- only products where one or more competitors are cheaper.
- only products where we have room to put the margin up.
As well as, of course, all data for each competitor.
Once I have the core functionality I will look to how I am going to present that data to the user. This is going to be one or ideally both of the following;
While all this is going on I am also thinking about a program to read in a CSV of historic order details so that we can make use of the data. This should be a relatively simple process but one which could be of use.
Oh, and I’m also off work, so I’m “relaxing” too.