Please Log in or Create an account to join the conversation.
For the renumbering? You don't even need to bother checking status. Just let it renumber anytime that event is calledIf we use onCPayAfterPaymentStatusUpdateEvent, what is the best global status to use ?
It can't wrongly renumber them as it clears the number and renumbers each call. I'm not 100% sure the SET variable will even work in a Query action so be sure to test carefully.So how can we avoid to have three times the auto action running for the manual gateways and wrongly implemented payment invoice numbers ?
That's due to $user being passed. Try the below.Also I have noticed that the invoice output only displays the [user_id] of the mod and not the one of the user.
Please Log in or Create an account to join the conversation.
I'm not 100% sure the SET variable will even work in a Query action so be sure to test carefully.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
We will implement frontend payment history that matches what everyone else is doing (just a table of data, as you're doing now) and we will be reviewing a separate invoice numbering system for those payments (as you're doing with the query action). What you choose to rename things using language strings will be entirely up to you.I guess that you should implement this kind of thing in CBsubs. So Baskets would be in fact orders, and Payments would be in fact invoices (either pending or paid, but as soon as Payment is initiated an invoice with a correct number would be displayed)
There is no requirement for them to be PDF. We've no plans to implement PDF generation at this time. You can use &tmpl=component&print=1 in your URL to make them print accessible.If now we could output this directly in PDF that would be perfect to have a great system
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.