Eric Thunem Thinkmax Senior Consultant

When you create a threshold discount (for example buy $100 get $10 off) the discount amount is pro-rated to the lines in the transaction. If I was buying an item that was $90 (Line A) and an item that was $20 (Line B) then the result is that I have a $10 discount for a total of $100 (ignoring taxes here). The $90 line will have a $8.18 prorated discount and the $20 line will have a $1.82 prorated discount. This is fine in the context of a sale but if I then return either item, I will invalidate the original threshold for the discount of a $100 or more purchase. In this case the POS currently refunds exactly what the customer paid, so $81.82 if I refund line A and $18.18 if I return line B. This way, a customer could return one of the products, and still benefit from the discount on the other one, even though they technically shouldn't have gotten the threshold discount after the fact. The refund should be the net amount paid for the item return, less the discount applied on the other item. For example, if I return item B, then I should give $18.18 - $8.18 (discount on item A) for a total refund of $10. If i returned item A, then the refund would be $81.82 - $1.82 = $80.00. The one caveat is that this could be confusing to the customer, however, it would be a deterrent to try and game the system.

This would be the ability to automatically print a new coupon code on the POS receipt if certain conditions were satisfied in the transaction. The customer could then use this coupon in a future transaction.

A common case is that a company will want to enforce a return policy for a group of products (ex. returns only valid for 30 days past purchase). Currently there is no way to audit/enforce a policy like this or warn the store associate if a return is processed outside this limit. There should be an option to configure a return time limit for a product or a product category and have this linked to an info code to prompt the store associate that the return is past the time limit. It would also be nice if there were some way to create an audit record if the return is still processed outside the return policy window. This would help retailers enforce their return policies more effectively.

When using the warehouse module and processing consolidated shipments for orders (multiple sales orders are packed in the same box and shipped together), it results in a consolidated packing slip that is related to multiple sales orders. However, only 1 sales order ID is referenced on the packing slip and invoice header. This causes issues in Ecommerce order history synchronization, because when using the Retail APIs to look up sales order details and invoices, they are not returned for sales orders that are linked to the consolidated packing slip and invoice. This happens because the related packing slips and invoices do not have the same SO number on the header.

The APIs should work regardless and should return the linked packing slip and invoices for a sales order that is contained in these entities.

There is a feature today called Future Orders in the call center functionalities (see details here https://community.dynamics.com/blogs/post/?postid=f8b28e3b-814f-4eaa-8555-66baabb7c8cb). Currently this feature will only work at the header level (applies to all sales lines). Therefore, a whole order is identified as a future order or not, and you must manage the payment authorizations at the order total level. To make this more flexible it should be possible to evaluate future orders at the sales line level, so the system can treat a specific sales line as a future order and not trigger a payment auth for that specific sales line with a future delivery date.

It would be great to have a mode of delivery selection functionality that is more like an ecommerce experience when creating a call center sales order. instead of having to default or set the mode of delivery on the header/lines, the system should give you mode of delivery options at the order completion stage.