#SBPro Question
13 messages in this thread
Hi, Bill —
Thanks for your ideas regarding how I might set up relational files
on
SBP4 for a private practice environment. I am going _very_ slow on this,
as
it seems to me that even though I can set up and connect new files later
in
the process, careful planning now will result in less work and more
productivity later. I want to be able to satisfy easily NH Blue Shield's
requirements for periodic progess reports, since they are providing about
70% of my income, but also meet my own needs for demographics, ledger
card
updates, patient billing, etc. The more I look into SBP4, the more
impressed I get, and your statement about the limitations being only my
imagination or creativity seems quite correct. So, we'll see, I guess….
Again, thanks. I think it was your earlier idea to upload application
ideas
involving SBP4 here. Regardless of where it (the idea) came from, I would
encourage all of us SuperBase/SuperPlan users to act as a resource group
for each other….
— Ed (In Nawth NH) –
Ed,
I've been following your conversation with Bill Roberts with some interest;
I'm a pediatrician and recently purchased SBPro4 to eventually set up my
office totally with AMiga software; I've just begun exploring the basics
of relational files for my patient database. I'd be very interested to see
snippets of what you're doing and would be happy to send you bits and
pieces as I (also very slowly) continue to work on this project.
The biggest hurdle I'm having is in trying to understand how to set up a
billing database; the patient/guarantor/insurance files seem easy enough,
but the conceptual basis for Accounts Recievable and Payable, etc… are
quite foreign to me.
Did you imply that BS is _paying_ you to set up this database, or that 70%
of your patient reimbursements come from BS…if it is the former, i'd be
interested in finding out how you were able to arrange this :^)
Where in NH are you located? I used to live about 1/8" (map-wise :^) )
from Nashua, NH but on the MA side.
Tim
.. Tim Trompeter…
Tim,
I hate to be a spoilsport, but probably the best thing you could do
for your long-term sanity is to get your hands on a decent guide for
understanding relational database management systems (RDBMS).
Basically, the accounts payable, receivable etc. can be dealt with
using a file for account numbers and descriptions, so that everything
is organized by account number, and then using a single file as your
general ledger, so to speak, where all of your transactions are
entered with their specific account numbers, both the debit and the
credit account. ie.:
DATE Credit Account Debit Account Details
1.Apr.92 123 456 Purchased computer book.
where account 123 and 456 are entered into your lookup table as:
Account Number Account Description
123 Computer Literature
456 Cash
Later, when generating your reports, you can then check to make sure
the accounts balance, as well as assigning everything that pays out
(make an extra field for the assignment in the account description
maybe) to Accounts Payable and grouped on Account Number, and the
same for Receivables for your income. I hope this was of some help.
Thanks for the reply. Actually, I've been plodding through several
accounting books and have two different "RDbMS-type" books. I had
originally planned to do this project using Paradox, but of late
decided to go all Amiga (if it's possible:) )
If I ever become "accounting-literate" I'll have half a chance at
tackling this; I'm finding the relational database concepts far
easier than ledgers and accounting.
Thanks again.
Tim,
you're welcome. I truly understand the word *plodding*. Some of these books
are so dry they are absolutely boring. I've found it best to read a bit,
then play with my software a bit, then read it over again. Then I usually
understand better what I am learning. The basic layout I gave you should
get you started. I'll add a couple of tips however:
– Look over the Trading Package example as a place to start.
– Use similar concepts: A main menu program and a program for each form
using CHAIN to travel from one to the other.
– Don't put involved code into your field descriptions. Keep them simple.
– Put the difficult code into DML in a subroutine in the program where it
is actually used. It makes your maintenance simpler later.
– Establish a few naming conventions for variables and subroutines right
at the start.
– I also recommend that you use the same name for the file, form, and the
program that controls the form.
Hope this gets you going in the right direction.
Ciao, Neil
Neil, did you get ahold of John in England?
Regards, Whap!penned…
Pat @Oxxi (310) 427-1227
Pat,
I missed him by an hour or so. The guy I talked to said that they do not
currently have the Amiga Client software available in the UK, that it is
only available in the US. He also didn't otherwise know that much about it
and said that John was definitely the person to talk to. Does he speak
CI$ese? 8-).
Ciao, Neil
Problem is, Neil, he was in and out of here at a dead run — he's on his
way to Chicago for Comdex.
Regards, Whap!penned…
Pat @Oxxi (310) 427-1227
Well Pat,
Once you get him back and stationary for more than a couple of minutes, try
and figure this one out for me. Especially since you are sending me stuff
anyway, this would be the perfect time to send the works. In any case, I
won't have time to set stuff up on the Amiga for at least a week, since I
have a number of clients on the MS-DOS side who are waiting for delivery of
SB4W products.
Ciao, Neil
OK, Neil — though I'm supposed to bug out of here the same week he comes
back, we may overlap…
Regards, Whap!penned…
Pat @Oxxi (310) 427-1227
I might add to this thread that you will find a great deal of the power of
SBPro in the ability to handle many edits and relations in the file
definition or Data Dictionary. The capabilities in SBPro to extablish much
of your relational integrity concerns in the file definitions is one of
it's more powerful features. You are on the right path in trying to
understand the basics of relational system design, especially understanding
the concepts of entity-attribute relationships and the concept of a
'subject database', along with the idea of data driven design: define the
data requirements first, design the files, then begin application
development. It will save a great deal of application re-write and
'patching' later. Fortunatley, SBPo is totally forgiving about file
changes and additions later on, as opposed to some DBM's that are very
sesitive to changes in file structure.
– via Whap!
After setting up the general ledger accounts, you might want to set up
a second file of common transactions. This would consist of a
Transaction key ( BuyEquip ), the account number to debit for the
transaction ( 123 – Small Equipment ) the credit account ( 456 – cash
). The SB4 programs then asks the date, and posts the accounts for
you. Payroll, Accounts Payable, and Accounts Receivable are
variations on this same theme.
If you are just doing accounting, you would probably be better off
just buying one of the existing accounting programs. But if you want
to do some other analysis of the data, you will probably have to
write your own program.
>> careful planning now will result in less work and more productivity
latter.
Anybody setting up a data base should have that phrase tatooed on the
inside of their eyelids with glowing ink. There is no place for poor
planing to show up like a data base. Sounds like you have an
interesting project there. Do you have to consider DRG's for
Medicare as well? If so, good luck. DRG's are the Medical
Programmers' income guartee. On another note: How is Nawth
pronounced? Like North in Baaston (Naughth?).