Лучший способ хранить информацию налога с продаж
При разработке системы баз данных управления запасом для продаж и покупок, каков был бы лучший способ сохранить различные налоги и другие такие суммы?
Несколько полей, которые могли быть сохранены:
- Цена за единицу товара, исключая налог
- Цена за единицу товара включая налог
- Налог на объект
- Общее количество, исключая налог (округленный к 2 десятичным числам)
- Общее количество включая налог (округленный к 2 десятичным числам)
- Общий налог (округленный к 2 десятичным числам)
- Налоговый процент
- Fk связываются с Налоговым % (и не хранят сумму налога),
В настоящее время самое разумное решение до сих пор хранит вниз (примерно) объект, количество, общее количество, исключая налог (округленный) и общий (округленный) налог.
Существует ли лучший способ сохранить эти детали для универсальной системы?
Учитывая систему должно быть устойчивым, что должно быть сделано, если бы было несколько налоговых значений, которые, возможно, должны были бы быть разделены (например, состояние и город)? В этом случае отдельная таблица была бы в порядке, но это будут считать чрезмерным, чтобы просто иметь rowID и некоторый taxID, отображающийся на totalTax столбец?
Разъясниться: Выяснение, как хранить данные об отдельных транзакциях и той стороне; не так детали о налоге определенные уровни.
1 ответ
Проблема с подходом заключается в том, что если налог меняется, то НДС (налог с продаж) в Великобритании менялся дважды за последние 12 месяцев.
Когда я работал на сайтах электронной коммерции, у нас была таблица Tax_Rate, в которой хранились различные налоговые ставки, с которыми имел дело магазин, например
- TaxFree - 0%
- Vat - 17,5%
- DiscountedVat - 15%
- и т.д....
и затем поля вашей таблицы запасов могут иметь
- ItemId
- UnitPrice
- fk_TaxRate
ваша таблица строк invoice_detail будет
- fk_OrderId
- fk_ItemId
- PerItemPriceCharged (денормализовано)
- TaxRateCharged (денормализовано)
- QuantityOrdered
ваша таблица счетов будет
- OrderId
- fk_CustomerId
Где fk_ обозначает внешний ключ. Обратите внимание, что OrderId не будет уникальным в вашей таблице строк счета-фактуры.
РЕДАКТИРОВКА: Сегодня голова идет кругом.
Вам нужно денормализовать итоговую строку счета-фактуры и итоговую ставку налога, потому что вы не хотите, чтобы будущие изменения в цене товара или ставке налога повлияли на исторические счета-фактуры.