UK Vat изменился с 17,5 до 15% - как это повлияет на ваш код?

Question

Британская система НДС меняется с 17,5% до 15%. Какие стратегии вы использовали в своем коде для хранения НДС и как изменения повлияют на ваши приложения. Храните ли вы историю чанов, чтобы рассчитать старые цены, или старые счета хранятся в отдельной таблице? Это простая настройка конфигурации, или вы обманули? Какой идеальный способ хранения НДС?

Answer 1

Не рассчитывай это. Сохраните это!

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

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

Центральный тариф хранения

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

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

Вы можете получить такую ​​таблицу (пример):

id | Rate name | VAT rate | Start date | End date
---------------------------------------------------  
1  | Standard  | 1750     | 01/01/1991 | 30/11/2008
2  | Standard  | 1500     | 01/12/2008 | 31/12/2009
etc

Приведенная выше таблица является лишь примером. Ставка НДС хранится в виде целого числа «базисных пунктов» (например, сотых долей процентного пункта), но предполагает, что ставка НДС никогда не будет превышать 2 знаков после запятой. Очевидно, вы могли бы расширить это с помощью дополнительного столбца, чтобы решить эту проблему, но, возможно, это будет слишком далеко!

Answer 2

Не храните это. Рассчитайте это!

---

Мой рекомендуемый способ хранения процентных ставок / процентов:

У вас должна быть таблица 'VAT_param', как

Процентная ставка | Действует с (дата) | Срок действия до (дата)

Я верю,

" Все, что можно рассчитать, не должен быть сохранен "

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

Тогда НДС должен быть аккуратно рассчитан на основе эффективной ставки за период, на основе даты выставления счета. Это будет

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

• У вас есть централизованный однорычажный для управления скоростью. Ваша таблица VAT_param.

Answer 3

Мои мысли ...

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

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

c- Это огромная (и решаемая) сделка в США, поскольку налог с продаж варьируется в зависимости от штатов, округов и даже городов. Я живу и работаю в округе Лос-Анджелес, и ставка налога с продаж составляет 8,25%. В 10 милях к югу, в округе Ориндж, ставка налога с продаж составляет 7,75%. Интернет-магазины и каталоги должны знать правильный тариф, так как он определяется местом доставки!

Удачи.

Answer 4

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

Answer 5

У меня неприятное ощущение, что 2 из унаследованных мной систем где-то жестко заданы.

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

Даже хуже того, я не знаю, где у меня будет время, чтобы действительно внести изменения. Так что я представляю, что это не будет сделано вовремя к изменениям в понедельник. Конечно, есть более интересные проблемы, например, наша подписка на 10 фунтов стерлингов основана на том, что она стоит 10 фунтов, включая 17,5% НДС (8,515 фунтов стерлингов или что-то еще). Теперь это будет £ 9,79 или около того, полный беспорядок всего, что его рекламирует за £ 10, а все расчеты сайта основаны на £ 10.

Все это потому, что идиот, отвечающий за копилку, хотел получить заголовок.

Answer 6

Относительно аргумента store vs calc. Если вы храните его, вы всегда можете рассчитать его позже, если передумаете;)

Answer 7

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

Какой бы способ вы ни делали, нет необходимости записывать начальную и конечную дату в вашей таблице НДС, так как периоды НДС идут непосредственно друг за другом.

Вы можете получить доступ к правильному чату, выполнив запрос, подобный приведенному ниже, где vat_date - дата начала ставки НДС.

SELECT * FROM vat WHERE NOW() > vat_date ORDER BY vat_date DESC LIMIT 1

Answer 8

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

Answer 9

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

Table tbl_config
   config_id int
   config_name varchar(255)
   config_value varchar(255)

Одной из этих настроек была наша основная комбинация имени пользователя и пароля администратора для сервера (без хэширования). Я думаю, что разработчик, который создал его, всегда хотел получить к нему доступ, если он забыл! Само собой разумеется, это исчезло теперь.