Post vendor entries to a different payables account

FMac

Hi,

I have a scenario in which payments in advance (created through the Payment Journal without applying to anything) need to go to a G/L Account different than the Payables Account in the Vendor Posting Group. Now, I have done in the past a customization to enable a client to switch Customer and Vendor Posting Groups in transactions, but that kind of thing is out of the question for the installation in which I have this scenario.

Standard pre-payment functionality doesn't really cover this, as in many cases the advance payment will have to be posted before even knowing what the eventual invoice from the vendor will be like. I'm thinking about posting the payments as usual and then move the amounts manually to the Advance Payment account, but I wonder if I overlooked any other (better) options.

I've been reading the boards for years and never really participated much, and I intend to change that. Not really comfortable with starting by *asking* but hey, I could use a little help here ;-)

Many thanks in advance.

-Frank-

rmv_RU

I think you should add "Prepayments Account" field to "Vendor Posting Group" table and modify posting routlines.
Post prepayments into Prepayment Account and move applied amount into Payables Account when prepayment will be applied to invoice.

jannestig

You must know the amount you are going to have to pay at the time of creating the payment journal, what is wrong with creating a GL or Prepay item on an order line line then creating the prepayment invoice, then then post your payment line as a normal one.

Back on the the Order you can then enter a reverse GL/Item line for the same qty and amount and then add in your details below for the actual items etc ?

The Prepayment account will act as your additional account while removing the need to change posting groups

If it is the actual payment that must sit in another account EG not the bank Yet then you could have a clause to use 2 payment code and create 2 lines?

FMac

Thanks to both for the reply!

A development that messes with the posting routines is not an option in this case. About the prepayment functionality, what I meant is that at the time of doing the payment we still don't know what will be the amount of the invoice: imagine a service vendor that will bill you monthly for whatever services you "consumed" during last month, but also at the beginning of each month expects an advance payment based on an estimation of what the next invoice will be like. "You want me to do this an that, it will be around $ 1000, so I'll need you to pay $ 500 in advance", something like that. Then the invoice may turn out to be for 900 or 1500, but we don't know about that.

But something like creating an additional line on the invoice/PO and then balancing to zero with an opposite might do the trick. I'll try, show it to the end user and let you know.