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

← →
Olivka (2003-07-31 22:22) [0]

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

← →
Anatoly Podgoretsky (2003-07-31 22:30) [1]

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

← →
KSergey (2003-08-01 10:32) [2]

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

← →
Sergey13 (2003-08-01 11:18) [3]

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

← →
KSergey (2003-08-01 12:17) [4]

Не в тему.

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

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

← →
MsGuns (2003-08-01 12:30) [5]

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

← →
Cranium (2003-08-01 12:39) [6]

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

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

← →
MsGuns (2003-08-01 12:53) [7]

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

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

← →
TohaNik (2003-08-01 13:54) [8]

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

← →
Anatoly Podgoretsky (2003-08-01 14:17) [9]

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

← →
Olivka (2003-08-04 14:26) [10]

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

← →
Olivka (2003-08-04 16:02) [11]

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

← →
testthewest (2003-08-05 09:59) [12]

Есть документ в котором 15000 строк, средняя цена товара 8 копееек. Как тут считать ндс, нсп ?

цена ндс нсп
0,08 0,016 0,004
0,01 0,002 0,0005

Мне кажется в конце по общей сумме было бы правильнее.

>> Округлять до 5 копеек
В какую сторону? А где про это написано?

← →
Alexandr (2003-08-05 10:48) [13]

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

← →
MsGuns (2003-08-05 12:41) [14]

В дополнение к в Alexandr © (05.08.03 10:48) :
НДС ни один проверяющий долбонавт не считает по позициям - только по сумме сделки (купли-продажи). А вот если НДС не равен, норме (к примеру 20% на Украине), то тогда уже может и "перебрать" на калькуляторе и фактурку. Во избежание чего частенько товар с нестандартным НДС продавец выделяет в отдельную накладную. В свете этого товар может стоить хоть 0.01 копейки за штуку (это не вымысел,- мне приходилось сталкиваться с системой учета, где поштучно расценивались гвозди, шурупы, скрепки, кнопки и т.д. - так там были "цены" и покруче), - налог взимается со всей суммы реализации
Поэтому изгаляции с округлениями по большому счету никому не нужны.

← →
petr_v_a (2003-08-05 15:34) [15]

В некоей таблице ... есть нечто ... и с него надо взять что-то... :) Много чего на свете бывает... :)

поделите систему на
Справочники
Документы
Операции
Ну, в справочниках все ставки должны быть. Если в документах налоги считаются "на лету", справочники должны иметь историю. А в операциях хранится расчетная сумма, сторого равная сумме в документе.
С бухгалтером не всегда легко говорить. В любом случае гораздо полезнее самому почитать книжки и Консультант+, после этого часто бухгалтер узнает много нового. PS Не наживите в нем врага из-за этого! :)

← →
Olivka (2003-08-05 21:26) [16]

Консультант я почитаю, спасибо за совет, а может быть еще в инете есть ссылки на программы такого типа, на которые можно глянуть?

← →
MsGuns (2003-08-05 21:44) [17]

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

Бухгалтеру сложно рассказывать программную реализацию. Как правило, способ мышления у экономистов (бухгалтер - это "подмножество" экономистов) совершенно отличается от прогаммерского. Абстактное воображение им совершенно не доступно.
Поэтому приходится за них "домысливать", делать нЕчто, показывать, получать горы критики (не всегда конструктивной), переделывать, опять показывать и т.д. Но, если такая прга будет доделана до успешного конца и бух будет ею доволен, то В следующий раз Ваш опыт позволит в разы сократить время на разработку и внедрение.

← →
Olivka (2003-08-05 22:15) [18]

У бухгалтера никто и не спрашивает программную реализацию, а только то - как должно быть, как они привыкли, а еще - самой домысливать и полагать - какие могут быть ситуации (ошибки, например, когда придется задним числом чего-то исправлять - это самое сложное). Тем более что бухгалтерию как таковую я совершенно не знаю. В этой задаче думаю, что должны быть уже заранее известные - методы, способы и ходы - как все это делается, как хранится и высчитывается, "наработанное годами" :)
К тому и вопрос - я могу продумать, как программист - алгоритм и реализацию, а будет ли это применимо для бух-ра - вот вопрос.
Вот и не хочу сразу дров наломать. /Такое понятие как закрытие расчетного периода, например, - для программиста - в сущности необъяснимо - хранение расчетных (итоговых) сумма в бд!:)) А поди ж ты - с т.з. законодательства - это первое дело!/

← →
MsGuns (2003-08-05 22:38) [19]

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

← →
MsGuns (2003-08-05 22:48) [20]

По поводу того, что все "уже кем-то придумано".
Ложь это и провокация ;)))

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

← →
Olivka (2003-08-05 22:53) [21]

Да я согласна с вами, полностью. ОДнако почти всегда, когда поговоришь с ними - легче сделать так, как они привыкли, ;)
Только нам от этого легче не становится ;) Хочется только себе облегчить жизнь в будущем, предугадать - какой отчет им (даже я не совсем для бух. пишу, а скорее для начальства) понадобится! Чтобы потом с базой не мудрить, тем более что это Интербейз (мне все еще кажется,что на MSSQL больше можно сделать и быстрее - как бы простора больше)

← →
Olivka (2003-08-05 23:01) [22]

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

← →
TohaNik (2003-08-06 09:59) [23]

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

ИМХО если задача незнакомая попробуй сделать так.
Полностью собери все входные документы и формируемые на их основе в бухгалтерии, актуальные для поставленной задачи.
Както удобно для себя, например на каждом документе обведи карандашом и присвой номер каждой информационной единице.
В тетрадке напиши принятое в вашей бухгалтерии название этой единицы информации(для более простого общения в будущем) и досконально выясни каким образом она попала в документ и если это описательная характеристика, возможно ли ее обЪединить в справочник. Уясни для себя последовательность во времени при которой одна цифра не может появиться до появления другой(это четко надо выяснить). После того, как определишь, что должно быть в справочниках, внимательно их проанализизуй на педмет структуризации. Например, если это спавочник наименований продукции то навеняка нужно будет их связывать с видом или номенклатурой и т. п. Если в документах присутствует какойто шифр, то обязательно узнай про каждую букву или цифру в этом шифре и почему она там появилась. После всего этого выясни(можно даже надоедливо и не один раз:)) при каких условиях и могут менятся ранее введенная информация и каким образом это это должно повлиять на другую информацию(документ или группу документов) и на какой(обязательно) промежуток времени это влияние должно распространяться.
Удачи.

← →
Olivka (2003-08-08 11:21) [24]

Совет очень кстати, СПАСИБО!

← →
MsGuns (2003-08-08 11:25) [25]

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

← →
Olivka (2003-08-08 11:44) [26]

Да уж, без вопросов :)

← →
MsGuns (2003-08-08 12:40) [27]

Специально для Вас, Марина, поделюсь личным опытом, как я в свое время осваивал бухучет.
После того, как мне окончательно запудрил мОзги мой главбух (пытаясь объяснить мне основы учета в торговле), после того, как я офигел от чтения бухг.литературы, мне на глаза попалась брошурка "1000 типовых бухгалтерских проводок". Начинается она с Плана бух.счетов, а затем тупо идет по каждому счету перечень его корреспонденций с другими счетами с кратким описанием смысла проводки (операции). Блин, я ее просто бегло прочитал и СТАЛ ВРУБАТЬСЯ ! После этого с главбухом я стал уже изъясняться на понятном ему языке, а он стал понятен мне !

← →
petr_v_a (2003-08-08 14:49) [28]

> MsGuns © (08.08.03 12:40) Поддерживаю! Единственно, я еще на курсах учился. А научиться бухгалтерии от бухгалтера можно в 10, наверно, процентах случаев.
> Olivka
Программ "такого типа" слишком много, от 1С до R3 :) Сформулируйте, что НЕСТАНДАРТНОГО в вашей системе должно быть? Ответьте себе на вопрос, чем Ваша система должна быть лучше, чем 1С?
После этого половина ( не все ) вопросы по структуре, архитектуре пр. умным вещам решатся сами.

← →
MsGuns (2003-08-08 18:22) [29]

>petr_v_a © (08.08.03 14:49)
> После этого половина ( не все ) вопросы по структуре, архитектуре пр. умным вещам решатся сами.

Ну батенька, это уж Вы загнули ;))) Что подразумевается под "1С" ? Базовая конфигурация "Предприятия" ? Там, извините, не то что половины, а и 25 % нетути - все достраивается и дописывается. О торговле базовой вообще молчу - не знаю ни одной конторы, где бы она работала без донастройки. А для розницы или ЧП вообще малопригодна.

← →
Olivka (2003-08-09 00:10) [30]

С 1С общего у меня ничего нету, потому как задача специфическая - услуги наши - ГТД (эл. копии и все прочее, эл. декларир.) А из бух. всего-то кусочек - оплата "прочих" услуг:))
Я всего-то спрашивала про учет и хранение налогов и промежуточных сумм. ДЛя этого, думаю, не надо изучать всю бух.? С этим кусочком-то я должна справиться..

← →
petr_v_a (2003-08-09 14:11) [31]

> Olivka © (09.08.03 00:10)
Ну тогда либо расчетные суммы хранить, либо справочники с историей вести. Для второго случая необходим или раскудрявый SQL, или большая усидчивость. Вообще, по моему мнению, дискуссия идет ни о чем, если что-то непонятно в конкретике, описывайте КОНКРЕТНУЮ задачу. Если Вы хотите КОНКРЕТНЫЕ примеры, давайте общаться по почте или по аське, если это взаимоинтересно ( в смысле, обмен технологиями )

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