Transactions can have a list of items

[Megadash452]

When creating a new Transaction, the user has the choice to include a list of the items that they purchased as part of that transaction. This feature is especially useful for transactions with many items (e.g. a visit to the grocery store). Having detailed data on a big list of items that recurrently purchased can help with budgeting,
such as finding items that you can cut from your next visit to the grocery store when your budget is lower.

• Implement basic features:
  • Item name. Includes brand + classification (e.g. Favio's olive oil). Items can be stored in a HashMap (with name as key) while the user is creating the transaction/editing items.
  • Item price: How much is the specific item's unit cost.
    • All item's prices must use the transaction's set currency, regardless of if it is set by the locale or by the user.
    • Item prices must add up to the total transaction price (set separately). If not, that's an error and the new transaction can't be submitted.
      • When the summed cost of items is less than the full Transaction price, it may be because the Tax item (described below) is missing. Show the user a button to add the tax item.
  • Multiplier: How many of this item were purchased in this transaction.
    • If the user tries to add an item with the same name as an already existing item when creating the transaction, the multiplier of the existing item should be incremented.
      • In this scenario, the prices must match both instances, otherwise it is an error and the multiplier cannot be incremented.
• Optional Tax item:
  • This item must not be mandatory, as not all transactions detail a Tax cost.
  • Contains extra field for tax percentage (not stored as separate column).
  • Item name format: <TAX_PERCENTAGE> Tax.
  • Multiplier must be locked to 1 and hidden from user.
  • Price must be the sum of all other items * percentage, otherwise it's an error and transaction can't be submitted.
• Use OCR to scan for items in an image.
  • Manually typing each item is very impractical for large transactions, so there should be an easy way to add all items from a receipt to the transaction.
  • The OCR engine should respect the user's privacy, so it will ideally be fully offline.
  • The image of the receipt should be stored in the database (or a separate database that only stores receipt images). The transaction should contain a reference (ID) to the image if one exists.
  • After a scan is done, the user should be able to revise (easily read and edit) it in case of errors.

The OCR engine is not a very important goal and is very involved because it must handle a lot of edge cases, so it might be one of the last features to be implemented.