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

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

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

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

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

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

petr_v_a (2003-08-09 14:11:00) [1]

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

Olivka (2003-08-09 00:10:00) [2]

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

MsGuns (2003-08-08 18:22:00) [3]

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

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

petr_v_a (2003-08-08 14:49:00) [4]

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

MsGuns (2003-08-08 12:40:00) [5]

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

Olivka (2003-08-08 11:44:00) [6]

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

MsGuns (2003-08-08 11:25:00) [7]

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

Olivka (2003-08-08 11:21:00) [8]

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

TohaNik (2003-08-06 09:59:00) [9]

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

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

Olivka (2003-08-05 23:01:00) [10]

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

Olivka (2003-08-05 22:53:00) [11]

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

MsGuns (2003-08-05 22:48:00) [12]

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

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

MsGuns (2003-08-05 22:38:00) [13]

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

Olivka (2003-08-05 22:15:00) [14]

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

MsGuns (2003-08-05 21:44:00) [15]

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

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

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

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

petr_v_a (2003-08-05 15:34:00) [17]

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

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

MsGuns (2003-08-05 12:41:00) [18]

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

Alexandr (2003-08-05 10:48:00) [19]

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

testthewest (2003-08-05 09:59:00) [20]

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

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

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

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

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

Наверх

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