Лучшая структура базы данных инвентаризации

Ответ 1

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

Таблицы:

create table product (
  id integer primary key,
  name varchar(100) not null,
  price decimal(6,2) not null,
  inventory integer not null
);

create table sale (
  saledate date not null,
  product_id integer not null references product,
  quantity integer not null,
  price decimal(6,2) not null,
  primary key (saledate, product_id)
);

Отчетность за день:

select s.product_id, p.name, s.quantity, s.price, (s.quantity * s.price) as total
from product p, sale s
where p.id = s.product_id
and s.saledate = date '2010-12-5';

Отчетность в течение всех дней:

select saledate, sum(quantity * price) as total
from sale
group by saledate
order by saledate;

Хороший главный отчет за все дни, с итоговой строкой:

select *
from (
    (select s.saledate, s.product_id, p.name, s.quantity, s.price, (s.quantity * s.price) as total
    from product p, sale s
    where p.id = s.product_id)
  union
    (select saledate, NULL, 'TOTAL', sum(quantity), NULL, sum(quantity * price) as total
    from sale group by saledate)
) as summedsales
order by saledate, product_id;

Ответ 2

Это модель, которая поддерживает многие аспекты,

• Поддержка сайтов, мест и складов и т.д.
• Поддержка категоризации и группировки
• Поддержка общего продукта (например, "Настольные часы" и специальный продукт "Citizen C123 Multi Alarm Clock" )
• Также поддерживайте варианты брендов (разными производителями).
• Имеет CSM (поддержка цвета/размера/модели) Пример. Bata Sandles (цвет 45 дюймов синий цвет)
• Экземпляры продукта с серийными номерами (такими как телевизоры, холодильники и т.д.).
• Управление партиями/пакетное управление с серийными номерами.
• Размер упаковки /UOM и UOM-конверсия
• Производитель и бренды, а также поставщики
• Также включена примерная таблица транзакций (заказ на поставку)
• Существует много других типов транзакций, таких как "Проблемы", "Трансферы", "Корректировки" и т.д.

Надеюсь, это поможет. Пожалуйста, дайте мне знать, если вам нужна дополнительная информация по каждой таблице.

Ура!!!...

Wajira Weerasinghe.

Сайты

• ID
• site_code
• site_name

Склад

• ID
• site_id
• warehouse_code
• warehouse_name

Категория товара

• ID
• category_code
• category_name

Группа элементов

• ID
• group_code
• group_name

Общий продукт

• ID
• generic_name

Продукт

• ID
• product_code
• category_id
• group_id
• Brand_ID
• generic_id
• model_id/part_id
• product_name
• PRODUCT_DESCRIPTION
• product_price (текущая ставка)
• has_instances (г/л)
• has_lots (y/n)
• has_attributes
• default_uom
• PACK_SIZE
• average_cost
• single_unit_product_code (для пакетов)
• size_group (указывая на размеры)
• lot_information
• warranty_terms (общий неконкретный)
• is_active
• зачеркнуть

тип атрибута продукта (цвет/размер и т.д.)

• ID
• attribute_name

product_attribute

• ID
• product_id
• attribute_id

значение атрибута продукта (этот продукт → красный)

• ID
• product_attribute_id
• значение

product_instance

• ID
• product_id
• имя_экземпляра (как указано изготовителем)
• serial_number
• brand_id (это бренд)
• stock_id (запись запасов, указывающая qih, местоположение и т.д.).
• lot_information (lot_id)
• warranty_terms
• идентификатор свойства продукта (если применимо)

серия продуктов

• ID
• lot_code/batch_code
• date_manufactured
• date_expiry
• идентификатор свойства продукта (если применимо)

Марка

• ID
• manufacturer_id
• brand_code
• BRAND_NAME

Производитель торговой марки

• ID
• manufacturer_name

Фото

• ID
• product_id
• storage_id, zone_id, level_id, rack_id и т.д.
• количество в руке
• Идентификатор значения атрибута продукта (если применимо) [у нас есть 4 элемента красного цвета и т.д.]

Отчет о ценах на продукцию

• product_id
• FROM_DATE
• PRODUCT_PRICE

Заголовок заказа на поставку

• ID
• supplier_id
• ПОКУПКИ
• TOTAL_AMOUNT

Линия заказа на поставку

• ID
• po_id
• product_id
• unit_price
• количество

Поставщик

• ID
• supplier_code
• Имя поставщика
• supplier_type

product_uom

• ID
• uom_name

product_uom_conversion

• ID
• from_uom_id
• to_uom_id
• conversion_rule

Ответ 3

Попробуйте моделировать продажи как транзакции - с помощью "заголовка", то есть проданного, когда продано, счета # (если применимо) и т.д. и "позиций", т.е. 20 * product_x @$5 = $100. Самый безопасный подход заключается в том, чтобы не полагаться на цены и т.д. Из таблицы продуктов - поскольку они, по-видимому, будут меняться со временем и вместо этого копировать большую часть информации о продукте (если не все) в вашу позицию - так что даже когда цены, описания предметов и т.д.., информация о транзакции остается такой же, как и в момент совершения транзакции.

Ответ 4

Инвентаризация может стать довольно сложной моделью. Сначала вам нужно понять, что вам нужно указать стоимость инвентаря на основе того, что вы заплатили за него. Это означает, что вы не можете полагаться на таблицу продуктов, которая обновляется до текущей цены. Хотя вам может понадобиться такая таблица, чтобы помочь вам разобраться, что ее продавать, есть налоговые причины, по которым вам нужно знать фактическую сумму, которую вы заплатили за каждый товар на складе.

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

Затем вам понадобится таблица, в которой хранится фактическое местоположение склада каждой части и цена при покупке. Если элементы достаточно велики, вам нужен способ индивидуально пометить каждый элемент, чтобы вы знали, что было снято. Обычно для этого используются штрих-коды. Эта таблица должна быть обновлена, чтобы записать, что эта часть больше не существует, когда вы ее продаете. Я предпочитаю сделать запись неактивной и иметь ссылку на мои данные о продажах на эту запись, поэтому я точно знаю, за что заплатил и за что продал каждую часть.

Продажи должны иметь как минимум две таблицы. Один для общей информации о продаже, пользовательское имя (также должна быть таблица клиентов большую часть времени, чтобы получить эти данные), дату, где она была отправлена ​​и т.д.

Затем таблицу подробных данных о продажах, которая включает запись для каждой позиции в заказе. Включите все данные, необходимые для части, цвета, размера, количества, цены. Это не денормализация, это хранение исторических данных. Единственное, что вы не хотите делать, это полагаться на цены в таблице продуктов за все, кроме основной записи в эту таблицу. Вы не хотите делать отчет о продажах, и цифры выходят неправильно, потому что цены на товары изменились накануне.

Не создавайте базу данных инвентаризации без консультации с бухгалтером или специалистом по налогам. Вы также должны прочитать некоторые данные по внутреннему контролю. Легко украсть у неизвестной компании, которая не выполнила свою работу по внутреннему контролю в базе данных.

Ответ 5

Я думаю, вам нужна таблица с полями, показывающими свойства транзакций для каждого клиента ИЛИ таблица с полями - дата, продукт (зарубежный), количество - таким образом у вас не будет проблем с новыми продуктами.

Ответ 6

Попробуйте несколько таблиц со ссылками

table_products
id
name

table_product_sales
id
product_id
quantity
price_per
transaction_time AS DATETIME

SELECT table_product_sales.*, table_product.name 
FROM table_product
JOIN table_product_sales
ON table_product_sales.product_id = table_product.id
GROUP BY DATE(transaction_time)

Не пробовал, но будет ли что-то подобное работать? Это позволяет вам хранить каждую транзакцию отдельно, чтобы вы могли запрашивать такие вещи, как среднее количество проданных за продажу, общее количество проданных за день, общее количество продаж за день и т.д.

Ответ 7

@Wajira Weerasinghe

Вы структура хорошая, я хочу использовать в нашем проекте. Можете ли вы выслать мне диаграмму ER для системы управления запасами