January 9, 2020 at 2:15 pm
jcelko212 32090 wrote:>> Given the request, pretty sure that debit and credits represent units in inventory NOT currency. <<
Why would you say "debit" and "credit" which are terms from accounting? What
about "restock" , "withdrawals", "shrinkage", etc?
>> As to just simply recommending fundamental changes to an accounting ledger....wow <<
And I also recommend normalizing databases ..Wow! Seriously, I do not like using a data model that is hundreds of years old and based on Roman numerals. O probably ought to write an article or book chapter on the changes that came with EDP and Arabic numerals.
For someone who just finished expounding on the use of standards, recommending that someone change away from the *well established and still currently in force* industry standard for the field of accounting rings a bit phony. The review standards applied to said antiquated concepts would make ISO look like playground antics. Perhaps you should go get on the IFRS review committee and tell them how antiquated and ridiculous their model is.
Of course I probably wouldn't be objecting so strenuously if you weren't spending so much time on answering anything other than something useful to the OP's request.
Can you post the link to IFRS's recommended database schema for accounting? Without this, I'd still agree with what Joe posted as far as the schema because he's pretty much correct. _However_ if an accounting authority has mandated database schema that needs both debit and credit columns, well I have a stack of vendors I need to rat out LOL
Of course I probably wouldn't be objecting so strenuously if you weren't spending so much time on answering anything other than something useful to the OP's request.
This does have some merit, sometimes its ill advised to change database design because it might not be in OP's power to make the change.
January 9, 2020 at 2:40 pm
Matt Miller (4) wrote:jcelko212 32090 wrote:>> Given the request, pretty sure that debit and credits represent units in inventory NOT currency. <<
Why would you say "debit" and "credit" which are terms from accounting? What
about "restock" , "withdrawals", "shrinkage", etc?
>> As to just simply recommending fundamental changes to an accounting ledger....wow <<
And I also recommend normalizing databases ..Wow! Seriously, I do not like using a data model that is hundreds of years old and based on Roman numerals. O probably ought to write an article or book chapter on the changes that came with EDP and Arabic numerals.
For someone who just finished expounding on the use of standards, recommending that someone change away from the *well established and still currently in force* industry standard for the field of accounting rings a bit phony. The review standards applied to said antiquated concepts would make ISO look like playground antics. Perhaps you should go get on the IFRS review committee and tell them how antiquated and ridiculous their model is.
Of course I probably wouldn't be objecting so strenuously if you weren't spending so much time on answering anything other than something useful to the OP's request.
Can you post the link to IFRS's recommended database schema for accounting? Without this, I'd still agree with what Joe posted as far as the schema because he's pretty much correct. _However_ if an accounting authority has mandated database schema that needs both debit and credit columns, well I have a stack of vendors I need to rat out LOL
Of course I probably wouldn't be objecting so strenuously if you weren't spending so much time on answering anything other than something useful to the OP's request.
This does have some merit, sometimes its ill advised to change database design because it might not be in OP's power to make the change.
Sorry if I was unclear - but I was taking issue with trying to rewrite accounting ledgers without debits and credits. In this case "model" wasn't data model per se, but the conceptual entity model. Besides the fact that Joe actually didn't know enough to know that's more complicated that just putting a sign on a number and thus is offering poor advice, advising anyone to just go mess with the accounting system's physical data model is misguided at best.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
January 9, 2020 at 3:27 pm
Sorry if I was unclear - but I was taking issue with trying to rewrite accounting ledgers without debits and credits. In this case "model" wasn't data model per se, but the conceptual entity model. Besides the fact that Joe actually didn't know enough to know that's more complicated that just putting a sign on a number and thus is offering poor advice, advising anyone to just go mess with the accounting system's physical data model is misguided at best.
First off, its been an old habit of Joe's that he objects to data models without regard to poster's ability to effect their change. I like reading these, but I can understand that others don't, so enough said about that. I certainly don't recommend anybody go in to their accounting systems and delete columns but I'd hazard a guess that this isn't Joe's actual advice either, although sure I probably shouldn't speak for everyone LOL
But lets say this isn't even an accounting question. All you have to do is ask yourself, do you lose any information when you use a different format for saving information? To test that, see if you can change the representation from two columns to one, and then reconstruct the original two column representation and then check to see if the information matches.
So can you do this or can't you? The ONLY question you have to ask, is if the OP's design allows negative numbers. If the OP NEEDS to be able to have a negative number in either the credit or debit column, then Joe's assumption fails. If you are writing accounting software, until I'm proved wrong on this, its my view that Joe's model is not only correct, but has efficiencies. Prove me wrong on this and I'll be a fan of yours, but please make it a proof that stands examination.
Still, let me reemphasize, if the original objection had been something along the lines of "the OP probably can't change the database design" then that's something I'd be in agreement with.
January 9, 2020 at 3:39 pm
I defy you to produce a proper Balance Sheet without distinguishing between debits and credits. Show me how that would be done.
I gotta go with Joe on this. The sign on the entry line in combination with the chart of accounts should square away what a debit is and what a credit is. You REALLY REALLY need that chart of accounts in any case, otherwise what would you validate your account number against?
No, you don't need to reference an entire COA -- which can be very large, btw -- if you have separate debit and credit columns. Indeed, the point is to be able to get debit and credit totals without having to reference the COA. You only need the COA for certain tasks, not for every total you do or every report you create.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
January 9, 2020 at 3:51 pm
x wrote:I defy you to produce a proper Balance Sheet without distinguishing between debits and credits. Show me how that would be done.
I gotta go with Joe on this. The sign on the entry line in combination with the chart of accounts should square away what a debit is and what a credit is. You REALLY REALLY need that chart of accounts in any case, otherwise what would you validate your account number against?
No, you don't need to reference an entire COA -- which can be very large, btw -- if you have separate debit and credit columns. Indeed, the point is to be able to get debit and credit totals without having to reference the COA. You only need the COA for certain tasks, not for every total you do or every report you create.
Without knowing the account, how do you tell whether a transaction's debit increases or decreases an accounts balance?
January 9, 2020 at 3:51 pm
ScottPletcher wrote:x wrote:I defy you to produce a proper Balance Sheet without distinguishing between debits and credits. Show me how that would be done.
I gotta go with Joe on this. The sign on the entry line in combination with the chart of accounts should square away what a debit is and what a credit is. You REALLY REALLY need that chart of accounts in any case, otherwise what would you validate your account number against?
No, you don't need to reference an entire COA -- which can be very large, btw -- if you have separate debit and credit columns. Indeed, the point is to be able to get debit and credit totals without having to reference the COA. You only need the COA for certain tasks, not for every total you do or every report you create.
Without knowing the account, how do you tell whether a transaction's debit increases or decreases an accounts balance?
Heck, for that matter, without knowing the account, how do you know which account gets its balance changed? So many questions!
January 9, 2020 at 3:53 pm
x wrote:ScottPletcher wrote:x wrote:I defy you to produce a proper Balance Sheet without distinguishing between debits and credits. Show me how that would be done.
I gotta go with Joe on this. The sign on the entry line in combination with the chart of accounts should square away what a debit is and what a credit is. You REALLY REALLY need that chart of accounts in any case, otherwise what would you validate your account number against?
No, you don't need to reference an entire COA -- which can be very large, btw -- if you have separate debit and credit columns. Indeed, the point is to be able to get debit and credit totals without having to reference the COA. You only need the COA for certain tasks, not for every total you do or every report you create.
Without knowing the account, how do you tell whether a transaction's debit increases or decreases an accounts balance?
Heck, for that matter, without knowing the account, how do you know which account gets its balance changed? So many questions!
Also, are you saying we database people should work only with small tables? Can you elaborate?
January 9, 2020 at 6:58 pm
x wrote:x wrote:ScottPletcher wrote:x wrote:I defy you to produce a proper Balance Sheet without distinguishing between debits and credits. Show me how that would be done.
I gotta go with Joe on this. The sign on the entry line in combination with the chart of accounts should square away what a debit is and what a credit is. You REALLY REALLY need that chart of accounts in any case, otherwise what would you validate your account number against?
No, you don't need to reference an entire COA -- which can be very large, btw -- if you have separate debit and credit columns. Indeed, the point is to be able to get debit and credit totals without having to reference the COA. You only need the COA for certain tasks, not for every total you do or every report you create.
Without knowing the account, how do you tell whether a transaction's debit increases or decreases an accounts balance?
Heck, for that matter, without knowing the account, how do you know which account gets its balance changed? So many questions!
Also, are you saying we database people should work only with small tables? Can you elaborate?
You specifically, yes, you should stick to very small tables indeed.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
January 9, 2020 at 7:09 pm
x wrote:x wrote:x wrote:ScottPletcher wrote:x wrote:I defy you to produce a proper Balance Sheet without distinguishing between debits and credits. Show me how that would be done.
I gotta go with Joe on this. The sign on the entry line in combination with the chart of accounts should square away what a debit is and what a credit is. You REALLY REALLY need that chart of accounts in any case, otherwise what would you validate your account number against?
No, you don't need to reference an entire COA -- which can be very large, btw -- if you have separate debit and credit columns. Indeed, the point is to be able to get debit and credit totals without having to reference the COA. You only need the COA for certain tasks, not for every total you do or every report you create.
Without knowing the account, how do you tell whether a transaction's debit increases or decreases an accounts balance?
Heck, for that matter, without knowing the account, how do you know which account gets its balance changed? So many questions!
Also, are you saying we database people should work only with small tables? Can you elaborate?
You specifically, yes, you should stick to very small tables indeed.
So what's the reasoning here? I don't usually argue against efficiencies, heck that's why I'm posting in support of Joe's post. But honestly, even a very large chart of accounts even with subsidiary ledgers are going to be subsequently dwarfed by the transactions against them, and we don't discard our transactions in accounting systems right? Can you elaborate on this some? This is very counter intuitive.
I'm not saying some efficiencies aren't going to be debatable, but the reason I questioned your assumption on the two column deal, is that the subsequent complexity required WAS NOT VERY COMPLEX and in fact I would suspect it should not be a complexity. Now you are going forward still, with reservations about looking up accounts in a chart of accounts because of the chart of accounts size.
January 9, 2020 at 7:11 pm
So can you do this or can't you? The ONLY question you have to ask, is if the OP's design allows negative numbers. If the OP NEEDS to be able to have a negative number in either the credit or debit column, then Joe's assumption fails. If you are writing accounting software, until I'm proved wrong on this, its my view that Joe's model is not only correct, but has efficiencies. Prove me wrong on this and I'll be a fan of yours, but please make it a proof that stands examination.
Still, let me reemphasize, if the original objection had been something along the lines of "the OP probably can't change the database design" then that's something I'd be in agreement with.
Well I won't speak on behalf of the OP, but having spent a LOT of time dealing with accounting and financial feeds, credits and debits these days can have both positive and negative amounts, which as you mentioned would invalidate JC's design. For example, an administrative reversal of certain activities are logged using the opposite sign but in the same debit or credit bucket, as opposed to putting an entry on the other side.
Also - even if you somehow didn't have that behavior, just having the expertise by which you could get the signs right (like scott P mentioned it is not as simple as d=positive and c=negative or the other way around) would require you to be a full on accountant. Never mind the impacts on everything that's been built (journals, reports etc...)
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
January 9, 2020 at 7:57 pm
x wrote:So can you do this or can't you? The ONLY question you have to ask, is if the OP's design allows negative numbers. If the OP NEEDS to be able to have a negative number in either the credit or debit column, then Joe's assumption fails. If you are writing accounting software, until I'm proved wrong on this, its my view that Joe's model is not only correct, but has efficiencies. Prove me wrong on this and I'll be a fan of yours, but please make it a proof that stands examination.
Still, let me reemphasize, if the original objection had been something along the lines of "the OP probably can't change the database design" then that's something I'd be in agreement with.
Well I won't speak on behalf of the OP, but having spent a LOT of time dealing with accounting and financial feeds, credits and debits these days can have both positive and negative amounts, which as you mentioned would invalidate JC's design. For example, an administrative reversal of certain activities are logged using the opposite sign but in the same debit or credit bucket, as opposed to putting an entry on the other side.
Interesting point!
A counterpoint to this would be to have a credit / debit indicator, this means you can ditch the extra numeric but still have room for a sign to handle the negative column entries, _HOWEVER_ "administrative reversals" being signified with a sign looks like bad coding honestly. Can you elaborate on these? When would an administrative reversal not just be a manual journal adjustment? Would there be a better term that you might not have handy?
The "administrative reversal" of a journal entry sounds suspiciously like a reason for the journal entry being entered. Wouldn't the sign signify a really small number of possible reasons for the journal entry? Like ie., 1?
Wouldn't it be better to do a correcting entry instead?
https://www.accountingtools.com/articles/correcting-entry-definition-and-usage.html
That said, since I'm sure many of us get to have fun with financial stuff, I'd love to hear more about when "administrative reversals" are used, especially with documentation that can fit in a sign bit LOL
Also - even if you somehow didn't have that behavior, just having the expertise by which you could get the signs right (like scott P mentioned it is not as simple as d=positive and c=negative or the other way around) would require you to be a full on accountant.
I mean once you enter the discussion, don't you have to be able to solve development problems in the domain? I get it, in today's environment, its going to be pretty rare that we develop accounting systems from scratch, but by golly we'd better either understand the signs, debits, and credits, or get with someone who does right?
Scott struggles with case statements and now he's now doubling down and saying database systems CANNOT BE TASKED WITH DOING LOOKUPS ON THE CHART OF ACCOUNTS. I think I can excuse him from the discussion at this point, but if my posting sends otherwise competent folks into crazytown maybe my posts aren't as valuable as I'd like to think LOL
Never mind the impacts on everything that's been built (journals, reports etc...)
Well that I can agree on, like I said Joe likes to criticize database designs without regard to whether the OP can change them or not, and while I enjoy these critiques, if someone else asked him to stop I guess that I wouldn't feel so compelled to junk up the thread with my comments 🙂
January 9, 2020 at 8:36 pm
Matt Miller (4) wrote:x wrote:So can you do this or can't you? The ONLY question you have to ask, is if the OP's design allows negative numbers. If the OP NEEDS to be able to have a negative number in either the credit or debit column, then Joe's assumption fails. If you are writing accounting software, until I'm proved wrong on this, its my view that Joe's model is not only correct, but has efficiencies. Prove me wrong on this and I'll be a fan of yours, but please make it a proof that stands examination.
Still, let me reemphasize, if the original objection had been something along the lines of "the OP probably can't change the database design" then that's something I'd be in agreement with.
Well I won't speak on behalf of the OP, but having spent a LOT of time dealing with accounting and financial feeds, credits and debits these days can have both positive and negative amounts, which as you mentioned would invalidate JC's design. For example, an administrative reversal of certain activities are logged using the opposite sign but in the same debit or credit bucket, as opposed to putting an entry on the other side.
Interesting point!
A counterpoint to this would be to have a credit / debit indicator, this means you can ditch the extra numeric but still have room for a sign to handle the negative column entries, _HOWEVER_ "administrative reversals" being signified with a sign looks like bad coding honestly. Can you elaborate on these? When would an administrative reversal not just be a manual journal adjustment? Would there be a better term that you might not have handy?
The "administrative reversal" of a journal entry sounds suspiciously like a reason for the journal entry being entered. Wouldn't the sign signify a really small number of possible reasons for the journal entry? Like ie., 1?
Wouldn't it be better to do a correcting entry instead?
https://www.accountingtools.com/articles/correcting-entry-definition-and-usage.html
That said, since I'm sure many of us get to have fun with financial stuff, I'd love to hear more about when "administrative reversals" are used, especially with documentation that can fit in a sign bit LOL
Also - even if you somehow didn't have that behavior, just having the expertise by which you could get the signs right (like scott P mentioned it is not as simple as d=positive and c=negative or the other way around) would require you to be a full on accountant.
I mean once you enter the discussion, don't you have to be able to solve development problems in the domain? I get it, in today's environment, its going to be pretty rare that we develop accounting systems from scratch, but by golly we'd better either understand the signs, debits, and credits, or get with someone who does right?
Scott struggles with case statements and now he's now doubling down and saying database systems CANNOT BE TASKED WITH DOING LOOKUPS ON THE CHART OF ACCOUNTS. I think I can excuse him from the discussion at this point, but if my posting sends otherwise competent folks into crazytown maybe my posts aren't as valuable as I'd like to think LOL
Never mind the impacts on everything that's been built (journals, reports etc...)
Well that I can agree on, like I said Joe likes to criticize database designs without regard to whether the OP can change them or not, and while I enjoy these critiques, if someone else asked him to stop I guess that I wouldn't feel so compelled to junk up the thread with my comments 🙂
Since you like Joe so much, I'll give you some plain "Joe speak."
I don't have trouble with CASE statements, I have trouble with idiots.
I stated it's not worth it to always have to join to a COA to make any accounting entry. I've worked in accounting systems -- unlike you obviously -- and no system involves the COA in every accounting entry. That's just a stupid notion.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
January 9, 2020 at 8:38 pm
Just want to clarify here Scott, who's the idiot you are having difficulties with?
January 9, 2020 at 8:39 pm
Just want to clarify here Scott, who's the idiot you are having difficulties with?
That q obviously makes it self-evident.
Accounting entries are not properly classified simply by a + or - sign. Nearly every financial event in a company ultimately effects some type of accounting entry. An employee taking a day of vacation causes an accounting entry(s). It's just ludicrous to suggest that every time anything happens that a COA would need to be consulted. In fact, traditional accounting entries are never negative, they are simply positive cr or dr amounts.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply