dcsimg
Results 1 to 20 of 20

Thread: SQL Table and row linking - Double entry accounts

  1. #1

    Thread Starter
    Junior Member
    Join Date
    Aug 2012
    Posts
    31

    SQL Table and row linking - Double entry accounts

    Hello,

    I am making my program, however I am unsure on how to create the double entry accounts side of things.

    Here is the design:

    Tenant transactions
    Landlord transactions
    main cashbook

    Now when I collect the rent it goes into tenant transactions and main cashbook, but inside these tables are the rents collected and fees etc for all the tenants! and in cashbook mixed landlords and tenants.

    I want to make it so once its posted into tenant and casbook transactions to be able to delete it from just one the tables, either. And it deletes from both not just one, otherwise you would have messed up accounts.

    Please, please help me get around this I cant think of any ideas, ids wont work as they might be different or already used in another table, help!!!

    lol

  2. #2
    PowerPoster dunfiddlin's Avatar
    Join Date
    Jun 2012
    Posts
    8,242

    Re: SQL Table and row linking - Double entry accounts

    Well the first thing I would say is that if I were a tenant I would be extremely unhappy with the way things are done. I should expect to have a table (ie. a rent book) to myself and for transactions to be recorded both there and in the main accounts. Secondly I would expect the very idea of 'deleting' any transaction to be anathema!

    Secondly, if you want help coding something, please show us what you have done rather than providing us with airy-fairy concepts. We like to deal in the concrete round here.

  3. #3
    PowerPoster Evil_Giraffe's Avatar
    Join Date
    Aug 2002
    Location
    Suffolk, UK
    Posts
    2,555

    Re: SQL Table and row linking - Double entry accounts

    Just a quick question - what do you expect to get from double entry accounting? Because the way you've described it, I'm not sure you've gained anything. The point of double entry is that you have two separate entries in separate systems, such that incorrect entries (whether that be by fraud or simple mechanical error) in a single system can be detected.
    It seems to me that you can get the same functionality from a single table with a transaction appearing once, and there is a column for the debited account and one for the credited account. Then to display each account you simply select the transactions where the debited account is equal to your account or the credited account is equal to your account.

    If you actually want to do double entry you will need to have two separate systems with two separate databases that have different DBAs that exist on two separate servers that do not have the same server/network admins (which probably means two separate network domains). Are you sure you want to do double entry accounting?

  4. #4
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,410

    Re: SQL Table and row linking - Double entry accounts

    "If you actually want to do double entry you will need to have two separate systems with two separate databases that have different DBAs that exist on two separate servers that do not have the same server/network admins (which probably means two separate network domains). Are you sure you want to do double entry accounting?" -- double entry accounting doesn't mean two different systems... it just means that you have a way of tracking where something came from and where it went... every transaction is entered twice...usually in Debit/Credit pairs... (at a minimum they done as pairs) ... as oppose to a single entry journaling, where a transaction is a single entry. Think of a checkbook register... that's a single entry system. You write a check, and record it in the journal. It's just one entry...


    "I should expect to have a table (ie. a rent book) to myself " ... yeah, one would think so... but as someone that's built A/R systems over the years.... doesn't work out that way.

    As for creating a double entry system... first thing you need to do is to stop thinking like a developer... that's the first mistake often made when creating accounting systems... it ends up being designed and created by developers that have no sense of how accounting works... the next thing to do is to get a book, Accounting for Dummies if you have to... beat yourself over the head until you are sure you're no longer thinking like a developer... then read the book. Then when you have an idea of the basics... use pen and paper to mimic what you are trying to do... smack yourself everytime you think about a table or something programmy.... that's jsut going to get you into trouble. THEN once you have written it all out... THEN you start start thinking like a programmer and breaking things down... but keep that internal accountant handy. And then go make friends with an accountant or CPA that's willing to let you pick their brain on how it should work.

    I can already tell you that your table design... wrong approach...

    you should have a table of Journal Items, as subtable of Jounral Item Details, and one more table that tracks accounts. Each account gets a code. When you then record a transaction, you record A PAIR of transactions...
    First you DEBIT an account, and then CREDIT the next.... the codes recorded with the transactions tell you where the money moved from/to ... if you sum all the debits and subtract the sum of all debits, you should get 0.

    OK...


    So, let's use your example:
    Tennat rent is due....
    in the Accounts table you have the following:
    Code:
    CODE     Account Name           Description
    0001      Rent - Apt 01            Rent for Apt 01
    0002      Rent - Apt 02            Rent for Apt 02
    9999      Cash                        Cash account
    9988      Deposits                   Bank Deposits
    9900      Receivables               Receivable amount
    So let's say the rent on Apt 01 is $500/month .... rent is now due for that tennant....
    So the first thing that needs to be done is to put that tennant into debit and note his rent as a receivable.
    So a Journal Item is created:
    Code:
    ID Date           Description
    1  8/1/2012 -- Rent due for Apt 01
    Now in the Journal Item Details, you record the Debit from the tennat's account, and the crediting of the Receivables:
    Code:
    ID   JOURNALID AccountCode  TransactionType Amount
    1    1              0001              Debit                500
    2    1              9900              Credit               500
    Now we show that the tennant owes us 500 for the rent.... when they make a payment....it's a new Journal Item

    Code:
    ID Date           Description
    2  8/5/2012     Rent paid for Apt 01
    and in the Journal Item Details, we 1) debit the Cash account, 2) credit the tennant's account, 3) debit the receivables, and 4) credit the deposit (presumably the rent will be deposited into the bank).

    Code:
    ID   JOURNALID AccountCode  TransactionType Amount
    3    2              9999              Debit                500
    4    2              0001              Credit               500
    5    2              9900              Debit                500
    6    2              9988              Credit               500
    Head explode yet? This stuff isn't for the weak hearted or timid. It's serious stuff. And I didn't even get into reversals, adjustments or anything like that. This was just a simple example...

    On the other hand... this is all predicated on wanting to do it right. I don't know what your intent is, but trust me... if you're building a foundation for something long term... do it right... trust me. I'm battling a system what was built by developers with no accountant help or any inkling of how accounting works... and it isn't pretty. We recently had someone with an accounting background re-build our entire GL Accounting system... he turned what was close to 30 tables.... into something simple, not all that far different from the designed I just used in my example. Had it happened two years ago.. or right from the start... I wouldn't be worried about ulcers right now... I'be happily plugging away for a new client.

    Anyways, I realize some of this is deep, but at the very least it's worth reading, even if it doesn't stick. It's possible, that this maybe overkill for your needs and you'll just end up ignoring it. That's fine. At least the next time I see some one going down the wrong accounting road, I'll someplace to point them to.

    -tg
    Last edited by techgnome; Aug 13th, 2012 at 12:24 PM.
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  5. #5

    Thread Starter
    Junior Member
    Join Date
    Aug 2012
    Posts
    31

    Re: SQL Table and row linking - Double entry accounts

    Thank you for your replies.

    I have misunderstood double entry accounts it seems, I used to work for a company who sold lettings software etc, it was no double entry and if you deleted a transaction from say the cashbook it didnt from the tenant transaction log, so the accounts got messed up and clients were not happy as you can imagine!

    My idea is to make software that does not have the same mistakes and more user friendly functionality. So Ill start again.

    Oh and to the first reply, I would give each tenant a separate one, but how can I have tables for each individual tenant and property, the database would be huge and untidy.

    I planned to have a table purely for tenants transactions using a unique tenant id, the same for landlords, agents and the maincash book.

    My confusion is deletions,

    I can easily use insert statements to put the rows into each seperate table using a button, however they are not linked and if then I added a deletion button, it would delete the seperate row in the individual table.

    I want one button to delete a linked transaction, so If I deleted it from cashbook, OR tenant transactions, it would remove the row from the remaining entity.

    I hope this makes more sense.

    I appreciate your replies thanks.

  6. #6
    Frenzied Member MattP's Avatar
    Join Date
    Dec 2008
    Location
    WY
    Posts
    1,227

    Re: SQL Table and row linking - Double entry accounts

    http://msdn.microsoft.com/en-us/library/ms973833.aspx

    Some business rules require that a group of modifications be treated as a single transaction. For example, in accounting software, a debit and a credit must succeed or fail together because the accounts must "balance." If a debit succeeds and the credit fails, the accounts will not balance.
    This pattern in common to all great programmers I know: they're not experts in something as much as experts in becoming experts in something.

    The best programming advice I ever got was to spend my entire career becoming educable. And I suggest you do the same.

  7. #7
    PowerPoster dunfiddlin's Avatar
    Join Date
    Jun 2012
    Posts
    8,242

    Re: SQL Table and row linking - Double entry accounts

    the database would be huge and untidy
    Unless you have several million clients it will certainly not be huge and it was exactly for the purpose of keeping these kinds of records that relational databases were invented in the first place. Untidy is having all the different tenants thrown in together without any obvious way of tracking their payment records. When you're handling people's payments it makes sense to have corroborating records even if they are otherwise redundant. And as I said, there should never be any need to delete an entry of any kind. Even if a mistake is made it should be corrected by a further entry never wiped away.

  8. #8
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,410

    Re: SQL Table and row linking - Double entry accounts

    Uhhhh.... yeah no. If you're putting tennant payments into different tables as your sole means of keeping them seperated.... something is wrong. If you're building a library systembwoild you put mystery in one table and scifi in another and historical fiction in yet another table? No... you would have a categories table... and then the book table would fkey to it. Your solution sounds EXACTLY what the past developers did to our system... and *I* am the one paying for it. There are now a dozen tables, all which look like each other all storing the same info... the only difference is one stores revenue one stores property another etoresbstock another benefits.... and so on. Then try reporting on it... trust me, its bs.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  9. #9
    PowerPoster dunfiddlin's Avatar
    Join Date
    Jun 2012
    Posts
    8,242

    Re: SQL Table and row linking - Double entry accounts

    As you will but I'm bound to point out that books are not making regular payments to anyone and expecting you to know exactly when and how the money was received! And I'm afraid property, revenue, stock and benefits are entirely different things and it's quite appropriate to have them separately recorded. I would seriously consider consulting with the company accountant and a tax expert before you commit yourself to a single entry system if this is going to be your main or sole record.

  10. #10
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,410

    Re: SQL Table and row linking - Double entry accounts

    I'm afraid we'll have to agree to disagree... and I never advocated a single entry system... if you look back on my example, you'll see that it is in fact a double entry accounting system... I have worked with accountants before... that's how I came to help build A/R systems... while they may be physically different... all of those to an accountant, are all the same... they are financial transactions... OK... so you want to know all of the payments made by the tenant in Apt 01? Query it out... SELECT * FROM JournalItem where TenantID = 1 ... what's so hard about that? Yes, a book isn't going to make payments, but it does get checked in and out... a book is a book, a tenant is a tenant.

    Ok, let's look at it this way.... as the Management of the apartment complex.... I want to see ALL payments .... if it's all in the JournalItem table.... SELECT sum(Amount) from JournalItem .... baddabing.... done... otherwise I have to go to each table and sum it up, then sum up those results. Heck! What if a tenant moves out? Now their table is invalid! Now I have to figure out when to include a table or exclude it...


    But hey... what ever... I don't have to maintain it or use it so what do I care?

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  11. #11
    PowerPoster Evil_Giraffe's Avatar
    Join Date
    Aug 2002
    Location
    Suffolk, UK
    Posts
    2,555

    Re: SQL Table and row linking - Double entry accounts

    Quote Originally Posted by techgnome View Post
    "If you actually want to do double entry you will need to have two separate systems with two separate databases that have different DBAs that exist on two separate servers that do not have the same server/network admins (which probably means two separate network domains). Are you sure you want to do double entry accounting?" -- double entry accounting doesn't mean two different systems... it just means that you have a way of tracking where something came from and where it went... every transaction is entered twice...usually in Debit/Credit pairs... (at a minimum they done as pairs) ... as oppose to a single entry journaling, where a transaction is a single entry. Think of a checkbook register... that's a single entry system. You write a check, and record it in the journal. It's just one entry...
    Okay, looks like I got myself confused. I thought the separate recording was an integral part of the DE system, but I was clearly mistaken. So what I described above apparently is still essentially a Double Entry system by my revised understanding because the transaction is linked to two accounts. I suggested recording the transaction with a single line, because I'm not really sure what the difference is in terms of data storage between:

    Code:
    ID   JOURNALID AccountCode  TransactionType Amount
    1    1         0001         Debit           500
    2    1         9900         Credit          500
    and

    Code:
    ID   JOURNALID DebitAccount CreditAccount Amount
    1    1         0001         9900          500
    When pen and paper was used, the transactions were recorded twice to detect recording errors. Nowadays we can rely on databases to store these things correctly. Both of those lines in the first example will be recorded in a single transaction, right? So they will either succeed or fail together. There are no transcription errors where one record will be recorded and the other not. Similarly, the 'amount' value will be calculated once and put in the SQL INSERT statements without any risk, so we don't really gain anything from being able to check that the amount values match.

    What I hadn't accounted for in my thinking was the next example you give where there are four entries for one journal item - but this surely is two transactions?

    This is just my understanding of the intent of the system - I've picked up bits from my delving into single-entry systems (I have a slow-burning cashbook type app I'm (not really) working on in the background). I really would be interested to hear if there's something I'm actually missing. Clearly, the accountants would want to have this data presented with two separate entries on screen, but that doesn't necessarily mean it must be persisted like that, no? Although, having said that I don't see anything inherently harmful about storing it with two records (database transactions allowing us to know that they'll be recorded correctly as per my argument for the opposite above; storage costs being negligible; can't imaging the additional IO will be horrific given the data almost certainly will be written to disk right next to each other) so the additional harmony between the persisted form and the user mental model is probably worth it.

  12. #12

    Thread Starter
    Junior Member
    Join Date
    Aug 2012
    Posts
    31

    Re: SQL Table and row linking - Double entry accounts

    Hi Guys,

    I've worked it out properly in my head now after a lot of thinking my head literally hurt and I wanted to go crazy and smash things up because it seemed too complicated, however after thinking logically;

    Conclusion;

    1 table purely for transactions,

    The table will have transactions for landlords, tenants, contractors and the main cashbook.

    I will seperate each entity by a uniqueID for each transaction, the cusID(Imported from the landlord,tenant or contractor tables) each tenant landlord and contractor has a primary key so each table i.e tenant table has a unique row reference will will be the CusID in transaction table.

    There will be duplicate CudID's in transaction table, but thats perfect as I will then have colums IsTenant, IsLandlord etc.. So

    1) Primarykey 300.00 33(cusid) 4531(uniquetransid) 1(istenant) 0(islandlord) 0(iscontractor)

    So if I wanted to have a tenant record open on the transaction tabs, I could use something like select * from transactions where cusid = 33 and istenant = 1

    As 33 in the tenant table is unique and is tenant = 1.

    Same applies for landlords and also deleting transactions delete from transactions where cudid = 33 and transactionid = 232 and istenant = 1

    Does this make sense?

  13. #13
    PowerPoster Evil_Giraffe's Avatar
    Join Date
    Aug 2002
    Location
    Suffolk, UK
    Posts
    2,555

    Re: SQL Table and row linking - Double entry accounts

    Quote Originally Posted by andybonse2012 View Post
    Does this make sense?
    Given that you're still talking about
    Quote Originally Posted by andybonse2012 View Post
    and also deleting transactions
    then, no not really - why are you deleting transactions?

    Also this:
    Quote Originally Posted by andybonse2012 View Post
    I will seperate each entity by a uniqueID for each transaction, the cusID(Imported from the landlord,tenant or contractor tables)
    ...
    There will be duplicate CudID's in transaction table, but thats perfect as I will then have colums IsTenant, IsLandlord etc..
    No, this is wrong. You have one table holding the primary record for your customers (which might be specialised with additional tables or optional columns). Do not keep tenants landlords and contractors separately - a customer is a customer - if the same customerId value can be used for separate tenants, landlords and contractors then you've got something really badly wrong.

  14. #14

    Thread Starter
    Junior Member
    Join Date
    Aug 2012
    Posts
    31

    Re: SQL Table and row linking - Double entry accounts

    Deletions are there for if they collect the rent e.g. and input the wrong amount, can easily then go delete and re collect. Rather than having contra entries. I'm just going by other providers I've seen. Obivously only the managers of the company can delete them. Lets face it, putting adjustments into it would mess with reconciliation as adjustments wouldnt exist in the bank.

    As for seperate tables for contractors and that, its because each type of customer has different data, e.g applicants will need matching information, how many bedrooms, how much rent they want to pay etc.

    Landlords and contractors do not need these.

  15. #15
    PowerPoster Evil_Giraffe's Avatar
    Join Date
    Aug 2002
    Location
    Suffolk, UK
    Posts
    2,555

    Re: SQL Table and row linking - Double entry accounts

    Quote Originally Posted by andybonse2012 View Post
    Deletions are there for if they collect the rent e.g. and input the wrong amount, can easily then go delete and re collect. Rather than having contra entries. I'm just going by other providers I've seen. Obivously only the managers of the company can delete them. Lets face it, putting adjustments into it would mess with reconciliation as adjustments wouldnt exist in the bank.
    I'd suggest you re-read tg's first post in this thread where he walks you through the transactions involved in this. Note how the bank deposit transaction (which is what you would reconcile against) is a separate journal item to the initial debiting of the tenant's account when the rent is due? What if adjustment transactions were made between those two journal items that adjusted the tenant's account - would they affect the bank deposit account?

    Quote Originally Posted by andybonse2012 View Post
    As for seperate tables for contractors and that, its because each type of customer has different data, e.g applicants will need matching information, how many bedrooms, how much rent they want to pay etc.

    Landlords and contractors do not need these.
    Hint: I think you maybe need to separate the idea of an account out from your concept of tenants, landlords and contracts.

  16. #16
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,410

    Re: SQL Table and row linking - Double entry accounts

    E_G - there's one condition where your single line, double entry won't work (and I see this a lot) ... since this is a simply system, it's not necessary, but in my real world situation, I can have a single payment that goes to more than one acccount... that's why we record on multiple lines. This case though is a much simpler case and so having both the credit and debit account on the same line is probably adequate.

    andy - the idea behind the ledger idea is that things are never deleted... never. If you need to make an adjustment, you do just that, record an adjustment. The way we do it (which I'm not sure I completely agree with) is to REVERSE the original transaction, then issue NEW transactions for the correct amount.

    So let's go back to the example I last left with:
    Code:
    ID   JOURNALID AccountCode  TransactionType Amount
    3    2              9999              Debit                500
    4    2              0001              Credit               500
    5    2              9900              Debit                500
    6    2              9988              Credit               500
    Oooops! Their rent is only $400.... not $500....
    Because we are still dealing with the same parent transaction we simply add new details to the journal

    First we reverse the original amount by swapping the debit and credit accounts... putting the money back...
    Code:
    ID   JOURNALID AccountCode  TransactionType Amount
    7    2              9988              Debit                500
    8    2              9900              Credit               500
    9    2              0001              Debit                500
    10   2              9999              Credit               500
    Now that we've reversed the original transactions... we issue new transactions for the new amount....
    Code:
    ID   JOURNALID AccountCode  TransactionType Amount
    11   2              9999              Debit                400
    12   2              0001              Credit               400
    13   2              9900              Debit                400
    14   2              9988              Credit               400
    Nothing is EVER deleted, and you're left with a historical ledger that shows what happens to your accounts over time.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  17. #17

    Thread Starter
    Junior Member
    Join Date
    Aug 2012
    Posts
    31

    Re: SQL Table and row linking - Double entry accounts

    Hi,

    I see, so typically, I should have no delete option, but have a Adjustment option. I guess it would make sense as deleting things would make it messy and untrue.

    E.g

    Collect rent 400 but was meant to be 500. Make an adjustment into the transactions for that tenant for 100? Showing whats happens and how its been resolved?

    I'm not 100% how you are using the account codes as obviously you understand accounting a lot better than me, I have however used sage before and seethe same type of structure.

    My program will consist of:

    Transactions table and will have the following screens:

    Cashbook - Will show all of the transactions with a total balance.
    Cashbook Reconciliation - Will have 2 screen reconciled and non reconciled, I will split these by a column integer IsReconciled = 0 or 1.
    Tenant Transactions - This will show the specific transactions for that tenant, split by the CusID.
    Landlord Transactions - Same as above but for landlord
    Contractor Transactions - ""
    Agent Transactions - Same as above, but this is for commission from contractor jobs.

    I think this is all I need so far, I will get some code sorted for you but I'm first planning the exact way the accounts are going to work, rather than do it and have to re-do it all!

  18. #18
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,410

    Re: SQL Table and row linking - Double entry accounts

    you could simply enter new transactions, yes, that's also an acceptable way of recording it... the system I work on does it the long way (by reversing everythign then re-issuing transactions)... but yes, the idea is to never actually delete anything. From the user's perspective you could still call it "Delete" ... but behind the scenes, you wouldn't actually delete.

    The account codes relate to what the transaction is... so there's an account code for each of the apartments, an account code for contractor payouts, account codes for landlord transactions....and so on... so for each type of transaction, there would be a corresponding code.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  19. #19

    Thread Starter
    Junior Member
    Join Date
    Aug 2012
    Posts
    31

    Re: SQL Table and row linking - Double entry accounts

    Ah, I see!

    I have a column called transaction_type, like rent received / rent charged etc..

    Should I put another column in and give all the rent charged a code like 9999 and then rent received 9998 and then make a report run to show all transactions for say code 9999.

    The only thing I don't understand is if the rent is received in (debit), wheres the credit? As with double entry there must be a debit and credit for each transaction am I correct?

    Usually the accountant would come with Sage to clients and do their accounts collecting the information from our system
    Last edited by andybonse2012; Aug 14th, 2012 at 08:59 AM.

  20. #20
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,410

    Re: SQL Table and row linking - Double entry accounts

    the credit goes against the tenant's account.... and you don't necessarily have to have actual account codes .... just some kind of code to show where the credit and debits are coming from/going to. At this point, I REALLY highly suggest picking up a copy of Accounting for Dummies.... it would help ALOT (it did for me, and that was AFTER I'd gotten into this)...

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width