Simply Accounting

[Question Boy]

I have a client db and am looking for a way to pass information (name,
address, etc) to simply accounting. Does anyone have any experience with
this. I haven't been able to find an SDK on the company's website. Any
help would be appreciated to get started.

QB

 

[Albert D. Kallal]

It actually turns out that simply accounting uses ms-access files (and the
same database engine jet).

What this means is you can open up those files directly with MS access, and
actually edit the data with ms-access.

now of course simply accouting is access based, but they don't use the same
"mdb" file extension, but that's more done just to fool you keep your prying
eyes out of the system.

However, the problem is not the fact that you can open an edit those files
directly, the problem is that if you update one file, there's probably about
50 other tables that you have to update and maintain perfectly correct. If
you don't do that, your likey to throw out balances and totals in a whole
bunch of other tables that ALSO need updating.

What this means is it's probably not a good idea to try and diretly edit and
change and modify the files using MS access.

You probably should export the data from MS access as a comma delimited
file, and then set up and use the simply accounting import options. As
mentioned, this is a preferred approach because the simply counting software
knows how to update the zillions of tabls, and there is a rahter LARGE
amount of code that must run to keep things correclty setup.

If you attempt to modify the tables directly, you'll have to rewrite part of
the accounting package to ensure that all balances, account numbers, and
virtually every other little detail is wrutten exactly the same as the
simply accounting software would do.

As for the software development kit? Try the simply accouting groups. As for
the documentation of all the tables? If you install simply accounting, or
even the trial edition onto a computer, you'll find a "sub" directory in the
program files dir that has the information and documentation as to the table
structures. (it was a pdf file last time I looked).

In my situation I simply wrote some software to open up the simply accouting
files from MS access, and read out a chart of accounts that I needed because
I was too lazy to re-type this list.

The other interesting thing here is that you can use the MS access report
later directly on the simply a counting files because as mentioned, simply
counting uses the same database format as ms-access. I haven't done this for
a few years, but I also recall there was a workgroup file you had to join
also, and if you don't join that workgroup file, then you'll not be all to
open those tables.

Doing some digging through my library of code, here's the piece of code I
used to open in list out the tables and simply accounting file

Dim strSql As String
Dim dbe As PrivDBEngine
Dim wrk As Workspace
Dim dbs As Database
Dim strTables As String
Dim rstTables As DAO.Recordset

Dim rstFrom As DAO.Recordset
Dim rstTo As DAO.Recordset

Dim strTableName As String

If IsNull(Me.txtWorkGroup) = False Then

' setup new workgroup
' Return a reference to a new instance of the PrivDBEngine object.
' we have to do this to OPEN a file with a DIFFERNT workgroup

Set dbe = New PrivDBEngine
' Set the SystemDB property to specify the workgroup file.
dbe.SystemDB = Me.txtWorkGroup


dbe.DefaultUser = Me.txtUser
If IsNull(Me.txtPass) = False Then
dbe.DefaultPassword = Me.txtPass
End If
Set wrk = dbe.Workspaces(0)
' Open the secured database.

Set dbs = wrk.OpenDatabase(Me.Text0)

Else
Set dbs = OpenDatabase(Me.Text0)
End If



' database open...now grab table list...

strSql = "SELECT MSysObjects.Name FROM MsysObjects WHERE
(Left$([Name],1)<>'~') AND " & _
" (Left$([Name],4) <> 'Msys') AND (MSysObjects.Type)=1 ORDER BY
MSysObjects.Name;"


Set rstTables = dbs.OpenRecordset(strSql)

MsgBox "table count = " & rstTables.RecordCount

' now make a string to fill the combo box on the screen

Do While rstTables.EOF = False

If strTables <> "" Then
strTables = strTables & ";"
End If

strTables = strTables & rstTables!Name
rstTables.MoveNext

Loop

Me.cboTables.RowSource = strTables



I also note my code that the file extension was .sdb (that is the mdb file)
I also note in my code that the workgroup (securty) file had a extension of
..sdw

It's rather interesting in practice that everybody would love to be able to
open the accouting files directly, but in actual practice it's not that
workable to *update* the data files.

However, it is rather nice that you can directly open and read simply
accounting files, and note that you don't have to use the above code, but
you can browse and use MS access to open up those simply accuting files
directlity without writing any code.

Unfortunately the above code and examples helps you read data from simply
accounting, but for updating the data in simply accounting, that's getting a
little bit more complex, and I would look into the importing options for
simply accouting...not trying update the tables direclity.

 

[Question Boy]

I know you say not to update info into simply because it can require updating
tons of tables, but does this apply to only inputting client info (name,
address, tel number) and not financial. I am simply looking to create the
client contact record. The actual financial information... will all still be
done directly through simply. I am simply looking to eliminate the
duplication of client information data entry. I'm sorry if your previous
post applied to this case as well, but I just wanted to be explicit about my
specific case should you have experience with this in particular.

QB

It actually turns out that simply accounting uses ms-access files (and the
same database engine jet).

What this means is you can open up those files directly with MS access, and
actually edit the data with ms-access.

now of course simply accouting is access based, but they don't use the same
"mdb" file extension, but that's more done just to fool you keep your prying
eyes out of the system.

However, the problem is not the fact that you can open an edit those files
directly, the problem is that if you update one file, there's probably about
50 other tables that you have to update and maintain perfectly correct. If
you don't do that, your likey to throw out balances and totals in a whole
bunch of other tables that ALSO need updating.

What this means is it's probably not a good idea to try and diretly edit and
change and modify the files using MS access.

You probably should export the data from MS access as a comma delimited
file, and then set up and use the simply accounting import options. As
mentioned, this is a preferred approach because the simply counting software
knows how to update the zillions of tabls, and there is a rahter LARGE
amount of code that must run to keep things correclty setup.

If you attempt to modify the tables directly, you'll have to rewrite part of
the accounting package to ensure that all balances, account numbers, and
virtually every other little detail is wrutten exactly the same as the
simply accounting software would do.

As for the software development kit? Try the simply accouting groups. As for
the documentation of all the tables? If you install simply accounting, or
even the trial edition onto a computer, you'll find a "sub" directory in the
program files dir that has the information and documentation as to the table
structures. (it was a pdf file last time I looked).

In my situation I simply wrote some software to open up the simply accouting
files from MS access, and read out a chart of accounts that I needed because
I was too lazy to re-type this list.

The other interesting thing here is that you can use the MS access report
later directly on the simply a counting files because as mentioned, simply
counting uses the same database format as ms-access. I haven't done this for
a few years, but I also recall there was a workgroup file you had to join
also, and if you don't join that workgroup file, then you'll not be all to
open those tables.

Doing some digging through my library of code, here's the piece of code I
used to open in list out the tables and simply accounting file

Dim strSql As String
Dim dbe As PrivDBEngine
Dim wrk As Workspace
Dim dbs As Database
Dim strTables As String
Dim rstTables As DAO.Recordset

Dim rstFrom As DAO.Recordset
Dim rstTo As DAO.Recordset

Dim strTableName As String

If IsNull(Me.txtWorkGroup) = False Then

' setup new workgroup
' Return a reference to a new instance of the PrivDBEngine object.
' we have to do this to OPEN a file with a DIFFERNT workgroup

Set dbe = New PrivDBEngine
' Set the SystemDB property to specify the workgroup file.
dbe.SystemDB = Me.txtWorkGroup


dbe.DefaultUser = Me.txtUser
If IsNull(Me.txtPass) = False Then
dbe.DefaultPassword = Me.txtPass
End If
Set wrk = dbe.Workspaces(0)
' Open the secured database.

Set dbs = wrk.OpenDatabase(Me.Text0)

Else
Set dbs = OpenDatabase(Me.Text0)
End If



' database open...now grab table list...

strSql = "SELECT MSysObjects.Name FROM MsysObjects WHERE
(Left$([Name],1)<>'~') AND " & _
" (Left$([Name],4) <> 'Msys') AND (MSysObjects.Type)=1 ORDER BY
MSysObjects.Name;"


Set rstTables = dbs.OpenRecordset(strSql)

MsgBox "table count = " & rstTables.RecordCount

' now make a string to fill the combo box on the screen

Do While rstTables.EOF = False

If strTables <> "" Then
strTables = strTables & ";"
End If

strTables = strTables & rstTables!Name
rstTables.MoveNext

Loop

Me.cboTables.RowSource = strTables



I also note my code that the file extension was .sdb (that is the mdb file)
I also note in my code that the workgroup (securty) file had a extension of
..sdw

It's rather interesting in practice that everybody would love to be able to
open the accouting files directly, but in actual practice it's not that
workable to *update* the data files.

However, it is rather nice that you can directly open and read simply
accounting files, and note that you don't have to use the above code, but
you can browse and use MS access to open up those simply accuting files
directlity without writing any code.

Unfortunately the above code and examples helps you read data from simply
accounting, but for updating the data in simply accounting, that's getting a
little bit more complex, and I would look into the importing options for
simply accouting...not trying update the tables direclity.

 

[Albert D. Kallal]

I know you say not to update info into simply because it can require
updating
tons of tables, but does this apply to only inputting client info (name,
address, tel number) and not financial.

How do you know the above is in fact the case? How do you know when you add
a new vendor or client, that a whole chart of accounts and a bunch of other
things are not created in other files all over throughout the application?

How will you know what next autonumber (whoops, come to think of it I don't
think simply counting use as the auto numbers, and they have their own
custom built in internal number generation system that is rather complex).
So, how can you even assign the primary key to the reocrd you plan to add to
this table?

In a good number of my applications, I actually have a series of tables with
fields that hold the next primary key number that I'm going to generate for
a given table new customer. (this is especially the case one is gonna be an
external number that users use, as they need to be kept separate from
internal primary keys).

Who knows what approach and what numbering systems that simply accouting ses
to generate this new accout, or client number? As I said, in theory it
sounds wonderful to simply insert a record into a table, in actual practice
you'll have to take the millions of dollars of code that was spent on
designing and building simply accounting, and you have to now duplicate that
code that they used to insert that reocrd. Do you know what other tables
you'll have to access to get that next vendor or client number assigned?

As I said, the problem is not inserting a record, the problem is finding out
what mechanisms they used to assign the primary key and set up all the other
55 plus tables that that application uses. You don't know how all this works
in simply, and your placing yourself in a situation like a intern in a
hospital ward, and you're telling me it's no problem to do brain surgery at
all, where's the knife? Unfortunately we can't let that intern out of
ignorance simply go in there and start chopping open people's brains because
they think it's simple and easy. To make the assumption that is gonna be
trivial and easy task is ONLY somthing that a inexperienced deveoper going
to make, not somone in our software industry trying to build a soltion for a
customer.

I am simply looking to create the
client contact record. The actual financial information... will all still
be
done directly through simply. I am simply looking to eliminate the
duplication of client information data entry. I'm sorry if your previous
post applied to this case as well, but I just wanted to be explicit about
my
specific case should you have experience with this in particular.

What you said does not change one thing at all.


As I said, you're free now to open and take a look at the tables in simply
with MS access. (it going to take you less time to do that then to write
your post!!! it is possbile that simply uses the standard autonumber field
for the primary key, but I don't think that's what simply uses. They using
custom code that pull the numbers from another table, and then they
increment the value in that table and save it. They then add the
client/vendor reocrd, and then use that new number they just created from
those toher tables as the primary key.

You're probably far better off going to the simply a counting support people
and newsgroups, as I can only speculate here. As I said, directly modifying
the tables is possbile, but it going to be more difficult to add a new
reocrd, especially when you have to assign those internal account numbers
and IDs to that record.

Perahps the best choice is to check if simply supports object automation.
Aautomation is the same thing we do in MS access when we launch outlook, or
words from access, and then have an application do or execute commands that
we want. It's quite easy in MS access to launch a copy of outlook, and at a
new contact to the contacts database. However, to directly modify the
outlook tables is a very difficult task, because we would have to be aware
of all kinds of minor details such as how is the primary key an auto number
generated for this record.

Automnation is your best choice here (if available), and perhaps a second
choice would be the text export/import idea. The last idea would be to try
to add the record directly to the simply tables by opening them via
ms-access.

 

[Question Boy]

Albert,

I don't know and I never assumed it was easy to do. In fact I have no clue.
That was the point of the question(s). To learn from someone such as
yourself who has had experience with SA.

So now that directly updating client info is not looking to promising. Is
there a way to automate the import to your knowledge? I have no issue with
generating a file for import and letting SA perform the import, but can it be
automated so no user intervention is necessary in your opinion?

Also, you mentioned checking out SA forum. Would you happen to have a URL.
I checked their site and got tossed all over the place (general website,
partner portal, ...) but never came across a forum to my knowledge.

Thank you for all your help. You've already saved me countless hours of
trial and error and learning!

QB