Khaled Mohamed Mohamed Hussein El Tahawy

When a reason code is mis-clicked in the POS, it erroneously adds a product linked to a subcode with a price. The enhancement should ensure that when a new reason code is selected, any items linked to the previous info code are automatically voided. This will prevent incorrect items from being added to the transaction and improve the accuracy of the return process.

Implement a feature in the POS system that triggers a warning pop-up when a user attempts to add the same item twice to a partially received purchase order. This warning will inform the user that the item has already been added and provide an option to continue or cancel the action. This enhancement aims to prevent accidental duplicate entries, ensuring inventory accuracy and improving user experience.

Currently, when creating alternative prices through 'Margin Component Price Adjustments' by percentage, the prices often include decimals. This can be problematic for retail and commerce customers who prefer rounded prices for better customer experience and operational efficiency. However, the existing smart rounding functionality is not applied in this scenario.

Integrate the smart rounding functionality into the margin component price adjustments process. This enhancement would make sure that prices are automatically rounded according to predefined rules instead.

In scenarios where a POS transaction involves a single item and multiple payment methods, the system currently consolidates all tender-based discounts into a single discount line labeled as "Cash Discount." This behavior does not reflect the actual tender types used in the transaction and leads to inaccurate representation in the discount transaction screen.

The expected behavior is that each tender discount applied—such as Cash and Credit Card—should generate a separate line, each correctly labeled according to its respective tender type. This would ensure transparency and alignment with the configured tender discount logic.

Summary:

POS currently allows creation of purchase orders for vendors on hold for "Purchase Order" in HQ, bypassing expected validation.

Background:

This behavior was reported as a bug and marked as "Won’t Fix" by engineering, citing lack of channel-side data and low demand. However, this validation is critical for maintaining procurement controls and aligning POS behavior with HQ configurations.

Expected Behavior:

POS should block PO creation if the vendor is on hold for "Purchase Order", just as it does for "All".