Credit Card handling on Purchase Orders
Overview
There is a desire in the xTuple community to be able to process purchase orders that are paid for with credit cards. There is currently a manual work around to handle this that involves creating a credit memo equal to the credit card amount that is later applied to a Voucher. However this process is cumbersome and error prone. What would be better is a process that works similar to credit card handling is Sales Order where credit card transaction is associated with the order, and alter automatically applied to the invoice.
Functional Requirements
Adding credit card support for purchase orders would require the following features:
- The ability to differentiate bank accounts that are checking accounts and credit card accounts.
- The ability to associate credit cards to a purchasing agent.
- The ability to specify a pre-charged amount on a credit card against a Purchase Order.
- When the purchase order is Posted, the credit card charge generates a credit memo.
- The credit memo is pre-allocated to the Purchase Order.
- When the subsequent reciept is Vouchered, the credit memo is automatically applied to it.
- Add support for the ability to add a credit card charge directly to Voucher or a Misc. Voucher.
New Terms and Definitions
This is the place to define new words and phrases to be used in the application and the documentation. If this feature introduces a new concept or changes the semantics of an existing concept in the application then define it here. Define it even if you think the definition should be obvious, since your definition might not match the definition used by the reader, like so:
- new definition
- new definition, followed by how the new semantics differ from the old
new term
revised concept
Related Existing Functionality
What does the application do now that is similar to the requested functionality?
Similar and Related Requests
What other requests have we gotten that might tie in nicely with this feature?
What open issues might be addressed by this feature?
Try to create hyperlinks to web-accessible data, such as this link to Mantis issue 2949.
Conflicting Features
What features currently exist and what feature requests have we received that might conflict with the feature described here?
User-Level Functionality
Describe how the new functionality will appear to and behave for the application user. To write this properly you will need to jump back and forth between this section and the Internal Design section.
Describe the menu changes and overall application structure changes here then get detailed in the subsections.
Window Changes
What windows do we expect to change?
What windows do we expect to eliminate?
What windows do we expect to add?
Insert screen shots of window mock-ups like this:
[Insert image here.]
Describe what each window does, what its fields mean, what the buttons do, what right-click menu items are available in the list views, etc.
Report Changes
What reports do we expect to create, eliminate, or change?
Batch Manager Changes
What functionality do we expect to add to, remove from, or change in the Batch Manager?
Usability Considerations
How do we think this will affect user access to existing functionality?
What problems do we anticipate users might have with this functionality and how can we minimize the impact of these problems?
What errors or abnormal situations do we expect users might encounter during normal processing and how can we make it easy for the user to fix these problems using the application?
Problems and Alternatives
What might go wrong with the solution described in this document?
Why might this not be the best solution?
What are the limitations of this approach? What's missing that might be desirable?
Describe briefly other ways to solve the basic problem and the advantages and disadvantages of each alternative.
Justify the chosen solution or argue why one of the alternatives would be better. Be as broad as possible here, since an important purpose of this section is to provide alternatives in case the initial attempt at implementation encounters a significant implementation block.
Internal Design
Now that we have defined what we have to do and how we think it should look to the user, we can describe the internal structure of the application. If possible, outline the architecture of the feature implementation here. Then in the sections below describe the changes and additions to the application to create this architecture.
Basic Algorithms
Are there particular algorithms required to implement this feature? If so, describe them here.
If you are going to outline a particular algorithm in pseudo-code
put it in a programlisting
try to limit lines to approximately 80 characters
try to limit programming constructs while still being clear about intent
end if // a programming construct that may be unavoidable to maintain clarity
Custom Widget Changes
Do we expect to modify existing custom widgets to support the windows described above?
What new custom widgets will we need? Will they be derived from existing widgets? What behavior do we expect from them?
Schema Changes
What changes do we anticipate making to the database schema? New tables? Views? Indexes?
The new whatever-you-call-it table
|
Column Name |
Description |
Data Type |
Comments |
|
field1 |
Describe me |
data_type |
how it's used |
|
foreign_key |
Describe me |
integer |
foreign key to other_id |
|
enum_field |
Status or similar field |
character(1) |
Can take one of the following: |
What privileges do we need?
|
Privileges for feature |
|
|
Name |
Description |
|
MaintainWhatever-you-call-it |
Can Add/Edit/Delete stuff |
|
ViewWhatever-you-call-it |
Can View stuff |
Stored Procedure Changes
What stored procedures do we expect to create, eliminate, or change?
Performance Considerations
How will this feature impact the performance of the application overall?
Error Handling
What internal errors do we anticipate might occur?
How can we best hide them from the user, prevent them, or fix them automatically?
QA Considerations
Does this feature require any special tools or data to test? Is it testable (some features may be hard to reach from the user level)?
What are some anticipated areas of concern that require special attention?
Documentation Considerations
Is there a significant documentation impact?
Does the feature require a standalone essay or only field-level descriptions?
Release Considerations
What release would we like to target?
What is the potential impact on a release if we don't finish in time?
What happens if we only get some of the functionality done?
Are there any pieces that would be useful on their own?
Are there any dependencies on other features or applications (such as Qt 4 or a particular release of OpenRPT)?
What is the anticipated impact on users, particularly those who have customized the sources, reports, and database schema?
The proposed system is peculiar to purchase orders. Often in business, the credit card limit is used to prevent substantial abuse of a credit card account. In practice, in such situations, an organisation will not strictly control its credit cards and the accounts department is then left with the task of back-capturing credit card transactions without having the benefit of existing purchase orders.
Under the proposed scheme, a purchase order would have to be issued, even though the transaction is long-since completed. This is an unecessary and a noisy step. When I say noisy I mean that the purchase orders created after the fact are in the same pool as genuine purchase orders and looking at the pool of purchase orders there will be some genuine orders and others that are not genuine as the sale is already complete (up to a couple of months prior by the time the statement arrives and is processed).
The noise can wreck any analysis of purchase orders and also (probably more importantly) involves the usual checks and balances and extra transactional work associated with initiating a purchase order. Under normal circumstances, an organisation assigns roles to people who can initiate purchase orders of various types and uses other measures to ensure access into the purchase order system is appropriately restricted by a vriety of mechanisms. In the case of back-capturing credit card transactions, these checks and balances are uneccessary as the transaction is already complete (a.k.a. trying to close the stable door when the horse has already bolted).
Further, this issue (dealing only with credit card transactions) is only a subset of a bigger problem, which involves modernising the accounts payable system to account for real world practice, which (at least in organisations in the Antipodes) do not often make use of physical cheques (checks) but instead make extensive use of electronic payments where payments are handled electronically and involve transferring funds directly from an organisation's bank account to creditors' bank accounts. This proposed solution therefore fails to deal with the bigger picture and continues to leave the accounts payable system effectively in an archaic state that does not accommodate current commercial practice.
In conclusion, what I am effectively saying here is that it is my belief that: firstly using the purchase order system to handle after-the-fact credit card payments is driving a round peg into a square hole involving extra effort for no good reason and secondly that the proposal fails to deal with the bigger picture of non-cheque payments generally.
Ok, instruform, thanks for the feedback.
As of right now this proposal is barely a proposal at all, but a starting point for a conversation which you have engaged in. What would be helpful is suggestions as to how it should work. Also bear in mind that the proposed bullet points are targeted toward the user that has potentially offered to underwrite development, so this specification is likely going to lean in a direction that meets their needs. If you are willing to provide sponsorship or code contribution to this effort, that will increase our ability to expand the scope to incorporate your specific needs into the proposal. That is the nature of our business model.
Note that the bullet points above suggest credit card support for Misc. vouchers, which would allow you to process credit card transactions without a P/O, and support to set up bank accounts as credit card accounts. You previously proposed we add a button to the A/P workbench to pay by G/L transaction (though I can't seem to find the screenshot). I'm sure we could work something like that in, though I would prefer it be something like a "Pay by credit card" button that prompts the user to select a credit card bank account to transact against. Perhaps we need some mechanism to associate bank accounts as vendors so you can process payments to the bank?
Also note we have already added support for electronic payments in North America (http://www.xtuple.org/ElectronicChecks), so some infrastructure is in place for that. Another community member has contributed code for Australian electronic format which we need to get incorporated into the base: (http://www.xtuple.org/issuetracker/view.php?id=8967). We'd like to incorporate that in such a way that users can easily snap additional electronic check formats for other regions as well.
Our electronic payment process does, however, only generate a file. It does not connect directly to institutions. We are interested in a dialog about that, though there is a concern about the level of effort it would take to support connectivity to potentially hundreds or thousands of banking institutions. This might be something that would be supported by third party xTensions perhaps? Or perhaps there are fewer connectivity issues connecting to banks than I am thinking and that this is something that can be designed to be more or less configurable by the user. In any case it is a topic that requires investigation.
Regards,
John
Well this whole issue sets up all sorts of opportunites. With the internet as a purchasing outlet credit cards are used frequently. The challenge we have is how to monitor, control and process credit card transactions. I will try to outline some of the issues as I see them.
Credit Card payments can be a three legged transaction. The credit card is used to pay a vendor which creates a payble to the credit card company which then a payment must be made to the credit card compnay. We would want to be able to track payments to vendors with credit cards and we would want to record payments to the credit card company.
Now credit card payments can be for different things, prepayment on a purchase order, purchase of an airline ticket, direct payment of an item without a PO, payment to a vendor which we would like to track and payments to vendors we might not want to track or better said don't need to record to a vendor but possibly to the user of the card. For example, would we want to set up Starbucks or McDonalds as vendors. And what about that fancy resyurant on the bay. Do we need to record them as a vendor to track the payment.
If prepayments are being made, we would like to have a way to monitor and control prepayments so they can be applied to invoices properly as material is received. In a lot of cases an invoice is not generated after the shipment is made but when the order is made. So we would need to voucher the invoice before the item is received and then link the invoice and payment to the receipt thise closing out the transaction.
Credit card statements and payment of credit card balances should handled as short term debt transactions. And recorded seperately from the charge made to a specific vendor.
Just some inital thoughts.
I would also like to request the use of debit cards also, they may or may not be on the same account as the checking account.
I believe credit and debit is a great idea. I work in an industry involving technology and point of sale. Much like technology, credit processing is growing to another level. It's getting to the point where tap and go is a trend even being used on buses using wireless. If i was more experienced with programming i would try it out.
I found xtuple because I'm in the process of opening a motorcycle shop. I have not found any open source ERP software (i chose open source because there is nothing out there affordable for my needs.) as clean and stable as xtuple. The only option this software is missing is the use of peripherals to conduct typical POS, cash, credit, debit, e-check, what have you. Some of you may ask, why not get a stand alone POS? Well, I'm a geek and my business partner is also, therefore we like to make technology work for us. We are attempting to integrate, shop management, customer management, POS, Inventory management, etc..
Based on what i've seen, Verifone Pin Pads, and ID Tech card readers is a good start. Heck, with the ID Tech Card Readers, user management can be more controlled by using an ID card with a mag strip.
Credit Process
From my understanding this is the steps the application would use to process a credit transaction.
1. user swipes card.
2. software acquires information from track 1 of the card magnetic strip
3. Packs the transaction information and send to the bank
4. bank send a response back (Approved/Disapproved)
5. Software Prints a Reciept
If Denied
5. Software delivers a denied error message.
Debit processing is the same, but... pinpad Encryption is involved and the software reads track 2 instead.
seems fairly simple to implement.
Just my 2 cents!
This forum is about credit card support for Purchase Orders, but it sounds like you are talking about Sales.
You realize there is support for credit cards on sales, including the POS module, right?
What's missing is the support for magnetic stripe reader and 40 col. printed receipt. A partner actually contributed some code for those, but never committed it to Source Forge:
http://www.xtuple.org/xtincident/view/features/11312
http://www.xtuple.org/xtincident/view/features/11313
What we really need on POS to keep it moving along is an enthusiastic advocate/user that is either A) willing to dive in to and commit code to improve it or B) is interested in sponsoring (i.e. paying) someone else to do the work. Are you interested in either of these options?
I didn't know that. I'm sorry, i got overly excited when i found this software. I have no problem with commiting to code, i like the challenge. :] I'm not familiar with the development architecture of this software but i have been reading religously on the developer zone to get up to speed. When you say support for these peripherals, do you mean drivers? or do you mean the ability for xtuple to detect as a particular peripheral and use accordingly?
I believe the changes proposed just treat the card swipe as keyboard input. For sure the 40 col printer solution is just a special report definition file that formats for credit card printers.
John,
I remember checking on this a while ago and am unsure if any progress has been made or additional conversation even. I can't imagine any small business that does not have a need for this to be implemented. Could I suggest a feature mob approach to getting the ball rolling on this, I am confident of getting our company to contribute to this right away. I doubt we could fund the entire project but as I mention I just can't see this not being needed by the majority of your customers?
