Hi group Is it just us or does xTuple seem to be very traditional in the way that it treats A/P transactions? This traditional approach causes us a lot of overhead in the setting up and managing of the A/P system. Our organisation makes extensive use of credit cards to pay our bills. This is due to our use of government websites (and others) that require up-front credit card payments to effect transactions. Despite this trend to move to a fully electronic payments system, the current xTuple system requires the use of the check run system to capture these transactions, even though no actual check was ever used. To handle credit card transactions and still track the use of these transactions through the A/P system, we have had to create a bank account for the credit card in xTuple (which is problematic as it is actually a liability account for reporting purposes). We then have to create a voucher for each transaction, then post the voucher, select the voucher for a check run, then create a bogus check run in the "credit card" bank account, print the checks, and then post them before the payments reflect in the G/L. In other commercial accounting packages available in this part of the world (e.g. MYOB and QuickBooks), the use of on-line banking and credit cards are now the norm and payments on a credit card or on-line banking can be captured in a single "easy" screen entry off a downloaded credit card or bank statement from the bank, for example. This is often a one-step process as the transaction is selected from the downloaded statement and a voucher is created on the spot for it, including G/L distributions, etc. and this voucher and the payment is then posted in a single shot. I think that the "easy" approach above can lead to sloppy bookkeeping practices that can miss errors and may not keep proper track of invoices (that the IRD loves to catch people on in IRD audits for failure to account for GST or otherwise due to "missing" invoices). However, the "easy" approach also has much to commend it in its simplicity and the realisation of the electronic payments world we now live in. Even using a "traditional" bank account (as opposed to a credit card) for paying for A/P vouchers is generally done using automatic payments or electronic transfers of funds. Our organisation used only a handful of actual cheques this past financial year (about 1% of our A/P transactions). I have seen suggestions in the forums that G/L journal entries can be used instead as a quick fix, but our understanding of this is that doing so does not permit the use of the A/P system for aging and reporting against vendors in the future. If the traditional approach of using a check run is the way that xTuple is going to forge into the future, we will probably still tag along because of the advantages we perceive in the use of the open source system, but it is a royal pain dealing with such an antiquated view of the A/P system. As an interim fix, what about permitting payment of vouchers that simply does a transfer of funds from a nominated G/L account? This quick fix would short circuit the 4 steps of: select voucher for a check run, prepare the run, print the checks and post the checks to the G/L. This would solve another issue that we have, namely the payment of business expenses by the private monies of shareholders (or employees). In other accounting systems I have used in the past, we dealt with this situation by simply posting payment of a voucher from an equity account (for a shareholder) or an employee's liability account (as opposed to a bank account). The liablility account can then be zeroed with an actual payment at some point in the future from a bank account. At least this method permits the A/P account to still reflect the transaction against the vendor. What are the views of others? Regards Mark
Don’t forget, if you are willing to roll up your sleeves you can also get involved in direct development on the PostBooks project as well:
As a user who is in the process of changing to xTuple and still learning how it works I agree with you Mark it does seem to be quite a long winded A/P process. Certainly I would be interested in a better process and also the ability to utilise .aba files for payments.
Does any one else want to be able to use this functionality?
We’re always interested in providing users with simpler internal processes the ability to compress steps - and A/P is certainly a good candidate for that.
Can you identify specific places you’d like to see streamlined?
My suggestion would be to use a G/L-style payment interface available through the A/P Payables workbench. Pictures are worth thousands of words so I have created some mock-ups of what I think it could look like.
Payables workbench with new button at the right bottom:
Once a voucher item is selected from the list then this can be paid by clicking the “Pay by G/L transaction” button.
This brings up the next screen:
The amount to distribute and the distribution date are selected as is the G/L account to credit the amount to. The
document #, O/S amount and vendor are all pre-populated from the workbench selected item.
Once the details are selected then the G/L transaction is completed by debiting the creditors/Accounts Payable and crediting the selected G/L account. Unlike a pure G/L-style transaction, the A/P system is also posted to with the posted amount automatically applied against the voucher.
This could obviously be neatened up by permitting posting of a single amount to multiple vouchers or providing a list of pre-set up commonly used payment accounts (similar to the current expense categories), but I have not drawn up how this would be accomplished. Even with the single selection system, I suspect that this would considerably speed up the A/P system for non-check transactions.
Thanks for the write-up. This basic problem has come up several times (see issue 6240 for one example). As the notes on that issue suggest, we’re waiting for an implementation sponsor or group of sponsors to raise the priority of addressing it.
Funny this subject should be getting a lot of attention now. I was just speaking to a potential xTuple user this week about P/O credit card transactions. We came to the conclusion that the best way to do this was to create an A/P credit memo for the credit card transaction using the credit card bank account as the “Alternate pre-paid Account” on the credit memo. The credit memo can then be applied to the voucher at any time and the transaction history pretty much mirrors what actually happened.
This could be made even slicker if the credit card credit memo could be created from the P/O window and pre-allocated to the P/O in the same way credit card transactions generate credit memos that are pre-allocated to sales orders on the sales side. When you post the voucher, the memo would be automatically applied, same as sales order invoicing. This would make the behavior of the application for both P/O and S/O nice and consistent.
The trouble with the A/P C/M system (as presently implemented) is that it is still very cumbersome, especially if there are a large number of transactions to process. Let us take the example of paying a voucher by credit card.
Here are the steps
 Enter a C/M from the statement (for example) and reflect this against the appropriate vendor (sometimes tricky involving some hunting around for the original A/P voucher to see which vendor it was allocated to, especially for foreign currency transactions where the amounts may differ).
 Allocate the C/M to an alternate G/L account. This is under a separate tab, so I list this as a separate operation.
[*] Locate the C/M in the workbench and apply it to the original voucher.
From a time and motion study perspective, the above approach has serious drawbacks as the entry of a C/M involves at least 4 mouse clicks and 6 manual entry data fields. Coupled with that is the application of the C/M (first locating it in a list of potentially hundreds) = 2 manual entries of vendor, amount and 4 mouse clicks.
In an organisation that has little to do with a traditional check system, this approach has to be multiplied out essentially by the bulk of the organisation’s A/P transactions. Each time a voucher has to be paid, the above steps have to be followed for each voucher.
To prevent the keyboards of data capture people and the people themselves not being worn out, I think that that the process should be more streamlined. Additionally, given the very manual method used with a lot of user entry required, there is a large scope for errors (e.g. wrong account being selected, wrong vendor entered for a C/M, wrong amount applied). Given that we are at the coalface of what an accounting package is supposed to do (simplistically to track expenses and income) I think that there should be some serious consideration given to minimising the effort required to pay for vouchers.
I by no means say that my proposal is the best solution, but it does have a more streamlined approach than what is currently available or proposed.
Right. But to did you catch my suggestion about making it work like
Maybe you aren’t familiar with how sales order credit card
transactions are processed. If we followed my proposal to mirror that
behavior on the purchasing side, the creation of credit memos and
their application to vouchers would be fully automatic and elminate
most all the processing steps listed.
Sent from my iPhone
On May 17, 2009, at 6:05 PM, firstname.lastname@example.org wrote:
Credit cards and prepayments are a problem for us. We have tried must of the methods mentioned in this tread. All of them are very data entry intensive and seems to be a prone to much confusion. For example, an item is purchased via a web site and paid for by credit card. A PO is created to record the order and to be able to receiive the item. The invoice is generated at time of order and usually received before material is received. Item is received but there is no invoice receipt to trigger the vouchering of the receipt.
Then there is the issue of how to record cc payments for items not on a purchase order. And then how do you habdle the eventual payment of the credit card balance.
Would be very interested in co-sposoring enhanced cc oayment processing.
One of the posters here has suggested they might be interested in sponsoring some of the work we’ve been discussing on this thread. We’ve started a specification on the topic. Feel free to comment!
Also, this isn’t a done deal yet. If any of you are interested in putting some funds or code work into this development there is a greater chance that A) it will actually happen and B) that your voice will be heard as we hammer out the implementation.
If you are interested, please contact me directly.
Could there be a way when you enter the payable to choose a different “accounts payable” default account … which would be the liability account for the credit card. I know this doesn’t remove the issue of the vendor name not being the same as they end resulting payee … but it might be a start.
That’s definitely on the right track. However, the payable still has to be cleared which currently can only happen by applying a credit memo or cutting a check. If a payable were to work that way, the process would have to be smart enough to mark the payable as paid immediately which would be a bit of a new twist on current business logic.
I didn’t see a direct email link in your profile. Please begin the sponsoring (with funds or code) conversation by emailing us at email@example.com or telephone 619-501-2466 in Pacific time zone afternoon.
I am stuffed up with this exact problem and will be making a change … the short way is via a php script that makes postgres SQL statements to solve the problem, but it’s possible I could do Qt since my foundation of programming is in C/C++…
Just wondering if there has been any development for this yet? And if so, when should we expect it to be released? I am using the credit memo method but am absolutely drowning in it. I am also concerned at the ramifications of the books showing that there was a credit when there actually was not - can anyone with more accounting experience than me comment on that?
No progress has been made on this issue because a development like this requires direct sponsorship or contribution by a user. If we could get at least one company to step up to the plate, that might get the ball rolling again. Let us know if you are interested in making a financial or code commitment.
There’s a lot of different directions this could go. Keep in mind the main benefit to being a sponsor is you have great influence over the outcome of the actual design to ensure it will meet your business needs.