Business Accounting Design Document, v0.1

[Derek Atkins]

Josh Sled <jsled@asynchronous.org> writes:

[ GUID stuff snipped ]

> I think you likely want both.

Yes.  I have both.

> | The object descriptions here are mostly done in C, for simplicity.
> | SQL Definitions can be easily derived, as most of these objects were
> | shamelessly grabbed from JobTracker and SQL-Ledger SQL table
> | definitions (or in many cases changed to suit the needs herein).  In
> | fact, these objects were designed specifically to be stored in a
> | SQL-style database.
> 
> Why?  Why does it matter?  Do you have existing datastores that you want
> to convert over?

Me personally?  No.  But I know others who do.  Considering all the
other tools from which I based my initial research used SQL, I was
trying to grab my ideas from there, mimic what they do, so I could
provide similar functionality.

> I'd recommend using VCard for contact info [this, and Shipping], if
> possible...  a) it's a level of detail and vocabulary that people are
> used to and b) it's supported by other programs...

Are you talking internally or as a saved format?  At the point I was
writing this I was talking in the abstract.

> |  int	 Terms;
> 
> Eh?  I'm assuming this decodes somehow into "Net-15" , "Net-30" or
> something...?

Yea...

> |  bool  TaxIncluded;
> 
> Is this really a property of a Customer?

Well, SQL-Ledger seemed to think it was.

> |  float	 Discount;
> 
> Eh?

Do we provide this Customer a discount, and if so, what percent
discount do we provide them.  This is, obviously, just a default value
and can be changed an a per-order, per-item basis.

> |  bool	 Active;
> 
> Perhaps 'date completed', and (!valid(date_completed) == active)?

Not required for a Job.  Perhaps this should be changed into "show-p"
or "hide".  The point is to have a simple flag for whether to show
this Job in the default list.  In fact, all object (now) have this
flag (or at least something similar).

> | 2.4. Sales Order
> | 
> | A Sales Order is an object that maintains order and service
> | information.  It is basically a collection of billable (or
> | non-billable) items that are applied to a Job and will eventually be
> | invoiced.
> 
> Thought:
> Non-billable := zero amount split/transaction
> Billable := non-zero amount split/transaction
> Fixed-cost service = Billable
> Material item = Billable
> 
> I wonder if that simplifies things at all... I guess you do want to be
> able to list them seperately on the invoice, but perhaps that can be done
> as a KVP-frame elt.

Actually, I kind of did it this way...

> | SalesOrder {
> 
> |  date	   Date;
> 
> This is the date-of-billing?  The date-of-sale?  What if there's a 6-mo
> sales cycle?  Or even a 6-day sales cycle?

This structure was confusing...  As I said it was part of a SQL table;
each "SalesOrder" is really a line-item.  So, this would be the date
of the specific order.

> |  float	   Tax;
> 
> How is this not just a split in the transaction?

The tax is tied to the line-item.  There is no transaction.

> |  bool	   Billed;
> 
> Perhaps: date_billed and ( !valid(date_billed) -> !billed ) ?

The date_billed is part of the invoice.  This flag really means
"invoiced?"  It could probably be implemented as "is_valid
(invoice-id)".

> |  chat *	 Notes;
> 
> So this is an array of IM "chat" logs... ;)

*thwap*

> | 2.7. Employee
> 
> | Employee {
> 
> |  char *	 Language;	// To allow customization of the UI
> 
> Seems like a UI thing, not an engine thing... the language choice the
> user runs the interface with will allow all customization of the UI.

This came from, I believe, JobTracker.  You are right that it could
probably go away here.

> |  char *	 ACL;		// Access Control List, for system permissions
> 
> There was discussion about this a while ago, I believe, WRT the SQL
> backend ... I don't believe that this necessarily should be a feature of an
> engine object... it seems more like a UI/engine-consumer thing... perhaps
> first-order "Credentials" are in order, but not for the engine...?

Why not?  Employee's can relate almost directly to actual users of the
system.  Based on that assumption, having a permissions list tied to
the employee is just as good as anywhere else to have it.

I think having access control mechanisms in the engine is ABSOLUTELY
the right place to enforce it.  To draw an analogy from distributed
systems, you want to present the access-control at the client but
you want to ENFORCE it at the server.  The reason:  the interface
between client and server can be reproduced and you (as a server) don't
want to trust the client to protect your data.  Similarly, the engine
should not trust the GUI to protect the data.

> |  float	 WorkDay;	// Default work day
> |  float	 Rate;		// Default Billing Rate
> 
> What if this varies per job?

Then you change them.  They are just default values to supply
_something_ to begin with; a way to simplify in the "usual"
case.

> For instance, on one job, I'm out of my element technically [it's highly
> hardware-based], and I do docs... on another [highly software-based],
> I do software.  For the former, it's $30/hr ... for the latter, $80/hr.

That's fine; assume you work on software 80% of the time.  When you
enter billable hours for jobs at the hardware rate, you just have to
manually change it in the billing entry.

An extension here would be a list of rates....

> ...jsled

Thanks for your comments.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available