7
Many scenarios in retail orders utilise pre-payments. This may be to take a deposit, or when using payment methods such as cash or gift card. When you take pre-payment for an order, the customer payment journal is immediately (on sales order submit in call center / or on order sync if from CSU) created and posted against the customer account. The result of this is a 'credit' balance on the customer account.
Many retailers utilise customer account payments / offer customers credit limits, (common practice in mainland Europe, especially DE & AT, also often used for 'credits' from refunds, or where retailers serve both B2B and B2C customers - such as builders merchants).
The result of a pre-payment being taken for an order, causes the credit to be applied to the customer balance. Although the customer transaction is marked as a pre-payment, this value is included is still included within the credit limit calculation. Even when using the sales ledger 'Credit limit type' = 'Balance+All' (which should include open customer orders to reduce the available credit), the pre-payment order is ignored for that calculation, so the pre-payment value is still 'available credit'.
As a result, customers believe they have additional credit available to spend against, and the system will allow 'on-account' orders to be created, utilising the pre-payment value. The end result is the last order to be dispatched will fail, as not enough credit is available, (long after the customer placed the order, on the assumption they had enough credit).
One example is:
- Customer A has a credit limit of $200
- Customer A places and order, and uses their $100 dollar gift card to pay for the order.
- Customer A goes online, and their account shows as $300 available to spend (the first order is not yet dispatched). They now create an order for $250 and chose to pay on their account.
- The second order happens to be dispatched first
- The first order now fails to dispatch, because it will take the customer over their credit limit. This is confusing as the order has been fully paid for using a gift card.
Microsoft has rejected this bug as 'Working as designed'. I appreciate this is a cross-team issue in Microsoft, but the scenarios given are specific to retail, hence adding in Commerce section.
Many retailers utilise customer account payments / offer customers credit limits, (common practice in mainland Europe, especially DE & AT, also often used for 'credits' from refunds, or where retailers serve both B2B and B2C customers - such as builders merchants).
The result of a pre-payment being taken for an order, causes the credit to be applied to the customer balance. Although the customer transaction is marked as a pre-payment, this value is included is still included within the credit limit calculation. Even when using the sales ledger 'Credit limit type' = 'Balance+All' (which should include open customer orders to reduce the available credit), the pre-payment order is ignored for that calculation, so the pre-payment value is still 'available credit'.
As a result, customers believe they have additional credit available to spend against, and the system will allow 'on-account' orders to be created, utilising the pre-payment value. The end result is the last order to be dispatched will fail, as not enough credit is available, (long after the customer placed the order, on the assumption they had enough credit).
One example is:
- Customer A has a credit limit of $200
- Customer A places and order, and uses their $100 dollar gift card to pay for the order.
- Customer A goes online, and their account shows as $300 available to spend (the first order is not yet dispatched). They now create an order for $250 and chose to pay on their account.
- The second order happens to be dispatched first
- The first order now fails to dispatch, because it will take the customer over their credit limit. This is confusing as the order has been fully paid for using a gift card.
Microsoft has rejected this bug as 'Working as designed'. I appreciate this is a cross-team issue in Microsoft, but the scenarios given are specific to retail, hence adding in Commerce section.
STATUS DETAILS
Needs Votes