Ideas for SalesPad Desktop

Editing of a credit card manual payment, no matter how old, should not be "expected behavior" on the Payment screen.

Make the credit card payments non-editable, and follow the same rules as removal of a payment.  If a user can not remove a payment, I don't want them editing it either, unless it is the current day.  So, the following steps need to be followed when pulling up the payment screen and looking at payments already recorded: a.  Can the user remove the payments (setting in security).  If Yes, let them, if NO, Don't let them. b.  Can the user modify the payment amount?  (Use the same setting as remove above or create a new security for modify existing payments). If Yes, Let them, if NO, Let them ONLY if the current day is the day that the original payment/deposit was recorded.  They can correct a deposit only the day it is made, after that, only those with the proper security settings can modify a credit card payment.

  • Guest
  • Oct 5 2017
  • Future consideration
  • Attach files
  • Admin
    Jacob Pegg commented
    October 6, 2017 15:23

    If we did this, it would be just to add a setting to allow editing of an existing manual entry without the "allowed on the same day" piece.  This will likely go into a future consideration status, but this sounds like it may be specific to one of your existing clients, which means timing as to if we decide to do it and when.  If that is the case and the customer wants it sooner then later, I would suggest going custom. 

    With that said, I played around with the screen a little in my environment and there is an audit trail in that payment screen when someone modifies an existing payment.  This could potentially be handled in the short term by making sure all users have that log showing on the right side of the payment screen and ensuring they are taking the right steps.  Along with that, you guys could write them a workflow rule to grab documents that have had a manual payment updated and direct those into a new workflow batch.

  • Guest commented
    October 6, 2017 18:31

    Hi Jacob, I had written it up just in case (attached) as a custom. This is the part of the email I did not post – I posted only the solution that D Ray had suggested and what was used to create the custom quote. Here is the reason he brought it to my attention: Also below, you can see one way I tried to improve it with a work around but that fell flat as well.

    D Ray: "I am being made aware of a bug in the payment screen of SalesPad. You
    will remember that I updated a security setting in the payment screen
    (payment on an order) that removed the option for counter and some manager
    security groups to be able to remove a payment from an order. For the most
    part, that has worked. However, if the payment was made by credit card,
    there is a glitch. Here is what is happening. 1. A partial payment is
    applied using a credit card on an order. 2. Order is pulled up later and
    the users "intent" is to apply a balance payment to finish the order and
    move it on. The payment line is grayed out and the user is "expected" to
    click "NEW PAYMENT" to record the balance. However, the field showing the
    original payment amount at the bottom left of the screen is editable. We
    are having idiots.... er... employees who are changing that to be the new
    payment amount, thus "unintentionally" editing the original payment amount
    with a new payment amount when they are thinking they are adding a new
    payment. The result of this is the original payment was changed to the new
    payment, and the order is still short paid and the idiot.... er.....
    employee is wondering where the original payment went. Somewhere, the
    security setting we click to lock out the removal of a payment, which does
    gray out that button, needs to also block out any editing of a previous
    payment. I think this is a bug in salespad. I can't see any reason that the
    amount of an original payment, which we have already accounted for in GP
    and deposited, needs to be edited. I don't want it to be. Tasha in Cedar
    City has duplicated this error and could show it to you."*

    I really don't want that field editable by anyone. We have already
    accounted for that money and deposited it in the bank. Very few users with
    accounting security have the rights to remove a payment on an order, but
    anyone can type over a payment made with a credit card. I can't imagine
    that being a "feature". It has happened twice this week after a company
    bulletin pointing out the issue and for our users to be careful. Previous
    payments need to be locked down on an order and not able to be modified by
    anyone. Only accounting people who know what they are doing should be able
    to touch any deposit. If someone messes up, they can go to an accounting
    manager to remove the payment and then they can re-do it.

    Also Jacob, I tried to customize the Payment window as a way to prevent problems but not only did they not save, after a while I noticed that there was a false Audit Log entry for Deleting a Payment (not the same one I used in the screen shot) – which really concerned me ([#YOS-872-41126]: Payments Layout not saving) but when I tested it, I determined it was not really deleted but I had to modify the audit log table so JPG didn’t think I had. Really scary! No answer to this yet.

    [cid:image001.jpg@01D33E9B.E2813D50]

    [cid:image008.jpg@01D33E9E.F9D50B00]

    Thank you,

    Tim Brown | Senior Consultant
    [cid:image009.png@01D33E9E.F9D50B00]
    6965 Union Park Center, Suite 400 Cottonwood Heights, UT 84047
    O: 801-487-8400 | C: 801-414-8790 | tbrown@premiercomputing.com
    www.premiercomputing.com