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

(Сразу хочу сказать, что речь идет о Голландии.)

Для каждой позиции заказа нужно хранить цену, процентную ставку НДС и рассчитанный НДС.

Не могу решить, как лучше хранить цену позиции заказа.

Разные позиции заказа могут иметь разное значение процентной ставки НДС (в зависимости от группы НДС, к которой принадлежит товар).

При этом база данных должна использоваться как магазинами типа Business-to-Customer (B2C), так и магазинами типа Business-to-Business (B2B).

B2C - магазин, в котором покупают обычные покупатели. Пример - обычный супермаркет.

B2B - магазин, в котором покупают компании. Например, оптовый магазин, в котором покупают розничные магазины.

В фактуре B2C-магазина цена показана с учетом НДС, в фактуре B2C-магазина цена показана без учета НДС. (НДС показывается отдельно о обоих случаях).

Соответственно, в B2C-магазине покупатель видит цены с учетом НДС, а в B2B-магазине без учета НДС.

И еще: первоначальная цена товара (которую устанавливает администратор магазина) может быть как с учетом НДС, так и без учета НДС. Для B2C-магазинов удобнее задавать цену с НДС, а для B2B-магазинов без учета НДС. То есть в таблице цен в БД цена может хранится как с учетом НДС, так и без него.

Думаю о таких вариантах хранения цены (я имею в виду цену в таблице, где хранятся позиции заказа). Все цены округленные до второго знака после запятой (используется SQL Server 2008, тип данных Decimal(10, 2)):

1. Цена + НДС; % НДС; величина НДС (округленная)
2. Цена без НДС; % НДС; величина НДС (округленная)
3. Цена + НДС; цена без НДС; % НДС. Величину НДС не хранить (можно рассчитать на основе двух цен).
4. Цена без НДС или Цена + НДС; флаг, показывающий, включен НДС в цену или нет; % НДС; величина НДС (округленная).

При этом следует иметь в виду, что процентная ставка НДС для позиции заказа может измениться после того, как заказ создан и оплачен.

Например, покупатель заказал в магазине телевизор 30 декабря и тут же оплатил заказ. Товара в тот момент на складе нет, он будет поставлен через две недели. 1 января изменился % НДС для этой группы товаров. Фактура выписывается в момент отправки товара покупателю, уже с новым значением процентной ставки НДС. При этом величина цены товара + НДС должна остаться неизменной (производится пересчет, то есть величины цены товара без НДС и величина НДС становятся другими, но их сумма остается неизменной).

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

softwarer
Имхо наиболее безгеморройный в общем случае метод - храните первичку. Информацию в том виде, в каком она внесена и "работает".

А что такое "первичка" ? А то я давно уже эмигрировал и в русских терминах не разбираюсь.

softwarer
- Если в декабре клиент заплатил 30 сребреников - напишите в таблицу "30 сребреников".
- Если в январе программа решила, что НДС=10% - модифицируйте запись на "ставка=10%", и опционально можно записать "НДС=3 сребреника".
- Итд.


Так и собираюсь, но в этом случае еще собираюсь хранить старое значение цены и НДС (пока это не нужно, но кто его знает, может, в будущем понадобится).

softwarer
Для НДС, суммы без НДС и так далее - можно делать вычисляемые поля, можно делать view, можно ещё как - это уже вопрос десятый. Главное - не терять первичку и плясать от неё.

"Первичка" в этом случае - это исходная цена товара, я правильно понимаю ?

mazzy
Храните так, чтобы минимизировать число делений (они порождают округления).
Операции: Сложение, Вычитание безопасны с точки зрения округления.

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


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

mazzy
Кроме того, учитывайте, что в качестве налогов может выступать не только НДС
А также в одном заказе могут встречаться несколько налогов (например, НДС и акциз)


Ну, с этим у нас в Голландии просто (по крайней мене, для Интернет-магазина) - имеется только НДС трех видов: 0%, 6% и 19%.

John 3VoltaПодозреваю, что ставка НДС не меняется каждый день. Значит описанная ситуация, когда нужно подгонять цену под итоговую сумму, достаточно редкая. Может всё же хранить цену без НДС? "Накрутить" процент всё же проще.

Исходную цену не всегда удобно хранить без НДС. В B2C-магазине удобнее задавать цену сразу с НДС, потому что:
1. Администратору магазина так удобнее, потому что это та цена, которую видит покупатель.
2. %НДС может измениться, и в этом случае цену придется пересчитать, чтобы цена + НДС (для покупателя) осталась той же. Хотя это и редко происходит, но все же лишняя работа.

NafНаверное такие вопросы нужно у заказчика узнать
С уважением, Naf

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

DataFlower
Но кто ж позволит 0,005 округлять к 0, а не к 0,01 ? :)


Хорошая мысль, надо не забыть использовать при вычислениях.

DataFlower
SQL Server 2008, тип данных Decimal(10, 2) - а что у этого типа с округлениями при выполнении операций?

Реализовано стандартное математическое округление. Например, для


и для


результат будет 2.35.

В этом смысле Microsoft непоследователен - например, в C# реализовано банковское округление. В следующем примере


результат будет 2.34.
DataFlower
Если не ок, то какой-то целочисленный возможно лучше, хотя и напряжно потом все время при визуализаии отделять копейки.

С целочисленным тоже не все просто - при округлении просто отбрасывается дробная часть:

Результатом


будет 3, а не 4, как надо бы.

mcureenabтип Decimal(10, 2) для валюты не очень хорош. А ну как в Японию проект портировть придётся? Лучше хранить целое число и единицу измерение - копейки, центы, пенсы и т.п. или их производные.


Для Японии можно просто дробную часть всегда устанавливать в 0. Мне кажется, в этом случае проблем быть не должно.

В остальных случаях использовать Decimal(10, 2).

Правда, в 1995 году (не знаю, как сейчас) была одна валюта, которая состояла не из 100 частей, а из 1000. Но это у какой-то экзотической страны.

mcureenab
% НДС неудачное решение. Лучше иметь тип налога, точнее метода расчёта налога, или группы налогов.


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

mcureenab
Причём для розницы налог может расчитываться от цены с налогом, а для организаций от цены без налога, т.е. налог один а методов расчёта два.


У нас так и происходит - для розницы (B2C) цена товара хранится с НДС, а для организаций (B2B) - без НДС.

Конкретнее, магазины могут быть 3-х типов

1. B2C - все цены хранятся с НДС.
2. B2B - все цены хранятся без НДС.
3. B2B и B2C - каждый из покупателей принадлежит к одной из групп. Каждая группа задает тип покупателя - либо B2B (организация), либо B2C (розница). Для каждой группы имеется своя цена товара. Цена для группы B2C хранится с НДС, для группы B2B - без НДС.