I have never used FR but have heard good things about it.



Another response to RB noted some configuration and database space. That is
only if you're storing reports in your database or if you use their end-user
solution.



The other response noted some configuration issues. As long as you have a
TDataset compatible data source, you're good to go.



And, RB's support seems to be very decent. I've needed a solution to an
problem before, called them direct and got the answer.

Again the downside to RB is price but with the reports I've created, it's
been well worth it in spades.



HTH,

Kevin





_____

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of James N Hitz
Sent: Thursday, December 14, 2006 4:28 AM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] My ACCOUNTING table structure



Sorry to drive this thread further off-topic and "off-group" but I can't
help but ask, how does ReportBuilder compare to FastReport, do you know?

Anthony Tanas wrote:

> I'll check it out then, thanks for the suggestion. :)
>
>
> _____
>
> From: firebird-support@ <mailto:firebird-support%40yahoogroups.com>

yahoogroups.com

> [mailto:firebird-support@ <mailto:firebird-support%40yahoogroups.com>

yahoogroups.com] On Behalf Of Kevin Stanton

> Sent: Monday, December 11, 2006 11:18 PM
> To: firebird-support@ <mailto:firebird-support%40yahoogroups.com>

yahoogroups.com

> Subject: RE: [firebird-support] My ACCOUNTING table structure
>
>
>
> Although this is a bit OT for this group, if you spent one day with RB,

you

> would never go back to QR. You can do just about anything in code as well
> with RB. I dumped QR years ago and have never looked back.
>
> _____
>
> From: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> [mailto:firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com] On Behalf Of Anthony Tanas
> Sent: Monday, December 11, 2006 4:10 PM
> To: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> Subject: RE: [firebird-support] My ACCOUNTING table structure
>
> Ah, I currently use QuickReports (Delphi 7). I like being able to anything
> I want from code.
>
> _____
>
> From: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> [mailto:firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com] On Behalf Of Kevin Stanton
> Sent: Monday, December 11, 2006 6:50 PM
> To: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> Subject: RE: [firebird-support] My ACCOUNTING table structure
>
> The application is currently in Delphi 6, using IB Objects (TDataset
> compatible) and the reporting tool is ReportBuilder (
> www.digital-metaphors.com <http://www.digital-
> <http://www.digital- <http://www.digital-
> <http://www.digital- <http://www.digital-metaphors.com/> metaphors.com/>

metaphors.com/> metaphors.com/>

> metaphors.com/> ) which I
> can't say enough about. It has built in capabilities for drill-downs and

is

> extremely easy to set up the drill down. A little spendy but there has not
> been a report that I haven't been able to create.
>
> _____
>
> From: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> [mailto:firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com] On Behalf Of Anthony Tanas
> Sent: Monday, December 11, 2006 3:04 PM
> To: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> Subject: RE: [firebird-support] My ACCOUNTING table structure
>
> OK thanks Kevin. Yes I see the benefit of closing out balances so reports
> don't have to grind through years of data.
>
> No I don't have to worry about company and division. My user will be a
> small medical practice. Occasionally multiple offices will be involved. I
> will not need to track assets or anything of the like at this time.
>
> If I may ask what language/tool do you code in and (if Delphi) what
> components do you use for reports (and does it provide events and the like
> for "drill down" capability?)?
>
> _____
>
> From: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> [mailto:firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com] On Behalf Of Kevin Stanton
> Sent: Saturday, December 09, 2006 10:47 AM
> To: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> Subject: RE: [firebird-support] My ACCOUNTING table structure
>
> Hi Anthony,
>
> I've built an accounting system from scratch and here are some of the

things

> I did (I'm sure they can be improved upon but it currently works):
>
> 1) I have a general ledger table and a sub-ledger table. The
> sub-ledger holds all accounting at the order number level. The general
> ledger holds summarized entries by company, division, accounting period,
> batch id and g/l number. My users can enter in a "batch" of invoices of

say

> 20 or 30 invoices to separate customers. Upon posting the batch, I print

out

> journals for user entry verification (as well as screen edits). Also upon
> posting, a batch id is assigned and the records get posted to the

sub-ledger

> and ledger tables (and others as needed like an invoice history table). My
> general ledger table has one amount field in it but when I run my G/L
> report, I create calculated fields: 1 for a debit amount, and another for

a

> credit amount. I also have a "source" field in the both ledger tables.
> This tells me how the entries got there: INV (invoicing), JRN (journal
> entry), REC (cash receipt), CHK (check/disbursement), ADJ (adjustment).

And

> of course I log the user id and entry timestamp. Having only one field in
> the general ledger table makes it extremely easy to post records to the
> table and query.
>
> 2) Manual journal entries are always required. There are always
> beginning balances even if starting a company from scratch: capital
> investments, cash, fixed assets, etc. And J/E are needed on a monthly

basis

> as well.
>
> 3) I too have a year-end close process that simply roles up all the
> income and expense accounts into retained earnings (or a similar account).
> This process also creates a balance record for each

company/division/year/GL

> account number. This way, I don't have to query many years of data, just

go

> to the g/l balance table, get last year's balances and total up the

current

> year.
>
> 4) I don't have sub-account numbers, just a 10 character G/L number
> but I wish I did have sub-accounts. Several of my customers have requested
> them but changing to a format like that now would be a huge deal.
>
> 5) Reporting you can go crazy on. I've built in some drill-down
> features which have turned out be invaluable. When my customers run the

G/L

> report and select "drill down capability", the user can click on say a

batch

> id of invoices. The report expands to show all the order numbers/source
> entries that make up the summarized G/L report entry. (hope this makes
> sense). I also put the drill down on my balance sheet and income statement
> to show source G/L entries and a drill down within a drill down to show
> order numbers as well. Users really like this and it helps finding entry
> errors.
>
> Also, it can never hurt to have a company field or in my case, company and
> division fields. This way you can have separate financials for each

company

> and/or division. My system can handle multiple companies and multiple
> divisions within a company. If you create something like this then you

will

> probably have to have a "consolidation" feature for your financial

reports.

> This allows the user to create different consolidation combinations with
> company/divisions to typically produce a company-wide balance sheet/income
> statement.
>
> Hope this helps,
>
> Kevin
>
> _____
>
> From: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> [mailto:firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com] On Behalf Of Anthony Tanas
> Sent: Friday, December 08, 2006 11:21 PM
> To: firebird-support@ <mailto:firebird-support%40yahoogroups.com>
> yahoogroups.com
> Subject: RE: [firebird-support] My ACCOUNTING table structure
>
> Some obversations:
>
> a) Is this for a single entity, or are there divisions, branches,
> departments involved? May need additional fields & reporting for this.
>
> Single entity. There may be multiple offices but I think I have that
> covered.
>
> b) Printed output - reports of patients accounts, statements,
> reminders & mailing, aged listings, trial balances, reportwriter access
>
> There will be a "walk out statement" that will correspond to one SUPERBILL
> and a "mail out statement" that will show activity that has an open

balance.

> Also I will need to provide AR reports and various productivity reports.
>
> c) Cash accounting records not clearly detailed here - cash books,
> monthly bank reconciliations
>
> Not sure what you mean about cash accounting records? There will be a CASH
> account, or more specifically two seperated by the source of the money
> (insurance or patient). I'm not sure if bank reconciliation is necessary

as

> I'm not trying to replace the role of an accounting package (at this

time).

> In my current released version of my beta software I have set up a simple
> single entry accounting system (basically just charges and credits) and

have

> run into some issues that are not too cleanly resolved (like refunds,
> patient credits, reversal of write offs, et. al.). I want to do things in
> more of an accounting way to better handle these issues and also I would
> like the option to expand it into a full featured accounting system in the
> future.
>
> d) Budget figures required?
>
> Not at this time.
>
> e) Ledger account entries typically have an opening balance, a debit
> column, a credit column and a (current) balance column, with
> a date for each posting to each account.
>
> Well my LEDGERACCOUNT table just defines the accounts and then the LEDGER
> table stores each transaction. As far as the current balance goes, won't
> that be a calculation? I mean I shouldn't necessarily store that I don't
> think. The opening balance would be assumed to be 0 on all accounts, aside
> from any data I convert into the system.
>
> f) Are subaccounts required to provide a categorised breakdown
> per account?
>
> No, I'm trying to keep it as simple as I can at the moment.
>
> g) Manual Journal entry functionality is commonly required
>
> Can you please elaborate on this? In my application I plan to wrap up all
> of these tables into various classes that will then move data back and

forth

> to the user inteface. My billing screen will have simple to use functions
> for the user for any activities they would need. Basically this would
> include the following functions: adding CHARGES, PAYMENTS, DISCOUNTS,

WRITE

> OFFS, INSURANCE ADJUSTMENTS, REFUNDS and then reverseing any of those. I
> will not allow anything to be deleted once it is "posted".
>
> h) Multiuser with access/role controls for security reasons
>
> Well my system is definately multi-user and I have security. I would take
> care of security at the application level. Basically my application has a
> login, and my application controls what can be done based on the

application

> log in. (There is a single Firebird login embedded in the application.)
>
> i) Ability to handle other accounting functionality - creditors
> & suppliers accounts and payments, rent, repairs & maintenance,
> vehicles, assets, equity & capital accounts etc
>
> Yep, defiantely don't want to do that now. This is a pretty big task at

the

> moment. However I definately want what I do have to be done correctly so
> that I can grow into that sort of thing in the future.
>
> j) Year end accounting close off possibly months after the
> actual end but still able to process & report on the new
> year.
>
> OK, now here is something I was wondering about. Why is this necessary? I
> can tailor my reports to report on any period of time the user wants. Why
> is it necessary to "close off" the account and functionally how would this
> be done?
>
> k) Reporting will be extensive - current output functions
> will be a good guide to the level of complexity & transaction
> volume, which will then indicate the type & extent of
> storage & summarisation required.
>
> HTH,
> John
>
> I guess to summarize what I am trying to do is that I want to have sort of
> minimal accounting functionality done in a correct way so as to be

flexible

> and avoid problems I have encountered in my beta test so far and leave me
> the option to grow accounting functionality in the future. However it is
> not required to take the role of the accounting pacakge at this time.

Thank

> you for your insights! :)
>
> -Anthony
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebird <http://www.firebirdsql.org> sql.org and click

the Resources item

> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoeni

<http://www.ibphoenix.com> x.com

>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>

[Non-text portions of this message have been removed]