Announcement Module
No announcement yet.

Customer #s and Consignor #s conflict

Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Customer #s and Consignor #s conflict

    Recently I contacted support about a problem where Liberty was cutting checks for our customers who did not consign, including checks for $2000.00 The problem is, regular customers recieve store credit (as this one did) and Liberty treats regular customers like consignors with balances to be paid. This is a big problem for our stores.

    As I understand, both customer and consignoraccounts are combined in Liberty 2002.

    The advice support gave was to change every regular customer # currently in our databse by adding 100 to every account, as well as every new account added. This is very problematic. We have currently over 20,000 customers in the Washington D.C., Northern Virginia Area. This solution is not sufficient, nor efficient.
    In Liberty for Windows, as I understand from the CIO before me, the customer #s and consignor #s were not combined and operated differently.

    What will it take to get a better solution?

    Is anyone else having the same problems?

    Josh Lynch
    IT Administrator
    Upscale Resale

  • #2
    diferent #'s

    I find it very frustrating not to be able to differentiate between consignors, customers & vendors. Because we had lots of consignors who shopped w/ us, they are now in the data base 2x since converting. Used to be able to run sreports in just a few minutes by limiting the # sequence to vendors or whomever. Don't understand this aspect of the new program.
    Debbie McDaniel
    Sid and Nancy
    Columbia SC


    • #3
      There are two different issues here: first, you can make a transaction definition that is non-payable so you are not paying out your customers that do not consign. Click on tools maintain transaction definition. Make a definition for your customers that is non-payable, as long as that definition is used they will not receive a check.
      As for the differentiating between consignors and customer, that was a suggestion that was given in the summer survey. We are listening and are in the process of developing an enhancement that will let you separate consignors from customers. The release date has not been established yet.
      Thank You,
      Have a Great Day
      Valerie Bergeron


      • #4
        Shouldn’t a 'store credit' already be defaulted as a 'non-payable' within the Liberty system... just by nature of the language...STORE = in house monies not to be paid. Why would everyone have to create a 'new' transaction definition?

        This problem occurs at POS and has nothing to do with the transaction definition screen to the best of my knowledge. The customer is issued a 'store credit' receipt at POS, which they will use as 'money' the next time they come in to make a purchase. However, this creates the 'payout' when checks are run so if this isn't 'caught'..... the customer has an opportunity to double-dip if they are not honest.

        So in effect, any gift certificate or coupon utilized in a sale, and that item is returned in another transaction, this could cause the 'store credit' to be issued....then a check would be cut on the next payout cycle. (This would be an ideal way for customers and/or staff to rip-off the store).


        • #5
          The Store credit at POS was designed to be a deduction not a credit, if you made it non-payable it would not come off the check and the money would not be deducted from the client's account. We are looking at making a payment type that will enable you to issue non-payable store credit; it is still in the works.
          Thank You,
          Have a Great Day
          Valerie Bergeron