Now this is groovy.
I just created a Quickbooks Clone as a Totally applet.
Will this be a good way to provide an accounting module for Totally instead of writing it all myself? Could be, could be.
Yes, you'll need a copy of Quickbooks.
Yes, that copy of Quickbooks needs to be running.
Yes, you need to have a company file open.
No, you don't need a fully registered copy of Quickbooks - a trial edition will do!
This is great.
The current Quickbooks Clone allows you to:
1. List all your customers and their jobs
2. Click on a customer and view all their invoices
3. Click on an invoice and enter a payment.
4. Add new invoices for a customer.
The other good thing about this is that we don't have to do a complete import of Quickbooks data directly into Totally and manage it ourselves. We just tell Quickbooks what to do, and it'll store everything we need. Then, at the end of the financial year, the Totally user can take their datafile to the accountant (who will have a properly registered copy) and be able to see all the data in that company file. The trial editions of Quickbooks don't show you anything if you have around 250 transactions.
Totally, using the Quickbooks SDK, can "see" everything. So we just need to mimic the data entry / display forms, and send that data to Quickbooks.
This also allows the Quickbooks Clone to call on extra applets that perform calculations etc on current Quickbooks data - all those things that Quickbooks doesn't natively support or offer. Great.
Caveat: This has only been tested on the Quickbooks Pro 2003 Australian Edition Trial Version.
Various stuff about stuff - I have no idea of audience so if something you read here helps you, then I'm glad.
Saturday, July 31, 2004
Friday, July 30, 2004
.:Totally:. - Feedback!
This is great!
I had some feedback from a prospective customer!
Quoting Chowdhury:
Dear Brad:
Thanks for making me understand what "Totally" is. It would be a great software! Are u making it only for Australia? Since you are still in developing stage I would request you to make it (easier) for end user. Cause all these codes is out of our range.
I will check your webpage now and then. And will wait for an alpha/beta release to test.
Best of luck! You are doing a good work for people like us who are stuck in the middle of company operation and QB's understanding of these operations.
Yours,
Chowdhury.
Excellent!
Thanks Chowdhury!
I had some feedback from a prospective customer!
Quoting Chowdhury:
Dear Brad:
Thanks for making me understand what "Totally" is. It would be a great software! Are u making it only for Australia? Since you are still in developing stage I would request you to make it (easier) for end user. Cause all these codes is out of our range.
I will check your webpage now and then. And will wait for an alpha/beta release to test.
Best of luck! You are doing a good work for people like us who are stuck in the middle of company operation and QB's understanding of these operations.
Yours,
Chowdhury.
Excellent!
Thanks Chowdhury!
.:Totally:. Installation
Here's a few thoughts on installing Totally.
Each copy will come with and install both the Firebird RDBMS and a pre-configured database so that it can be used straight away (unless I can figure out a way of getting the installer to only install the RDBMS if the user selects it)
If Totally is installed on all workstations within a LAN, then there are going to be multiple database servers running. This is probably not a good thing, but for standalone workstations, not needing to connect to a database across the LAN, this is required.
I think the best way to solve this is, when each user changes the connection to use the networked version of the database, then it should stop the rdbms service on that workstation. Or maybe, for failsafe, keep it running - for example, should the networked database not be available for some reason, then each workstation could have their own locally synced version.
Hmm - need some replication here! Oops - this is getting big. But there is replication software available? Yes I think so.
Oh well, forget about that for the time being.
To change the connection from the local database to the networked one then, there needs to be an option or a preferences dialog where the end user can change to the networked version.
It should enumerate all the LAN machines, and let the user select one. The connection string in the Totally.INI file should then point to the networked version of the database - but we still have a problem in determining the actual path to the db on the "server".
Perhaps Totally should also install a "listener" app that "knows" about the location of the database on that particular machine. When the user changes connections, it can query all the listeners - the listener will tell the workstation where the db resides on the server machine.
This is good, but how to install and run the listener service? Put it in the HKLM\....\Run key of the registry so it always starts up? Yes, that sounds fine.
Perhaps Totally can do it itself - instead of the listener. Yes, this is better. Totally needs to be running on the "server" machine anyway so that it can accept Jabber requests from the outside world - (for the publish / subscribe facility) which means any firewalls in place will have to forward Jabber port requests to the server on which Totally is running. Hmmm - that means the local LAN admin needs to do some setting up.
Oh well, for now, we'll just have to implement it using Internet Connection Sharing and ZoneAlarm - no external hardware firewall - need to write up some docs for that.
But wasn't one of the tenets of Totally going to be "Napster for business"? I can run PSI as a Jabber client, and I can still communicate via my LAN gateway machine, so Totally shouldn't have a problem either. NAT/ICS will take care of that for me. So it seems to be ok from a hardware firewall point of view also?
Need to do some more investigating.
Each copy will come with and install both the Firebird RDBMS and a pre-configured database so that it can be used straight away (unless I can figure out a way of getting the installer to only install the RDBMS if the user selects it)
If Totally is installed on all workstations within a LAN, then there are going to be multiple database servers running. This is probably not a good thing, but for standalone workstations, not needing to connect to a database across the LAN, this is required.
I think the best way to solve this is, when each user changes the connection to use the networked version of the database, then it should stop the rdbms service on that workstation. Or maybe, for failsafe, keep it running - for example, should the networked database not be available for some reason, then each workstation could have their own locally synced version.
Hmm - need some replication here! Oops - this is getting big. But there is replication software available? Yes I think so.
Oh well, forget about that for the time being.
To change the connection from the local database to the networked one then, there needs to be an option or a preferences dialog where the end user can change to the networked version.
It should enumerate all the LAN machines, and let the user select one. The connection string in the Totally.INI file should then point to the networked version of the database - but we still have a problem in determining the actual path to the db on the "server".
Perhaps Totally should also install a "listener" app that "knows" about the location of the database on that particular machine. When the user changes connections, it can query all the listeners - the listener will tell the workstation where the db resides on the server machine.
This is good, but how to install and run the listener service? Put it in the HKLM\....\Run key of the registry so it always starts up? Yes, that sounds fine.
Perhaps Totally can do it itself - instead of the listener. Yes, this is better. Totally needs to be running on the "server" machine anyway so that it can accept Jabber requests from the outside world - (for the publish / subscribe facility) which means any firewalls in place will have to forward Jabber port requests to the server on which Totally is running. Hmmm - that means the local LAN admin needs to do some setting up.
Oh well, for now, we'll just have to implement it using Internet Connection Sharing and ZoneAlarm - no external hardware firewall - need to write up some docs for that.
But wasn't one of the tenets of Totally going to be "Napster for business"? I can run PSI as a Jabber client, and I can still communicate via my LAN gateway machine, so Totally shouldn't have a problem either. NAT/ICS will take care of that for me. So it seems to be ok from a hardware firewall point of view also?
Need to do some more investigating.
Thursday, July 29, 2004
.:Totally:. and Things and Applets
Hmmm - I was just looking at the menu structure to the Totally MDI UI, and it occurred to me that there is only really a need to show Things (Customers, Suppliers, Invoices, Emails etc) and Applets.
An Applet can process Things, so there isn't a need to have the UI cluttered up with menu choices to start this applet or that applet. This is a better design too, because then the administrator of Totally can decide to only allow certain applets to be installed on each end-users PC (in the applet-cache folder). If it's not there, they can't even see it. Yes, much better.
The only menu items that a end-user should see are those that allow them a bit of personalisation as to how their copy of the Totally UI looks in terms of background colours/images etc.
The only applets needed on each workstation are those that let the user choose which Thing or Applet to work with.
The current Things applet is called InternalMenu (I had this wild idea of being able to use the database schema to support Ingenieum menus) so began with that. It probably needs to be called something else now that I've had a bit of a think about it.
An Applet can process Things, so there isn't a need to have the UI cluttered up with menu choices to start this applet or that applet. This is a better design too, because then the administrator of Totally can decide to only allow certain applets to be installed on each end-users PC (in the applet-cache folder). If it's not there, they can't even see it. Yes, much better.
The only menu items that a end-user should see are those that allow them a bit of personalisation as to how their copy of the Totally UI looks in terms of background colours/images etc.
The only applets needed on each workstation are those that let the user choose which Thing or Applet to work with.
The current Things applet is called InternalMenu (I had this wild idea of being able to use the database schema to support Ingenieum menus) so began with that. It probably needs to be called something else now that I've had a bit of a think about it.
.:Totally:. and Banner ads
I had this crazy idea of adding an animated gif banner thing to the top of the Totally UI. This was really to prompt the user to register Totally, (and I'll keep this) but the other good thing is that any business that subscribes to the Total service can have their own banner ad appear on every other copy of Totally that is running.
With current banner ads, you actually need to go to a website to see them. As a business owner, which website do you choose to have your banner ad displayed? And can you be guaranteed that your target audience is going to see it anyway?
Basically, this is an idea ripped straight out of Opera's book. If they can do it, so can I.
So I need a URL inside Totally that will pick up a random banner ad given to PSI by the subscribed business, and each copy of Totally will pick a banner at random. Since the subscribed business doesn't pay for placement (only their monthly fee) there is no guarantee that their banner ad will always be seen. However, a better idea may be to rotate them.
Hmm - I'll have to look at Microsoft's AdRotator component. Must go do that now before I forget.
More soon.
With current banner ads, you actually need to go to a website to see them. As a business owner, which website do you choose to have your banner ad displayed? And can you be guaranteed that your target audience is going to see it anyway?
Basically, this is an idea ripped straight out of Opera's book. If they can do it, so can I.
So I need a URL inside Totally that will pick up a random banner ad given to PSI by the subscribed business, and each copy of Totally will pick a banner at random. Since the subscribed business doesn't pay for placement (only their monthly fee) there is no guarantee that their banner ad will always be seen. However, a better idea may be to rotate them.
Hmm - I'll have to look at Microsoft's AdRotator component. Must go do that now before I forget.
More soon.
.:Totally:. and Jabber
In order to communicate between instances of Totally, we'll be using the Jabber protocol. It's XML based, which is great. It also offers an SSL mode of connecting to a Jabber server, so for me, that's a good thing.
And because session ID's and digital certificates will only be known to the communicating copies of Totally, it'll make it hard for a cracker to connect to a running instance of Totally using some Jabber client. They'd have to work very hard in order to fake a connection - and what will they get even if they do? A whole stream of 128bit cryptographically secure data.
I think we're safe - but I've been wrong before.
And because session ID's and digital certificates will only be known to the communicating copies of Totally, it'll make it hard for a cracker to connect to a running instance of Totally using some Jabber client. They'd have to work very hard in order to fake a connection - and what will they get even if they do? A whole stream of 128bit cryptographically secure data.
I think we're safe - but I've been wrong before.
Wednesday, July 28, 2004
More Ingenieum download requests are coming in
We've had more Ingenieum download requests over the past few days.
Thanks to Roman for wanting to be kept informed. Will email you soon Roman, with details of the new version.
I'd just like to know how one can get more hits on a website
a) without paying huge amounts of money
b) without spamming
c) without looking like a jerk
Hmmm - perhaps I need to post a few messages on that website about Windows desktop replacements. What was that URL? hmmm www.shellfront.org looks good.
Look for me there!
Thanks to Roman for wanting to be kept informed. Will email you soon Roman, with details of the new version.
I'd just like to know how one can get more hits on a website
a) without paying huge amounts of money
b) without spamming
c) without looking like a jerk
Hmmm - perhaps I need to post a few messages on that website about Windows desktop replacements. What was that URL? hmmm www.shellfront.org looks good.
Look for me there!
"Totally" is moving along well
Totally, the software portion of the Total small business service, is moving along quite nicely thank you.
Its great. I added a few silly little things that won't be much on the larger scale of things, but it makes the whole product look that much better.
1. Animated banner ads in the top right hand corner, just like Opera. Thanks to Stephen Lebans for his OCX to do animated gifs.
2. Easy ASP page invoking a COM DLL to accept data sent to it by a class provided by Eduard Morcillo (Edanmo) and allowing me to store registration details in my customer database without having to install Internet Explorer just to send a form, like other apps do.
But I'm having a lot of fun.
Now, just have to build it and you'll be able to download it soon.
Stay tuned.
Its great. I added a few silly little things that won't be much on the larger scale of things, but it makes the whole product look that much better.
1. Animated banner ads in the top right hand corner, just like Opera. Thanks to Stephen Lebans for his OCX to do animated gifs.
2. Easy ASP page invoking a COM DLL to accept data sent to it by a class provided by Eduard Morcillo (Edanmo) and allowing me to store registration details in my customer database without having to install Internet Explorer just to send a form, like other apps do.
But I'm having a lot of fun.
Now, just have to build it and you'll be able to download it soon.
Stay tuned.
Saturday, July 17, 2004
Ingenieum's Page Generation
This is great. I'm getting so far along with the new version of Ingenieum.
Today I added another stored procedure to call on existing stored procedures that lets me get the entire content of the menu page in one call to the database.
Then, the entire page gets sent back to the browser with no extra processing needed by the script that gets the content - it is formatted by the stored procedure.
Brilliant! I am so happy.
Today I added another stored procedure to call on existing stored procedures that lets me get the entire content of the menu page in one call to the database.
Then, the entire page gets sent back to the browser with no extra processing needed by the script that gets the content - it is formatted by the stored procedure.
Brilliant! I am so happy.
Friday, July 16, 2004
New Ingenieum release!
We're working on a new release of Ingenieum.
We've also got a new website being developed now - it looks fantastic - congrats to Don and Sam for getting it moved along. Beej - your design has worked for the last 3 years, but we felt it was time for a revamp (love you btw) and we thank you profusely for the work you did in getting the current site together.
So, what's in the new release? In a word, lots.
1. A proper RDBMS instead of MS Access. We'll be using the open-source Firebird RDBMS - see http://www.firebirdsql.org for details.
2. Lots of page generation stuff will be inside the database in the form of stored procedures, so we can easily put the database on another platform (Linux, Unix, MacOS) and connect to it via PHP served by Apache! So if you've been put off by needing IIS, have another look at Ingenieum soon!
3. Getting Ingenieum to run on other platforms gives us a lot of scope to provide more and more functionality and services.
Stay tuned at http://www.ingenieum.com for more details.
We've also got a new website being developed now - it looks fantastic - congrats to Don and Sam for getting it moved along. Beej - your design has worked for the last 3 years, but we felt it was time for a revamp (love you btw) and we thank you profusely for the work you did in getting the current site together.
So, what's in the new release? In a word, lots.
1. A proper RDBMS instead of MS Access. We'll be using the open-source Firebird RDBMS - see http://www.firebirdsql.org for details.
2. Lots of page generation stuff will be inside the database in the form of stored procedures, so we can easily put the database on another platform (Linux, Unix, MacOS) and connect to it via PHP served by Apache! So if you've been put off by needing IIS, have another look at Ingenieum soon!
3. Getting Ingenieum to run on other platforms gives us a lot of scope to provide more and more functionality and services.
Stay tuned at http://www.ingenieum.com for more details.
Ingenieum Version Numbers
Before I forget, here's the most recent version numbers of the applications in the Ingenieum suite.
MenuServer - 2.0.0.12
Database Administrator - 2.6.0.39
Application Launcher - 2.1.0.125
Impero - 1.1.0.66
Impero Configuration Editor - 1.0.0.0
Reperio - 1.1.0.12
Reperio Configuration Editor - 1.1.0.9
Database Selector - 1.1.0.14
Unreleased software:
Ingenieum Web Admin - 1.0.0.0
MenuServer - 2.0.0.12
Database Administrator - 2.6.0.39
Application Launcher - 2.1.0.125
Impero - 1.1.0.66
Impero Configuration Editor - 1.0.0.0
Reperio - 1.1.0.12
Reperio Configuration Editor - 1.1.0.9
Database Selector - 1.1.0.14
Unreleased software:
Ingenieum Web Admin - 1.0.0.0
Ingenieum's Licensing Functionality
Ok - I need to add license monitoring to Ingenieum.
Basically, the original premise of licensing was for CDROM apps. Now, it has to extend to websites as well.
The problem is that the original MenuServer only took licensing into consideration if the link that was about to be launched was an application (12345.ald) - now it appears that we have to use the Application Launcher to go to web sites too - therefore, the only way that licensing can work for the *current* version of Ingenieum's MenuServer is to force all websites to be opened in a new browser window.
So the item link must have an entry in the Program's tab - then, the link will be opened using Application Launcher, which will then use the AsynchDownload class to contact the MenuServer to say that a license needs to be checked out from the pool.
Then, when the next user requests that link, we can check the license pool and dishonour that request if there are no licenses available.
Hmmm - this should work out ok - as long as the end user administrator likes the idea of opening licensed web content in a new window. Must ask Anna about this.
So that's as much as I can think of at the moment. More later.
Basically, the original premise of licensing was for CDROM apps. Now, it has to extend to websites as well.
The problem is that the original MenuServer only took licensing into consideration if the link that was about to be launched was an application (12345.ald) - now it appears that we have to use the Application Launcher to go to web sites too - therefore, the only way that licensing can work for the *current* version of Ingenieum's MenuServer is to force all websites to be opened in a new browser window.
So the item link must have an entry in the Program's tab - then, the link will be opened using Application Launcher, which will then use the AsynchDownload class to contact the MenuServer to say that a license needs to be checked out from the pool.
Then, when the next user requests that link, we can check the license pool and dishonour that request if there are no licenses available.
Hmmm - this should work out ok - as long as the end user administrator likes the idea of opening licensed web content in a new window. Must ask Anna about this.
So that's as much as I can think of at the moment. More later.
Subscribe to:
Posts (Atom)