I am back from my trip to Cancun. Hope nobody had any trouble while I was away.
I am back from my trip to Cancun. Hope nobody had any trouble while I was away.
Well… do you feel smart today punk?
Well, do you?
Sometimes a good joke might take a few msecs to figure out.
These ones will make you think… a lot! J
See how many you get.
How many did you get?
Coming Soon to a Theatre Near You…
Flowershop Network Interface
Happy Mother’s Day!
I’m out of here.
I hope that you all had a prosperous Mother’s Day holiday and none of you ended up institutionalized.
As for me, I’ll be leaving for…
Cancun early Tuesday morning and not coming back until May 21st.
So if you have any questions or requests for improvements, get them in on Monday or wait until I get back.
I don’t know how cell phone service will be down there but you can always email me.
In my absence, if you have any non-technical questions that can’t wait until I get back, you can call Cris Bandle (https://flowersoftsilver.com/2015/03/26/who-is-cris-bandle/)
or Lambros Barbagiannis (https://flowersoftsilver.com/2015/04/17/happy-birthday/).
They are 2 of the most knowledgeable flowerSoft users in the country and I am sure they will be able to help you with any operational questions.
See you soon!
A Blast From the Past
Here is what flowerSoft’s Version 5 Order Entry menu screen looked like back 20 years ago!
And this is what it looks like today…
I think we’ve improved. J
I wonder how long it took me to get all those colors on the screen 20 years ago.
For those of you wondering, flowerSoft did start with version 1 and did not switch to year versions until flowerSoft 2000 which came out in September of 1999 Y2K ready!
Ever since then, all flowerSoft versions have been year versions, from flowerSoft 2000 through flowerSoft 2015.
Your Own Floral Wedding Agreement
Since everyone thinks theirs is the best, I’ve decided to allow everyone to design their own floral wedding agreement.
You will be able to create, change and modify this agreement to your liking without my intervention.
Here is what you have to do:
The default document will be found in a folder called WEDDINGS. This folder is located in \FSSILVER\FSROOT\EMAILS\ATTACHMENTS folder.
It can also be found in the \FSSILVER\FSROOT\DOCS folder.
You can save the newly created document anywhere you want but you must also save it in the folder called \FSSILVER\FSROOT\EMAILS\ATTACHMENTS\WEDDINGS
You must give it a name that is unique to your shop and that flowerSoft has access to.
You can find that name by going into the Manager’s menu > System Information > Defaults > Operating Defaults and navigating to page # 16 of the defaults.
The name will be in a field called “Customized Processing Set Name:”
If there is no name in that field, update the record and enter your shop’s name (or part of it) there.
Use the name in that field to save your .pdf file. If you do not use that name, flowerSoft won’t be able to send the attachment.
If you do not save it in that folder and using that name, flowerSoft will not be able to find it when you need to e-mail it.
That is all you need to do.
Now, after you have created a wedding proposal in flowerSoft, you can print it or e-mail to your customer like this…
and hit E if you want to e-mail or P if you want to print. If you select to print, the document(s) chosen will just go to the printer.
but if you choose to e-mail the document’s to the customer, flowerSoft will then ask you for the e-mail address to use.
If there is an e-mail address in the bride’s wedding information, it will fill the field with her address but it will allow you to change it.
If you have any comments or suggestions for improvement, please let me know.
Y2K Bug… again?
Unless you are under 20, anyone?, anyone?… most of you will remember the Y2K panic of 1999.
The late 1990s were defined by a number of ridiculous things, but somewhere near the top of the list was the panic that boiled over in 1999 as people prepared for the end of civilization as we knew it.
Because of the “Y2K” bug, you see, anything and everything controlled by a computer would stop functioning when the clock struck midnight and December 31, 1999 rolled into January 1, 2000.
That obviously didn’t happen, but the Y2K bug was a pretty sizable nightmare for programmers as they were made to pour through code and change two-digit year abbreviations to four digits.
What was (or is) the Y2K bug?
When complicated computer programs were being written during the 1960s through the 1980s, computer engineers used a two-digit code for the year.
The “19” was left out. Instead of a date reading 1970, it read 70. Engineers shortened the date because data storage in computers was costly and took up a lot of space.
As the year 2000 approached, computer programmers realized that computers might not interpret 00 as 2000, but as 1900.
Activities that were programmed on a daily or yearly basis would be damaged or flawed.
As December 31, 1999, turned into January 1, 2000, computers might interpret December 31, 1999, turning into January 1, 1900.
The fix was to expand the year portion of the date to 4 digits. A pretty simple fix, although I spent many hours switching all the date fields in flowerSoft from mm/dd/yy to mm/dd/yyyy.
But wait… can this Y2K bug, who we thought was totally out of our lives be causing problems again?
Maybe. Perhaps you have even experienced it in flowerSoft.
Unfortunately, it looks like some programmers’ jobs still aren’t done.
The Associated Press reports that Y2K is back with a bang in Pennsylvania, where the families of 14,000 deceased men were just sent notices that their dearly departed must register for the draft or face fines and even imprisonment.
The men were all born between 1893 and 1897, so the youngest among them would be 116 or 117 years old right now.
So how is the bug coming back to haunt you? Well, because of the fix that was used to correct the problem in flowerSoft and other databases.
Because many users were still using databases like flowerSoft with a mm/dd/yy date format, there had to be a way to distinguish the century when a date such as 02/14/00 was used.
Was it 02/14/1900 or 02/14/2000?
That gave birth to a setting still being used in flowerSoft called PFCMARK. This setting is followed by a number which tells the database (flowerSoft) which century the 2-digit year is for.
Back in 2000, I set the PFCMARK=20 in flowerSoft’s environment because at that time it seemed like the most logical number.
That meant that any 2-digit year from 00 to 19 was assumed to be in the 21st century and any 2-digit year from 20 to 99 was assumed to be in the 20th century.
So if you had an employee that was born in 05/02/86, flowerSoft would know that you meant 05/02/1986.
If you had an order date of 05/02/12, flowerSoft knew it was really 05/02/2012.
In short, with PFCMARK=20, flowerSoft translated any 2-digit year from 00 through 19 to 2000 through 2019.
Any 2-digit year from 20 through 99 was translated to 1920 through 1999.
So what is happening now?
After all, flowerSoft uses 4-digit years throughout all its modules. Why is there a potential problem?
The problem is that credit card expiration dates are still being inputed as 2-digit years.
Credit cards are beginning to come in with expiration dates in 2020. When the expiration dates is inputted into flowerSoft, it is done as 09/20 for example.
With PFCMARK set as 20, flowerSoft thinks that date is really in 1920 and is flagging any new credit cards from customers expiring in 2020 as expired.
I’ve been changing the PFCMARK setting to 25 to avoid this problem, at least for another 5 years but then I would have to do it again.
So what I’ve come up with a better solution and that is to set the PFCMARK variable each time you log into flowerSoft by adding 10 the current year.
So, if you log into flowerSoft anytime during 2015, the PFCMARK would be set to 25. In 2016, the PFCMARK would be equal to 26 and so on.
Since the PFCMARK would change every year, you should never have a problem with dates anymore…
Unless, of course when we get to the year 2038. That problem will not affect flowerSoft buy may impact flowerSoft users.
But that is a different story.
If you want to read about it, here is the link… http://www.theguardian.com/technology/2014/dec/17/is-the-year-2038-problem-the-new-y2k-bug
The year 2038 problem is caused by 32-bit processors and the limitations of the 32-bit systems they power. The processor is the central component that drives all computers and computing devices. It crunches the numbers and performs calculations that allow programs to run.
Essentially, when the year 2038 strikes 03:14:07 UTC on 19 March, computers still using 32-bit systems to store and process the date and time won’t be able to cope with the date and time change. Like the Y2K bug, the computers won’t be able to tell the difference between the year 2038 and 1970 – the year after which all current computer systems measure time.