[Please see my next post, as hopefully it is clearer.]
When selling a product, the journal entry would look (generally) like this:
[1] Dr. Cost of Goods Sold
[2] Dr. A/R, Cash, Checking, etc
[3] Cr. Inventory
[4] Cr. Income
Presumably, any decent invoice/POS system will automatically valuate the inventory sold [3] and credit the associated roll-up account for that. The debit for COGS [1] should also be handled. In NEXTerp, this is done for us in the POS/Invoicing system and works fine from what I have experienced.
The [4] is handled by NEXTerp, but [2] is somewhat mysterious. On one hand, the POS payment section allows me to specify the “debit to” account; this is automatically filled in when I select the payment method. But if I uncheck POS, the payment section disappears and I no longer have access to it. In that case, it seems that the “debit to” section takes precedence and is used when the entry is submitted for posting.
My question is why it works this way. Shouldn’t there be just ONE field to debit for [2] in my sample entry above? And why is it that POS toggles access to the payment section, but not the Accounting/Debit to section? I am just trying to understand how to better use this system.
The difficulty comes when entering credit card transactions, as I indicated in the first post of this thread. I have to uncheck the POS box in order to be able to enter the actual amount paid and then use the write-off section for the processing fees. Now, I realize I actually COULD just let the fees ride and make a separate journal entry for this, and perhaps that would be a better approach until the credit card processing module is available. I just like to keep as much of a transaction together in one piece as possible; I believe this is good practice as nothing is overlooked and a review of the entries will not overlook external entries.
I hope this post makes more sense than the first one. I was in a rush that day I posted, trying to catch up with the transactions from the beginning of the year. I had tried out at least a dozen different ERP’s by then (about January 4) and was racing against time. We have contractors needing receipts and reports, etc. So I am sorry if the first post was confusing or rambling.
I should have also mentioned I have to re-check the POS box in order to submit the post. Otherwise, I get an error. The error goes away once the transaction is POS again, and it posts without failure.
@cary will be great if you can use screenshots rather than long descriptions. They are quite hard to follow 
Debit to is usually the Accounting Ledger. You are right, in case of POS it should directly be Cost-of-Goods sold, but right now the Accounting Ledger is tied to Party as ERPNext follows an accrual accounting system. Maybe we can look into this at some point.
Apparently, it could not be too hard to follow, because your comment seems to grasp what I am explaining. And you can see this behavior yourself, using your own system to create it.
Yes, I get that the “debit to” is the accounting ledger (what else CAN it be?). You see what I am saying about the COGS. I know the ledger (can be) tied to the Party construct, and that is good and helpful. But I am not asking anyone to change that. In fact, I am not sure at this point that I am requesting any sort of change. I’m simply trying to understand how I am supposed to work with this.
If I have to switch back and forth between POS and plain invoice mode (the checkbox) until this is addressed, I guess I can live with it. The system, overall, is fairly good and doesn’t seem to have major issues (other than the reporting, but I hear jasper reports are on the way).
Rather than changing the ledger to be able to work with non-party data, which is absurd, because it works well this way, why not simply allow users to debit the accounts they want in the payment section? What I mean is, when I set up a credit card payment type, I’d like to be able to specify an A/R account. This is really what is broken; I’m only using the “debit to” field as a stopgap fix.
If this cannot be changed, generally, for the entire user base maybe due to various use patterns, then could there be a facility for changing which TYPES of accounts one can select in various places around the system? I’d assume this is generalized in the UI, so it should not be too hard to make it configurable. But, I know. It’s another to-do.
One other thing. I was able to add a filter to show all the accounts, and I can indeed select an A/P account. The problem there is that the system does not get that I want to associate the transaction credit with the Party I’ve already selected. Thus, the transaction causes an error.
The problem is that every change potentially breaks someone’s workflow. So unless there is enough time to test, we don’t usually try and make small changes, since its really very tempting.
But I am not speaking of actually changing the configuration for all users. I just mean a generalized facility for making the change on a site by site basis, according to users needs. That’s what I meant.
Obviously, we would not want to make this a requirement for anyone. The system would continue to operate as it does currently, but if someone like myself wanted to override the drop down lists, they could do so through some sort of setup configuration option (similar to other such configuration items elsewhere in the existing system).
Thus, this change would not break anything for anyone.
At this point, though, I am more concerned with why the invoice does not pick up the customer info for A/R and A/P accounts?
Have you been able to find out why the invoice is not picking up the customer info for A/R and A/P accounts yet? It should be able to detect this from the selections – which are mandatory – made when opening a new invoice.
Otherwise, is there a way to manually add this info? I don’t like that approach, but maybe that could be a solution.
It is important to be able to “pay” an invoice based on pre-paid customer (credit) balance. Note that this is NOT customer credit in the extended credit sense, just to avoid that confusion. What I am talking about is the ability for a customer to pre-pay for services and then later pay for services when they are actually rendered. Is this doable, or could it be?
Never mind. I can create a credit voucher and apply those pre-payments against purchases. I just have to make the voucher prior to making an invoice.
But there is still the matter of why there is a debit to field when there is also a payment section that specifies the account to be debited.
1 Like