Практика заказа / выставления счетов: сохранить чистую / брутто / НДС или рассчитать?

Так что это будет зависеть от нескольких других факторов.

Является ли это новой средой или той, которая уже работает некоторое время? Изменение дизайна db на том, что в настоящее время используется, является головной болью. Это особенно верно, если таблица OrderItem является важной частью бизнес-процессов Inbound.

Если мы находимся в новой среде db без каких-либо пользователей или данных, о которых нужно беспокоиться, я бы сказал, что мы в безопасности, чтобы внести изменения. Однако мы также должны спросить, возможно ли, что эти «исторические данные» станут «активными данными» в будущем.

Если это активный дБ, нам нужна веская причина, чтобы пройти через головную боль изменения схемы таблиц с уже связанными с ней данными. Как часто нам нужно ударить VatCodeID (FK) в наших текущих процессах отчетности? Если ответ «не очень часто», мы можем сэкономить много времени и много денег, оставив его как есть.

Но, возможно, мы часто используем OrderItem, и это будет Приятно иметь все наши данные на плоской таблице по деловой причине. Затем мы должны спросить: могу ли я уйти с меньшими затратами и добиться аналогичного повышения производительности?

Поскольку мы проверяли, как часто запрос OrderItem запрашивается при присоединении к тому, что ссылается на VatCodeId, мы можем найти эти запросы и посмотреть, можно ли их вообще оптимизировать. Это может включать добавление индекса либо к OrderItem, либо к ссылке VatCodeId, которая будет по-прежнему предпочтительнее изменять структуру таблицы большую часть времени.

Имейте в виду, что даже после того, как вы altered участвовали в таблицах и переносили данные, вам может понадобиться исправить любые insert заявления, в которых разработчик ленился и не был таким как они должны были быть. Кроме того, если запись в OrderItem связана с несколькими записями в таблице VatCodeId, то нам также придется пройти и исправить инструкции group by, которые вытягиваются из OrderItem.

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

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

I сильно рекомендуют хранить рассчитанные значения всех полей, так как ставки налога и расчеты изменяются. Это включает чистую, валовую, НДС и общую сумму. Причина в том, что расчеты могут измениться в любое время.

Например, представьте себе, что ставка налога составляет 10%. Вы продаете 10 единиц по 10 долларов США каждый. Так что брутто составляет 100 долларов. Вы рассчитываете налог, вычитаете 10%, а ваша сеть теперь составляет 90 долларов.

Но через два года ставка налога составляет 13%. Собираетесь ли вы изменить свои программы отчетности, чтобы они иначе рассчитывали налог для более старых транзакций? Сделав это в прошлом, я буду держать пари, что вы ошибаетесь где-то. Вам придется изменить десятки или, может быть, сотни программ отчетности. Вы обязательно пропустите несколько, и вы не найдете их всех в течение лет . Спасите себе головную боль: храните все, что вам нужно. Не зависеть от способности вычислять завтра то, что вы рассчитали сегодня.

Также обратите внимание, что другие вещи, кроме ставок, могут измениться. Они могут изменить, какие предметы облагаются налогом. Они могут добавить градуированные налоговые ставки или заставить вас рассчитать два разных вида налогов или ... поверьте мне, многое изменится. В США налоговые расчеты для бензина заставят вашу голову вращаться, с разными ставками для федерального, штата, округа, города и т. Д. Иногда ставка налога зависит от того, сколько времени у вас было топлива в инвентаре, где вы его отправили откуда вы отправили его, и (я не шучу) в день недели, в который вы его доставляете. Это безумие!

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

Я бы также сохранил всю историю по причинам, указанным другими плакатами. Тем не менее, вот вам эта мысль: используя временные таблицы SqlServer, вы можете затем спроектировать свои запросы, чтобы захватить различные налоговые структуры как на дату транзакции. Эта функциональность обеспечивается движком базы данных с несколькими дополнительными ключевыми словами для вашего SQL. Этот подход понравится вашему порядку и правильности, я уверен, но очевидно, что вам необходимо обеспечить, чтобы вы использовали функцию по мере необходимости (ее было бы легко упустить или забыть). Другим недостатком является то, что. Множество отчетов или ORM еще не поддерживают его изначально, поэтому для вас больше SQL или процедур.

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