Postponed to 7.x-2.x.
Invoices are to orders what receipts are to payments: an overview of what's going on. Invoices list the items purchased in a particular order, together with things like shipping, handling fees, and taxes. Receipts show payment details, such as the amount, currency, date, and status. The two, like orders and payments, are similar, but not identical.
At the very least, it could be an asset to facilitate pluggable receipt 'generators', and extend the UI so users can easily get receipts for their payments.
Comments
Comment #1
xanoReceipts, like invoices, can be tied to a person or business entity. If we extend payments with basic personal/company properties, contexts can set them, and payment methods can use them. The more complicated issue is: what if contexts do not set this information?
- Do we use fields (Payments are fieldable) to collect it?
- How do we map fields to Payment properties? Are the properties programmatical fields no matter what?
- If we use fields, do we allow those for complex properties, such as the address, to be changed, or do we depend on Address Field, for instance?
We had something like this before, called paymentbilling.module (now Card), but it was bulky and especially at the time not within the scope of Payment.
Comment #2
xanoComment #3
pbuyle commentedWhile working on integration of a Canadian payment gateway (OptimalPayments' NETBANX Checkout), I come across their requirements to display a transaction record (that looks like a receipt to me). This transaction record should include payment details, including paid amount and taxes. I will likely implement a dedicated solution to provide this receipt, but having a pluggable receipt 'generators' would be helpful.
Comment #4
xanoAt this moment payments can already be viewed. They are limited, however, in that by default they are linked to user accounts and they are web pages. However, payers are most definitely able to review their payments after making them. The problem with taxes is that they are too complex for Payment to handle well, and they don't actually matter. Taxes are an invoice thing, and do not have much, if anything, to do with payments. This is why tax support has been removed from 8.x-2.x.
Comment #5
pbuyle commentedI agree, Payment itself should not handle taxes details, they have to be handled by the payment context and included in the items amount or added as separated items.
But taxes are not a invoice only things, differentiating between taxes, fees and actual bought goods/services may also be required to properly display a payment information. Especially in countries where products' prices usually don't include taxes (US and Canada for instance), are added on payment and listed separately on the receipt.
To me, a receipt is purely about displaying information about the payment to the user. My idea of a Payment receipt would be composed of two main components: A list of label/value pairs used to display information about the Payment itself (status, date, total amount, etc.) and the list of Payment items.
Creating a Payment receipt is already doable with the current state of Payment 7.x, and it could be done in a third party module, it does not need to be in Payment core. The only thing that I see missing and would like to have in Payment core, is a way to group a Payment's items. Allowing items to be displayed grouped (with the group label on top). An item group could be anything and does not have any particular meaning to Payment itself, it is only a label used on display (however, a group may have a meaning for third modules). This way Payment itself (and the receipt code) could be kept simple, but with enough flexibility to display taxes and other fees as wanted on the receipts (or the payment pages). This can be as simple as adding a nullable 'group' property on the PaymentLineItem.
Comment #6
xanoExactly. Let's not make the project needlessly large. If there is enough interest in this feature, we can always consider it in the future.
Comment #7
pbuyle commentedAs I said in #5, for proper receipt handling in a third party module, consumer of the Payment API need to be able to group payment's items. Something that wasn't possible the last time I used payment. Should I update this issue to reflect that or create a new feature request issue?
Comment #8
xanoI'm not really sure what you mean with grouping items, but if you feel this is important, please create a new issue and describe this feature in more details, so we can find possible ways to implement it.