@lubos, I’ve mentioned this before, but don’t believe I’ve seen an answer. Is there a reason that a line item on a sales invoice cannot be allocated directly to Customer credits and the customer’s subaccount? This would eliminate the need for a separate liability account for advance payments/deposits and the requirement for a separate journal entry to transfer deposits to Customer credits so they can be automatically applied to future sales invoices.
Thanks.
I just don’t understand the logic behind this. What is the invoice charging for if Customer credits account could be selected on invoice?
Can you come up with some example what use-case you are trying to solve?
Yes, a situation that I think must be fairly common:
A customer requests services or products. Terms of the deal involve a deposit of X before work will begin. But the customer’s procedures require presentation of a sales invoice for authorization and payment of the deposit. Since no economic activity has actually occurred, under accrual-based accounting, no allocation can yet be made to an income account. Allocation on the sales invoice to Customer credits would create the account receivable, which in turn would be cleared by payment of the deposit. Note that at this point no income has yet been recognized.
Now the work can be begin. Upon delivery of the products or services, another sales invoice can be created, and Manager would automatically apply the customer credit, reducing the balance due, but detailing all work on a single invoice.
To do this now, the first sales invoice must allocate the deposit to a temporary liability account. Then a journal entry must be made to transfer the deposit to the customers subaccount in Customer credits. The goal here is to properly associate the deposit with a specific customer for application to future sales invoices, not just to lump it into an undifferentiated prepaid income account.
This is being already handled by Sales Quotes tab. You can create a sales quote and call it Pro-forma Invoice then send it to customer requesting up-front payment.
When customer pay, the payment should be allocated to Customer credits account.
I had not thought about that approach, because I don’t use Sales Quotes. Two objections are that (1) it requires enabling and learning the workflow for another tab and (2) a customer’s policies may not permit payment against a quote, but only against an actual invoice.
My question originally was why allocation directly to Customer credits is not allowed, regardless of whether there is a workaround. If there is a technical reason, or if you decide not to make the change, I think my advance deposit account approach is a simpler workaround than enabling the new tab and changing document titles, considering that it entails learning another workflow. The Sales Quote method also does not allow tracking of the account receivable. Allowing the direct allocation to Customer credits just seems like a simpler alternative, giving users another way of doing things.
The main issue I have is that if company is requesting an advance payment before the work can start, is that accounts receivable? I mean if the customer never pays, work will never start and nobody really owes money to anyone.
Accounts receivables is meant for selling on credit. If you are collecting prepayments, pro-forma invoices is the way to go. I agree it’s a bit more clicking around to have pro-forma invoice but that will be simpler as time goes.
From purely technical point of view, it just introduces more complexity. The moment you create an invoice which debits Accounts receivable and credits Customer credits it makes it look like customer has a credit while at the same time they owe you money. This breaks one of the principles behind accounts receivables in Manager - customer cannot normally owe you money and have customer credit at the same time.
OK. I surrender. 
Actually, I see your point about whether Accounts receivable should be involved with a deposit, since you are technically only making a request for prepayment. No legal obligation yet exists. Ironically, the customer that originally sparked my interest in this use case will probably never buy anything again. 