Utter confusion with Customer Accounts (particularly refunds)

If your refunding a transaction on an account just refund the item on the ticket giving a negative total and charge that to account…
You can’t make a positive ticket in regards sales/receivables become a ‘credit’ on the account…
There might be an option you need to change in the account/transaction to allow negative charge but its exact same prickle as refunding cash.
Account is a payment type so the sale needs to match the payment, you can’t pay a normal ticket with a refund.

2 Likes

@JTRTech is correct.

Unfortunately, the Payment Screen is not made to do this type of operation. It really wants to see Balance > 0. And that behavior is hard-coded.

It is somewhat the same as trying to Credit a Customer Account using the Payment Screen. It “sort of” works if you put the screen into BALANCE mode, but at the same time, it will not allow you to ADD Credit if the Account Balance is less than 0… This is the reason I abandoned using the Payment Screen when Adding Credit to Accounts, because it does not work unless the Account has a POSITIVE Balance (owes money).

You are better off using the Account Statement tutorial, and add another button to the screen to “Refund Account” and fire an Account Doc that invokes the Tx Type. This is the way the “Add Credit” button works, but it uses Docs that put money into a Payment Account like Cash or Credit Card. In fact, one of the selections is “Contra”, which puts money into a “WriteOff” Account.

But this goes against everything @Jesse says about doing proper accounting…

Plus the issue I ran in to with Negative ticket values is image the customer paid a $30 cash deposit and $40 on the customer account. If I need to refund the item then it’s not possible to type “-30” on the settle screen, therefore it’s not possible to split the refund between cash and the customer account.

Also, [quote=“JTRTech, post:14, topic:14681”]
You can’t make a positive ticket in regards sales/receivables become a ‘credit’ on the account…
[/quote]
This is why I am trying to put the positive value as a credit on the customer account (to cancel out the debit which would have been applied when the customer paid on account).

If you take a look at Kendash’s Reverse Accounting examples it does make a lot of sense. In particular, it is possible to use postivie values and still process a refund with money coming out of the “Cash” account… It’s just a quirk of SambaPOS that it’s not working for Customer Accounts.

I am not “paying the ticket” - no such functionality exists as far as I am aware. The Customer Account trancends all ticket types, so it a debit is applied the the CA using a Sales Ticket it should be possible to apply a Debit to the CA when using a different type of ticket, for example a Refund Ticket

But this is exactly the problem. Using negative values as JTRTech suggests is simple, it’s what I had set-up for some time. But since -70 is not >0 we have issues when refunding anything other than All

Using a standard sales ticket which has a negative settle value you can’t split where you are assigning this negative number since you can’t type a minus (-) in to the numberpad. This issue is discussed further here…

There is so much I like in your AS tutorial, but I really need to ease of the settle screen when it comes to payments in multiple currencies, credit card surcharges and rounding.

I am using a “Customer Account Credit” product which does do a very good job of allowing a customer to pay for some items on credit and then later pay it off, all through the POS screen.

This is not my experience… See the ScreenCast below.

  1. John has a 0 balance
  2. He tops up $10 on to his account using USD, MXN and Credit Card (with surcharge)
  3. When we load him as an entity we can see the we owe him $10 (He is in credit with us)
  4. He then buys $10 of wristbands and pays with his customer account
  5. He ends on a 0 balance

1 Like

Very true you would not be able to split a payment on a refund done this way.

1 Like

Yes, I found this out the hard way! It just seems strange why the specifc customer account can be blank as both the source and the target when the transaction is used for payments or change, but the source cannot be blank when used as a payment on a refund ticket.

@emre do you have any idea what could be happening here?

@mjb2000 SambaPOS thinks this is a configuration mistake and cancels payment. But it shouldn’t… While working on @QMcKay’s setup he helped me a lot to support more cases on that screen and I can remember he mentioned it but I probably didn’t understand :slight_smile: Your detailed explanation helped a lot. Well this is not a real issue as it is payment screen but it will be nice to support this case. So on next update we will also check if source account is a non default account.

3 Likes

Amazing. Thanks @emre :heart_eyes:

@mjb2000, curious to know what program you are using for capturing video?

I am using http://www.screentogif.com/
There is an option I have just discovered which allows the option to include a progress bar which gives a good indication of where we are within the looping video.

Is this the functionality you were talking about in terms of crediting the account even when it is at zero?

That is what made me notice a difference. I use ShareX as many others on the Forum do. I wonder if it has an option for progress bar.

Not exactly. I was using a dummy 0-price product similar to what you are doing, but keeping that Product at 0 and switching the Payment Screen to Balance Mode, which allows Payments to Entity Account. But if the Account was in Credit (ie. Balance <= 0) then the Payment Screen would not allow to post more Credit to the Account. Maybe @emre could make that possible in the next update. But your method with changing the Product Price seems to work almost as well.

I agree, the Payment Screen seems like the natural way to do this for all the rest of the functionality it has built in already. The Account Statement method requires a lot of Automation to be built out to support that same functionality, which seems unnecessary when the Payment Screen already does everything.

Yes, this was partly my concern - because it departs so much from the core. Because my knowledge is quite limited, I wanted to stick to core functionality as closely as possible.

One this I like about going through the POS screen is that the account payment can be made at the same time as purchasing other products. In the example below…

  1. The customer already owes money
  2. I press “Clear Balance” to add an account top-up equivilant to the outstanding balance (just created this option :wink:)
  3. I then add additional items to the bill
  4. Finally the whole bill is settled using USD and Credit Card (with surcharge)

Quick Question: How can I make the display of the “Clear Balance” dependeant on the customer having an outstanding balance? I already have a contraint in the rule to prevent the action firing is the balance is not >0 but I would prefer to hide the button altogether.

1 Like

Those buttons visibility is controlled by states. So to do that you need to create a state flow that can read balance do some quick function to check if balance is there then set state. You can set visibility to that state in the Automation Command Mapping.

Since your using Tickets you would use an event like Entity Changed or Ticket Created event and use the Update Ticket State action and a constraint that includes your validation. The validation constraint can use Printer tags to check balance.

2 Likes

Hi @emre

Do you have any idea when you might realease the next update? I am nearly ready to go-live so trying to work out if I should wait for this to be available, or just traing staff on work arounds instead?

Check Beta release to find out. There may be no notes to this regard, but that doesn’t mean it wasn’t included in latest beta, which as of now is 5.2.2 … I am running it in Production now at 2 Venues.

I am in the #v5-beta group, but I don’t see a 5.2.2 thread - Am I not in that one? I was wondering why I hadn’t seen anything for over 1 month?..

5.2.2 is in the 5.2.1 Beta Topic. It should really be titled 5.2.x :wink:

Ah thanks! :slight_smile:

I just tried it, and it seems it is still not updated… :frowning:

For this version, when payment with customer account first time, transaction can be pay.
But at second time with same customer account, we can’t pay with it. And Sambapos crash

You need to show us the crash error report. But typically a crash on payment means misconfigured transaction types.

I have temporarily got around this by…

  • creating a misc account called “Customer account hack”
  • adding a payment type to pay this misc account
  • create an account transaction type and document type to move money from this hack account to a customer account (leaving the specific customer account blank)
  • create a rule which is triggered when that hack payment type is used
  • in this rule, trigger the account transaction document to credit the current customer’s account