I had a new question asked today - Can you use Wessex Professional abroad? Well, it's been so long since I'd talked about that subject that I momentarily forgot how the program was set up! So, I thought it might be a good idea to set down what happens if you are using the program outside of the UK.
The obvious one is the currency symbol. This is taken from whichever country you have the computer set to (in Control Panel > Clock, Language & Region). If, for instance, you have the computer country set to United States, then the currency symbol will automatically be "$". If the computer is set to Germany then the symbol is "€". (It may be obvious, but you don't actually have to be in that country to have the computer set to it!)
Easy so far?
From a programming point of view I thought I'd cracked it, that is until someone told me that in France the symbol comes after the amount (ie. 25.67€)! So I had to design a sub-routine that tested the resulting string of characters to see if the symbol was before or after the amount. Then the rest of the program could get to grips with just the figures (adding up an invoice for instance).
The next point is the tax abbreviation. In many European countries it is "VAT", while in France it is "TVA". Whichever abbreviation is used in your country you can set that in the program by going to "Setup > Values" and choosing the "% + VAT tab". You can use up to 10 characters/spaces, so there is room for "Sales Tax".
As most countries have a decimal system there is no problem with working out the price - you just need to adjust the program values to give the prices you want. In Europe the values will be something like 20% higher than the sterling equivalent (Nov. 2013), but there may be local variation to allow for (glass may be more expensive for instance).
There is a potential problem if you use the update files issued in the UK (Wessex & Frinton), as the moulding is priced in sterling. You can get round this by opening the file (in Excel) and changing the Price/mtr column values and then importing it as usual. On the other hand you are unlikely to be using a UK supplier directly, so the problem is unlikely to arise.
That only leaves the language itself - everything is in English. All I can say is that if sufficient framers want a different language I'll do my best to sort it out.
Friday 8 November 2013
Friday 3 May 2013
An interesting problem
The pricing program for PC (WPP4) has been behaving itself nicely. I've been working on a couple of minor improvements, including being able to create a file on mouldings that can be imported into the new Android App.
That was until a framer rang me up with a problem concerning the Invoice number.
The problem -
The invoice number can be increased in "Setup" > "Options". The idea was that you may not want to start with invoice number "1". However, this framer had a (quite reasonable) scenario of changing the invoice number to reflect her financial year, for example "1314001". She saved the new invoice number value and then tried to save an invoice - this produced an error and the invoice couldn't be saved. The problem was made worse because invoice number couldn't now be decreased in the "Options" form.
The reason for the error goes back to the original design of the database some 6 or more years ago. Each column in the database has a data type, for instance the"DateCollected" column in the table "WorkTickets" is datatype "date". Well the datatype of the "InvNum" column in "WorkTickets" is "integer". All well and good you think (well, I did anyway). But type "integer" in this form of database turns out to be "int16", a number made up of 2 bytes which has a maximum value of 32,787. A much better choice would have been "long integer" ("int32"). This number is made up of 4 bytes and has a maximum value of 2,147,483,647.
The Solution -
Once the data type has been set up in the design of the database it is very difficult to change. Certainly trying to change it programatically would be likely to throw up more problems than it solved. So, if you need to use numbers larger than 32,000 for your invoices here is what to do, "Export" your database and open this copy in Microsoft Access.
You will see a list of Tables at the left hand side. Choose "WorkTickets", the "WorkTicket" table and its data is now shown in the main pane. We want to get to the data types, so go to "Views" at the top left and choose "Design View". Now the Field (Column) names and their datatypes are displayed. Click on "InvNum" (second one down) and at the bottom of the screen its Field Properties are shown. The first one is "Field Size" as "Integer". Click on that line and from the drop-down box select "Long Integer" instead. Save the changes and close Access.
Now all that remains is to "Import" the modified database file back into the program. This will throw up a warning saying the database is corrupted, continue to import? (This is because we've changed the structure of the file.) Click "Yes" and the new database will be imported anyway.
You will now be able to use large numbers for your invoices.
Phew!
That was until a framer rang me up with a problem concerning the Invoice number.
The problem -
The invoice number can be increased in "Setup" > "Options". The idea was that you may not want to start with invoice number "1". However, this framer had a (quite reasonable) scenario of changing the invoice number to reflect her financial year, for example "1314001". She saved the new invoice number value and then tried to save an invoice - this produced an error and the invoice couldn't be saved. The problem was made worse because invoice number couldn't now be decreased in the "Options" form.
The reason for the error goes back to the original design of the database some 6 or more years ago. Each column in the database has a data type, for instance the"DateCollected" column in the table "WorkTickets" is datatype "date". Well the datatype of the "InvNum" column in "WorkTickets" is "integer". All well and good you think (well, I did anyway). But type "integer" in this form of database turns out to be "int16", a number made up of 2 bytes which has a maximum value of 32,787. A much better choice would have been "long integer" ("int32"). This number is made up of 4 bytes and has a maximum value of 2,147,483,647.
The Solution -
Once the data type has been set up in the design of the database it is very difficult to change. Certainly trying to change it programatically would be likely to throw up more problems than it solved. So, if you need to use numbers larger than 32,000 for your invoices here is what to do, "Export" your database and open this copy in Microsoft Access.
You will see a list of Tables at the left hand side. Choose "WorkTickets", the "WorkTicket" table and its data is now shown in the main pane. We want to get to the data types, so go to "Views" at the top left and choose "Design View". Now the Field (Column) names and their datatypes are displayed. Click on "InvNum" (second one down) and at the bottom of the screen its Field Properties are shown. The first one is "Field Size" as "Integer". Click on that line and from the drop-down box select "Long Integer" instead. Save the changes and close Access.
Now all that remains is to "Import" the modified database file back into the program. This will throw up a warning saying the database is corrupted, continue to import? (This is because we've changed the structure of the file.) Click "Yes" and the new database will be imported anyway.
You will now be able to use large numbers for your invoices.
Phew!
Sunday 10 February 2013
A frame pricing app for Android devices
If you went to the Wessex stand at the Spring Fair on Sunday or Monday you would have seen what I think is a world first - the first Android Picture Frame Pricing App. ever!
I was amazed by the enthusiastic reception, it certainly seemed to fulfil a need to be able to price frames on the move. From market stalls to home visits, people kept coming up with new scenarios to use it in.
The App. was so new that there were still some finishing touches to do to it. These have now been completed and it will be available to download from the Wessex website very shortly.
I'm also working on integrating the App. more closely with Wessex Professional, so the prices issued are the same.
Watch out for WPP4 (ver 4.2.5).
 |
| Wessex Pricing App. on HTC Wildfire S |
The App. was so new that there were still some finishing touches to do to it. These have now been completed and it will be available to download from the Wessex website very shortly.
 |
| App. on 7" tablet, with Wessex Professional in background |
I'm also working on integrating the App. more closely with Wessex Professional, so the prices issued are the same.
Watch out for WPP4 (ver 4.2.5).
Sunday 20 January 2013
Some changes in ver. 4.2.4
It's that time of year again, just before the NEC and I've just finished putting together the latest version of the Wessex Pricing Program (4.2.4).
It contains the latest Wessex & Frinton lists as well as some tweaks that make the program easier to use. The main ones being - better deposit information, and in the Customer records, details for how much the customers has spent, how many jobs etc.
I've made a small, but interesting change to the way the program works out the price of multiple items. Users may have noticed that 2 items are not always double a single item (eg one frame = £24.44, two frames = £48.89). This is because the program works out the price of one frame to many decimal places, then multiples by the number required and THEN rounds to the nearest penny. (eg. one frame = 24.44401,this equals £24.44. But two frames = 48.88802 this rounds to £48.89) Working out the price this way is the most accurate but not the most logical to us humans.
The effect is even more noticeable if the framer is using the "Whole Pounds" option. Using the above figures - one frame = 24.44401 equals £25. But two frames would equal £49.
So, now all that is changed, by rounding the price to the nearest penny for the first frame and then multiplying by the number required. Leaving us with I hope a more user friendly experience.
It contains the latest Wessex & Frinton lists as well as some tweaks that make the program easier to use. The main ones being - better deposit information, and in the Customer records, details for how much the customers has spent, how many jobs etc.
I've made a small, but interesting change to the way the program works out the price of multiple items. Users may have noticed that 2 items are not always double a single item (eg one frame = £24.44, two frames = £48.89). This is because the program works out the price of one frame to many decimal places, then multiples by the number required and THEN rounds to the nearest penny. (eg. one frame = 24.44401,this equals £24.44. But two frames = 48.88802 this rounds to £48.89) Working out the price this way is the most accurate but not the most logical to us humans.
The effect is even more noticeable if the framer is using the "Whole Pounds" option. Using the above figures - one frame = 24.44401 equals £25. But two frames would equal £49.
So, now all that is changed, by rounding the price to the nearest penny for the first frame and then multiplying by the number required. Leaving us with I hope a more user friendly experience.
Subscribe to:
Posts (Atom)