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

Question

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

Проблема, с которой я сталкиваюсь, заключается в следующем.

У меня есть таблица для моих продуктов с

id, name, price, quantity.

Теперь у меня есть другая таблица для моих продаж, но есть моя проблема.Какие поля мне нужно иметь.В конце дня я хочу сохранить такую ​​запись:

20       product_x       $ 5,00         $ 100,-
20       product_y       $ 5,00         $ 100,-
20       product_z       $ 5,00         $ 100,-
20       product_a       $ 5,00         $ 100,-
-------------------------------------------------
                                        $ 400,-

Итак, как мне смоделировать это в записи о продажах.Должен ли я просто создать объединенную запись с разделением запятой идентификатора продукта.

Или есть другой способ сделать это правильно.

Answer 1

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

1. Поддерживает сайты, местоположения, склады и т. Д.
2. Поддерживает классификацию и группировку
3. Поддержка универсального продукта (например,«Настольные часы» и конкретный продукт «Citizen C123 Multi Alarm Clock»)
4. Также поддерживаются варианты брендов (от разных производителей)
5. Имеет CSM (поддержка цвета / размера / модели) Пример.Bata Sandles (цвет 45 дюймов, синий цвет)
6. Экземпляры продукта с серийными номерами (например, телевизоры, холодильники и т. Д.)
7. Контроль партий / Контроль партий с серийными номерами.
8. УпаковкаРазмер / конверсия UOM и UOM
9. Производитель и бренды, а также поставщики
10. Также включен пример таблицы транзакций (Заказ на поставку)
11. Существует много других типов транзакций, таких как «Проблемы»,Передачи, корректировки и т.д.

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

Приветствия ... !!!

Wajira Weerasinghe.

Сайты

• id
• код_сайта
• Имя_сайта

Склад

• id
• идентификатор_сайта
• код_склада
• имя_склада

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

• идентификатор
• код_категории
• category_name

Группа товаров

• id
• group_code
• group_name

Универсальный продукт

• id
• generic_name

Product

• id
• product_code
• category_id
• group_id
• brand_id
• generic_id
• model_id / part_id
• product_name
• product_description
• product_price (текущий курс)
• has_instances (y / n)
• has_lots (y / n)
• has_attributes
• default_uom
• пакет_размер
• средняя стоимость
• single_unit_product_code (для пакетов)
• размерная группа (указывает на размеры)
• информация о лоте
• гарантийные сроки (общие, не специфичные)
• is_active
• удалено

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

• id
• имя_атрибута

атрибут_продукта

• 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)
• Guarantee_terms
• идентификатор значения атрибута продукта (если применимо)

лот продукта

• идентификатор
• код_строки / код партии
• датаe_manufactured
• date_expiry
• идентификатор значения атрибута продукта (если применимо)

Марка

• идентификатор
• factory_id
• brand_code
• brand_name

Производитель бренда

• id
• имя_производителя

Складской запас

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

Записи о ценах на продукты

• product_id
• from_date
• product_price

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

• id
• supplier_id
• дату покупки
• total_amount

Строка заказа на покупку

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

Поставщик

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

product_uom

• ID
• uom_name

product_uom_conversion

• ID
• from_uom_id
• to_uom_id
• conversion_rule

Answer 2

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

Таблица:

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;

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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_sales
JOIN table_product_sales
ON table_product_sales.product_id = table_product.id
GROUP BY DATE(transaction_time)

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

Answer 6

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