Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Структура базы, хранение НДС , НСП и т.п.

Страницы: < 1 2
Olivka © (2003-07-31 22:22:00)

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

Olivka (2003-08-04 16:02:00) [21]

Вот-вот, системный. Я с бухгалтером поговорила - стало еще запутанней

Olivka (2003-08-04 14:26:00) [22]

Вот-вот, системно. Я с бухгалтером поговорила, однако яснее не стало. :(

Anatoly Podgoretsky (2003-08-01 14:17:00) [23]

Одно ясно, надо исходить из местных условий, но стараться сделать системно, потом будет трудно.

TohaNik (2003-08-01 13:54:00) [24]

Поддержу Anatoly Podgoretsky
По какойто позиции цена может изменяться в течение времени
и один и тотже товар стоить поразному
причем бывает что необходимо:) поменять цены в прошлых документах поэтому у меня есть таблица изменений цены на позицию заказа с датой изменения и при расчетах по дате документа выбирается цена, это приемлимо и для налогов.

MsGuns (2003-08-01 12:53:00) [25]

>Cranium © (01.08.03 12:39)
> И фирма может выбирать какую политику использовать: средневзвещанную, по партиям и т.д. А как быть если меняется учетная политика, ни кто не задумался...

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

Cranium (2003-08-01 12:39:00) [26]

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

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

MsGuns (2003-08-01 12:30:00) [27]

Поддержу обоих Сергеев ;)
Никаких "расчетных" сумм НДС, т.е. не запомненных в БД, а вычисляемых "на лету". Только как физические поля таблицы ! Даже если в 99% из 100 сумма и определяется стандартным процентом налога.
Вычисление же для помощю юзверю можно сделать "по кнопке" при вводе документа.
Если это документ фактурного типа (накладная за товары, к примеру), то суммы налогов (в частности НДС) должны быть по каждой строке ! В справочнике товаров только общие характеристики, не зависящие от партии прихода (накладной). Т.е. я там не храню даже цену ! Все - в приходе. Правда, и отгрузку надо прододить по приходам, что приводит к усложнению логики и некоторому повышению нагрузки на сервер, но совершенно оправдывает себя в точности и актуальности учета.

KSergey (2003-08-01 12:17:00) [28]

Не в тему.

Перечитал свой пост, есть в нем некорректность, н опрочитав и Sergey13 © (01.08.03 11:18) позволю себе вольную компиляцию

Хотелось бы добавить от себя про хранение налогов. В реальных условиях часто приходится уходить [от уплаты].

Sergey13 (2003-08-01 11:18:00) [29]

Хотя у Anatoly Podgoretsky © (31.07.03 22:30) все более правильно с теоретической точки зрения, я все таки соглашусь скорее с KSergey © (01.08.03 10:32). В реальных условиях часто приходится уходить от теории. Я например обычно просто предлагаю % из справочника и даю юзеру возможность либо вставить сстандартный либо свой. Это еще помогает в том случае, когда для разных видов товара есть разные ставки налога.

KSergey (2003-08-01 10:32:00) [30]

Хотелось бы добавить от себя про хранение налогов.
Надо в базе хранить все: сумму без налога, налог, сумму, возможно - процент или ссылку на справичник с процентом. Но это уже по вкусу, а вот суммы надо хранить все, а не вычислять их каждый раз.
Поясню: важно, чтобы единожды (не важно как) вычисленные суммы всегда были одинаковымиво все времена. Если же их постоянно перевычислять - могут быть искажения +-копейка (а то и больше) - а это криминал, если в одном документе так, а в другом - эдак. К тому же есть страшная ошибка - сложить итоговые суммы, а потом от суммы взять 20% и считать, что это и есть сумма НДС - нет! Надо по всем документам отдельно сложить суммы по каждому столбцу - это и будут искомые суммы по столбцам.
Более того, вообще-то (не знаю как именно сейчас, сведения годовалой давности) сумму НДС (например) можно округлять по 5 копеек а то и больше (если это по каким-то причинам удобнее бухгалтеру), т.е. вообще говоря вполне допустима ручная корректировка составляющих суммы, и хранить надо так, как переправили.

Anatoly Podgoretsky (2003-07-31 22:30:00) [31]

Справочник правильнее, поскольку неверно хранить расчетные суммы. Процент тоже не совсем верно, лучше ссылку на справочник с налоговой ставкой. Только учти, что на одну и туже сумму могут быть несколько различных налогой, может наряду с таблицей с суммлй иметь еще и таблицы вычетов, тогда решается проблема с множественными налогами и нет привязки к текущей системой налогов, как только появляется новый налог, так сразу начинает действовать.
Во всяком случае тебе надо задуматься над структурой в условиях "гибкого" налогообложения :-)

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »