Failures in ./spec/features/admin/enterprises_spec.rb and ./spec/models/exchange_spec.rb
Sorry the log doesnāt format very well, but searching for āfailā will get the info. If itās unworkable let me know and Iāll screen print a few shots for you.
Just wondering, does the Balance differentiate positive and negative balances? If I was to see my balance at Ā£8 I would assume Iām in credit but it looks like actually the user owes Ā£8.
Hi everyone! @lin_d_hop Iām just wondering, because we have the same need (great to see you are working on it!) if you had also any ābackofficeā version of that need?
As a hub manager I would like to see the total balance due to me by my customers, and see the detail by customer of course (and ideally be able to send a kind reminder if at some point the buyer has not paid ;-)) For example in ācustomersā, that would be great to see for the customers of my hub the balance for each customer (basically the same info you want your customer to be able to see)ā¦
Do you also have that need or is it only on the front office on your side?
Ping @Olivier
You can use the report under Order Cycle Management - Payment Methods Report to see customers for a hub that have an outstanding balance. You can filter by Hub and Order Cycle as well.
This was implemented by me to fill this need for the UK team (so ping me with bugs if you spot them).
Let me know if you would like more functionality added to this. I can look into implementing for you.
Yes, it will change to say āCredit $xā instead (and will style this green/red or something too). Youāre right that itās confusing for a customer though if they only see that - I guess Iāll change it to balance owed/due or something instead to make it clear. Spree only considers outstanding balances from the merchantās point of view, unsurprisingly
OK this is on uk staging for now, so please add any tweaks/requests here!
My list so far:
Smaller distributor logos, default to something sensible (tractor logo as in producers page?)
Some translations missing. I am guessing these need to be added to en-GB for UK. Is there any way to fall back to en.yml if a translation is missing rather than just show the translation key? I think we can mostly understand Australian
Also re translations, some of the text (order payment status) etc. comes direct from the database - can we assume that is already in the desired language or translated by spree in the case of order status etc?
The header of the page is a bit boring/blocky/crammed over to the leftā¦any suggestions to make it look nicer??
Could be nice to have a background image a la producers page if someone wants to design oneā¦
The page only shows orders with state: complete. Let me know if this is not correct.
Couple of screenshots below showing what happens with credit/debit. If all orders have been paid (ie balance zero, which I imagine will be the case for most) it doesnāt display anything, e.g. Simple Hub below.
Ping @CynthiaReynolds@Olivier@marito59@Selmo@nickwhite@gnollet for info.
It looks great @stveep!!!
So that means, in the spirit of CSA, that we could have a hub that propose the members to put money in advance on their āwalletā and use it slowly by buying in the hub (the pre-payement aspect of CSA models). Ping @Selmo about the discussion we had about your āAMAPā.
I just have a question @stveep on the "OFN Hub 3"case, why the number of the first order doesnāt appear? Even if itās all pay and 0 balance, we should be able to see what order it refers to, no?
And also what happens if an ordered is adjusted (a product is mission for example). Then it adjust the amount in the āvalueā colum and adjust accordingly the balance, am I right?
Hi @MyriamBoure, Iāve made some fixes to the bugs in this report. Maybe you might like to have a look. Currently in PR #826 and due to go into v1.6. Also I seem to remember you also asking for some other features in these reports, but I canāt seem to track them down. Do you remember what they were?
As @maikel has been going through my PR on this, I have been thinking about it some more. I got stuck trying to write an appropriate query and now Iām wondering if my current implementation is actually showing what we want.
In the screenshots above, it displays all ācompleteā orders, and the ācompletedā payments for those that have them. If an order has no payments, it shouldnāt be ācompleteā, but it can be ācompleteā and have incompleted payments with statuses like āvoidā, āinvalidā, ācheckoutā etc.
My original thinking was that we shouldnāt show these, as they donāt count towards the balance for the order. However now Iām wondering if it is useful to see some or all of these - so the user will know if (for example) a card payment was declined. We could do something like this:
E.g. in the screenshot above we would want to show the cash on collection orders, since they contribute to the balance owed by the user and thatās probably useful information for them. Maybe more cryptic ones like āvoidā/āinvalidā are not so usefulā¦
@NickWeir, @lin_d_hop@MyriamBoure - what do you think? Would need some formatting changes to make clear which payments were not counting towards the balance of the order.
@maikel I think the query problem boils down to: we still need to get an order row from the database even if there are only incomplete payments, but [in the current implementation] only actually show the payments that are completed. I still canāt find a SQL or AR solution, and this made me think that it is more of a display/filtering issue rather than a data issue after all.
Thanks Steve. In my opinion it would be useful to see all payments. When I was involved in the day-2-day Stroudco management there were several shoppers who made payments that were not linked to orders and it would be very useful to see all payments (irrespective of the order they relate to). I will see if @Oliver has time to comment on this
I agree it would be useful to see all payment and order attempts, though obviously failed and cancelled wouldnāt contribute to the balance.
One thought in relation to Nicks point, as we can only have payments related to orders weāll also need to accommodate payments of a higher value than the order as many customers wish to add credit to their accounts. I guess this is an added complexity to handling the āCompletedā state.
Thanks for this @stveep. Great thinking, I agree this change would improve usability from the customer perspective
Itās a tricky one because different hubs may well want to use this in many different ways. Like Nick says, if the balance is to be correct, then orders and payments should really be independent of each other, so that people can pay a monthly standing order, for example, and cover any order from their balance. Having said that, OFN isnāt meant to be bookkeeping software, so how far do you go?
On Stroudcoās current software we are simply able to enter credit and debit amounts at will, which means we can use that functionality for credit notes, payments and any other balance adjustment, while invoices are entered by the software.
In the above screenshot you would include all amounts from all invoice (unless of course cancelled) in the balance and then reduce the balance with each payment or credit entered.
As far as Stroudco is concerned, Iām actually planing on using online bookkeeping software to do all this, including showing balances. This is something thatās changed since I took over the day-to-day running. The functionality thatās being developed here is still important, though, in my opinion. Itās just a question of where you draw the line.
Agreed @Oliver. I would like to explore that functionality in the future. But unfortunately it is outside the scope of this issue.
Itās also one I would delay until after Spree upgrade.
@stveep thank you for all this! One thing Iām not sure. For me itās a bit confusing to see all values the same way, whether it be a negative or positive value. Especially the void case, the way it is displaied here is a bit confusing, for me it should be a form of āpaiementā, or treated as such as it comes as a negative amount on what is due (like a payment).
I donāt understand why the balance due doesnāt go up at the checkout line, itās a bit confusing if I look at it as a userā¦
I would rather have one line per order, when I order, the balance due goes up, and then when I make a payment one line per payment, and as mentionned, I agree that for me the paiment shouldnāt be linked to a specific order.
Hi @stveep, Iāve had a test of this and it seems to be working well! What a great feature! One thing I havenāt tested is whether Paypal/Pin payments are captured. Thereās also the questions of how many historical orders to load. Good stuff!
HI @sstead, thanks for testing it! What is the potential concern with Paypal/Pin payments? Is there anything special about payments of these types?
I guess we could load the last year by default? Any idea/data on how many orders users typically have?
In the meantime, Iāve updated this to show unsuccessful payments. āInvalidā, āVoidā or āFailedā payments show with the little warning sign. āPendingā or āProcessingā are displayed without the warning but greyed out and not contributing to the order balance. So now all payment statuses except ācheckoutā are being displayed.
Hi @stveep, Paypal/Pin is just different in the sense that itās not manually marked off as paid, but should be automatically captured. I just wanted to mention that I havenāt checked this is happening. I think we have a dummy paypal, i could check this with a 1c order if this gets tested again.
At most a user may have an order every week, once a week, for a year or two.