Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Как лучше написать запрос, для такоой задачи .... ?  [new]
DennisL
Member

Откуда: Латвия
Сообщений: 43
Есть следующая структура таблиц для хранения данных о операциях с бугалтерскими счетами :
Таблица 1 : Список счетов (Acconts)
Поля : 1. Acc_id - код счета (Prim Key)
2. AccNum - номер счета
3. AccTitle - название счета

Таблица 2 Список типов операций
Поля: 1. OperType_id - код операции(Prim Key)
2. OpTitle - Название операции
4. Sys - Система к которой относиться операция


Таблица 3 Список операций
Поля: 1. Oper_id - код операции.
2. OperType_id - код типа операции(For Key)
3. OpDate - дата операции
4. Agr_id - код договора


Таблица 4 Операции со счетами
1. Oper_id - код операции(Prim Key)
2. DAcc_id - код Дебетного счета
3. KAcc_id - код Кредитного счета
4. Summ - сумма
5. Curr - валюта

Из этого всего надо получать :
1. список счетов
(для указанной валюты)
и указанного периода
и каждому показать остаток но начало периода, дебет, кредит и остаток.

AccNum, AccTitle, StartSum, DebetSum, KreditSum, EndSum

И чтобы это все можно было фильтровать (или не фильтровать если соотвествующий переметр NULL) :
1. коду договора (Agr_id)
2. коду системы (Sys )

У кого есть мысли как это сделать ... чтобы при этом еще и быстро работало ?

Вопрос может кто встречался с такими задачами .... не лучше ли структуру таблицы 4 (Операции со счетами)
Построить так :

Таблица 4 Операции со счетами
1. Oper_id - код операции(Prim Key)
2. Acc_id - код счета
3. DebetSum - сумма зачисленная на дебет счета
4. KreditSum - сумма зачисленная на кредит счата
5. Curr - валюта
то есть вместо одной операции фиксировать две на одну записывать сумму в дебет на другую в кредит

вроде это облегчит задачу но потом трудно связать каждые две операции ...
10 май 01, 19:34    [6462]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Garya
Guest
То, что ты перечислил, годится только для синтетического учета (для сведения баланса), но никак не аналитического (для ответов на все остальные вопросы, кроме сведения баланса). Отсутствуют аналитические справочники. В частности, для счетов учета взаиморасчетов 60, 62, 76 и т.п. это справочник предприятий-контрагентов. Для счета учета товара 41 это справочник складов, справочник номенклатуры (можно еще справочник партий для партионного учета или учета LIFO или FIFO). Для основных средств - справочник инвентарных единиц с указанием шифра амортизационных отчислений, нормы амортизации, счета отнесения износа и т.п.
Кстати, количественные характеристики также относятся к характеристикам аналитическим - они есть не у всех счетов, а информация об остатках товара в количестве тоже необходима.
2 All: Прошу всех извинить за многословие. Не было времени на лаконичный ответ.
То, что касается валютного учета, тоже не все так просто. Обязательно должна существовать базовая валюта, в которой составляется баланс и в которой обязана быть оценена любая проводка и любая хозоперация (в России это рубль). По одному и тому же счету (например, счету 52, 55 или счетам взаиморасчетов) проводки могут осуществляться в разных валютах, но каждая из них обязана иметь эквивалент в базовой валюте. Таким образом, остаток может получиться мультивалютным, и по нему необходимо умудриться посчитать курсовые и суммовые разницы. Это можно сделать, только в том случае, если проводки по валютным счетам делаются в двух валютах одновременно - в базовой и в валюте проводки. Таким образом, валютный учет (не в базовой валюте) тоже относится к аналитическому учету, и у части счетов вообще отсутствует (например, у основных средств или у товара).
В бухучете есть такой базовый принцип - метод двойной записи. Его суть сводится к тому, что одна и та же сумма отражается одновременно на паре счетов. У одного счета в дебете, у другого в кредите. И если ты попытаешься от него уйти, наживешь кучу неприятностей на свою голову, как в свое время нажила фирма ИНФОСОФТ в системе "Бухучет-Финансы-Бизнес". В этой системе аналитические признаки привязывались не к счету, а к хозоперации, или к проводке в целом. Пока корреспондировались счета с разными аналитиками, это прокатывало. Но когда нужно было сделать проводку между двумя счетами с одинаковыми аналитиками, все летело к чертям. Например, Д60(ЗАО "Рога и копыта") К60(ВТФ "Азот") 2500 рублей - переброска задолженности по соглашению о взаимозачете (в виде письма) с одной организации на другую.
В ИНФИН-бухгалтерии это учли, и у них в проводке для дебета и кредита отдельно указываются аналитические признаки. Все, кроме количества. В результате если и дебетовый и кредитовый счет используют количественный учет, возникают проблемы. Пример: Собрали один агрегат из 12 частей: Д20(Агрегат) К10(части, полуфабрикаты) 5000 рублей, 12 шт. Со счета 10 ушли 12 шт, а на счет 20 должна прийти 1 штука, а на самом деле приходит тоже 12. Приходится 11 штук без суммы списывать со счета в тартарары (на любой счет, на котором не ведется количественный учет), чтобы получить более-менее правдоподобную картину.
То, что касается структуры, в которой ведется учет остатков и оборотов (бухгалтерский счет) - тоже штука сложная. Если ее реализовать просто в виде таблицы, будешь месяц ждать пока у тебя подсчитаются текущие остатки по всем хозоперациям, совершенным от самой печки до нынешнего момента за 5 лет. Если будешь сохранять остатки, возникающие после каждой операции, то в случае необходимости сделать проводку задним числом, придется остатки всех последующих периодов пересчитывать и повтороно записывать в таблицу, а это тоже весьма долгий процесс. Оптимально выбрать некую золотую середину так, чтобы промежуточные остатки хранились, но с определенным интервалом относительно оборотов. Построить такую структуру не просто. Еще сложнее сделать так, чтобы данные прошлых периодов выпадали из планов SQL-запросов, чтобы обортно-сальдовые ведомости расчитывались отталкиваясь только от ближайших к ним хранящимся в таблицах остатков.
Вообще, ты затронул весьма обширную тему. Подобными вопросами занимаются софтверные "киты". Не думаю, что программист-одиночка сможет что-нибудь сделать лучше, чем они. IMHO, лучше купить готовый продукт и настроить его под собственное предприятие. Рекомендую ИНФИН (на сайте www.infin.ru можно скачать демоверсии). Не смотря на некоторые недостатки (которые есть практически у любого продукта), он превосходит по своим функциональным возможностям большинство других продуктов, одновременно оставяась одним из самых простых в освоении. Тот факт, что большинство их программ являются DOS-приложениями, не должен смущать. Ни одно Win-приложение не добилось того, чего добились они в своих DOS-приложениях. Кстати, WIN-версия с SQL-сервером (SyBase либо MS SQL 7.0) у них уже тоже недавно поступила в продажу. Но не смотря на ее еще более выдающиеся возможности, она несколько сыровата - лучше немного подождать, пока обкатается. В любом случае рекомендую скачать демо-версию ИНФИН-бухгалтерии и посмотреть как они сделали. На 2-м месте (IMHO!) Парус. 1С где-то месте на 8-ом - 10-ом (не по продаваемости, а по своим функциональным возможностям).
Вообще, ты затронул довольно емкую тему. Если еще не отпала охота решать эту задачу, загляни в статьи http://nsa.chat.ru/Raznoe_BigPrgOriginal.html. Первую часть пропусти, ибо безбожно устарела, начинай читать с раздела "О базовой структуре системы, ее объектах и администрировании". И вот еще одна статья, которая тебе может пригодиться: http://nsa.chat.ru/Raznoe_DataDomain.html
10 май 01, 21:35    [6463]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
SergSuper
Guest
Некоторые мои соображения по теме.

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

В принципе я во многом согласен с Garya, но на некоторые вещи у меня есть другое мнение(не факт что оно верное!)

1. Насчет синтетического и аналитического учета. Я вообще считал, что это слова(и еще "сведение баланса") для бухгалтеров, никак не для программистов. И в одной из предложенных Garya-й статей примерно так и пишется. По идее проводки должны делаться по аналитическим(в банковской терминологии - лицевым счетам), а синтетические использоваться в отчетах. В любом случае это не большая проблемма, просто надо несколько модифицировать таблицу 1 DennisL-а, добавив ссылку на синтетический счет.
Таблица 1 : Список счетов (Acconts)
Поля : 1. Acc_id - код счета (Prim Key)
2. Acc_synt_id - код синтетического счета (Forien key)
3. AccNum - номер счета
4. AccTitle - название счета
[hr]
2. Валютный учет. Практически во всем согласен, кроме одного - не всё так сложно.
Таблицу 4 надо организовать примерно так(я бы назвал её "проводки по счетам"):
1. Oper_id - код операции(Prim Key)
2. DAcc_id - код Дебетного счета
3. KAcc_id - код Кредитного счета
4. Summ - сумма в базовой валюте("рублёвый эквивалент" по банковской терминологии)
5. DCurr - валюта для дебета
6. CCurr - валюта для кредита
7. DSumm - сумма в валюте по дебету
8. CSumm - сумма в валюте по кредиту.
Если операция не валютная, то все суммы должны быть одинаковы.
Если надо вести и количественный учет, то наверное можно еще добавить суммы и коды для количества по дебету и по кредиту.
[hr]
3. Как хранить данные чтобы это быстро работало и можно было бы легко получить сведения.
Нужна еще одна таблица, про которую DennisL почему-то не написал - остатки по счетам.
Таблица 5 : Остатки по счетам
Поля : 1. Acc_id - код счета
2. date - дата, на которую остаток
3. curr - валюта, в которой остаток
3. s - остаток на эту дату(на "вечер")
4. d - суммарный оборот по дебету по счету за день
5. c - суммарный оборот по кредиту по счету за день
Первые три поля - это ключ.
В этой таблице есть остатки по тем счетам, по которым за этот день были обороты. И здесь уже я не соглашусь с упомянутыми статьями - пассивный остаток на лицевых счетах должен быть отрицательным, а активный - положительным(или наоборот).
Эта таблица должна заполняться триггерами таблицы проводок - именно проводки меняют остатки. На первый взляд непонятно зачем здесь, в остатках, обороты по счету, но это удобно для написания триггера(например, когда обороты обнуляются, запись надо стереть - т.е. за этот день нет изменений) и для отчетов тоже пригодиться.
Аналогичную таблицу можно сделать для синтетических счетов, но там уже надо разносить остатки на актив и пассив.
[hr]
4. Наверное в меня сейчас полетят камни, но я бы не делал(а я и не делал) отдельно кода счетов и номера. Т.е. я бы выкинул поле Acc_id, а работал бы сразу с AccNum. Несколько проще будет писать, придется связывать в запросах на одну(а то и две) таблицу меньше. База несколько вырастет в размере - но зачем экономить на байтах в наше-то время, "когда космические корабли бороздят бесконечные просторы Вселенной"?
[hr]
5. В принципе написать бух. ядро можно. Но появляются всякие детали, в которых можно утонуть - и безопасность, и разная обработка для разных счетов, отдельная песня - заключительные обороты, кому-то покажется странным, но самые тяжелые впечатления у меня остались от округления баланса до тысяч рублей. И т.д. Вобщем если можно чего-то использовать - лучше использовать.

Удачи
С приветом Сергей
11 май 01, 10:56    [6464]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
DennisL
Member

Откуда: Латвия
Сообщений: 43
Garya ! Огоромное спасибо за такой обширный ответ !
Ситуация у меня такая :
1) Я не пытаюсь создать полноценную бугалтерскую программу !
2) Я разрабатываю достаточно большую лизинговую информационную систему ...
это довольно специфический бизнес и тут нет не штук товаров не чегото подобного, а только деньги
счета оплаты ....
3) Описанную задачу мне надо решиь для поддержки автоматического зачисления сумм на строго определенные бугалтерские счета ... (они строго фиксированы !). Чтобы затем дать главному бугалтеру возможность просматривать главную книгу, плюс разбиение сумм на счетах по договорам ...

Пример : В программе происходит регистрация платежа клиента что фиксируеться во всех специальных таблицах которые относяться к лизиноговому учету. Затем вызываеться соответствующая сохраненная процедура которой передаються суммы они идут на строго фиксированные счета. Примерно так я это задумывал ...
Потом остатки на счетах например на конец месяьтся могут быть перенесены в бугалтерскую программу для сведения общего баланса ...
4) После твоего ответа я еще раз попытал бугалтера и выяснилось что действительно надо все суммы для каждой операции надо переводить в нашу валюту (то есть ЛАТ) ... де еще и считать остатки на конец месяца (по курсу на конец месяца) и зачислять обытки или прибыль на соответствующие счета

5)Главным образом меня сейчас интересует какую выбрать лучше структуру таблици для фиксации операций со счетами ...
Счет СуммаДебета СуммаКредита Валюта СуммаЭвивалет

или СчетДебет СчетКредит Сумма Валюта СуммаЭквивалент

как я понял ты не советуешь выбирать второе ? (мне тоже вроде кажеться что это вызовет больше проблем при расчете остатков сумм и т.д. но привлекает законченость каждой операции ... если их надо отобразить пользователю)
6) Как я понял надо обязательно ввести таблицу с остатками на счетах , чтбы избежать повторного прохода всей таблицы ... допустим :
дата счет-ID СуммаОстата Валюта СуммаЭквивалент

Но тогда главная проблема организовать запросы чтобы они не просматривали главную таблицу. Можно ли это сделать в сохраненной процедуре с помощью простого IF ... ?
11 май 01, 12:23    [6465]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
SergSuper
Guest
3) "на строго определенные бугалтерские счета ... (они строго фиксированы !). " - и ты поверил? Это сейчас они так говорят.

4) Еще спроси - будет ли переоценка остатков?

5) оба варианта неправильные, я уже писал как сделать таблицу, см выше

6) не понял что значит "повторный проход всей таблицы" и "главная таблица", что вообще нужен за запрос? При правильной организации данных можно всё.
11 май 01, 12:56    [6466]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
DennisL
Member

Откуда: Латвия
Сообщений: 43
Serg ! Я писал свой ответ когда еще не видел твоего ...

3) В принципе это меня не очень должно волновать ... т.к. если они потом изменяться придеться коректировать сохраненные процедуры и т.д. тоесть придеться опять вызывать меня (или когото другого) и платить ..
Тоесть сами номера счетов могут измениться т.к. все привязанно к ID но вот принцип начисления на эти ID нет ...

4) О переоценке остатков : у нас была дискусия с главным бугалтером и там выязнилось что надо будет каждый месяц проводить расчет обытков или прибыли в зависимости от курса на конец месяца (соответствующие суммы идут либо на счет потерь или счет прибыли) Незнаю это тоже самое что переоценка остатков или нет ? дело в том что говорят они у нас на латышском потому прямо я спросить не могу
С этой фигней я не очень понял т.к. вроде мы проводим этот расчет и все ! в следующем месяце мы уже считаем что была такая сумма за прошлый месяц (в эквивалентной валюте) и считаем за текущий ...

5) Насчет таблицы : получаеться что она похожа на вторую таблицу которую я описал
СчетДебет СчетКредит Сумма Валюта СуммаЭквивалент ну естественно надо добавить кодОперации

а вот насчет валютаДебет валютаКредит СуммаВалКредит СуммаВалДебет не понятно ... вроде как
такие операции проводяться через промежуточный счет (он может быть указан для каждого типа операции отдельно чтобы было легче понять куда ушли деньги) или такой прием из бугалтерии трудно реализуем програмно и повлечет дополнительные трудности и заморочки ?

6) Главной таблицей я называл таблицу 4 "Операции со счетами" т.к. она должна получиться самой большой и хранить всю информацию о суммах и т.д. "проход всей таблицы" это я имел в виду суммирование по всем записям для получения остатков, но с этим теперь все есно нужна еще таблица с остатками ...

Во вервых мне надо получить на любой период главную книгу в эквивалентной валюте :
НомерСчета Название ОстатокНаНачало Дебет Кредит Остаток

и затем при перемесчении по этой таблицы показывать для каждого счета разбиение по договорам (код договора имеется в записи операции-одна операции может включать несколько операций со счетами)

все это надо либо в общем либо для определенной группы операций (у меня это : все что относиться к лизингу, или все что относиться к факторингу ) поле (Sys)

Вот такой запрос нужен ... при этом чтобы максимально быстро работал (обычное требование
11 май 01, 13:49    [6467]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
SergSuper
Guest
4)Что такое переоценка.
У тебя делаются проводки, которые влияют на остатки. Допустим есть некая валюта в курсом на сегодня 3.00, а вчера был курс 2.00. Вчера на счет были положены деньги 10 в валюте и следовательно 20 в родном эквиваленте. Допустим это была первая проводка. Тогда там и остаток соответственно 10 и 20. Но сегодня курс изменился и по идее эквивалент должен стать 30. Чтобы он им стал и проводят переоценку - с некого счета снимают или кладут одни эквиваленты. Если у нас нет проводок из одной валюты в другую, то в итоге там(на переоценочном счете) будет в конце концов нуль. Если есть проводки из одной валюты в другую, то будет перекос, который красиво называется "открытая валютная позиция". Но это я уже отвлекся.

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

6)Как ты уже понял остатки с оборотам можно будет получить из "таблицы остатков", не читая таблицы проводок. "Таблица остатков" будет скорее всего меньше "таблицы проводок" (или же "главной таблицы" у тебя), т.к. там данные по счету будут уже сгруппированы за день, особенно если по есть несколько проводок по одинаковым счетам. А уже по каждому конкретному счету можно смотреть и проводки. Опять же если есть такая "таблица остатков", то можно сразу увидеть когда были обороты и читать только за нужные дни.

если что - пиши sergsuper@mail.ru
С приветом Сергей
11 май 01, 15:57    [6468]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Garya
Guest
2 SergSuper.
1. Синтетические и аналитические счета - это не разные счета, а одни и те же. Грубо говоря, синтетические счета - это итоги по сальдо и оборотам аналитических счетов со всернутыми аналитиками всех уровней, выраженные в базовой валюте.
2. Если программист занимается автоматизацией учета, то он не должен делить, что для бухгалтеров, а что для программистов.
3. Насчет камней и кодов счета. С чего ты взял, что в тебя должны лететь камни? Лично я с тобой в этом вопросе полностью согласен.
4. Относительно того, что дебетовость и кредитовость сальдо (остатков) можно определять по знаку суммы я еще могу согласиться. Но по части оборотов - ни в коей мере. Пример: Д62 К46 12000руб и Д46 К62 -12000руб с точки зрения не только бухучета, а вообще элементарной логики - разные вещи. В первом случае сумма попадает в объем реализации (поскольку относится к кредиту 46 счета). Во втором случае - нет (поскольку это уменьшение затрат, а не увеличение кредита). Вторая проводка сторнирующая и это сразу видно невооруженным глазом (такие проводки используются для аннулирования ранее сделанных операций). Первая проводка НЕ является сторнировочной, а является обычной проводкой, обозначающей некую хозоперацию. Возможно, это не совсем логично с точки зрения программиста, но это абсолютно логично с точки зрения финансиста или бухгалтера, для которых программист пишет программу.
5. Пояснение, которое ты привел, к переоценке остатков имеет довольно отдаленное отношение. Следует различать расчет курсовых разниц, суммовых разниц и переоценку. Курсовые разницы возникают ТОЛЬКО на валютных счетах в результате того, что операции на них проводятся при разных значениях валютных курсов, и производимая в момент совершения операции оценка в базовой валюте к концу учетного периода может оказаться некорректной из-за изменения курса валюты. Для корректировки соотношения валютного/рублевого остатка на валютном счете делают проводки в базовой валюте (в рублях для данного случая) и называются они курсовыми разницами.
Если по условиям договора взаиморасчеты ведутся в некоторых у.е. (или USD), но реально осуществляются в базовой валюте (в рублях), то отражение таких операций производится на НЕ валютных счетах. Из-за расхождений в моментах отгрузки и оплаты по обязательствам договора могут возникнуть расхождения из-за изменения курса валюты, к которой привязаны у.е. В этом случае делают проводки по суммовым разницам, смысл которых близок к курсовым, но все-такие немного отличается.
Переоценка осуществляется обычно либо по решениям правительства, либо на основе нормативных актов, разрешающих ее производить для определенных случаев жизни. Обычно необходимость в ней возникает в результате инфляции или ухудшения потребительской стоимости материальных ценностей в результате длительного хранения. По решениям правительства делается переоценка основных фондов (на основе специальных таблиц) по состоянию на 01 января определенных лет. По нормативным актам разрешается уценка портящихся продуктов, хранящихся на складе (и в аналогичных случаях). Более никаких переоценок не допускается (по крайней мере, в России).
Кроме трех приведенных ситуаций может быть еще деноминация. Это уже общегосударственная штука - полагаю, в пояснениях не нуждается.

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

2 DennisL.
1. Не думаю, что твоего главбуха удовлетворит автоматизация проводок лишь по части счетов. Кроме того, трудоемкость изготовления продукта на часть счетов и на все счета различается незначительно.
2. Лизинговая вы компания или хайринговая, это не существенно. Учет ведется на любых предприятиях, и его принципы общие для любых предприятий. Может изменяться перечень и состав счетов, их аналитики, схемы отражения на них определенных операций, порядок налогообложения (как для банков, например), но базовые принципы учета остаются одними.

Я предлагаю (упрощенно):
1. Завести в системе перечень счетов, в которые могут добавляться новые счета или изменяться настройки существующих счетов.
2. Кроме счетов в системе должен иметься перечень аналитических справочников. В этот перечень при необходимости должна иметься возможность завести новые справочники.
3. При вводе в перечень справочников нового справочника указывается перечень полей, их наименование и тип (фактически, конструирование таблицы). На один справочник заводится одна таблица с заданной структурой.
4. В настройках счетов необходима возможность указания следующих свойств:
а) валютный/не валютный
б) ведется или не ведется количественный учет
в) перечень аналитических справочников (выбираются из перечня справочников), по аналитикам которых разворачивается учет данного счета.
5. После указания всех атрибутов настройки счета (см.п.4) создаются по две таблицы на каждый счет. В одной ведется учет оборотов, в другой - учет остатков (остатки с периодичностью в 1 месяц). Поля этих таблиц - ссылки на соответствующие справочники (связь один-ко-многим) и поля ресурсов, учитываемых на счете - сумма в базовой валюте, сумма валютная, количество (два последних поля у части счетов могут отсутствовать). Кроме перечисленных полей в таблице оборотов должны быть служебные поля - Дебет/Кредит (логическое), номер корреспондирующего счета, ссылка на ответную часть проводки в корреспондирующем счете, ссылка на соответствующую запись в таблице баланса (будет сказано далее).
6. Кроме перечисленных объектов необходимо завести таблицу баланса. В этой таблице отражаются все проводки по любым счетам. Она должна содержать поля - номер дебетового счета, номер кредитового счета, ссылки на идентификаторы соответствующих записей в дебетовом и в кредитовом счете, сумму в базовой валюте, комментарий.
7. Каждая проводка отражается одновременно в трех местах - на дебетовом счете (попадает в таблицу оборотов дебетового счета, вызывает пересчет остатков в таблице остатков), на кредитовом счете (попадает в таблицу оборотов кредитового счета, вызывает пересчет остатков в таблице остатков), в таблице баланса (высвечивается в перечне всех сделанных проводок). Все три объекта с помощью ссылок завязываются друг на друга так, что всегда через любой из них можно выцепить записи в двух других.
Можно просматривать обороты и/или под одному конкретному счету, сворачивая или разворачивая его аналитики (group by по полям ссылок на справочники, либо без group by - с полностью развернутыми аналитиками). Можно просматривать хозоперации в виде вала проводок с различными корреспонденциями (чере таблицу баланса), но с возможностью просмотра по любой выбранной проводке аналитик как под дебетовому, так и по кредитовому счету.
Обрати внимание, что один и тот же справочник может выступать в качестве аналитического уровня сразу у нескольких счетов. Например, если назначить один справочник контрагентов в качестве аналитики на все счета взаиморасчетов (60,61,62,64,76), то можно будет просматривать сводную картину всех движений ресурсов, привязанных к одному контрагенту по всем счетам одновременно.
Как делать автоматические и стандартные проводки, как их групировать (чтобы совокупность проводок воспринималась как одна хозоперация), как использовать формулы в настройках, как настраивать шаблоны печатных форм документов и отчетности - это все отдельный большой разговор.

В общем-то я вкратце пересказал концепцию ИНФИН-бухгалтерии. Если интересуют подробности, скачайте демо-версию (пардон, повторяюсь).
11 май 01, 17:43    [6469]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
SergSuper
Guest
2Garya
твоё "несогласие по некоторым позициям как желание пободаться" я не воспринимаю, я же знаю что я прав
Вообще мне конечно интересно, как другие пишут всякие бухгалтерии.

Что касается обращения ко мне:

1. В принципе согласен. Но надо понимать что это пошло с допотопных времен, когда всё считалось на счетах и надо было постоянно сверять счета, чтобы выискивать ошибки.
2.Трудно сказать. Первое время нас всё время спрашивали - а как свести баланс. Им(бухгалтерам) было не понять, что он всегда сведенный, в любой момент все пересчитывается. Вообщем это вопрос(как и предыдущий) больше теоритический и не стоит на нем заострять внимание.
3.Когда я перешел на новую работу и сказал, что не буду использовать коды для счетов - на меня как-то не так посмотрели. Ну хорошо, значит я не один.
4.Я нигде не писал, что обороты могут быть отрицательными. Не могут.
Насчет сторнирования - всё так, но для программиста сторнировочная проводка - абсолютно ничем не должна отличаться от обычной(ну естественно тип документа другой).
5.То что я описал(естественно очень приближенно) - это так делается переоценка в банке. Нигде кроме кредитных учереждений такая переоценка не разрешается, а на предприятии под "переоценкой" понимают совсем другое(такая "переоценка" в банках тоже бывает), что ты и описал. Об этом я как-то не подумал, поэтому получилась такая путаница с терминологией.

Что касается твоих предложений

5.
- наверно имеется ввиду не "по две таблицы на каждый счет", а просто "две таблицы", где поле счет будет ключевым.
- переодичность остатков - наверное не месяц, а некий отчетный период. В данном случае это будет один день.
- "Поля этих таблиц - ссылки на соответствующие справочники (связь один-ко-многим) и поля ресурсов" - зачем в оперативной таблице хранить ссылки на справочники?
- "таблица оборотов" - как я понял одна проводка порождает 2 записи в этой таблице. Я считаю что это неудобно и лучше чтобы была одна запись с дебетом и кредитом, как у бухгалтеров. Хотя к производственно бухгалтерии бывает что по дебету 2 счета, а по кредиту - штук 5. Тогда может имеет смысл. Но неудобно. Допустим есть счет, надо получить выписку. Выбираем из таблицы проводок записи по этому счету, при "моей" схеме мы тут же выберем и корреспондирующие счета, если дебет и кредит в разных таблицах(или как минимум записях) - то уже надо писать некие ухищрения, небольшие, но всё же.

6.
Вот зачем еще таблица баланса - мне совершенно непонятно.

7.
О! Каждая проводка отражается одновременно в одном месте - в таблице проводок (вызывает пересчет остатков и суммарных оборотов по дебету и кредиту). И никаких связей и т.д. Очень удобно.

В принципе я хотел было написать что-то типа статьи какая у меня структура данных для бухгалтерии и обменяться опытом(может я совсем неправильно делаю?), но как-то времени нет. Может как-нибудь соберусь. Чего и другим желаю.

С приветом Сергей
11 май 01, 19:00    [6470]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Garya
Guest
2 SergSuper. Правильно говорят, что в спроре рождается истина. У меня такое ощущение, что мы по спирали заходим на одну точку.

> "...как свести баланс. Им(бухгалтерам) было не понять, что он всегда сведенный..."
Это смотря о каком балансе идет речь. Если об обортно-сальдовом, то да, он всегда сведенный. А вот если о Форме N1 и Форме N2 (которые сдаются в ГНИ), то не все так просто. Любая проводка с некорректной корреспонденцией запросто его может нарушить. Ну, в принципе, я не против не заострять...

>"...но для программиста сторнировочная проводка - абсолютно ничем не должна отличаться от обычной(ну естественно тип документа другой)"
IMHO, все-таки, должна. Когда она не отличается, это означает, что в таблицы они записываются одинаково. А они ОБЯЗАНЫ записываться по-разному. И одними знаками в оборотах не обойтись. В таблицах обязаны быть поля "Дебет" и "Кредит". Если в таблицах сторнировочная проводка не будет отличаться от обычной с противоположной корреспонденцией, то ни через какие SELECT-ы ты не сможешь правильно расчитать, к примеру, валовый доход или объем реализации, или затраты текущего периода или другие показатели хозяйственной деятельности, которые используются при расчете налогооблагаемой базы множества налогов.

> "Я нигде не писал, что обороты могут быть отрицательными. Не могут."
Как раз не не могут, а обязаны мочь. Иначе сторнировочных проводок никто никогда сделать не сможет. А я имел в виду, что нельзя ТОЛЬКО знаком числа определять сторону счета. То есть, нельзя понимать, что записывание на счет 50 суммы -5000руб эквавалентно кредиту 50 счету, а суммы +5000 рублей эквавалентно дебету этого счета. Вот это точно нельзя! Потому что и с плюсом, и с минусом нужно уметь записывать проводки и в дебет, и в кредит. И у каждой из четырех комбинаций знака и Д/К свой смысл.

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

Теперь по поводу структур таблиц.
Каждый счет имеет свои аналитические разрезы. Например, счет 62 "Расчеты с покупателями" должен иметь аналитику "Покупатели" (связь со справочником контрагентов). А счет 41 "Товары" должен иметь несколько аналитик:
1. Склады
2. Номенклатура
3. Партии
То есть, иметь связи один-ко многим уже не с одной, а с тремя различными таблицами справочников.
Счет реализации 46 не имеет вообще никаких аналитик (и связей).
Когда идет продажа товара, делаются не просто проводки со счета на счет, а указываются ЗНАЧЕНИЯ конкретных аналитик:
Д46(без аналитик) К41(Склад=Центральный, Номенклатура=Насос Малыш, Партия=12345, кол-во=10шт) Сумма=50000 руб
Д62 (Покупатель=ЗАО Рога и копыта) К46(Без аналитик) Сумма=80000 (Без количества, поскольку ни на счетах 62 и 46 учет количества не ведется!)

Если при сотворении проводки ты не укажешь аналитическую информацию, она ниоткуда в системе более не появится, и у тебя останется голый синтетический учет - без аналитического. Если на каждый счет не завести отдельную таблицу с собственным составом полей и ссылками на собственный перечень аналитических справочников, то потеряется львинная доля нужной информации.
Как ты себе представляешь структуру таблицы, в которой могут осуществляться проводки по любым и одновременно всем счетам? Как ты отобразишь проводку Д62 (Покупатель=ЗАО Рога) К62 (Покупатель=ЗАО Копыта) 123000 руб? В данной проводке нужно сослаться на один и тот же справочник два раза. Один раз из дебетового счета, другой раз из кредитового. Если ты предлагаешь поставить в соответствие всем счетам все возможные аналитики, то как ты предполагаешь контролировать, чтобы на счете 62 указывали ровно одну аналитику по покупателям, а не вколотили туда по ошибке материально-ответственное лицо или номенклатуру?
И потом, на практике более пяти аналитик для одного счета как правило не используется. А вот количество аналитических справочников может достигать 200 и даже более.
А вот еще интересней вопрос. Как отобразить проводку Д20(Продукция=Агрегат1, кол-во=1шт) К10 (Материал=Болты, кол-во=20шт) 200руб?

Нет, конечно, можно наворотить таблиц с метаданными. И поставить поверх одного SQL-сервера еще и самопальный в качестве прослойки. Это уже дело вкуса. Кому как проще...
11 май 01, 22:35    [6471]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Fompro
Member

Откуда:
Сообщений: 363
Не успел всё пока дочитать до конца. Посему ...
Думаю, что в той системе, разработкой к-ой занимается DennisL не применимы "Правила 66" (61 для кредитных организаций) Банка России. Тем не менее. Отсутствует понятие "сторно", как документ, т.е. у Вас есть возможность создать "исправительный" документ с соответствующим типом. Обороты, при этом, конечно, накручиваются. И сюда же: Вы не сможете, например, создать "чистый" кассовый документ, т.к. обратная проводка д.б. пройти по другому символу кассплана.
Утрясу мысли, продолжу.
12 май 01, 02:22    [6472]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Garya
Guest
2 SergSuper. Я тут поразмыслил... Похоже, что сделать структуру таблиц такой, как ты говоришь можно. Возникают проблемы с хранением остатков, разнесенных по аналитикам, но в приципе они разрешимы. Трудно сказать, какая структура более оптимальна. Но твоя концепция вполне имеет право на существование, и по части структуры я беру свои слова назад.

У твоего варианта есть специфика, на которой я хочу заострить внимание. Справочники загнать в одну таблицу не получится - у них разный состав полей. Проводки кладутся в таблицу проводок (первую таблицу) с указанием дебета, кредита и суммы проводки. Каждая такая проводка имеет уникальный идентификатор. Поля таблицы:
- ID проводки
- ID вида документа (накладная, акт, счет-фактура и т.д.)
- № документа
- Дата документа
- Дата проводки
- Номер дебетового счета
- Номер кредитового счета
- Сумма проводки в базовой валюте
- Комментарий
- Идентификатор группы проводок (это на любителя, если пр6едполагается делать некие совокупности проводок, которые могут существовать только вместе и взаимно зависят друг от друга - модификация одной из них требует пересчета остальных).
Во второй таблице размещаются ссылки на аналитики, причем как дебета, так и кредита. Она имеет поля:
- ID проводки
- ID справочника (из перечня справочника)
- ID записи справочника
- Данные для дебетового или кредитового счета проводки (bit)
Идентификаторы записи во всех справочниках должны иметь одинаковый тип (везде int, или везде uniqueidentifier).
Если у одного счета три аналитических справочника, в данную таблицу помещаются сразу три записи (ссылки на записи трех разных справочников). Контроль за тем, чтобы все ссылки были указаны и не было ссылок на некорректные справочники можно возложить на триггеры. Они должны контролировать ввод данных, используя информацию из таблиц метаданных - в которых расписано, какие аналитики привязаны к какому счету. Они же вызывают пересчет остатков (о таблицах остатков будет сказано ниже).
На самом деле вместо этой таблицы можно сделать таблицу-связку между таблицей проводок (первой таблицей) и таблицей совокупностей аналитик (таблицей 5, о которой будет сказано ниже). Я бы именно так и сделал (это более нормализованный вариант), но для понимания КАК производится привязка к аналитикам лучше сначала изучить структуру таблицы 2 в изначальном виде.
В третью таблицу помещаются данные о движении ресурсов в количественном выражении ТОЛЬКО для тех счетов, для которых в настройках указан количественный учет. Поля таблицы:
- ID проводки
- Данные для дебетового или кредитового счета проводки (bit)
- Количество
- ID единицы измерения (ссылка на справочник единиц измерения)
В четвертую таблицу помещаются данные о движении ресурсов, выраженных в иностранной валюте ТОЛЬКО для тех счетов, для которых в настройках указан валютный учет. Поля таблицы:
- ID проводки
- Данные для дебетового или кредитового счета проводки (bit)
- Сумма в валюте
- ID валюты (ссылка на справочник валют)
Все четыре таблицы имеют отношение только к оборотам. Ясно, что Foregn Key между таблицами справочников и второй таблицей по ID записи справочника реализовать невозможно - это поле ссылается на все таблицы справочников одновременно. Встроенные средства DRI не прокатят, реализация контроля логической целостности ложится на триггеры.
Теперь о самом неприятном - об остатках. Остатки необходимо хранить в развернутом по аналитикам виде. Приведу пример для наглядности.
На счете 41 на некоторую учетную дату имеется остаток:
На центральном складе | Номенклатура Насос Малыш | Код партии 12345 -> 5 шт на сумму 200руб
На центральном складе | Номенклатура Насос Малыш | Код партии 12346 -> 2 шт на сумму 80руб
На центральном складе | Номенклатура Насос Гигант| Код партии 77777 -> 1 шт на сумму 100руб
Для того, чтобы сие было возможно, необходима вспомогательная таблица, в которой одна совокупность аналитик обозначается одним уникальным кодом. Возникает пятая таблица - совокупностей аналитик. Поля таблицы:
- ID совокупности аналитик
- ID справочника
- ID записи справочника
Для приведенного выше примера в данную таблицу должно быть помещено 9 записей, группирующиеся по 3, у которых внутри одной группы одинаковые ID совокупности аналитик
Шестая таблица содержит развернутые по аналитикам остатки по всем счетам в базовой валюте. Поля таблицы:
- Номер счета
- ID совокупности аналитик
- Дата остатка
- Сумма в базовой валюте
Седьмая таблица содержит остатки в количестве только для тех счетов, для которых в настройках задан количественный учет. Поля таблицы:
- Номер счета
- ID совокупности аналитик
- Дата остатка
- Количество
- ID Единицы измерения
Восьмая таблица содержит остатки в валюте только для тех счетов, для которых в настройках задан учет в валюте учет. Поля таблицы:
- Номер счета
- ID совокупности аналитик
- Дата остатка
- Сумма в валюте
- ID валюты
Следует учесть, что в этой таблице может находиться несколько записей, соответствующих одному набору значений полей Номер счета, ID совокупности аналитик и Дата остатка. Это происходит для мультивалютных счетов. Например, по счету 52 может происходить движение в разных валютах, тогда остаток тоже формируется мультивалютным.

РЕЗЮМЕ. Подобный подход имеет и свои плюсы, и свои минусы по сравнению с формированием отдельной таблицы под каждый счет.
Плюсы: Единообразная схема запросов по любым счетам
Минусы: Невозможность использования интегрированных средств поддержки логической целостности. Возможны проблемы с быстродействием из-за более сложной структуры запросов и больших объемов данных, которыми эти запросы оперируют.

Трудно сказать, что тут перевешивает - плюсы или минусы. Каждый пусть решает для себя сам. Я допускаю, что единообразность запросов может перевесить минусы данного подхода.
12 май 01, 12:19    [6473]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
DennisL
Member

Откуда: Латвия
Сообщений: 43
Спасибо за такие развернутые ответы !
garya - ты описал систему позволяющую вести полный учет, на
будущее я эту схему напременно возьму во внимание ....

Хочу немного уточнить задачу которую мне надо решить сейчас :
1) Необходимо упрощенное решение, т.к. реализовать навтороченную
поддержку бугалтерских функций может не хватить времяни, и это вроде
не требуеться.

2) В моей программе необходимо обеспечить работу лишь с небольшим
количеством строго определенных бугалтерских счетов.

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

4)Количества или чегото подобного у моих операций нет ! (к моей
большой радости ) В виде аналитики выступет может быть только
договор к которому относиться данная проводка (в течении действия
договора 2-3 года, может быть много таких поводок)

5)У меня есть такое понятие как тип операции (вероятно его тоже надо
рассматривать как аналитику) выглядит это как "операция регистрации
нового договора для оперативного лизинга" или "операция оплаты счета
для финансового лизинга" и т.д. в пределах такой операции ваполняються
несколько "транзакций"=группы проводок со счета на счет. Кроме всего
прочего надо различать тип финансового продукта "лизинг" и "факторинг"
факториг разрабатываю не я но для регистрации проводок мы будем
использовать общие таблицы

6)Насчет мультиволютных проводок: мои бугалтеры не понимают как можно обойтись
без промежуточного счета (я вроде это понимаю) ... Тоесть в их видении проводка с разными валютами выглядит так : вначале проводка с Д13 К90 1000USD = 600Ls(эквивалент в нашей валюте по курсу банка латвии на день операции), затем Д90 К50 900EUR = 550Ls(эквивалент) тоесть на 90 Счете появляеться 50Ls прибыль она сразу идет на счет 80, Д90 К80 50Ls.
Вроде я понимаю что по методу предложенному SuperSerg можно заменить это просто Д13 К50 Двал=USD КВал=DEM ДСум=1000 КСумм=900 ДЭкв=600 КЭкв=550 и сразу зачислить разницу в 50Ls на счет 80 (но не будет ли потом сложнее работать с такими строками, для получения сумм и остатков т.к. получаеться два эквивалента для одной операции ??)
Бугалтера както с трудом понимают такую схему, точнее говорят что это не правильно, что нет движения через промежуточный счет и т.д., что это может вызвать проблеммы, хотя как я понимаю на этом счете всегда должен быть остсток ноль ...

7) Как примерно должен выглядеть запрос, который выдает остатки на счетах на определенный период используя данные как из таблицы проводок так и из таблицы остатков ?

Заранее спасибо всем за помощь !
14 май 01, 10:49    [6474]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
SergSuper
Guest
1.Насчет "сторно"
Если чесно - не знал что там используются отрицательные обороты. У нас в банке как таковых операций сторно не было, просто удалялись документы задним числом(бывало и за месяц, а если учесть что за день вводилось около 3000 документов...). Еще делались "исправительные проводки", обычные мемориальные ордера, их обороты "накручивались" на обычные. Я не хочу сказать что так и надо, просто объясняю почему я так думал.
Вообщем поправлясь: "для программиста сторнировочная проводка - абсолютно ничем не должна отличаться от обычной(ну естественно тип документа другой), кроме того что может иметь отрицательную сумму".


2.Теперь по поводу структур таблиц.
Когда идет продажа товара, делаются не просто проводки со счета на счет, а указываются ЗНАЧЕНИЯ конкретных аналитик:
Д46(без аналитик) К41(Склад=Центральный, Номенклатура=Насос Малыш, Партия=12345, кол-во=10шт) Сумма=50000 руб
Д62 (Покупатель=ЗАО Рога и копыта) К46(Без аналитик) Сумма=80000 (Без количества, поскольку ни на счетах 62 и 46 учет количества не ведется!)

А почему надо привязывать аналитики к проводке? Я тоже раньше так делал, но давно от этого отказался. Проводка - это некая производная от документа, который и содержит все аналитики. И уже на основании этих аналитик делаются проводки.
Так же например проводка не далжна иметь поля "комментарий" - это свойство документа.

Что касается твоего видения "моей" структуры - ну уж больно сложно. Я бы не разбивал(а я и не разбивал) всё на несколько таблиц. Допустим учет может быть только денежный(не знаю как правильно назвать), валютный и количественный. Я бы всё это держал в одной таблице и заполнял бы те поля, которые нужны. Т.е. например таблица остатков:
счет
дата
валюта
код количества
сумма в базовой валюте
сумма в валюте
количество

В сумме для количественного и валютного учета был бы в основном нуль - ну и пусть. И было бы 3 таблицы(документы, проводки и остатки) вместо твоих восьми(извиняюсь если сбился со счета). (На самом деле конечно не 3 и не 8, всё будет гораздо сложнее, но это понятно)

Из минусов, приписанных тобой моей структуре я согласен только с тем, что вырастает объем данных. Причем вырастает не количество записей, а только объём базы. А если же использавать для количественного и валютного учета поля с разрешенным NULLом, то и размер не вырастет.
Использования интегрированных средств поддержки логической целостности ничем не отличается.
Более сложная структура запросов - ? С чего бы это? Мне всегда казалось что если меньше таблиц, то и запросы будут проще. К тому же всяких связей меньше.

А вообще у меня такое чуство, что у нас уже сложился некий стереотип как всё должно быть, из которого трудно выбраться(ко мне это наверное тоже относиться). А надо пытаться.

С приветом Сергей
14 май 01, 11:32    [6475]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Garya
Guest
2DenisL.

> 1) Необходимо упрощенное решение, т.к. реализовать навтороченную
поддержку бугалтерских функций может не хватить времяни, и это вроде
не требуеться.

Попытка сэкономить время на первом этапе работы обычно приводит к его крупным потерям в будущем. Думаю, SergSuper меня поддержит. У меня такое предчувствие, что в этом вопросе наши точки зрения совпадают. Чтобы было ясно, о чем я говорю, приведу такую метафору. Делать фундамент дома - довольно трудно, а его построение само по себе не приносит каких-либо конкретных результатов. Однако, без него дом развалится. А попытка сделать фундамент ПОСЛЕ строительства дома приводит в итоге к 10-кратным трудозатратам, увеличению времени всей стройки и опасности просто разрушить дом.

>2) В моей программе необходимо обеспечить работу лишь с небольшим
количеством строго определенных бугалтерских счетов.

Если не хочешь мудрить, возьми за основу схему с отдельной таблицей под каждый счет.

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

Для мультивалютного учета главное в проводке - учесть сумму в ОДНОЙ валюте и ее эквивалент в базовой валюте. Мультивалютным получается остаток. Курсы всех валют задаются относительно базовой. Имея их , расчетным путем всегда можно получить РАСЧЕТНЫЙ курс между любой парой валют.

> 4)Количества или чегото подобного у моих операций нет ! (к моей
большой радости ) В виде аналитики выступет может быть только
договор к которому относиться данная проводка (в течении действия
договора 2-3 года, может быть много таких поводок)

Рано радуешься. Насколько мне известно, лизинг - это долгосрочная аренда основных фондов, которые имеют количественное выражение (например, 10 шагающих экскаваторов).

5)У меня есть такое понятие как тип операции (вероятно его тоже надо
рассматривать как аналитику) выглядит это как "операция регистрации
нового договора для оперативного лизинга" или "операция оплаты счета
для финансового лизинга" и т.д. в пределах такой операции ваполняються
несколько "транзакций"=группы проводок со счета на счет. Кроме всего
прочего надо различать тип финансового продукта "лизинг" и "факторинг"
факториг разрабатываю не я но для регистрации проводок мы будем
использовать общие таблицы

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

>6)Насчет мультиволютных проводок: мои бугалтеры не понимают как можно обойтись
без промежуточного счета (я вроде это понимаю) ... Тоесть в их видении проводка с разными валютами выглядит так : вначале проводка с Д13 К90 1000USD = 600Ls(эквивалент в нашей валюте по курсу банка латвии на день операции), затем Д90 К50 900EUR = 550Ls(эквивалент) тоесть на 90 Счете появляеться 50Ls прибыль она сразу идет на счет 80, Д90 К80 50Ls.
Вроде я понимаю что по методу предложенному SuperSerg можно заменить это просто Д13 К50 Двал=USD КВал=DEM ДСум=1000 КСумм=900 ДЭкв=600 КЭкв=550 и сразу зачислить разницу в 50Ls на счет 80 (но не будет ли потом сложнее работать с такими строками, для получения сумм и остатков т.к. получаеться два эквивалента для одной операции ??)
Бугалтера както с трудом понимают такую схему, точнее говорят что это не правильно, что нет движения через промежуточный счет и т.д., что это может вызвать проблеммы, хотя как я понимаю на этом счете всегда должен быть остсток ноль ...

Понимаешь ты почти правильно. За исключением того, что в приведенном тобой примере "по методу SergSuper" нарушается принип двойной записи. И в этом я с твоими бухгалтерами согласен. Сколько ушло с одного счета, столько должно прийти на другой - корреспонирующий счет. Причем, это "сколько" обязано быть в базовой валюте. То есть в той, в которой составляется баланс. Твоя же проводка приводит к нарушению баланса (равенству итоговых сумм на дебетах всех счетов и кредитах всех счетов).
Курсовая разница - это проводка чисто в базовой валюте на валютном счете (то есть, с суммой в валюте=0). Никакие метки тут не нужны. Когда расчитывается курсовая разница, там где она ранее посчитана правильно, проводка просто не делается.

7) Как примерно должен выглядеть запрос, который выдает остатки на счетах на определенный период используя данные как из таблицы проводок так и из таблицы остатков ?

Примерно так:
create procedure OstatkiNaDatu(@NaDatu smalldatetime)
as
select Ost.SummInBaseCurrency + (select summ(Deb.SummInBaseCurrency) from Oboroty Deb where deb.OborDate > Ost.Nadatu and deb.OborDate <= @NaDatu and deb.Debet=1 and deb.An1=Ost.An1 and deb.An2=Ost.An2) - (select summ(Kred.SummInBaseCurrency) from Oboroty Kred where Kred.OborDate > Ost.Nadatu and Kred.OborDate <= @NaDatu and Kred.Debet=0 and Kred.An1=Ost.An1 and Kred.An2=Ost.An2)
from Ostatki Ost
where Ost.NaDatu=(select max(NaDatu) from Ostatki where NaDatu<=@NaDatu)
group by Ost.An1, Ost.An2
Идея, полагаю, понятна. Навороты сам накрутишь.

-----------------------------------------------------------------------------------------
2SergSuper.
1. Рад, что консенсус достигнут. Хочу только заметить, что исправление (update) и сторнирование - вещи разные. Например, покупатель вчера купил товар: Д50 K46 1000руб. После этого мы имеем объем реализации = 1000 рублей. А сегодня пришел и сдал его обратно как дефектный и вернул свои деньги обратно. Если мы просто удалим вчерашнюю проводку, то у нас исчезнет информация о том, что товар был куплен, а затем его вернули. Если мы при возврате сделаем проводку с обратной корреспонденцией Д46 К50 1000руб, то объем реализации так и останется равен 1000 руб, поскольку он вычисляется как оборот по кредиту счета 46, а это неправильно. Поэтому при возврате делается сторнировочная проводка Д50 К46 -1000руб - объем реализации уменьшается на 1000руб, и все становится на свои места.

2. Конечно, можно хранить аналитики в документе. Но только если на каждый чих он есть, и существует некий алгоритм привязки полей документа к аналитикам. Например Д46 К44 (44-аналитика по статьям затрат) - остатки на счете 44 по всем статьям затрат переносятся в дебет счета реализации в конце месяца. Причем, если на 46 счете несколько субсчетов (по видам деятельности), то нужно сначала расчитать доли пропорционально объемам реализации, а потом уже делать проводки на конкретные субсчета 46 счета. Получается, что сумма проводки зависит от оборотов на счетах, а не от какого-то документа.
Еще одно "НО". Структура документов может быть весьма сложная. Например, по акту ОС-1 (по основным средствам) делается несколько проводок, которые затрагивают сразу несколько счетов (1, 2, 8, 10, 44, 19, 60, 68, 81, 8. Причем, часть из этих проводок делается ТОЛЬКО при наличии оплаты основного средства (а это совсем другой документ). Кроме того, по микроавтобусам и легковым автомобилям схема проводок одна, по капитальному строительству - другая, по сборке компьютеров - третья. А документ-то один! И в нем не указано, относится ли приобретение данного средства к уставной деятельности предприятия или нет (это нужно просто заглянуть в устав), а от этого тоже зависит схема проводок.
Я предпочитаю оставить принятие решения в подобных случаях за бухгалтером (иначе придется закладывать в алгоритм всего документа несколько талмудов Российского законодательства и потом программисту отслеживать все изменения законодательства 8-(). Предпочитаю не иметь жесткой привязки к документам.А вот для целей автоматизации и исключения повторного ввода данных между документами и проводками можно указывать логические связки (а можно НЕ указывать). И в определенных ситуациях использовать НАСТРАИВАЕМЫЕ операции, в которых проводки действительно могут привязываться к документам и формироваться на их основе. При этом поля документа при заполнении должны ссылаться на те же справочники, которые задействованы в проводках. Кроме того, документы должны иметь возможность формироваться на основании друг друга (например, накладная на основании счета, либо счерт-фактура на соновании накладной, либо любая другая комбинация между ними).
Кстати, в комплексе ИНФИН возможны две схемы работы, причем одновременно. Как формирование документов на основании проводок, так и наоборот - проводок на основании документов. Как житель России, гораздо чаще использую первую возможность, нежели вторую. Хотя это и противоречит принципам учета, но позволяет избежать тупого оформления целой кучи никому не нужного вороха бумаг (кроме законодателей, которые этот ворох придумали и требуют его обязательного оформления).

3. Что касается хранения количества и валюты по оборотам в полях основных таблиц с необязательностью их заполнения - да я ничего против не имею! Только с мультивалютными
14 май 01, 17:37    [6476]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
SergSuper
Guest
2Garya
Ну полный конценсус кроме того, что касается валюты

Для мультивалютного учета главное в проводке - учесть сумму в ОДНОЙ валюте и ее эквивалент в базовой валюте. Мультивалютным получается остаток. Курсы всех валют задаются относительно базовой. Имея их , расчетным путем всегда можно получить РАСЧЕТНЫЙ курс между любой парой валют.


Я бы написал первое предложение так: "Для мультивалютного учета главное в проводке - учесть сумму в КАЖДОЙ валюте и их общий эквивалент в базовой валюте."



Понимаешь ты почти правильно. За исключением того, что в приведенном тобой примере "по методу SergSuper" нарушается принип двойной записи. И в этом я с твоими бухгалтерами согласен. Сколько ушло с одного счета, столько должно прийти на другой - корреспонирующий счет.

Категоричецки не согласен. Принцип двойной записи никак не нарушается, нарушается только баланс по валютам, но не баланс по базовой валюте. К тому же например есть требования ЦентроБанка, в которых написано, что в некоторых проводках рубли так прямо и должны переходить в доллары без всяких промежуточных счетов.
14 май 01, 18:05    [6477]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Garya
Guest
Извините, случайно нажал кнопку... Продолжу. Только с мультивалютными счетами по одной совкупности аналитик необходимо хранить несколько записей (в разных валютах). А это накладывает определенные ограничения. Если из них вывернуться, то тоже в принципе не против.

4. Насчет более сложной структуры запросов. IMHO, они будут действительно сложнее. Как правило, в бухучете требуется получить оборотно-сальдовую ведомость за определенный период по конкретному счету. Поскольку запрос должен возвращать разное количество столбцов для разных счетов (зависит от числа аналитических разрезов конкретного счета), то без динамического SQL тут не обойтись. Динамический SQL-это проблемы с правами доступа (кроме отсутствия гарантий синтаксической корректности). А необходимость самопальных DRI на триггерах - это не усложнение? Когда много отдельных таблиц, можно на каждый случай обзавестись запросом, который решает одну конкретную задачу, и таких запросов сделать множество, и все статические а не динамические. Каждый из таких запросов написать проще, чем один супербольшой универсальный. И DRI использовать встроенные. Я все это не к тому, что множество таблиц лучше. Лично я бы делал бы, скорее всего, по твоему варианту. Нужно просто четко представлять, что теряешь, и чего находишь.
Даже если ты ссылаешься на аналитики через документы, на встроенных DRI построить завязку на аналитики IMHO не получится. Как ты добъешься, чтобы счет 70 (зарплата) мог сослаться ТОЛЬКО на сотрудников, и не мог сослаться, к примеру, на номенклатуру товара или справчник контрагентов? В любом случае получается, что одна таблица, глобальная для всех счетов, ссылается на совокупности РАЗНЫХ аналитик, а на встроенных DRI я не представляю, как такое возможно сделать (может, и есть какое-то решение из разряда твоих "финтов", но у меня чтой-то большие сомнения).

С уважением
Андрей Гордиенко
14 май 01, 18:14    [6478]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Garya
Guest
Как ты умудрился вклиниться между двумя половинками одного сообщения !

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

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

P.S. Как-то немножко неудобно становится... Похоже, что обсуждение это как-то уж сильно выпадает за тематику данной конференции. Сидит толпа программистов и читает про дебеты и кредиты... Того и гляди, тухлыми помидорами закидают...
14 май 01, 18:23    [6479]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
SergSuper
Guest
Я так думаю, что 95% программистов этой фигней и занимаются

Насчет п. 4. об усложнении запросов. Я всё-таки останусь при своём мнении. Я просто не вижу в чем моя схема сложнее. Ведь тоже можно использовать разные запросы.
Но может я не совсем так понял, может я не знаю каких-то конкретный задач(например до сегоднешнего дня я был убежден что к поводкам аналитику нельзя привязывать, сейчас я уже задумался).

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

С приветом Сергей
14 май 01, 19:09    [6480]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Павел
Guest
Требую продолжения банкета!
14 май 01, 20:33    [6481]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
Garya
Guest
2 Павел. Уточни, что именно тебя интересует.

2 SergSuper. По поводу усложнения запросов. Вариант 1 - под каждый счет своя таблица. Вариант 2 - под все счета одна универсальная + таблица метаданных + вспомогательные таблицы, в которых задаются комбинации аналитик.
Хочу немного поправиться. Использовать динамический SQL с универсальными запросами можно и в первом и во втором варианте. И так же в обоих вариантах можно писать отдельные статические запросы для каждого счета. Плюсы и минусы динамики и статики для варианта 1 и варианта 2 взаимно противоположны.
Для варианта 1 динамический SQL будет содержать скрипт размером с "Войну и мир" (перебор всех возможных вариантов счетов и их аналитик закладывается в сам скрипт, поскольку метаданные как таковые отсутствуют). Статические запросы наоборот получаются самые простейшие - JOIN таблицы счета с таблицей справочника - и все!
Для варианта 2 динамический SQL получается гораздо менее емким нежели динамический же из варианта 1. Поскольку в нем можно задействовать таблицы метаданных. А вот с отдельными запросами под отдельные счета произойдет усложнение. Придется писать JOIN между таблицей проводок, вспомогательной таблицей (задающей комбинации значений аналитик) и таблицей справочника с фильтрацией по таблице проводок только тех записей, которые относятся к данному счету. То есть в два раза больше объединений, сложнее WHERE.
Общий объем скрипта в варианте1+статические запросы будет гораздо больше, чем в варианте 2+динамика (рассмотрены наиболее оптимальные подходы для каждого варианта). Если говоря о сложности ты имеешь в виду суммарный объем скрипта, то тут я с тобой согласен. Я же подразумевал коэффициент напряжения лобной мышцы в момент написания одного любого взятого наугад запроса.
Консенсуc достигнут?

P.S. По поводу DRI - интересный подход. Взял на заметку.
17 май 01, 20:43    [6482]     Ответить | Цитировать Сообщить модератору
 RE:Как лучше написать запрос, для такоой задачи .... ?  [new]
SergSuper
Guest
2Garya

По поводу усложнения запросов. Может мы говорим о разном? Я уже например и не понимаю за какой я вариант. За второй вроде.
Вообщем тут без конкретного примера не понятно, у тебя одни стереотипы, у меня другие. Мне например твои рассуждения напоминают тот анекдот про логику: "Вот нет у тебя воблы - и бабы у тебя не будет".


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

С приветом Сергей
18 май 01, 10:08    [6483]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Как лучше написать запрос, для такоой задачи .... ?  [new]
snake
Member

Откуда: Russia, Penza
Сообщений: 2290
о, были времена, а!
15 май 03, 17:08    [200083]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить