Suggestions

Currently When creating a zone from the Zonifier, the user selector shows only the first name. This prevents distinguishing users with the same name; for example, several users appear as “Luis” without additional information to identify the correct one. I should The selector must show the full name of each user, validating the behavior of the Zones > + Add form, where it is already displayed correctly.

Add filters to the Product Activity report and breakdown by zone and customer category, including this information when exporting to Excel. This would allow us to analyze the consumption of each product by territory and type of customer, facilitating load scheduling and better decision-making.

Add a “take 6 and pay 5” promotion that allows you to combine any product in the catalog, without being limited to specific products or families. When the customer adds 6 products to the order, Handy must automatically identify the one with the lowest price and apply a 100% discount to it. That is, the customer wears all 6 products, but pays only 5. The promotion must be able to be applied again for each group of 6 products; for example, if the customer buys 12 products, the corresponding 2 lower-priced items must be discounted. Currently, promotions require defining activating products or families and a fixed reward product, so it is not possible to configure this mechanic.

Currently, when a product shortage is detected during the liquidation of a route, it is not possible to record the corresponding sale from Handy. This prevents charging the seller and correctly reflecting the movement in inventory. It is requested to incorporate a “Generic Sale Due to Shortage” option within the liquidation process, which allows: Record the product and the missing quantity. Generate the amount to be charged to the seller. Reflect the corresponding adjustment in the route inventory. Preserve the traceability of the movement, identifying it as a shortage registered in liquidation. With this, these cases can be controlled without affecting the consistency of the inventory or the closing of the cash register.

It is proposed to incorporate a loyalty program that allows customers to accumulate points when making cash purchases or credits to their balances. The points could be configured with an equivalence defined by each company (for example, points for each amount paid) and then redeemed for benefits, discounts or products. Points must be generated only for actual payments: cash purchases and credits. They should not accrue from sales on credit, since the benefit seeks to encourage timely payment. This would allow the implementation of loyalty strategies similar to reward programs used in commercial chains.

Currently, the Deliveries report shows the Result field with the custom categories configured for each account (for example, “Closed customer”, “Incorrect address”, etc.). The API only exposes the general delivery statuses, such as delivered, partially delivered, or closed, but not the customized result. This prevents external integrations from replicating the detail shown in the Handy report. Request: Add an object or fields for the delivery result to the list/detail of the API deliveries, including at least:

A customer uses the “Created from Web” source as an operational alert to identify modified orders after delivery. The seller creates the order from the mobile app. Warehouse prints and supplies it. If a product is missing during delivery, delivery notes it manually. Administration receives the notes days later and edits the order from the web to adjust the amount to what was actually delivered before invoicing it. Previously, when editing it from the web, the order was shown as “Created from the Web”. This notified the warehouse that it was a correction and prevented them from confusing it with a new order to print or fill. The order now retains its mobile origin when it is edited. As the correction can be made several days later, the warehouse may see a recent order marked as a “Mobile App” and interpret it as a new order, with the risk of duplicate stock.

Add a Unit column to sales and delivery tickets, next to Description, Quantity, Unit Price and Amount. Expected example: Cracker Marías 185 g | 1 | Piece | $ 14.00 | $ 14.00. Currently, the ticket already shows a description, quantity, price and amount, but it does not make the sales unit explicit. This can cause errors when stocking or delivering products with similar descriptions or that are sold in different presentations (part, box, package, etc.).

Allow you to create and save a delivery route with a manual or optimized order of customers, considering real distance along streets, road directions, opening hours, service windows and, if possible, traffic. Optimization should automatically prioritize customers with limited hours. For example, if some customers close from 13:00 to 17:30 and others remain open all day, the system must first visit those with restricted hours and leave those available all day for when the others are closed. The route must be able to be assigned to any deliveryman and be kept available even if the user changes, so that a substitute can follow the same route without relying on the knowledge of the usual deliveryman. It would also be ideal to export or open it as a complete route in Google Maps/Waze, with point-to-point navigation and progress to the next customer. Nowadays, the system allows the mobile user to enter the map, see the customers they should visit and create an optimized route for that route. However, once the route is created, all it does is draw it on the map; it does not allow creating a route with different stops to guide the driver so as not to have to ask customer by customer how to get there. Another thing that happens to me, for example, is on a two-way street: I have customers who, in order to reach, I must cross the street. In other words, if in 5 blocks I have 10 customers (8 on one side and 2 in the middle), the system today recommends that I visit those 2 customers when I walk through the door. In reality, perhaps the best thing to do is to first do what is left on one side and then do what is left in the opposite direction. These types of details, nowadays, the administrator has no way of prefixing them in the tour.

That the products are displayed in the same order when viewing and closing the route as when printing the initial and final inventory, ideally ordered by product code. Example of use: Upon receiving the initial inventory, the staff annotates and physically counts the products on the printed document. Later, when capturing the information during the route closure, the products appear in a different order, so they must search for and cross them manually. If both listings kept the same order, it would be easier to compare information, capture quantities and detect differences, reducing time and possible errors in closing.