13

Вопрос по ruby-on-rails – undefined

Я пытаюсь создатьbasic Система управления точками продаж и инвентаризации.

Некоторые вещи, которые следует учитывать:

  • The products are always the same (same ID) through the whole system, but inventory (available units for sale per product) is unique per location. Location Y and Z may both have for sale units of product X, but if, for example, two units are sold from location Y, location Z’s inventory should not be affected. Its stocked units are still intact.
  • Selling one (1) unit of product X from location Y, means inventory of location Y should subtract one unit from its inventory.

Исходя из этого, я подумал об этих таблицах:

  • locations

    • id
    • name
  • products

    • id
    • name
  • transactions

    • id
    • description
  • inventories_header

    • id
    • location_id
    • product_id
  • inventories_detail

    • inventories_id
    • transaction_id
    • unit_cost
    • unit_price
    • quantity
  • orders_header

    • id
    • date
    • total (calculated from orders_detail quantity * price; just for future data validation)
  • orders_detail

    • order_id
    • transaction_id
    • product_id
    • quantity
    • price

Хорошо, есть вопросы? Конечно.

  1. How do I keep track of changes in units cost? If some day I start paying more for a certain product, I would need to keep track of the marginal utility ((cost*quantity) - (price*quantity) = marginal utility) some way. I thought of inventories_detail mostly for this. I wouldn’t have cared otherwise.
  2. Are relationships well stablished? I still have a hard time thinking if the locations have inventories, or if inventories have several locations. It’s maddening.
  3. How would you keep/know your current stock levels? Since I had to separate the inventory table to keep up with cost updates, I guess I would just have to add up all the quantities stated in inventories_detail.
  4. Any suggestions do you want to share?

Я уверен, что у меня все еще есть некоторые вопросы, но в основном это те вопросы, на которые мне нужно ответить. Кроме того, поскольку я впервые использую Ruby on Rails, на самом деле, как опыт обучения, стыдно останавливаться на дизайне, не позволяя мне быстрее выполнять реализацию, но я предполагаю, что & # x2019 ; так оно и должно быть.

Заранее спасибо.

  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от Andrés Botero
  • Error: User Rate Limit Exceeded

    от Andrés Botero
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • хорошо, братан, это хороший вопрос

    от r.hamd
  • 2

    Брайан прав. Просто чтобы добавить дополнительную информацию. Если вы

    работаете в полную систему для вашего бизнеса или клиента. Я бы посоветовал вам начать работать на организационном уровне вплоть до процесса POS и бухгалтерского учета. Это сделало бы вашу базу данных более обширной ...: P По моему опыту в разработке систем, модули инвентаризации всегда начинаются с учета + + (возврат покупки-покупки) = SKU, доступный для продажи. POS не связан напрямую с модулем инвентаризации, а будет ежедневно согласовываться с руководителем отдела продаж. Итоговые ежедневные объемы продаж будут затем вычтены в SKU, доступный для продаж. Вы также разработаете модули калькуляции и ценообразования. Правильная нормализация базы данных всегда обязательна.

  • 19

    Сложность в том

    что вы действительно делаете больше, чем просто POS-решение. Вы также осуществляете управление запасами и базовая система учета затрат.

    Первый сценарий, который вам необходимо рассмотреть, - это какой метод учета вы будете использовать для определения стоимости любого проданного товара. Наиболее распространенными вариантами могут быть FIFO, LIFO или конкретная идентификация (все термины, которые можно найти в Google).

    Во всех трех сценариях вы должны записывать свои покупки ваших товаров в структуре данных (обычно называемой PurchaseOrder, но в этом случае я назову ее SourcingOrder, чтобы отличать ее от таблиц заказов в исходном вопросе).

    Структура ниже предполагает, что каждая строка заказа на поставку будет для одного местоположения (иначе вещи становятся еще более сложными). Другими словами, если я куплю 2 виджета для магазина A и 2 для магазина B, я добавлю к заказу 2 строки с количеством 2 для каждого, а не одну строку с количеством 4.

    SourcingOrder
     - order_number
     - order_date
    
    SourcingOrderLine
     - product_id
     - unit_cost
     - quantity
     - location_id
    

    Инвентарь может быть одного уровня ...

    InventoryTransaction
     - product_id
     - quantity
     - sourcing_order_line_id
     - order_line_id
     - location_id
     - source_inventory_transaction_id
    

    Каждый раз, когда SourcingOrderLine поступает в магазин, вы создаете транзакцию InventoryTransaction с положительным количеством и ссылками FK наsourcing_order_line_id, product_id а такжеlocation_id.

    Каждый раз, когда совершается продажа, вы создаете транзакцию InventoryTransaction с отрицательным количеством и ссылками FK наorder_line_id, product_id а такжеlocation_id, source_inventory_transaction_id.

    source_inventory_transaction_id будет ссылкой из отрицательного количества InventoryTransaction обратно на положительное количество InventoryTransaction, рассчитанное с использованием любого метода учета, который вы выберете.

    Текущий инвентарь для местоположения будетSELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ? GROUP BY product_id, location_id.

    Предельная стоимость будет рассчитываться путем отслеживания от продажи через 2 связанные операции с запасами до строки SourcingOrder.

    ПРИМЕЧАНИЕ. Необходимо обработать случай, когда вы распределяете одну строку заказа между двумя транзакциями инвентаризации, поскольку заказанное количество было больше, чем то, что осталось в следующей транзакции инвентаризации для распределения. Эта структура данных будет обрабатывать это, но вам нужно будет работать с логикой и запрашивать себя.