Citrus-Lime Backoffice

In the previous version of Cloud POS, the SIM Import screen remembered the last selected category and automatically applied it to subsequent lines, which saved time and reduced repetitive searching. In POS2, the category must be manually reselected for every line, significantly slowing down SIM imports, especially for users who cannot use Bulk SIM Import because they don’t have supplier SKU lists. Reintroducing the ability for POS2 to retain and reuse the last selected category during SIM Import would improve efficiency and usability and restore behaviour that users were already familiar with.

Customers often surprise us by mentioning that they actually have insurance for their bike, which covers the costs of the job. Depending on the job, there can also be different addresses within the same insurance company that need to be listed as the client on the invoice. So far, I haven’t found any way to change the billing address from the customer to the respective insurance company, which means we have to rewrite the entire job from scratch. These are usually jobs with a larger number of items, and this naturally takes time. It would help us a lot if we could simply replace the client on the job.

At the moment if we need to extend an expiry date or search for a voucher we have to go to Cloud Reports and then navigate back to find the customer record in Cloud POS Backoffice. Could a page be added to Cloud POS Backoffice where you can search gift vouchers.

Request: Improved Item Management and Reporting Controls in POS System I am requesting changes to the item management and reporting behavior within the Point of Sale system. I recently spent over an hour attempting to clean up duplicate item records related to Thousand Helmets, and the current limitations in the system are creating ongoing operational issues. Background Over time, multiple item codes were created for the same Thousand Helmet SKUs due to inconsistent coding sources: - Item codes generated by Pedego - Manufacturer item codes from Thousand Helmets for Version 1 helmets - Updated manufacturer item codes from Thousand Helmets for Version 2 helmets There is no meaningful difference between the V1 and V2 helmets. As a result, the same helmet (same collection, color, and size) existed under three different item codes. This resulted in: 279 item codes (31 colors × 3 sizes × 3 code sets). When there should only be 93 item codes (31 colors × 3 sizes). Actions Taken From day one, I asked to delete the duplicate items. That option is not available, so I at first I archived the incorrect (“bad”) item codes. However, they kept showing up in reports and options within the Back Office and Cloud Reports. This morning I spent nearly 2 hours merging the "bad" item codes into the correct (“good”) item codes. While the merge function technically works, it leaves the merged items as archived records that still appear throughout the system. Ongoing Issues Despite being archived, these merged item codes: - Continues to appear in reports and item lists - Appears unless “Archived Items” are manually filtered out (by setting Active = FALSE, which is not always obvious or consistently applied) - Are frequently selected by staff during check-ins because the archived items still match the same style, color, and size - Interferes with inventory counts, stock level reviews, and receiving processes See listing This creates confusion, inaccuracies, and unnecessary operational friction. Requested Improvements - Default Reports and Lists should only list Active Items, unless the user specifically requests the Archived Items be shown. -- In all cases, the system should default to showing Active items only in all lists and reports. -- Archived items should appear only when explicitly toggled on. -- This would prevent staff from inadvertently using incorrect or obsolete item codes. - Ability to Delete Item Codes I understand there may be historical or reporting implications when deleting items. A warning message explaining the potential consequences would be appropriate. However, as the business owner, I should have the option to permanently delete item codes from my own database if I choose. Deleting an item affects only my data and my reporting, and I should be allowed to make that decision. Summary The current behavior—where archived and merged items continue to surface throughout the system—creates ongoing inventory, reporting, and workflow problems. Allowing Active-only defaults, and true deletion of item codes would significantly improve data clarity, staff accuracy, and overall system usability. Thank you for considering these changes. I’m happy to discuss further or provide examples if helpful.

The existing feature is excellent: when an item is imported from SIM and is available from other SIM suppliers in my database, those suppliers are automatically added to the item card with the correct supplier numbers. This saves a huge amount of time. What would be a great improvement to this, would be when any new suppliers become available on SIM, if I then get that supplier added to my database, it will automatically add that supplier to the already existing item. For example, I might stock a SRAM item from QBP and JBI, both of which are already active SIM suppliers, so I import the item from one of them. I also get the item from SRAM directly. If SRAM later becomes available on SIM, it would be great if SRAM were automatically added to the existing item card. At the moment, this requires going back into SIM import and re-importing the item purely to add the new supplier. Is this something that would be possible at all?

Should be able to delete items that were added in error, providing they have never sold of have any history. for example - we did a sim upload but not realising it had stuff on it we would never use.

The current Price Wizard workflow makes it difficult for us to manage sale pricing independently. Supplier files can use either supplier part codes or UPCs, but do not always include both, while the Price Wizard export uses ILCs and does not include UPCs. This forces retailers to reconcile pricing across multiple files using Barcode or Alias reports, resulting in a complex and error prone spreadsheet process. Impact: The workflow is time consuming, increases the risk of errors, and frequently requires support involvement, creating friction for retailers and additional support overhead. Potential improvements: Add a UPC/Alias column to the Price Wizard output, or allow Price Wizard import files to consist of 3-4 required fields to simplify the process: ILC/SPC/Alias, sale price, and the sale start and end date.

Having the ability to search by dept/category on the calculate screen would be immensely helpful. For instance, when we are inventorying the Clothing department it would be much easier to focus in on the Jersey category to see discrepancies. Adding those 2 fields to the Manage View button would be awesome.

When adding standard items that already exist in BO into a matrix, the page where the attribute selection is made, you can only view the ILCs of the items, not the item descriptions. This makes it extremely tricky to work out which ILC relates to which attribute. Please could the item description be included on this page?

A customer bought a thing, or paid a deposit on a thing, but then brought it back for a refund or cancelled the order - and therefore needed a refund. Our accounts department want to check if the original purchase happened in one VAT quarter, and the refund happened in a later VAT quarter. Also, the customer changed his mind and wanted to order it again. Also also, we might want to check whether this customer habitually places orders and then cancels orders. Purchase history is where we go looking for answers to this kind of stuff, but it's not there!