Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10 .. 12      [все]
 чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Я думаю что почти все программисты сталкиваються с понятими дебет и кредит счетов

Сейчас передо мной стоит задача в разработке новой структуры данных, в которой будет в том числе и бухгалтерский блок.
Кто как организовывает разбивку цифр по счетам ?
9 авг 06, 15:58    [2983425]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Br. Potemkin
Member

Откуда: Таганрог
Сообщений: 310
каких именно цифр?
9 авг 06, 17:51    [2984308]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Menahem
Member

Откуда: Санкт-Петербург
Сообщений: 418
mr.vetal
Я думаю что почти все программисты сталкиваються с понятими дебет и кредит счетов

Сейчас передо мной стоит задача в разработке новой структуры данных, в которой будет в том числе и бухгалтерский блок.
Кто как организовывает разбивку цифр по счетам ?


Что Вы имеете в виду под разбивкой?
В бухгалтерии дебет и кредит появились не просто так, а из-за принципа двойной записи: по одному счёту в минус, по другому - в плюс (это если грубо).
9 авг 06, 18:51    [2984644]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Я просто имел ввиду кто как хранит это в таблицах.
К примеру
проводка дебет кассы, кредит еще чегото по документу 1 равняеться 5 у.е.

Кто как организовывает это в таблицах ?
учитывая еще то что нада хранить остаки по счетам

И еще такой вопрос стоит ли каждый месяц пережитывать остатки или ввести их один раз (хотя производительность базы от этого думаю упадет)
10 авг 06, 09:44    [2986078]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30414
mr.vetal

чтобы не писать велосипед, надо хотябы покататься на велосипеде.
Возьми 1С демо за 100руб и изучи в пределах школьницы студентки.
10 авг 06, 11:06    [2986528]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Petro123
mr.vetal

чтобы не писать велосипед, надо хотябы покататься на велосипеде.
Возьми 1С демо за 100руб и изучи в пределах школьницы студентки.


причем тут это

1. 1С не панацея
2. я имею представление как там все организовано
3. я у народа хочу спросить
10 авг 06, 12:57    [2987338]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Menahem
Member

Откуда: Санкт-Петербург
Сообщений: 418
mr.vetal
2. я имею представление как там все организовано


Если так, то Вы без сомнения в курсе, что
mr.vetal

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


1С-ка именно так и хранит остатки: на начало и на конец конкретного периода, заданного в конфигурации. Доступ к остаткам на промежуточные даты осуществляется уже пересчётом по тем записям по каждой операции, которые находятся после ближайшей записи остатков на начало периода.
10 авг 06, 13:10    [2987411]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
gybson
Member

Откуда:
Сообщений: 1107

1С не панацея


зато бухгалтерия довольно дешевая
10 авг 06, 14:51    [2988089]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Menahem
Member

Откуда: Санкт-Петербург
Сообщений: 418
mr.vetal

gybson

1С не панацея


зато бухгалтерия довольно дешевая


Да я и не навязываю никому 1С:Бухгалтерию! Просто привёл пример того, как хранение остатков организовано там. Кстати, такой способ хранения остатков позволяет повысить скорость исполнения SQL-запроса раза в 4-ре (в моём случае, на примере 1С-ки).
10 авг 06, 15:20    [2988316]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Menahem
mr.vetal

gybson

1С не панацея


зато бухгалтерия довольно дешевая


Да я и не навязываю никому 1С:Бухгалтерию! Просто привёл пример того, как хранение остатков организовано там. Кстати, такой способ хранения остатков позволяет повысить скорость исполнения SQL-запроса раза в 4-ре (в моём случае, на примере 1С-ки).


Вот и я думаю в базе организовать хранение остатков так же как и 1С каждый месяц. Но тогда нада будет "переводить базу в новый месяц". Хотя этого так не хочеться )

А никто не предложит структуру, как он хранит бух проводки и документы ?
10 авг 06, 15:51    [2988498]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30414
IMHO
а тебе всё равно придётся переводить в конце месяца, например налоги идут разово в конце месяца документом "Закрытие месяца". Т.е. нельзя списывать каждый день по копейке, надо в конце месяца разово.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
10 авг 06, 16:52    [2988988]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Я думаю, mr.vetal, Вы немного заблуждаетесь по поводу "хранения бух проводок в таблицах". "Бух проводка" - это всего лишь еще один способ индексации БД. Вряд ли разумно хранить индексы в отдельных таблицах (объектах) от тех таблиц (объектов), которые индексируются. Что касается хранения "остатков" на "счетах", то все используют комбинации трех решений: 1) текущий остаток на счете; 2) отклонение по счету за день; 3) остаток на определенные даты (начало/конец "периода").
10 авг 06, 21:10    [2990131]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Menahem
mr.vetal

gybson

1С не панацея


зато бухгалтерия довольно дешевая


Да я и не навязываю никому 1С:Бухгалтерию! Просто привёл пример того, как хранение остатков организовано там. Кстати, такой способ хранения остатков позволяет повысить скорость исполнения SQL-запроса раза в 4-ре (в моём случае, на примере 1С-ки).

а мужики то и не знают (с)
11 авг 06, 00:22    [2990384]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ScaleFactor
Member

Откуда: 4 часа полета от столицы
Сообщений: 64
проводки в отдельной таблице, с сылками на таблицу счетов (дебетовый и кредитовый) и на таблицу документов, по которым проходят проводки

таблицы остатков
- текущие остатки по всем аналитическим счетам с оборотами за тек. день
- текущие остатки по всем синтетическим счетам с оборотами за тек. день
- история остатков по всем аналитическим счетам в "свернутом" виде
- история остатков по всем синтетическим счетам

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

и много-много другого :)
11 авг 06, 08:33    [2990644]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
gybson
Member

Откуда:
Сообщений: 1107
Я предлагаю отказываться не только от изобретения велосипедов, но и от производства :)
11 авг 06, 09:10    [2990713]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30414
gybson
Я предлагаю отказываться не только от изобретения велосипедов, но и от производства :)

)))))))))))))))
11 авг 06, 10:02    [2991007]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Menahem
Member

Откуда: Санкт-Петербург
Сообщений: 418
mr.vetal
...
А никто не предложит структуру, как он хранит бух проводки и документы ?


Поставьте себе SQL-ную 1С бухгатлерию 7.7 и посмотрите для демо-базы таблицы на SQL-сервере и файл *.dds, и обретёте истинное знание вопроса сего.
11 авг 06, 12:41    [2992634]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
LSV
Member

Откуда: Киев
Сообщений: 30150
Menahem
mr.vetal
...
А никто не предложит структуру, как он хранит бух проводки и документы ?


Поставьте себе SQL-ную 1С бухгатлерию 7.7 и посмотрите для демо-базы таблицы на SQL-сервере и файл *.dds, и обретёте истинное знание вопроса сего.
Очень спорно. На это уйдёт очень много времени. С тем же успехом можно отсылать к САПу или АКЗАПТе и к ихним мануалам по 5тыс. стр.
11 авг 06, 19:08    [2994950]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 142462
mr.vetal.
Все-таки придется Вам изучить бухучет. Тогда Вы сами сможете ответить на свой вопрос.
В том виде, в котором задан вопрос, на него ответить невозможно.
Вкратце. Существуют две системы бухучета. Классическая двойная запись и более прогрессивная - журнально-ордерная система. Причем журнально-ордерная удобнее реализуется, но классическая двойная запись надежнее, так как несет избыточную информацию, которая может понадобится для восстановлеения системы.
=========
Хранение остатков тут вообще не при делах. Одно дело, когда речь идет о фирме торгующей спичками с тысячами отгрузок и поставок в день, другое - фирма, раз в год продающая тонну золота.
13 авг 06, 11:18    [2996756]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Люди говорили...
14 авг 06, 10:06    [2998060]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Я делал
Guest
Я делал Зарплату на Oracle9 на VB63 клиент.
После 1С сделал проект.
Придется тебе создать таблицы ПланСчетов, ВидыСубконто(ссылки на справочники),ЖурналПроводок, Справочник.ШаблоныПроводок.
Свертывать по месяцам в Oracle на малых объемах нет смысла.
14 авг 06, 10:21    [2998131]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Чернышев Андрей Леонидович
Я думаю, mr.vetal, Вы немного заблуждаетесь по поводу "хранения бух проводок в таблицах". "Бух проводка" - это всего лишь еще один способ индексации БД. Вряд ли разумно хранить индексы в отдельных таблицах (объектах) от тех таблиц (объектов), которые индексируются. Что касается хранения "остатков" на "счетах", то все используют комбинации трех решений: 1) текущий остаток на счете; 2) отклонение по счету за день; 3) остаток на определенные даты (начало/конец "периода").


Спасибо всем за ответы. Много почерпнул

А вот цитируемый сейчас мною ответ меня ввел в заблуждение.

Тоесть как это: хранить проводки как индексы, а не хранить их в отдельной таблице ? Раскройте свой ответ поглубже пожалуйста :)
15 авг 06, 16:53    [3006209]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Думаю, mr.vetal, Вам известно что такое денормализация. Так вот рассматриваемый случай - классический пример денормализации, при которой мы ничего не теряем, но во многом выигрываем (например, в производительности). Хранение проводок в "отдельной таблице" - это традиционный и очень плохой вариант. Проводки нужны просто для индексации операций. Но я не могу слишком подробно рассказывать о технологических особенностях реализации "бухгалтерского учета".
16 авг 06, 10:05    [3008432]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ScaleFactor
Member

Откуда: 4 часа полета от столицы
Сообщений: 64
интересно, а как будет выглядеть запрос, показывающий все проводки по документу или по счету, если их не хранить в таблице :)

что вы понимаете под "операцией" ?
16 авг 06, 10:08    [3008469]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Обычно будет выглядеть.
Операцию, и больше ничего. Иногда говорят "хозяйственная операция", иногда "событие" и т.п.
16 авг 06, 10:15    [3008520]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ScaleFactor
Member

Откуда: 4 часа полета от столицы
Сообщений: 64
чем она отличается от проводки ?
у нее есть атрибуты "дебет", "кредит", ссылка на документ и пр. ?
16 авг 06, 10:21    [3008542]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
"У нее" много чего есть, в отличие от "проводки". Что Вы от меня хотите ? Проект БД ?
16 авг 06, 10:27    [3008584]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ScaleFactor
Member

Откуда: 4 часа полета от столицы
Сообщений: 64
если у "операции" есть все или хотя бы основные атрибуты проводки, то вопросов нет, это просто расширенный вариант проводки :)
16 авг 06, 10:30    [3008609]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вам нравится называть операции выработки продукции, перемещения ее на склад, отгрузки и т.п. "расширенными проводками" ? Я не против. Но сути денормализации Вы, мне кажется, не поняли...
16 авг 06, 10:37    [3008670]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ScaleFactor
Member

Откуда: 4 часа полета от столицы
Сообщений: 64
да понимаю я что такое денормализация :)

хозяйственные операции - это одно, а проводки - это совсем другое
хоз. операции IMHO должна существовать независимо от бухгалтерии с ее счетами, остатками и пр.

а уже к хоз операции можно прикрепить набор проводок, отражающих ее (хоз операцию) в бух учете.

не совсем понимаю, Вы что храните все это вместе, в одной денормализованной таблице ?
впрочем, я не знаю конкретики вашей задачи, возможно в вашем случае есть основания поступать именно так
16 авг 06, 10:47    [3008756]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Конкретика моей задачи - эффективная корпоративная БД. "Так" нужно поступать во всех случаях, а не в "моем". Конечно "набор", и конечно не в "одной денормализованной таблице". Я же не о тотальной денормализации сказал, а о совершенно конкретной. Проводки - просто индексация операций. Хранение проводок в "отдельной таблице" плохое решение, через которое я, разумеется, проходил...
16 авг 06, 10:57    [3008849]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Конкретика моей задачи - эффективная корпоративная БД. "Так" нужно поступать во всех случаях, а не в "моем". Конечно "набор", и конечно не в "одной денормализованной таблице". Я же не о тотальной денормализации сказал, а о совершенно конкретной. Проводки - просто индексация операций. Хранение проводок в "отдельной таблице" плохое решение, через которое я, разумеется, проходил...

А можно хоть намекнуть то, о чем речь? А то все загадками...
Непонятно выражаетесь. В классическом понимании хоз. операция, к примеру, "отгрузили товар покупателю". А под ней 18 проводок... Как Вы их в одной таблице храните?
16 авг 06, 11:02    [3008897]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Эффективно. Что Вы от меня хотите ? Проекта БД ?
16 авг 06, 11:05    [3008919]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Я же не против, чтобы каждый прошел через "классическое понимание" и "классическое хранение проводок в отдельной таблице". Это полезно.
16 авг 06, 11:08    [3008944]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Мне Ваш проект БД не нужен, поверьте. У меня их сотни. То о чем Вы говорите не укладывается в логику при взгляде со стороны. Или разъясняйте каким образом Вы и 10 записей в одной объединяете, или не нужно умных слов. Пустое перемалывание воздуха. Может Вы что-то другое под хозяйственной операцией понимаете, может под проводкой..
16 авг 06, 11:38    [3009244]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 19162
Чернышев Андрей Леонидович
Проводки - просто индексация операций

ЧЕГО?
Не будет ли любезен многоуважаемый Чернышев Андрей Леонидович объяснить, что это означает? Ибо "индексация" - это процесс. А "проводка" - это сущность.
И где Вы храните проводки, если не в таблице? В отдельной или нет - не важно, но сущность "проводка" просто обязана быть. Можете привести пример, какие проводки формируются (физически, в какие таблицы что попадает) при принятии к учету ОС со стоимостью 100000 рублей, если надо принять к учету в целях БУ (лин. аморт), НУ (нелин. аморт), МСФО (не аморт.), отдельно для корпоративной управленческой отчетности в рамках холдинга (аморт. пропорц. объему продукции) и еще по ПБУ 18/02 понаделать? А то не ясно, как Вы это собираетесь делать, не имея отдельной сущности "проводка" и оперируя мифическими "индексированиями".
16 авг 06, 13:23    [3010229]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Уважаемый Сергей Васкецов. Если Вам что-то не ясно, то это не означает, что "это" что-то мифическое, не правда ли ? Зря Вы кипятитесь. Я же ясно сказал, что уже прошел через "сущность "проводка" просто обязана быть." Не обязана. Более того - это просто ошибка (неоправданная нормализация), так как "проводка" используется просто для дополнительной индексации БД.
И Ваш "пример" не имеет к этому абсолютно никакого отношения.

Ничего другого я не понимаю ни под операцией, ни под проводкой, iscrafm. Если в сотнях Ваших проектов проводки хранятся в отдельной таблице, то это плохо. Вы бесполезно снижаете производительность. Чтобы не заниматься "перемалыванием воздуха" я уже посоветовал Вам продолжать хранить проводки в отдельной таблице. А автору темы я посоветовал подумать над тем, что я сказал...
16 авг 06, 13:57    [3010503]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Как-то не сочетается, iscrafm: "Мне Ваш проект не нужен" и "разъясняйте каким образом ... храните". Сами догадаетесь рано или поздно.
16 авг 06, 14:05    [3010564]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ScaleFactor
Member

Откуда: 4 часа полета от столицы
Сообщений: 64
Чернышев Андрей Леонидович
А автору темы я посоветовал подумать над тем, что я сказал...

боюсь автор не поймет что вы имеете ввиду :) впрочем похоже и все остальные :)
никогда :)
16 авг 06, 14:06    [3010577]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
"Все" и "никогда" - это преувеличение, ScaleFactor.
16 авг 06, 14:12    [3010622]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Я сделал вывод что проводка у Чернышева Андрея Леонидовича это представление (или представления), собранное из отдельных таблиц, например тех же полупроводок.

По другому я пока не могу мыслить :( :( :(
Жаль что Андрей Леонидович не хочет хотябы намекнуть общественности о чем собственно поконкретнее идет речь
16 авг 06, 14:20    [3010699]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 19162
Чернышев Андрей Леонидович
так как "проводка" используется просто для дополнительной индексации БД

То есть, раз она дополнительная, ее можно вообще не делать? А как обороты считать? Или Вы БУ и УУ не разделяете?
16 авг 06, 14:29    [3010775]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Если в сотнях Ваших проектов проводки хранятся в отдельной таблице, то это плохо. Вы бесполезно снижаете производительность. Чтобы не заниматься "перемалыванием воздуха" я уже посоветовал Вам продолжать хранить проводки в отдельной таблице. А автору темы я посоветовал подумать над тем, что я сказал...

В отдельной от чего простите? Как можно одну единственную таблицу хранить еще отдельно? Игры разума...
16 авг 06, 15:22    [3011247]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы сделали неправильный вывод, mr.vetal. Нет никаких представлений, и никаких полупроводок.

Нет, Сергей Васкецов, нельзя вообще не делать. Но я бы не стал называть эту индексацию операций "основной".
16 авг 06, 15:23    [3011257]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
В отдельной от операций, iscrafm. Игры, игры, они самые. И перемалывание воздуха.
16 авг 06, 15:27    [3011293]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
В отдельной от операций, iscrafm. Игры, игры, они самые. И перемалывание воздуха.

:) А если вообще нет операций? Например набор форм, по которым делается разноска в таблицу проводок? Тогда отдельно от чего?
16 авг 06, 15:31    [3011341]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
"А если бы он вез патроны" ? Вот как раз ScaleFactor говорил о "специфике вашей задачи". Я с такими специфическими задачами не знаком, честно признаюсь.
16 авг 06, 15:38    [3011392]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
а никто о специфических задачах вроде не говорил в этой ветке. Речь идет об обычном бухучете..
16 авг 06, 15:49    [3011503]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Я и говорю, что понятия не имею что такое "обычный бухучет", при котором операции не регистрируются в БД. Наверное это важная и кому-то нужная задача, и мне даже стыдно, что я впервые слышу о такой задаче.
16 авг 06, 15:59    [3011583]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Чернышев Андрей Леонидович
Я и говорю, что понятия не имею что такое "обычный бухучет", при котором операции не регистрируются в БД. Наверное это важная и кому-то нужная задача, и мне даже стыдно, что я впервые слышу о такой задаче.


ну и закрутил :-)
16 авг 06, 16:16    [3011764]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Я и говорю, что понятия не имею что такое "обычный бухучет", при котором операции не регистрируются в БД.

Понятно. Вопросы сняты по причине отсутствия понимания сущностей бухучета.
17 авг 06, 09:15    [3014267]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Не расстраивайтесь. Ничего сложного в "сущностях бухучета" нет. Понимание обязательно придет.
17 авг 06, 12:20    [3015664]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Не расстраивайтесь. Ничего сложного в "сущностях бухучета" нет. Понимание обязательно придет.

Это Вы себя так успокаиваете? :)
17 авг 06, 14:53    [3017161]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Не сочиняйте, iscrafm. Я не знаю что такое "обычный бухучет", но хорошо понимаю сущность "бухучета" (а так же его "сущности"). Существительному "учет" сложновато выдержать сразу два прилагательных - "обычный" и "бухгалтерский". Даже только "бухгалтерский" делает учет субъективным, так как никакой теории "бухгалтерского учета" не существует (Я.В.Соколов и другие мыслящие "бухгалтеры" весьма переживают по этому поводу). А Вы еще и "обычный" приписали. Да еще и без регистрации операций. Видимо совершенные операции "записываются в книги" только в "необычном бухгалтерском учете". Но если основы учета объективного движения материи в пространстве и во времени Вы хорошо понимаете, то и субъективные "надстройки" (БУ,УУ,НУ,...) со временем поймете. И Ваши 100 проектов заиграют новыми красками, и станут еще лучше. Впрочем, может лучше уже некуда...
17 авг 06, 16:02    [3017770]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Не сочиняйте, iscrafm.

Видите ли, здесь не один я не понял, что Вы вкладываете в сущность хозяйственной операции. Так кто из нас сочиняет? Может объясните о чем Вы говорите?
17 авг 06, 17:30    [3018796]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вынужден повторить:
"Ничего другого я не понимаю ни под операцией, ни под проводкой, iscrafm".
И ничего не вкладываю. Все уже вложено. До меня.
И опять вынужден повторить: со временем Вы поймете "сущность хозяйственной операции".
Вы храните операции в одной "таблице", а проводки - в другой (к одной операции отгрузки у Вас 18 проводок). А я храню по-другому. В соответсвии с "сущностью бухгалтерского учета" и "сущностью хозяйственной операции".
Извините, но я не верю, что Вы чего-то не поняли в этом пустяковом вопросе.
17 авг 06, 18:56    [3019457]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович
Вынужден повторить:
"Ничего другого я не понимаю ни под операцией, ни под проводкой, iscrafm".
И ничего не вкладываю. Все уже вложено. До меня.
И опять вынужден повторить: со временем Вы поймете "сущность хозяйственной операции".
Вы храните операции в одной "таблице", а проводки - в другой (к одной операции отгрузки у Вас 18 проводок). А я храню по-другому. В соответсвии с "сущностью бухгалтерского учета" и "сущностью хозяйственной операции".
Извините, но я не верю, что Вы чего-то не поняли в этом пустяковом вопросе.


Да, ладно темнить то.
Если есть чего-то стоящего, то скажите.
Я все это дело держал в нескольких таблицах. Основная провадка в теле операции, допольнительные в общей таблице проводок со ссылкой к основным таблицам. Ссылки -тип,номер,дата псевдодокументов (напр, амортизация - IZ,123,12.07.09).
Можно, конечно, все это сунуть в CSV поле, н потом гемррой с парсингом.
17 авг 06, 21:51    [3019851]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
В соответсвии с "сущностью бухгалтерского учета" и "сущностью хозяйственной операции".

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

p.s. to ALL
Никто не знает, может я с ботом общаюсь, не встречались? Очень похоже
17 авг 06, 22:20    [3019907]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Если у Вас, Сахават Юсифов, "гемррой", то это же не значит, что у меня тоже "гемррой", не правда ли ? "Основная проводка в теле операции" - надо же, просто удивительно как удалось избежать "гемрроя" с "основной проводкой в теле".

Это Вы, то ли iscrafm, то ли бот, хотя бы на третьей странице скажите что там у Вас в таблице проводок, отдельной от таблицы операций (отгрузки) ? Например, Дата (проводки) там есть ? И она имеет разное значение в этих 18-ти проводках, имеющих ссылку (внешний ключ) на одну операцию отгрузки ? Правильно ?
18 авг 06, 08:57    [3020738]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 19162
Чернышев Андрей Леонидович
Например, Дата (проводки) там есть ? И она имеет разное значение в этих 18-ти проводках, имеющих ссылку (внешний ключ) на одну операцию отгрузки ? Правильно ?

Может и иметь разные значения в разных проводках по одному документу. Один и тот же факт может приниматься к учету в разных учетах в разное время и в разном объеме. Поэтому дата проводки может не совпадать с датой реального документа. Да даже если взять платежное поручение, если его отправить поздно вечером, то пройдет оно по банку только на следующий день, не раньше. Даже с точки зрения сермяжного БУ, дата проводки в этом случае не равна дате документа (то есть, проводка формируется за дату проведения, в книгу покупок/продаж оплата попадает тоже по дате проведения, но на печатной платежке стоит отличная от даты проведения реальная дата документа).
18 авг 06, 10:59    [3021434]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
p.s. to ALL
Никто не знает, может я с ботом общаюсь, не встречались? Очень похоже[/quot]Похоже это стиль общения:). Все термины понимаются по-своему, но расшифровок и более конкретных ответов не будет, готов спорить.
18 авг 06, 12:02    [3022079]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
А с определением проводки интересный парадокс - все используют термин в практике, но его нет ни в одном официальном документе - Закон о бухучете, ПБУ. Так что любое сообщение по теме нужно начинать с определений видов практикуемых учетных записей.
18 авг 06, 12:22    [3022302]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Пожалуйста, Сергей Васкецов, не отклоняйтесь от операции отгрузки, предложенной iscrafm. Тем более, что Вы сообщили о весьма неудачном решении - проводки по платежному поручению; да и "правильную" дату никто Вам не мешает хранить в операции (а не 19 раз - в операции и в 18-ти проводках).
Очень хорошо сочетаются две мысли ModelR. Даже спорить нечего. От него никогда не будет "расшифровок" по "вине" Закона.
И все это на пустом месте, из-за тривиальной ошибки при проектировании БД, которую, как я уже говорил, я и сам допустил в прошлом.
18 авг 06, 12:36    [3022463]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сергей Васкецов
Member

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

1. Еще раз для особо одаренных. Нет в данном случае правильной даты, их много. Есть еще более "неудачные" примеры, например, с ОСами.
2. Ладно, надоело это все, пока не будет конкретики - досвидос.
18 авг 06, 12:56    [3022673]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Очень хорошо сочетаются две мысли ModelR. Даже спорить нечего. От него никогда не будет "расшифровок" по "вине" Закона.
Еще раз напомню про топик, где кто есть кто сведено в "трехэтажную систему Хозоперация-Проводка-Полупроводка". Удачно или нет, но термины определены и можно их критиковать.
18 авг 06, 13:09    [3022826]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вот такой бухгалтерский пафос:

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

А если этот пафос убрать, то получится, что "выделяя существенные свойства" (обычное моделирование и проектирование БД) мы регистрируем в БД "факты хозяйственной жизни" вовсе без "бухгалтерского учета". А "кредиты" и "дебеты" "счетов" просто обязаны получаться автоматически, чтобы еще и "бухгалтерам" было приятно. И именно это (кредит,дебет,сумма,дата) и является собственно бухгалтерской проводкой, так как все остальное неизбежно регистрируется в БД не из "бухгалтерских" побуждений, а из желания как можно объективнее представить в БД объективное движение материи.
18 авг 06, 13:11    [3022849]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Ловко, Сергей Васкецов, и очень знакомо. Конкретика: ровно две даты, а не много - дата оформления и дата "проведения" (дата операции, дата проводки).
Вы допускаете очевидные ошибки при проектировании БД, а от меня требуете чего ? Какой конкретики ?
18 авг 06, 13:16    [3022895]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Обязательно почитаю тот топик еще раз, ModelR.
18 авг 06, 13:18    [3022927]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Перечитал, ModelR. "Аналитики привязаны к полупроводкам." Этим для меня все сказано. Традиционный "бухгалтерский подход". Там PVP на второй странице высказывал мысли, примерно схожие с тем, что я говорю. A Dogen сказал, что "этого сейчас не поймут". Надо же время какое застойное - то же самое было и с теорией баз данных, тоже все никак не поймут...
18 авг 06, 13:37    [3023161]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
LightNet
Member

Откуда:
Сообщений: 12
Чернышев Андрей Леонидович
Вот такой бухгалтерский пафос:

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

А если этот пафос убрать, то получится, что "выделяя существенные свойства" (обычное моделирование и проектирование БД) мы регистрируем в БД "факты хозяйственной жизни" вовсе без "бухгалтерского учета". А "кредиты" и "дебеты" "счетов" просто обязаны получаться автоматически, чтобы еще и "бухгалтерам" было приятно. И именно это (кредит,дебет,сумма,дата) и является собственно бухгалтерской проводкой, так как все остальное неизбежно регистрируется в БД не из "бухгалтерских" побуждений, а из желания как можно объективнее представить в БД объективное движение материи.

+1
кстати откуда цитатку дернули? Почитать хочется.
18 авг 06, 15:19    [3024215]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
мы регистрируем в БД "факты хозяйственной жизни" вовсе без "бухгалтерского учета". А "кредиты" и "дебеты" "счетов" просто обязаны получаться автоматически, чтобы еще и "бухгалтерам" было приятно.
Эх, жисть бы настала - мечта. И к ней кстати надо стремиться со всей серьезностью, но соизмерять затраты с результатами. Экономическая нерациональность 100% формализации и ведет к тому, что бухгалтеров до сих пор не заменили на программистов, а факты не сопадают с бухгалтерскими записями.
18 авг 06, 15:26    [3024273]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Ближе всего была книга Я.В.Соколова, по-моему (сейчас я уже не на работе) "Основы теории бухгалтерского учета" (как я уже говорил он же в одном из докладов, который можно найти в Internet, сожалеет, что пока не разработана теория бухгалтерского учета); из нее и "дернул".

Уверяю Вас, ModelR, затраты минимальны, только огромное сопротивление. За три приема добрался до того, что бухгалтеры больше не смогут делать бухгалтерские проводки (полный автомат), и больше не будут описывать типовые проводки (этого удалось давно, и это очень важно). Возможно последним шагом будет полный отказ от "проводок". Чтобы закончить "конкретику": дата и сумма, конечно, из операции. Да, в операции могут быть "бухгалтерские", "управленческие", "налоговые" даты и суммы - это не меняет сути дела (к тому же ВСЕ эти прилагательные к учету, как мы помним, субъективны). Что же остается "своего" в "проводке" ? Кредитуемый и дебетуемый "счета" ? Это ради них люди сооружают "отдельные таблицы", и "тащат" туда даты, суммы, и что-то еще из объективных операций (тоже ведь денормализация - дублирование)? Несложный анализ показывает, что это плохое архитектурное решение.
Думаю, что важной причиной недостатков "корпоративных систем" является подверженность проектировщиков влиянию прилагательных "бухгалтерский", "управленческий", "производственный" и др. к концепции "учета". То же самое можно сказать и о "планировании".
Парадоксально, но многие специализированные "учетные системы" (платформы), например, 1с, плохо приспособлены даже для бухгатерского (!) учета именно по той причине, о которой я сказал.
18 авг 06, 20:22    [3026404]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
А бухгалтеры становятся инженерами-методистами, специалистами по учету (без всяких прилагательных). Думаю им это должно быть приятно (?).
18 авг 06, 20:29    [3026417]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович
Если у Вас, Сахават Юсифов, "гемррой", то это же не значит, что у меня тоже "гемррой", не правда ли ? "Основная проводка в теле операции" - надо же, просто удивительно как удалось избежать "гемрроя" с "основной проводкой в теле".


Зря нарываетесь. В говно смешаю.
18 авг 06, 22:12    [3026812]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Был бы просто счастлив ! Тем не менее, "проводки" (правда только некие "основные") Вы храните не в "отдельной таблице", то есть "в основном" со мной согласны. Но нарываетесь именно Вы, а я Вас смешивать ни с чем не буду. Если будете и дальше нарываться, то сами себя смешаете.
19 авг 06, 10:57    [3027594]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович
Был бы просто счастлив ! Тем не менее, "проводки" (правда только некие "основные") Вы храните не в "отдельной таблице", то есть "в основном" со мной согласны. Но нарываетесь именно Вы, а я Вас смешивать ни с чем не буду. Если будете и дальше нарываться, то сами себя смешаете.


Ладно, не будем ругаться.
1. Независимая основная проводка.
Это естественная проводка. Напр.,получили от поставщика материал - д10,к60.
2. Вторичная автопроводка. (Разбивают основную или начисляются на их основе)
Выделили НДС. д19,к60.
При этом могут появиться подспудные субъекты , по которым надо вести учет. Количество проводок и субъектов могут варироваться.
3. Вторичная зависимая автопроводка.
При оплате - д60,к51 появляется вторичная проводка к68,д19 в зависимости от 2 (зависит от другог первичного документа).
При этом могут появиться подспудные субъекты , по которым надо вести учет. Количество проводок и субъектов могут варироваться.
4. Зависимая основная проводка.
д10,к60(субъект1) и д60(субъект2),к51 ->д60(субъект1),к60(субъект2)

Основная проводка базируется на первичных документах. Генерация вторичных и зависимых просто. Основная проблема - подспудные субъекты. Решается путем приписки счетов к субъектам.
Напр, счет 19 - приписан "Мы", а 68 - "Налоговая инспекция ... уезда".

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

Зачем держать Основную независимую проводку в теле операции?
1. Упрощается генерация ОНП. (Обычно зависит от типа документа и типа субъектов). Где-то 100% , а где-то выбор из субсчетов.
2. Упрощается получения смешаннай отчетности типа, "Там-то, на счете таком то, во насколько всякой херни."

Почему не надо держать другие проводки в теле операции?
1. Усложняется получения отчетности типа, "Там-то, на счете таком то, во насколько всякой херни."
2. Усложняется стыковка операций.
3. В тех случаях, когда нет первичных документов (износ ОС, зарплата), приходится ввести псевдодокументы.
.....
n. Невозможно отделить синтетический учет от аналитической.
n+1!!! Невозможно отделить аналитический учет от синтетической (ИП - я просто закрываю таблицу проводок и убираю поля д,к из тела операции).

Конечно, всу эту хреновину можно сунуть в какие-нибудь XML поля и спокойно работать. Раньше нелзя было, а самому парсить было неохота. Сейчас можно.
19 авг 06, 14:42    [3028036]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Понятно. Сильное влияние БУ на проектные решения, о чем я и говорил.
Для "аналитического учета" не нужно никаких проводок в принципе, даже "основных". Но для этого именно в операциях должны присутсвовать все данные. В частности, для "аналитического учета" по поставщикам, или, как Вы сказали "для ведения", но не 10-го, а активно-пассивного (или пассивного, если использовать 61) 60-го не достаточно Вашей "основной проводки". Получается не целостная картина. Далее: зачет налогов - это тоже операция, которая порождается автоматически при выполнении некоторых условий (конечно, не просто в связи с оплатой, но эта Ваша неточность не принципиальна), и используется в аналитических отчетах безо всяких проводок. И по этой операции делаются проводки, как и по операции оприходования.
"Почему не надо держать другие проводки в теле операции ?" - мне кажется не корректной постановкой вопроса. Правильнее объяснить себе почему суммы налога нет в операции, почему вообще нет операции зачета налога, и т.п. Понять пункты 1,2,3,n,n+1 Вашего объяснения я не смог. У меня никогда не возникало проблем "стыковки операций", операцию начислений износа я считаю полноправной, а не псевдо (это в БУ документа нет, но в БД он есть, и совершенно стандартный, как и ТТН, например), я против прилагательных к слову "учет", но "синтетический" и "аналитический" учеты (то есть то, что под ними традиционно понимается) намного лучше сосуществуют при размещении "проводок" в операциях, и т.д. Мне кажется Ваши решения концептуально не ориентированы на корпоративный уровень.
И еще раз повторю - надеюсь, что от проводок удастся избавиться полностью.
P.S. Насколько я понимаю, все что Вы наработали - все в одиночку. Это впечатляет. Я бы не смог.
19 авг 06, 19:43    [3028476]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович
Понятно. Сильное влияние БУ на проектные решения, о чем я и говорил.
Для "аналитического учета" не нужно никаких проводок в принципе, даже "основных".


1. Вы не работали с бухами. Им мало того, "что на складе чего то в таком то количестве на такую то сумму" - "на каком счете", "с какого счета" и т.д. - объязательно.
2. Частенко склады (обычно виртуалбные) - смешанные.

Чернышев Андрей Леонидович

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


Я же написал - полная аналитика + ОНП достаточна для получения смешанной отчетности (ситетика+аналитика) по не расчтено-распределительным, компенсационным счетам.

Чернышев Андрей Леонидович

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


Это был именно пример.

Чернышев Андрей Леонидович

"Почему не надо держать другие проводки в теле операции ?" - мне кажется не корректной постановкой вопроса. Правильнее объяснить себе почему суммы налога нет в операции, почему вообще нет операции зачета налога, и т.п.


Если пойти по пути "операций", то "Бухгалтерия" никогда не напищете.

Чернышев Андрей Леонидович


Понять пункты 1,2,3,n,n+1 Вашего объяснения я не смог.


Это и есть влияние БД и отчетных систем, как вы изволили заметить.

Чернышев Андрей Леонидович


У меня никогда не возникало проблем "стыковки операций", операцию начислений износа я считаю полноправной, а не псевдо (это в БУ документа нет, но в БД он есть, и совершенно стандартный, как и ТТН, например),


Все операции (документы) ЖЦ объекта стыкуются.
Износ (не только) - самое слабое место в бухучете(нашем). Неестественное. Которая приводит к появлению компеннсмрующих счетов. Что в свою очередь перечеркивает все попытки совместить аналитический и синтетический учет.

Чернышев Андрей Леонидович

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


Синтетический учет - хорошо продуманная вещь. Дает свободу бухгалтеру.
И намного информатинее, чем смешанный.
В принципе это и есть "бухгалтерский учет".
А аналитический - инвентарный.

Чернышев Андрей Леонидович

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


Я и не жду, что кто-нибудь скажет - Сахават - человек. Букашка - да. Это мы умеем.
[/quot]

Чернышев Андрей Леонидович

И еще раз повторю - надеюсь, что от проводок удастся избавиться полностью.


Проводка - свобода маневра. Реструктуризация!!! Избавившисть от нее избавитесь от сути бухучета. Хорошо это или плохо - вам судит.

Чернышев Андрей Леонидович

P.S. Насколько я понимаю, все что Вы наработали - все в одиночку. Это впечатляет. Я бы не смог.


Попробуйте. Не так все сложно.
19 авг 06, 21:41    [3028607]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Я работаю с "бухами" много лет. Они образованные люди, и понимают (постепенно), что в результате операций изменяются вполне объективные учетные величины, а не "счета". Государство, в целях стандартизации, унификации (для облегчения контроля за подданными) просто "сказало": вот эту величину вы должны обозначать цифрами 4 и 0. А потом оно "подумало" и "сказало": а теперь, подданные, эту величину вы должны обозначать цифрами 4 и 3. Зря Вы так беспокоитесь о "счетах". Продвинутые "бухи" о них уже давно не беспокоятся. "Проводки" автоматически делаются и делаются... И "бухи" любые свои (то есть государственные) отчеты получают.

Что значит "я же написал" ? У Вас одна составляющая "долга" перед поставщиком хранится в операции, а другая в проводке. Это не целостно, и не допустимо, если Вы строите корпоративную систему. А если некую "бухгалтерскую", то тут я ничего не могу сказать - это просто не интересно. И все равно приводит к проблемам типа "смешанной отчетности"...

Что значит "это был именно пример" ? У Вас есть операция зачета НДС (а не проводка) или нет ?

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

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

Теперь я практически уверен, что Вы заблуждаетесь в сути учета, раз говорите, что приписанные к зарегистрированной операции, и ничего не изменяющие по сути, значки
К 60 Д 10
это "свобода маневра" и "реструктуризация".
"Бухгалтерский учет", мне кажется, завел Вас в тупик, и перечеркнул Ваши "попытки совместить аналитический и синтетический учет".

Зачем же мне пробовать создавать столь сложные системы в одиночку, если в коллективе все получается быстрее и качественнее...
20 авг 06, 20:34    [3029508]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович

Я работаю с "бухами" много лет. Они образованные люди, и понимают (постепенно), что в результате операций изменяются вполне объективные учетные величины, а не "счета". Государство, в целях стандартизации, унификации (для облегчения контроля за подданными) просто "сказало": вот эту величину вы должны обозначать цифрами 4 и 0. А потом оно "подумало" и "сказало": а теперь, подданные, эту величину вы должны обозначать цифрами 4 и 3. Зря Вы так беспокоитесь о "счетах". Продвинутые "бухи" о них уже давно не беспокоятся. "Проводки" автоматически делаются и делаются... И "бухи" любые свои (то есть государственные) отчеты получают.


Когда-нибудь вы поймете красоту синтетического учета и свободу "образованного буха" в контексте оной.
Государство(дебильные законы об НДС и прибыли,...) и бухучет не совместимы. Налоговый учет должен естественно (по сути и по форме) интегрироваться в бухучет. Для этого должные отменяться все налоги с оборота. Налог должен быть либо на потребленте, либо на имущество, либо на рост стоимости бизнеса. В БУХУЧЕТЕ НИЧЕГО НЕ ДОЛЖНО РАССЧИТЫВАТЬСЯ СЛОЖНЫМ ПУТЕМ.

Чернышев Андрей Леонидович

Что значит "я же написал" ? У Вас одна составляющая "долга" перед поставщиком хранится в операции, а другая в проводке. Это не целостно, и не допустимо, если Вы строите корпоративную систему. А если некую "бухгалтерскую", то тут я ничего не могу сказать - это просто не интересно. И все равно приводит к проблемам типа "смешанной отчетности"...


То, что храниться в "теле операции" дублируется в "проводках".
"Проводки" полны синтетически, "тела" - аналитически с избыком в сторону синтетики.

Чернышев Андрей Леонидович

Что значит "это был именно пример" ? У Вас есть операция зачета НДС (а не проводка) или нет ?


У меня вообще нет оперций. Есть документы и проводки на основе оных.

Чернышев Андрей Леонидович

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


Все сложности возникают во время откатов или "справок-сторнировок".


Чернышев Андрей Леонидович

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


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


Чернышев Андрей Леонидович

Теперь я практически уверен, что Вы заблуждаетесь в сути учета, раз говорите, что приписанные к зарегистрированной операции, и ничего не изменяющие по сути, значки
К 60 Д 10
это "свобода маневра" и "реструктуризация".
"Бухгалтерский учет", мне кажется, завел Вас в тупик, и перечеркнул Ваши "попытки совместить аналитический и синтетический учет".


На счет значков - как хотите. Реформацию баланса никто не отменял. Один период может характеризироваться разными структурами и валютами баланса.
Следующий период начинается с УТВЕРЖДЕННОГО баланса, что откладывает сильную тень на "математику" бухучета.

Чернышев Андрей Леонидович

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


Дай бог! Коллектив, так коллектив. Деньга то все равно в рознь и сомооценка и "реальная оценка" и возраст, и

Спасибо.
20 авг 06, 22:56    [3029708]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Уверяю Вас, ModelR, затраты минимальны, только огромное сопротивление. За три приема добрался до того, что бухгалтеры больше не смогут делать бухгалтерские проводки (полный автомат), и больше не будут описывать типовые проводки (этого удалось давно, и это очень важно). Возможно последним шагом будет полный отказ от "проводок". Чтобы закончить "конкретику": дата и сумма, конечно, из операции. Да, в операции могут быть "бухгалтерские", "управленческие", "налоговые" даты и суммы - это не меняет сути дела (к тому же ВСЕ эти прилагательные к учету, как мы помним, субъективны). Что же остается "своего" в "проводке" ? Кредитуемый и дебетуемый "счета" ? Это ради них люди сооружают "отдельные таблицы", и "тащат" туда даты, суммы, и что-то еще из объективных операций (тоже ведь денормализация - дублирование)? Несложный анализ показывает, что это плохое архитектурное решение.
Думаю, что важной причиной недостатков "корпоративных систем" является подверженность проектировщиков влиянию прилагательных "бухгалтерский", "управленческий", "производственный" и др. к концепции "учета". То же самое можно сказать и о "планировании".
Парадоксально, но многие специализированные "учетные системы" (платформы), например, 1с, плохо приспособлены даже для бухгатерского (!) учета именно по той причине, о которой я сказал.
Да нет тут никакой Америки. Все это уже проходили: убрать бухгалтеров на фиг - вся их деятельность регламентирована, осталось только запрограммировать. Увы, факт что одни и те же документы могут иметь разную интерпретацию.

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

На сегодня реально работающие системы построены по пессимистическому варианту. Типа строки документа - это одна таблица, а складские операции, бухгалтерские операции по этим строкам - еще две таблицы. Уровнь дублирования очень высок, да. Но система гораздо живучее. Например, можно разрешить править документ, при этом прибить складские но сохранить бух. записи. После поправки провести заново по складу, а по бух. оформить сторнировку/ допроводку.

Если же речь о том, чтобы эти три комплекта записей физически свести в единственную сущность и назвать ее операцией, то это скорее вопрос конкретной СУБД - где что эффективнее.
21 авг 06, 10:47    [3030660]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
ModelR
На сегодня реально работающие системы построены по пессимистическому варианту. Типа строки документа - это одна таблица, а складские операции, бухгалтерские операции по этим строкам - еще две таблицы. Уровнь дублирования очень высок, да. Но система гораздо живучее. Например, можно разрешить править документ, при этом прибить складские но сохранить бух. записи. После поправки провести заново по складу, а по бух. оформить сторнировку/ допроводку.

Дело даже не в пессимизме. Чернышев все пытается выдать за какое-то ноу-хау разноску проводок "на лету" по записям операций. Вариант безусловно имеет право на жизнь, но в строго оговоренных условиях.
21 авг 06, 12:13    [3031317]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
ModelR
Чернышев Андрей Леонидович
Уверяю Вас, ModelR, затраты минимальны, только огромное сопротивление. За три приема добрался до того, что бухгалтеры больше не смогут делать бухгалтерские проводки (полный автомат), и больше не будут описывать типовые проводки (этого удалось давно, и это очень важно). Возможно последним шагом будет полный отказ от "проводок". Чтобы закончить "конкретику": дата и сумма, конечно, из операции. Да, в операции могут быть "бухгалтерские", "управленческие", "налоговые" даты и суммы - это не меняет сути дела (к тому же ВСЕ эти прилагательные к учету, как мы помним, субъективны). Что же остается "своего" в "проводке" ? Кредитуемый и дебетуемый "счета" ? Это ради них люди сооружают "отдельные таблицы", и "тащат" туда даты, суммы, и что-то еще из объективных операций (тоже ведь денормализация - дублирование)? Несложный анализ показывает, что это плохое архитектурное решение.
Думаю, что важной причиной недостатков "корпоративных систем" является подверженность проектировщиков влиянию прилагательных "бухгалтерский", "управленческий", "производственный" и др. к концепции "учета". То же самое можно сказать и о "планировании".
Парадоксально, но многие специализированные "учетные системы" (платформы), например, 1с, плохо приспособлены даже для бухгатерского (!) учета именно по той причине, о которой я сказал.
Да нет тут никакой Америки. Все это уже проходили: убрать бухгалтеров на фиг - вся их деятельность регламентирована, осталось только запрограммировать. Увы, факт что одни и те же документы могут иметь разную интерпретацию.

...

На сегодня реально работающие системы построены по пессимистическому варианту.
....

Присоединяюсь.
Более того, жизнь показывает, что определить все "операции" изначально раз и навсегда - утопия...
21 авг 06, 17:31    [3033768]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
Ой, я под "левым" ником!!! Ну, да ладно...
21 авг 06, 17:32    [3033780]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Итак, проводки дублируют операции, которые у Вас, каким-то загадочным образом "не полны синтетически". Будто-бы в "проводках" (Ваших) есть нечто, чего нет в "операциях" (Ваших), что делает их (проводки) "полными". Что там есть неизвестно. Как могут значки "Кр" и "Дб" обеспечить "полноту", "красоту" и "свободу" Вы объяснить не можете, но я начинаю подозревать, что проводки у Вас вручную делаются (для "красоты" и "свободы").

Операций у Вас нет. Замечательно. При этом "основные проводки" хранятся в "теле операции", которой нет. Теперь видимо так: "основные проводки" хранятся в "теле документа", а "дополнительные" в "отдельной таблице". Хорошо. У Вас есть сумма НДС в "документе", а не в "отдельной проводке" ? У Вас есть "документ" зачета НДС, а не "отдельная проводка" ?

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

Про "сильную тень на "математику" бухучета" мне трудно понять, ведь "математика бухучета" настолько тривиальна, что: 1) на нее сложно навести какую-либо тень; 2) проводки просто бессмысленно отделять от объективных операций.
Большое спасибо.
21 авг 06, 20:43    [3034531]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

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

Все операции, ###, давно раз и навсегда определены - не знать этого просто неприлично.
21 авг 06, 20:54    [3034543]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Обругали меня: "Правильно - ни при чем."
21 авг 06, 20:58    [3034549]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
Чернышев Андрей Леонидович

Все операции, ###, давно раз и навсегда определены - не знать этого просто неприлично.

Простите, у Вас большой опыт УПРАВЛЕНИЯ предприятием?
По мне так - неприлично когда теоретик, не имеющий ПРАКТИЧЕСКОГО опыта начинает поучать других...
21 авг 06, 21:59    [3034665]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Нгдлф
Guest
iscrafm
Чернышев все пытается выдать за какое-то ноу-хау разноску проводок "на лету" по записям операций. Вариант безусловно имеет право на жизнь, но в строго оговоренных условиях.


Следствия из мыслей господина Чернышева поглобальней, на мой взгляд. В скольких таблицах хранить, какие производные понятия и расчеты хранить, а какие считать онлайн – это дело прикладно важное, но десятое. Дублирование плохо только тогда, когда им заведуют люди, во всех остальных случаях оно вводится (чаще по глупости, конечно, и сложности охвата комплексной модели) для ускорения, так как не место же на диске и в памяти экономим. Если имеется целостная модель данных, в которой однозначно известно, что из чего выводится и как, где все места объективных противоречий (типа того, что считать «фактом» учета – к примеру, факт материального складского учета, или факт учета операции бухгалтером после проверки принимаемости бумажной СФ налоговой, или оба сразу, но при определенных условиях, в определенном порядке) сняты, то все стыкуется, и автоотматывается, сторнируется, перематывается на произвольную глубину.
Короче, само по себе дублирование безобидно, если известно, что это за дублирование (не только программисту, его введшему). А в будущем – будет полезно, когда СУБД научатся произвольной длины транзакции произвольного содержания туда-сюда отматывать по надобности.

ModelR
Уже упомянутый НДС - брать или не брать его к зачету на основании данной счета-фактуры (у Вас тут подчистка! Да это клякса, грузчики грязными руками.. Или адрес написан не полностью, Или дата январская а форма=то пршлогодняя будем звонить поставщику - дату менять или форму. и т.д. ) ? Кто отвечает за это решение? - бухгалтер. А как это связано с количеством на складе? - никак. Поэтому вопрос где-то филофсофский.

Какие проблемы, можно же и деятельность ручного «бухгалтера», заканчивающуюся «утверждением» всей предыдущей истории по данному «факту» вплоть до полного его пересмотра, считать «операцией».
То есть я присоединяюсь к "вопрос философский", правильней сказать - организационный - как принято, как можно нагнуть конкретную организацию, в каких условиях она находится (к примеру, если организация не считает копейки, и вопрос имеет место только при крупных суммах НДС, то все документально не подтвержденное, не считается "фактом", а значит, никакого другого "факта", кроме факта бухгалтерского учета и нету).
Более серьезные "философские вопросы" возникают, когда имеется несколько противоречивых взглядов (у разных субъектов, подсистем ИС) на один и тот же "факт".
21 авг 06, 23:01    [3034795]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 19162
Чернышев Андрей Леонидович
Все операции, ###, давно раз и навсегда определены - не знать этого просто неприлично.

Возникновение налогооблагаемой базы по НДС и восстеновление его за последние пару лет менялись в деталях несколько раз, причем коренным образом.
Даже в казавшееся столь незыблемым ПБУ 6/01в конце прошлого года были внесены изменения, причем в самую существеннуб часть, а именно, в тот раздел, который описывает условия, при которых актив принимается к учету в качестве основного средства.
Как реально учитывать ПБУ 18/02, похоже, сам МИНФИН не знает.
А у Вас все определено раз и навсегда? LOL.

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

Еще напишу следующее:
1. В проводках не только синтетический учет. А в случае множества учетов в одной системе в одной рабочей БД - даже и не столько. В принципе, абсолютно все можно реализовать на основании плана счетов с подсчетом и контролем остатка по счетам, даже склад можно сделать без складов, поэтому, можно всегда идти от обратной задачи, то есть, изначально вводить все в проводках. Но так ведь никто не делает. Не задумывались, почему? Дело не просто в большом объеме вводимой информации. Дело в нецелесообразности иметь всю информацию для учета в первичных документах (что бы ни называлось первичным документом). Как раз это и будет избыточностью. Например, параметры складского учета задаются не для конкретной номенклатуры, а для группы ТМЦ. Но никто рядом с номенклатурой в документах не вводит дополнительно ее группу. Потому что ее всегда можно получить из номенклатурного справочника. Для параметров учета, которые могут неняться со временем, настраиваются различные "схемы", например, бессмысленно вводить счет хранения в каждом документе склада. но, по идее, для одной и той же номенклатуры/группы ТМЦ он может меняться. Что, делать поле в документе? Глупо. Поддерживать версионность всех без исключения полей во всех без исключения справочниках? Не менее глупо. Остается простое решение - счет хранения использовать в проводках, а обороты по нему считать по проводкам со всей необходимой аналитикой. Вот вам пример, когда целесообразно аналитику иметь только в проводках, и не иметь ее в документе (на самом деле, есть более хитрая реализация задачи учета версионности счета хранения). Еще пример - аналитика по местонахождениям, видам деятельности и пользователям основных средств (хотя, как правило, этой аналитики на порядок меньше).
2. Плюс от дублирования информации в проводках в требуемой части - перенос сальдированного остатка по счетам в объеме всей требующейся аналитики, если используется только входящее сальдо. Вам же, если Вы это захотите сделать, придется делать документ (операцию). Например, переоценка валютных счетов как у Вас происходит. Или у Вас нет таких операций? А еще, запросы отдельно к документу и отдельно к его проводкам не будут коррелировать, что позволяет реально снизить конкуренцию за блокировки таблиц в "нагруженных" системах.
3. У Вас документы имеют статус(ы)? Как, например, определить, что в УУ событие совершилось, а в БУ/НУ еще нет? Я, например, утверждаю документ, и только после этого можно утвердить проводки. Разутверждение - наоборот. Если в УУ событие отражено корректно, а в БУ некорректно (например, с ошибкой), то достаточно разутвердить только проводки, а сам документ не трогается. Потому вся цепочка документов остается. Или у Вас не бывает ошибок, которые обнаруживаются "потом"? Или у Вас нет цепочек документов?
4. Начальство скажет примерно следующее "Начиная с 1 января следующего года начинаем вести дополнительно учет по МСФО". А еще через год - "У нас появляется отделение в Эфиопии, поэтому будем вести учет и по ЭСФО, причем, для всего концерна, а не только для филиалов в Эфиопии". Полезете добавлять пачками поля в документ? А еще, если необходимо иметь отчетность в валюте N зарубежных филиалов, у всех стран которых различная валюта, будете делать N валют/сумм в документе? А такие вопросы в правильно спроектированных масштабируемых и настраиваемых системах решаются "на раз-два-три".
5. При использовании репликации во многих случаях для учета деятельности достаточно реплицировать проводку по документу, а не сам документ. При десятке тысяч документов даже между десятком филиалов траффик наэкономите значительно больше, чем стоит еще один диск и слот памяти.

В общем, я бы Ваше решение охарактеризовал как "наколенное". Если оно Вас и Ваших заказчиков устраивает - и слава богу.
22 авг 06, 11:00    [3036049]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Если что-то не так, то специалист (это и не бухгалтер, и не программист, конечно же) просто не введет (например) дату поступления счета, и зачет не сделается. Или введет, а потом исправит свою ошибку, и зачет автоматически отсторнируется.
Не понял. Специалист, отслеживающий законодательство, судебную практику и точку зрения своей инспекции по НДС, и отвечающий за правильное решение по конкретной СФ и есть бухгалтер.
22 авг 06, 11:26    [3036265]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Хорошо, ModelR, Вы правы - это бухгалтер.
22 авг 06, 19:00    [3039674]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Не сочиняйте, iscrafm, про "попытку выдать". И про "строго оговоренные ситуации". Если Вы под каждую "ситуацию" делаете "систему бухучета", то понятно откуда 100 проектов. Но подозреваю, что Вы так не делаете. А просто сочиняете, не обращая внимания на мои объяснения про объективные операции и "бухгалтерские проводки".

Я Вас, ###, совершенно не поучаю. А только сообщил об ошибке в Ваших рассуждениях. Серьезной ошибке.
22 авг 06, 19:06    [3039694]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Да, Сергей Васкецов, раз и навсегда. Вы путаете объективные операции движения (в том числе и налогов) с тем, что сам МИНФИН не знает.

А по Вашему "гибкость" - это учесть в другом "учете" (другой системе) то, что не предусмотрено в этом "учете" (этой системе), так как этот "учет" "негибкий", а тот "гибкий" ?

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

Безусловно, о Вас и Ваших клиентах, так же как и обо всех остальных и их клиентах, можно сказать то же самое - "и слава богу".
22 авг 06, 19:28    [3039776]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
Чернышев Андрей Леонидович
Я Вас, ###, совершенно не поучаю. А только сообщил об ошибке в Ваших рассуждениях. Серьезной ошибке.


Любезный, Вы либо опубликуйте свой "самый полный и нерасширяемый, определенный раз и навсегда" список операций, либо прекратите пороть чушь!
23 авг 06, 06:24    [3040736]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
А просто сочиняете, не обращая внимания на мои объяснения про объективные операции и "бухгалтерские проводки".

У Вас завышенная самооценка, если Вы считаете свои посты объяснением. Не обратили внимания, что Вас почему-то просят до сих пор все объясниться?
23 авг 06, 10:48    [3041632]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Это другое дело, iscrafm и ###. Приятно, что начали говорить по существу. Эти ваши соображения помогут лучше понять суть "операций" и "проводок", и наверняка помогут mr.vetal. А с общеизвестным (а не моим) "списком операций" он и сам ознакомится, когда захочет.
23 авг 06, 20:57    [3045768]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
LightNet
Member

Откуда:
Сообщений: 12
А мне вот по теме статья понравилась. Там, как мне кажется, говорится то, что Чернышев Андрей Леонидович м.б. недоговорил в данном топике.
24 авг 06, 15:26    [3048899]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Yulka
Member

Откуда:
Сообщений: 152
LightNet
А мне вот по теме статья понравилась. Там, как мне кажется, говорится то, что Чернышев Андрей Леонидович м.б. недоговорил в данном топике.


Да, действительно, статья тематическая, в правильном направлении мыслит товарищ
24 авг 06, 16:27    [3049318]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
LightNet
А мне вот по теме статья понравилась. Там, как мне кажется, говорится то, что Чернышев Андрей Леонидович м.б. недоговорил в данном топике.

И где Вы там увидели то, о чем не договоривает Чернышев А.Л.? Там показана типовая структура основных таблиц главной книги. Реально, процентов 99% систем там и строятся. Эта статья под разными авторами не первый год бродит по просторам интернета.
24 авг 06, 16:55    [3049466]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
LightNet
А мне вот по теме статья понравилась. Там, как мне кажется, говорится то, что Чернышев Андрей Леонидович м.б. недоговорил в данном топике.

Вы умеете читать мысли? Поделитесь соображениями, что же такого гениального крутится в голове у ЧАЛ'а и о чем он так упорно молчит?
Лично я как-то не нашел связи статьи (iscrafm прав - статья на уровне букваря) с его мыслями.
24 авг 06, 19:04    [3050130]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
В этой статье, LightNet, описана типичная бухгалтерская система: счет-проводка-аналитики. Такие системы быстро распространялись в конце 80-х начале 90-х годов (имеется в виду в России). Тогда соревнование шло в области "количества уровней аналитик" и возможности их "перестраиваемости". Когда "производственники" тоже захотели планировать, учитывать, контролировать, и обратились к "программистам бухгалтерий", выяснилось, что механизм счет-проводка-аналитики не годится для описания спецификаций, технологических операций, регистрации самих фактов выработки, расхода, упаковки продукции, распределения по транспортным единицам и т.п. Пришлось учитывать специфику реальных операций. Кто "в лоб" программировал, кто какие-то инструменты создавал. Но "бухучет" ведь уже "сделан" ! Значит давайте соединять эти разные системы, то есть передавать данные из объективных систем, в которых итак есть все "аналитики" (бессмысленный для корпоративных систем термин), в бухгалтерские системы.
Короче говоря, эта статья пересказывает идеи 25-летней давности, но содержит (относительно) современные термины (OLAP, материализованные представления, инкапсуляция необходимой логики в middleware-слое и т.п.). Так можно строить "бухгалтерские системы (их, собственно, всегда так и строили), но не корпоративные, включающие "бухучет". "Бухгалтерские проводки" - это просто механизм дополнительной индексации объективных операций, в которых содержится вся необходимая информация. Кроме того, как я уже говорил, "бухгалтеру" может понадобиться видеть в "отчете по счету" и примечание из ТТН, и номер автомобиля, и все что угодно. И именно "корпоративное проектирование бухучета" обеспечивает полную свободу не только всем остальным, но и бухгалтеру.
24 авг 06, 23:16    [3051017]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Предлагаю поговорить о погоде. В Киеве холодает...
25 авг 06, 02:17    [3051340]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович
"Бухгалтерские проводки" - это просто механизм дополнительной индексации объективных операций, в которых содержится вся необходимая информация. Кроме того, как я уже говорил, "бухгалтеру" может понадобиться видеть в "отчете по счету" и примечание из ТТН, и номер автомобиля, и все что угодно. И именно "корпоративное проектирование бухучета" обеспечивает полную свободу не только всем остальным, но и бухгалтеру.


тут почти все.

К сообщению приложен файл. Размер - 0Kb
25 авг 06, 02:28    [3051349]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
Чернышев Андрей Леонидович
В этой статье, LightNet, описана типичная бухгалтерская система: счет-проводка-аналитики. Такие системы быстро распространялись в конце 80-х начале 90-х годов (имеется в виду в России). Тогда соревнование шло в области "количества уровней аналитик" и возможности их "перестраиваемости".
А до конца 80-х на счетах считали?
Чернышев Андрей Леонидович
Когда "производственники" тоже захотели планировать, учитывать, контролировать,
А до этого не хотели? Или Вы описываете какое-то КОНКРЕТНОЕ предприятие? Могу привести контрпример, когда бухгалтерию автоматизировали АСУТП-шники...
Чернышев Андрей Леонидович
и обратились к "программистам бухгалтерий", выяснилось, что механизм счет-проводка-аналитики не годится для описания спецификаций, технологических операций, регистрации самих фактов выработки, расхода, упаковки продукции, распределения по транспортным единицам и т.п. Пришлось учитывать специфику реальных операций.
А вот здесь поподробней - что же такого порочного в сием механизме?
25 авг 06, 07:22    [3051468]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
gybson
Member

Откуда:
Сообщений: 1107
Механизм счетов-проводок не годится для: резервирование, планирование, CRM
25 авг 06, 08:23    [3051553]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
gybson
Механизм счетов-проводок не годится для: резервирование, планирование, CRM
А также для забивания гвоздей, рожания детей и т.д. и т.п....
Мы вроде как об УЧЕТЕ говорили?
25 авг 06, 08:35    [3051580]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
iscrafm
LightNet
А мне вот по теме статья понравилась. Там, как мне кажется, говорится то, что Чернышев Андрей Леонидович м.б. недоговорил в данном топике.

И где Вы там увидели то, о чем не договоривает Чернышев А.Л.? Там показана типовая структура основных таблиц главной книги. Реально, процентов 99% систем там и строятся. Эта статья под разными авторами не первый год бродит по просторам интернета.
99% это преувеличение. Многие западные и некоторые российские системы используют в качестве элементарной записи не структуру УчетнаяПозицияДт-УчетнаяПозицияКт-Сумма, предлагаемую в статье, а так называемые полупроводки УчетнаяПозиция-Сторона-Сумма.
25 авг 06, 10:55    [3052260]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Мимо пробегал...
Guest
2###
автор
...А вот здесь поподробней...
А вот этого он не умеет
25 авг 06, 11:37    [3052628]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
ModelR
так называемые полупроводки УчетнаяПозиция-Сторона-Сумма.

Я это во внимание не брал. Речь о том, что все равно - выделенная таблица проводок. В этом смысле 99%. Один процент оставил на гениальную идею Ч.А.Л., если когда-нибудь он о ней расскажет.
25 авг 06, 12:21    [3052970]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
iscrafm
Я это во внимание не брал. Речь о том, что все равно - выделенная таблица проводок. В этом смысле 99%. Один процент оставил на гениальную идею Ч.А.Л., если когда-нибудь он о ней расскажет.
судя по всему проводка у чал хранится в документе (точнее - в операции). операции разбиты по таблицам, в зависимости от их типов (т.е. от присущих им "аналитик"). Оборотка по счету, буде запрошена, подтягивает все таблицы операций, в которых могут встречаться проводки по счету. каковая "возможность" - зашита в жесткой схеме генерации проводок типом операции (и, возможно, контекстом операции). Т.е. нет выделенной таблицы проводок (подвязанной к обобщенной таблице операций или к множеству специализированных), а все проводки хранятся "непосредственно в (специализированных) операциях". При вводе нового типа (изменение законодательства) видимо генерируеца новая "операционная" таблица и новый "операционный" интерфейс (+ переписываются методы свертки обороток). Ну или автомат какой этим занимается (патипа "объектного нафигатора").
25 авг 06, 12:35    [3053104]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
gybson
Member

Откуда:
Сообщений: 1107

Мы вроде как об УЧЕТЕ говорили?


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

Счета - предназначены для группировки и текущего учета однородных хозяйственных операций; отдельный счет открывается на каждый вид хозяйственных средств и их источников; делятся на активные и пассивные счета в соответствии с делением баланса на актив и пассив.
Двойная запись - способ регистрации хозяйственных операций на счетах бухгалтерского учета; состоит в том, что сумма каждой хозяйственной операции одновременно записывается в дебет одного счета и в кредит другого.
25 авг 06, 13:25    [3053481]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
На ЕС ЭВМ, ###, некоторые, а большинство на калькуляторах.
Хотели, на ЕС ЭВМ, в пакетном режиме.
Все типы примеров мне известны.
Когда АСУТП-шники автоматизировали бухгалтерию, они, надеюсь, оставались инженерами.
Или у них "производственные системы" уже (!) строились на механизме счет-проводка-аналитика ? Будет время загляните в оригинальные (написанные до бухгалтерских) системы АСУТП-шников, и поищите там "счета" и "проводки".

Есть неточности в Ваших рассуждениях, 4321.
Законодательство, о котором Вы говорите, не может изменить объективное движение материи.
"Подтягивает все таблицы операций" и в случае хранения "проводок" в "отдельной таблице". К чему же об этом говорить ? Тем более, как Вы правильно намекнули ("нафигатор"), РСУБД с ее "таблицами" все равно нельзя использовать для "учетных систем" (если Вы помните, для этих СУБД вообще не нашлось примера подходящей задачи).
"+ переписываются методы свертки обороток" - ошибка - не переписывается ничто, связанное с "проводками", если вдруг откроется новый закон природы, и добавится новая операция.
25 авг 06, 14:37    [3054054]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
Чернышев Андрей Леонидович
Есть неточности в Ваших рассуждениях, 4321.
Законодательство, о котором Вы говорите, не может изменить объективное движение материи.
посвольте уточнить: вы так прямо все объективное движение материи и моделируете. во всех, так-скаать диталях?

давайте не вешать лапшу друг-другу на уши. телодвижения материи посредством законодательства возможно и не меняюцца, но количество параметров, требующих "учета" в системе - лихко.
Чернышев Андрей Леонидович
"Подтягивает все таблицы операций" и в случае хранения "проводок" в "отдельной таблице". К чему же об этом говорить ? Тем более, как Вы правильно намекнули ("нафигатор"), РСУБД с ее "таблицами" все равно нельзя использовать для "учетных систем" (если Вы помните, для этих СУБД вообще не нашлось примера подходящей задачи).
"+ переписываются методы свертки обороток" - ошибка - не переписывается ничто, связанное с "проводками", если вдруг откроется новый закон природы, и добавится новая операция.
ну так и разложите свои не табличные (нереляционные) объекты на обозрение. мы на них плюбуемса.

касательно "не переписываицца ничего" - так для _реляционной_ бд вынос отдельной таблицы проводок и обслуживает эту задачу - "не переписывания ничего" при смене количества учитываемых в модели параметров "движения материи".
25 авг 06, 15:10    [3054338]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
посвольте
диталях
меняюцца
лихко
плюбуемса

в 5 строках столько ошибок, это ж надо. Какие материи, какое законодательство.. Поговорим о правописании.

К сообщению приложен файл. Размер - 0Kb
25 авг 06, 15:18    [3054401]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
iscrafm
Поговорим о правописании.
помои му, в топеге за я в лена иная тема.
ви не находить?
25 авг 06, 15:50    [3054628]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Молодец, 4321, но "количество параметров учета" не добавляет, само по себе, "новую операцию". И меняется не легко, а в результате титанических усилий законодательных и исполнительных органов; но даже эти усилия не могут не то что разрушить, а даже легко повредить объективную реальность.
Я Вам "лапшу" никуда не вешаю, а Вы можете вешать что угодно, и куда угодно - это не изменит объективную реальность, но, конечно, сблизит Вас с правительством.

Вот именно, если бы еще при использовании РМД данные от кода не отделялись, то вообще не о чем было бы говорить.
25 авг 06, 16:26    [3054939]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
Чернышев Андрей Леонидович
"количество параметров учета" не добавляет, само по себе, "новую операцию". И меняется не легко, а в результате титанических усилий законодательных и исполнительных органов; но даже эти усилия не могут не то что разрушить, а даже легко повредить объективную реальность.
вот я и спрашиваю "ви уже смоделировали в своей приладе "обЪяхтифную риальнась" во всей ее полноте"? (ф силу чаго и пазваляете сибе надсмехацца над нами, неразумными реляционщиками) Или таки предпочитаете моделировать исключительно существенные для учета детали?

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

Ить для случая центральной (сквозной) таблички проводок - я, в крайнем случае, могу и руками (или настройками) добавить любые _новые_ проводки - и делов. А чито мы имеем в такофском случАе при ползовании объектными нафигаторами? помимо деклараций, есс-но.
25 авг 06, 17:32    [3055430]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вот это я Вам, 4321, и объяснял весьма подробно. А Вы продолжаете "вешать" про "в крайнем случае". В "операции" у Вас данных не будет, а в "проводке" будут. Например, сумма НДС (когда "кто-то", якобы "придумает" НДС). И долг перед поставщиком будет у всех не правильный, а у бухгалтера - правильный. Или стоимость товара. Или что-то еще. И после этого детского лепета про
"отдельную таблицу на крайний случай"
Вы хотите, чтобы я над Вами не смеялся ? Хорошо, я буду хмуриться.
25 авг 06, 20:27    [3056019]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 884
Андрей Леонидович, возьмите какой-нибудь гипотетический пример движения материи на предприятии и примените к нему Вашу модель с пояснениями.
Вы очень красиво излагаете, но очевидно, что никто так и не смог полностью понять что же имеется в виду. Расставьте все точки на "ты".
26 авг 06, 16:19    [3057249]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Что означает, Кифирчик:
"очень красиво" ?
"очевидно" ??
"никто" ???
"полностью" ????
Расшифруйте, пожалуйста, а лучше дайте ссылку на источник.
27 авг 06, 18:13    [3058729]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Или возьмите какой-нибудь гипотетический пример движения материи на предприятии и примените к нему Вашу модель с пояснениями.
Я здесь никаких моделей не предлагал, а только сообщил автору темы, что размещение "проводок" в "отдельной таблице" - плохое решение.
27 авг 06, 18:19    [3058733]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Мимо пробегал...
Guest
Что означает, Чернышев Андрей Леонидович:
"гипотетический пример" ?
"движения материи" ??
"применение модели с пояснениями" ???
"плохое решение" ????
Расшифруйте, пожалуйста, а лучше дайте ссылку на источник.

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

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

ЧАЛ
РСУБД с ее "таблицами" все равно нельзя использовать для "учетных систем" (если Вы помните, для этих СУБД вообще не нашлось примера подходящей задачи).
Одиозный Вы наш, вы опять свои НЛП-фокусы начали? Откуда же ему это помнить то? Не было такого! а если хотите доказать, что было - напомните, "расшифруйте пожалуйста, а лучше дайте ссылку на источник".

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

...Кстати о кино. Почемубы Вам, ЧАЛ, в ваших терзаниях не занятся кинематографом? Нафига эти БД? Приходит клиент, а Вы ему вместо накладной видеопленочку с записью того, как ему товар запаковывали и отгужали. Приходит налоговая - а Вы ей пленочку с очередью у кассы выдачи зарплаты и крупным планом все выдаваемые купюры. Прикиньте ЧАЛ, ведь это самое, что ни на есть прямое отражение объективной реальности. Тогда не то что записи в рел. БД - тогда даже объектный нафигатор не потребуется. Дя что там объектный нафигатор! Вообще все все компьютеры выбросит можно... да и бумажки тоже!! На пленке то ведь все видно - кому чего отдали, у кого что взяли и, поэтому, бумажки не нужны. Вот оно где настоящее отображение объективной действительности то - в кинокамере!!! Не там копаете, ЧАЛ.
27 авг 06, 19:19    [3058783]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

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

Вам нужно поднатужиться. А то получится то же, что и с РМД и "Р"СУБД, для которых никому так и не удалось ни придумать ни одной подходящей задачи, ни даже объяснить смысл этих "технологий" (из-за отсутствия их формального описания), как Вы помните.

Если же Вы хотите, чтобы "настоящие специалисты" обсудили вопрос "операции/проводки" без меня, то так прямо и скажите, засекреченный Вы наш.
27 авг 06, 20:16    [3058851]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Наверное я слишком резок; все-таки должен признать, что в идеях Кифирчика и Мимо пробегал по вопросу хранения "бухгалтерских проводок" в БД для mr.vetal найдется что-то интересное.
27 авг 06, 20:29    [3058870]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Мимо пробегал...
Guest
ЧАЛ не пытайтесь выдать желаемое за действительное. Я с Вами ни о не спорю. Опыт показывает, что спор с вами быстро выливается в маразм. К сожалениев Ваших фразах отсутсвует причинно-следственные связи, что делает их похожими на бесконечные первомайские лозунги. Попытки понять Ваши слова (полностью или частично) не приносят результата. Точно также я мог бы спорить с кошкой, с флюгером или с радио.

ЧАЛ
...чтобы "настоящие специалисты" обсудили вопрос "операции/проводки" без меня...
...ЧАЛ, Вы конечно меня не поймете, но Вы весь в этой фразе. Кроме Вас здесь ,конечно же, остануться только "настоящии специалисты", Вы же, единственно, светоч и гонимый носитель истины.
27 авг 06, 20:49    [3058890]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович
Наверное я слишком резок; все-таки должен признать, что в идеях Кифирчика и Мимо пробегал по вопросу хранения "бухгалтерских проводок" в БД для mr.vetal найдется что-то интересное.


Да уж. Кто вас укусил?
ЕСли есть что сказать, то скажите. Зачем ругаться?
Идея хранить свойства объекта компактно - отличная.Но, в той среде, где есть простой доступ ко всему этому делу.
Вы работаете как наемник, или на себя?
28 авг 06, 00:44    [3059131]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Сахават, мнимая компактность.
Есть операция
Отгружен товар покупателю, на сумму 100р, НДС18%... Зачем дополнительная таблица, думает Андрей Леонидович. Дебиторы в колонке Сумма отгрузки, НДС в колонке НДС, здесь же, в документе (операции). Разноска давно определена. Все прекрасно. Перебирай документы и строй баланс.
28 авг 06, 01:08    [3059150]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Yulka
Member

Откуда:
Сообщений: 152
iscrafm
Сахават, мнимая компактность.
Есть операция
Отгружен товар покупателю, на сумму 100р, НДС18%... Зачем дополнительная таблица, думает Андрей Леонидович. Дебиторы в колонке Сумма отгрузки, НДС в колонке НДС, здесь же, в документе (операции). Разноска давно определена. Все прекрасно. Перебирай документы и строй баланс.


Валер, мне объясните, пожалуйста, я не понимаю. Я, понятно, не про проводки, и не про НДС. И даже не про "хранить свойства компактно", так как это не принципиально, как хранить, если ресурсы позволяют, так как оперативность важней, то часто вычислимые термы лучше дополнительно хранить. Главно знать (не человеку, а системе), что это одно и то же, и что из чего, и желательно, автоматом отслеживать, что это одно и то же. То есть это вопрос - исключительно вопрос переноса ВСЕЙ целостности на СУБД.
28 авг 06, 14:15    [3061295]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Юля, то что это одно и тоже прошивается в таком случае в логике программы. На бытовом уровне это выглядит как:
НДС > поле P1 в операции А1, поле Р5 в операции А4 и т.п.
Появляется новая операция(документ), для нее делается подобное описание.
Вынос главной книги в отдельную таблицу выполняется не от "плохого проектирования". Причины обычно более приземленные. Во-первых, как Вы говорите, хранение заранее подготовленных данных. Во-вторых в современных гетерогенных системах front-end для главной книги может быть самым различным и имплементация проводок непосредственно по операциям превращается в хороший гемморой. В-третьих, структура ГК наверное самая незыблемая вешь в информационной системе, тогда как формат операций может меняться и очень часто. В общем много причин для того, чтобы ГК выделять в отдельное хранилище. Ч.А.Л напирает на то, что бух. видит какие-то другие данные в отличие от менеджера, который вводит в систему ту же информацию об отгрузках. А вот это уже действительно проблема проектирования системы. Такого быть просто не должно. Для этого существуют процедуры постинга (разноски, проведения). Учтенная в системе транзакция выглядит одинаково для всех.
28 авг 06, 14:54    [3061543]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Yulka
iscrafm
Сахават, мнимая компактность.
Есть операция
Отгружен товар покупателю, на сумму 100р, НДС18%... Зачем дополнительная таблица, думает Андрей Леонидович. Дебиторы в колонке Сумма отгрузки, НДС в колонке НДС, здесь же, в документе (операции). Разноска давно определена. Все прекрасно. Перебирай документы и строй баланс.


Валер, мне объясните, пожалуйста, я не понимаю. Я, понятно, не про проводки, и не про НДС. И даже не про "хранить свойства компактно", так как это не принципиально, как хранить, если ресурсы позволяют, так как оперативность важней, то часто вычислимые термы лучше дополнительно хранить. Главно знать (не человеку, а системе), что это одно и то же, и что из чего, и желательно, автоматом отслеживать, что это одно и то же. То есть это вопрос - исключительно вопрос переноса ВСЕЙ целостности на СУБД.
Вот вся беда, что не одно и тоже. Решения, принимаемые бухгалтером, не вычислимы (не всегда вычислимы) из оперативных данных.
28 авг 06, 17:25    [3062530]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Жаль, что не хотите говорить по существу, Мимо пробегал, и продолжаете секретничать. Бегите дальше.

Сахават Юсифов, про "простой доступ ко всему этому делу" здесь уже все знают, и многих это почему-то задевает. Все данные предоставляются пользователю непосредственно, прикладные интерфейсы практически не программируются и т.д. Но это не относится к теме "операции"/"проводки".

Да, iscrafm, возможно удастся добиться полного исключения "проводок". Примерно так, как Вы это представляете: построили "аналитический отчет" и "вписали" в него на последнием этапе "балансовые счета".
И вдруг какой-то невероятный новый аргумент в пользу "отдельных таблиц". Теперь "главная книга", а уже не "проводки" (сумма, дата, кредитуемый счет, дебетуемый счет - что, конечно, бессмысленно хранить в "отдельной таблице"). Но ключевой аспект: "современные гетерогенные системы" ! Вот-вот: "бухгалтерия" ведь уже "написана". Давайте теперь связывать разные системы. Пошли по кругу. Я же Вам сказал, что рассуждаю исключительно в рамках идеи корпоративной системы, и как раз с "операциями" и "проводками" все очень просто решается. А Вы опять (сначала об этом говорил Сахават Юсифов) про геморрой. Не получается построить корпоративную систему на предприятии, поэтому у нас будет "современная гетерогенная система", а поэтому у нас будут отдельные таблицы (теперь уже несколько - и для "проводок", и для "главной книги", и, видимо, для "второстепенных книг"). Если "система" уже отдельная, то ясно, что и ее "таблицы" тоже отдельные. Ну и замечательно. Если не получается, что же тут поделаешь. Вам, наверное, будет полезен специализированный продукт, сами знаете какой, как раз для "современных гетерогенных систем".

Мы, вроде, о данных говорили, ModelR, а не о решениях. Здесь уже пробовали приводить примеры, когда данных нет в "операции", но они (практически это просто сумма) есть в "проводке". Тоже пошли по кругу. Бухгалтер не должен учитывать то, чего нет. "Решения" "вычислимы".
28 авг 06, 21:42    [3063528]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Да, и еще один аргумент, весьма распространенный, от iscrafm. Чтобы не пропадала "бухгалтерия", пусть это теперь будет (по современному !) хранилище данных. Наверное отсюда неожиданная подмена "проводок" (которые еще могут измениться) на "главную книгу" (закрыли месяц, и записали в хранилище "главную книгу").
28 авг 06, 21:55    [3063541]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Да, iscrafm, возможно удастся добиться полного исключения "проводок". Примерно так, как Вы это представляете: построили "аналитический отчет" и "вписали" в него на последнием этапе "балансовые счета".
И вдруг какой-то невероятный новый аргумент в пользу "отдельных таблиц". Теперь "главная книга", а уже не "проводки"

Под главной книгой имеется ввиду журнал проводок. Строить корпоративные системы получается. Вы бы постарались более четко мысли излагать. И выходите наверх из своей теплицы. Дальше без комментариев. Чтобы понять что Вы имеете ввиду, нужно принять. Я сейчас не в духе для этого.
28 авг 06, 21:56    [3063544]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Отлично, значит "главная книга" - это та же "отдельная таблица проводок" в рамках "корпоративной системы". Неожиданно быстро отпали оба аргумента: "современные гетерогенные системы" и "хранилище данных".
28 авг 06, 22:07    [3063565]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Читайте внимательный. Никакие аргументы не отпадают. Пока отпадает вся Ваша теория. Вы кстати знаете, что такое аргументы Андрей Леонидович? Это когда словарный запас хоть как-то подтверждается мыслью. Задумайтесь над этим.

p.s. Давно хотел сказать, все времени не было.
Если предприятие выпускает продукцию в упаковках (короба, рулоны и т.п.), то система позволяет тут же сгенерировать этикетку с уникальным штрихкодом, что существенно упрощает отслеживать дальнейшее движение упаковок по предприятию. Данная функция важна для предприятий, которые желают получить сертификат ISO 900x, требующий наличие прозрачности в материальном учете.

С ISO разберитесь на сайте, который у Вас в почте указан.
28 авг 06, 23:22    [3063705]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Мы, вроде, о данных говорили, ModelR, а не о решениях.
Данные суть воплощенные решения.
Чернышев Андрей Леонидович
Здесь уже пробовали приводить примеры, когда данных нет в "операции", но они (практически это просто сумма) есть в "проводке". Тоже пошли по кругу. Бухгалтер не должен учитывать то, чего нет. [quot Чернышев Андрей Леонидович]"Решения" "вычислимы".
Дык, никто не должен учитывать чего нет. Только область компетенции у каждого своя, поэтому для любого чего-то нет, хоть оно и есть.
Чернышев Андрей Леонидович
"Решения" "вычислимы".
ну да, при привлечении должного решателя и дополнительной информации (например, реальной формы данного документа и требований законодательства к оной форме). А только по оперативным данным - нет.
29 авг 06, 19:35    [3068512]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
То, что я глупый, и мыслей у меня нет для подтверждения словарного запаса - это не новость. Но вернемся, хотя надежд уже совсем не осталось, к "операциям" и "проводкам". Новая гипотеза: на сайте, где рассказано про ISO900х, с которым Вы разобрались, а я (конечно же !) нет, написано почему именно (видимо это предписано ISO) "проводки" должны храниться в "отдельных таблицах" ! Ваши аргументы, iscrafm, становятся все глобальнее, и, что особенно радует, подтверждаются мыслью.
Ну а главный аргумент просто великолепен: "проводки" нужно хранить в "отдельной таблице", так как "вся моя теория" (что за "теория" такая ?) отпадает !
29 авг 06, 20:48    [3068695]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Здесь мы с Вами, ModelR, расходимся. Вы говорите "нет", а я говорю "да". Никаких "собственных данных" ("сумм"), никому другому не нужных, у бухгалтера не может быть. То есть то, как строят системы многие участники этого спора, конечно, приводит (может приводить) к "чисто бухгалтерским данным". Но это ошибка. Серьезная. И ни одного примера, показывающего что это не ошибка, никто привести не сможет.
29 авг 06, 20:52    [3068705]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
То, что я глупый, и мыслей у меня нет для подтверждения словарного запаса - это не новость. Но вернемся, хотя надежд уже совсем не осталось, к "операциям" и "проводкам". Новая гипотеза: на сайте, где рассказано про ISO900х, с которым Вы разобрались, а я (конечно же !) нет, написано почему именно (видимо это предписано ISO) "проводки" должны храниться в "отдельных таблицах" ! Ваши аргументы, iscrafm, становятся все глобальнее, и, что особенно радует, подтверждаются мыслью.
Ну а главный аргумент просто великолепен: "проводки" нужно хранить в "отдельной таблице", так как "вся моя теория" (что за "теория" такая ?) отпадает !

хе-хе. Надежд действительно не осталось. Вы так и не смогли внятно выразить свою мысль :( Набор слов...
29 авг 06, 21:06    [3068738]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Даже не сомневался! Это общепринятая точка зрения, и самое надежное и беспроигрышное объяснение для mr.vetal почему "проводки" должны быть в "отдельных таблицах".
29 авг 06, 21:17    [3068766]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Ну Вы же не хотите убедить своих собеседников в том, что отсутствие выделенной таблицы с проводками работоспособно во всех случаях. Я Вам привел примеры, для чего и в каких ситуация проводки выносятся в отдельную таблицу. Да, и я тоже иногда не утруждаю себя отдельной таблицей, но возможно это в крайне ограниченном числе случаев. Приведите свои аргументы, объясните, почему Вы считаете что аргументы оппонентов не выдерживают критики и люди к Вам понянутся. Не стесняйтесь.
29 авг 06, 21:55    [3068828]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович
Здесь мы с Вами, ModelR, расходимся. Вы говорите "нет", а я говорю "да". Никаких "собственных данных" ("сумм"), никому другому не нужных, у бухгалтера не может быть. То есть то, как строят системы многие участники этого спора, конечно, приводит (может приводить) к "чисто бухгалтерским данным". Но это ошибка. Серьезная. И ни одного примера, показывающего что это не ошибка, никто привести не сможет.


Андрей, вы сталкивались с "реформация баланса"?
29 авг 06, 22:54    [3068953]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Я, не стесняясь, ответил на Ваши примеры, как и на все остальные. Они не выдержали моей критики, и люди ко мне (подавляющее большинство) не потянутся. И я по этому поводу не переживаю. Один потянется - и хорошо. Теория и проектирование баз данных достаточно сложная область. Все, что я говорю, не является мимолетной идеей или мимолетной личной точкой зрения. Это результаты многолетних исследований. И теоретических, и экспериментальных. И мне это уже мало интересно - пройденный этап. Большинство (но не все) "аргументы оппонентов" не "не выдерживают критики", а уже давно не выдержали критики. Но я же сказал - экспериментируйте на здоровье, размещайте "проводки" где угодно !
29 авг 06, 23:09    [3068984]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Липа, Сахават. Вы для "реформации баланса" сделаете "просто проводку" Кр 60 Дт 10 ? Или Кр 60 Дт 19 ? Или Кр 51 Дт 60 ? Или Кр 19 Дт 68 ? Это те четыре проводки по трем операциям (оприходование, оплата, зачет налогов), которые мы рассматривали. Так что на Ваш скрытый аргумент я отвечаю так же, как и отвечал. Должна быть четко определена типовая операция, по которой автоматически делаются бухгалтерские проводки. Хоть "в рамках" производства или сбыта, хоть "в рамках" "реформации баланса".
29 авг 06, 23:26    [3069011]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Чернышев Андрей Леонидович
Липа, Сахават. Вы для "реформации баланса" сделаете "просто проводку" Кр 60 Дт 10 ? Или Кр 60 Дт 19 ? Или Кр 51 Дт 60 ? Или Кр 19 Дт 68 ? Это те четыре проводки по трем операциям (оприходование, оплата, зачет налогов), которые мы рассматривали. Так что на Ваш скрытый аргумент я отвечаю так же, как и отвечал. Должна быть четко определена типовая операция, по которой автоматически делаются бухгалтерские проводки. Хоть "в рамках" производства или сбыта, хоть "в рамках" "реформации баланса".


Хорошо, оставим реформацию в покое.
Формально нет никакой разницы между (дХХ,кХХ) и (дХХ,кХХ1,дХХ1,...,кХХN,дХХN,кХХ). Это трогает только валюту баланса (легко отключается). А операций надо описать тъма.
Например 68 до факта оплаты стараются держать на 76. Хоть и глупо!
30 авг 06, 00:39    [3069101]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Никаких "собственных данных" ("сумм"), никому другому не нужных, у бухгалтера не может быть.
Управленческая информация:
СтруктураСклада (Ячейка, СкладГдеНаходится) КЛЮЧ (Ячейка)
РазмещениеТовара(Ячейка, Товар,Количество) КЛЮЧ (Ячейка, Товар)

Бухгалтерская информация:
Остатки (Счет, Товар, Склад, Количество, Сумма) КЛЮЧ (Счет, Товар,Склад )

В чем мысль? Упразднить Остатки и добавить Счет к РазмещениеТовара?
А складу нужны эти счета? А бухгалтеру ячейки?
30 авг 06, 10:25    [3069717]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Должна быть четко определена типовая операция, по которой автоматически делаются бухгалтерские проводки.

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

Чернышев Андрей Леонидович
Большинство (но не все) "аргументы оппонентов" не "не выдерживают критики", а уже давно не выдержали критики. Но я же сказал - экспериментируйте на здоровье, размещайте "проводки" где угодно !

Да здесь никто, кроме Вас пожалуй, не экспериментирует. Речь идет о реалиях, а не об опытах. А Вы просто пытаетесь с умным видом приторговывать воздухом. Проектирование информационных систем действительно очень сложная область. Кроме многолетних исследований Вам не помешало бы хоть немного практики в различных условиях.
30 авг 06, 10:37    [3069779]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 19162
Чернышев Андрей Леонидович
Я, не стесняясь, ответил на Ваши примеры, как и на все остальные

Видимо, очень стеснялся, когда отвечал. Продолжаю стоять в сторонке и ждать, но надежд на осмысленные ответы остается все меньше.
30 авг 06, 12:24    [3070431]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Операций, Сахават, не "тьма", а очень мало. И "отгруженный НДС" легко "держится" на 76 в рамках одной операции реализации. Не следует думать, что на каждую "сумму" для "проводки" нужна "операция". Все операции объективны - они не подстраиваются под "бухгалтерский учет".
30 авг 06, 22:11    [3073966]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Мы говорим об "операциях" и "проводках", ModelR, а не об "остатках" и "размещениях".
30 авг 06, 22:27    [3073991]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Опять сочиняете, iscrafm. ЭТО у Вас не работает, и не скоро заработает. У Вас проводки бессмысленно хранятся в "отдельной таблице". У меня они тоже так хранились, когда я был начинающим проектировщиком БД. Еще бы не хватало, чтобы в проводках были бы какие-то "суммы", отсутствующие в операциях - я уже давно понял, что у Вас, в отличие от Сахавата Юсифова, этого нет; уже хорошо.
Никакие изменения в "типовых операциях" не требуют никаких "изощренных механизмов", не выдумывайте. Формирование и удаление "проводок" во всех отношениях эффективнее когда "проводки" хранятся в "операции". Это факт. Но Вам об этом неизвествно, так как у Вас "реалии", Вам некогда. Я Вас понимаю, и сочувствую.
Но не отвлекайтесь от сути - Вы так и не объяснили, как Вам удалось определить, что "проводки" нужно хранить в "отдельной таблице". Хотите вернуться к аргументу "современных гетерогенных систем" (значит у Вас несколько систем, среди которых есть "бухгалтерская") ? Или к "бухгалтеркой системе" как "хранилищу данных" ? Или придумаете что-то еще ?
Ну а то, что у меня не только ума нет, но и практики - это уже давно "установлено". У Вас практика, конечно, есть, а у меня, конечно, нет и быть не может. Хороший аргумент в пользу хранения "проводок" в "отдельной таблице".
30 авг 06, 22:53    [3074057]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Насколько я понял новый аргумент Сергея Васкецова - "проводки" должны "стоять в сторонке и ждать", и для этого их следует хранить в "отдельной таблице". Неплохо.
30 авг 06, 22:59    [3074075]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Андрей Леонидович, наверное достаточно балагана, даже он надоедает. Ответьте хоть на один заданный вопрос (давайте на этот: что происходит с проводками прошлых периодов если изменить типовую операцию) или не отвечайте вообще.
На досуге почитайте документацию одной из моих систем, чтобы удостовериться что вынесение проводок в отдельную таблицу работает. Появится желание говорить по существу, пишите. Не появится - до свидания, на всякий случай.
30 авг 06, 23:20    [3074125]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Мимо пробегал...
Guest
Вот ведь баламут Ну ведь все переврёт, лишь бы выпутатся.
Поэтому еще один бесплатный совет ведения дискуссии с ЧАЛобразными (если у Вас уж нет мочи молчать). Надо быть предельно точными и не допускать фраз, которые могли бы перевраны или переиначены ЧАЛом - в чем он БОЛЬШОЙ искустник. В качестве примера возьмем последнюю реплику Сергея Васкецова
Сергей Васкецов
Чернышев Андрей Леонидович
Я, не стесняясь, ответил на Ваши примеры, как и на все остальные
Видимо, очень стеснялся, когда отвечал. Продолжаю стоять в сторонке и ждать, но надежд на осмысленные ответы остается все меньше.
Запомните! в споре с ЧАЛом недопустимы предложения с подразумевающимся подлежащим - потому что ЧАЛ сразу же начнет подразумевать их, как ему угодно.

Ответ ЧАЛа
Насколько я понял новый аргумент Сергея Васкецова - "проводки" должны "стоять в сторонке и ждать", и для этого их следует хранить в "отдельной таблице". Неплохо

Надо писать как можно более определнно! На месте Сергея Васкецова надо было написать так

правильная формулировка
Видимо ЧАЛ, Вы очень стеснялись, когда отвечали мне на мой последний вопрос. Однако Я продолжаю стоять в сторонке и жду от Вас ответа, но надежд на Ваши осмысленные ответы остается все меньше.
Тут ему уже никуда не деться.....и он просто не ответит .

....

Как обычно....Вот ведь уже со всех сторон его в дерьмо посадили и в ушах дерьмо? и в глазах, и в носу, и во рту тоже дерьмо. Другой бы отмываться убежал бы, а он всё "тьфу-тьфу" - отплёвывается.....

....

Специально для ЧАЛа - эта моя реплика не является аргуметов по обсуждаемой теме. Просто мне ОЧЕНЬ не нравится манера перевирать чужие фразы.
30 авг 06, 23:36    [3074158]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Это что еще один аргумент, iscrafm ? "Потому что работает" ??? Это же много лет у всех работает. И у меня тоже работало (несколько раз повторил !). Как Вы пришли к выводу, что это работает ЛУЧШЕ ? Я знаю, что это работает хуже, а Вы не знаете, потому что Вам "некогда экспериментировать".
Не "наверное достаточно", а прекратите, пожалуйста, балаган. Теперь Вы перескочили от вопроса хранения "проводок" (отдельно или в "операции") к вопросу "типовых операций". Понятно, что под "типовыми операциями" Вы что-то свое понимаете, и под их "изменениями" тоже. Все работает корректно при любых изменениях чего угодно в любых периодах, и это не имеет никакого отношения к способу хранению "проводок". А у Вас что не корректно что-то работает ? Я не сомневаюсь, что корректно. А Вы, значит, сомневаетесь, что у меня что-то работает ? Наверное это логично. Ведь Вы умный и с хорошей практикой, а я глупый, без практики, да еще весь в дерьме. Правильно ?
31 авг 06, 00:54    [3074275]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
А Вы, Мимо пробегал, не перевирайте чужие фразы, раз Вам не нревится Ваша манера перевирать чужие фразы.
31 авг 06, 00:57    [3074280]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
2 Мимо пробегал...
-----------------
Видимо Ваш рецепт все таки не дает 100% гарантии :) И Вас зацепило. В сети есть бот (и не один), его манера отвечать вопросом на вопрос или вообще не отвечать, а просто перефразировать собеседника. Иногда общением с таким полумозгом доставляет удовольствие, ради смеха, но быстро надоедает. Интересно общаться с интеллектом, а не бизнес-процессом. Поведение и манера общения того, кто скрывается под ником "Чернышев Андрей Леонидович" очень напоминает стиль общения ботов. Вы правильно заметили, нельзя им задавать вопросы, которые не поддаются алгоритмической расшифровке, ответят видоизмененными же вопросом. Следует заметить, что среди известных мне ботов, ЧАЛ самый несообразительный и скучный. Мне дочь в ICQ показывала куда более интересные и остроумные экземпляры.
31 авг 06, 01:17    [3074295]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Вы немного заблуждаетесь по поводу "хранения бух проводок в таблицах". "Бух проводка" - это всего лишь еще один способ индексации БД. Вряд ли разумно хранить индексы в отдельных таблицах (объектах) от тех таблиц (объектов), которые индексируются. Хранение проводок в "отдельной таблице" - это традиционный и очень плохой вариант. Проводки нужны просто для индексации операций.
Конкретика моей задачи - эффективная корпоративная БД. Проводки - просто индексация операций. Хранение проводок в "отдельной таблице" плохое решение, через которое я, разумеется, проходил...
Я .. уже прошел через "сущность "проводка" просто обязана быть." Не обязана. Более того - это просто ошибка (неоправданная нормализация), так как "проводка" используется просто для дополнительной индексации БД.
Вы храните операции в одной "таблице", а проводки - в другой. А я храню по-другому. В соответсвии с "сущностью бухгалтерского учета" и "сущностью хозяйственной операции".
мы регистрируем в БД "факты хозяйственной жизни" вовсе без "бухгалтерского учета". А "кредиты" и "дебеты" "счетов" просто обязаны получаться автоматически, чтобы еще и "бухгалтерам" было приятно. И именно это (кредит,дебет,сумма,дата) и является собственно бухгалтерской проводкой, так как все остальное неизбежно регистрируется в БД не из "бухгалтерских" побуждений, а из желания как можно объективнее представить в БД объективное движение материи.
За три приема добрался до того, что бухгалтеры больше не смогут делать бухгалтерские проводки (полный автомат), и больше не будут описывать типовые проводки (этого удалось давно, и это очень важно). Возможно последним шагом будет полный отказ от "проводок". Чтобы закончить "конкретику": дата и сумма, конечно, из операции. Да, в операции могут быть "бухгалтерские", "управленческие", "налоговые" даты и суммы - это не меняет сути дела (к тому же ВСЕ эти прилагательные к учету, как мы помним, субъективны). Что же остается "своего" в "проводке" ? Кредитуемый и дебетуемый "счета" ? Это ради них люди сооружают "отдельные таблицы", и "тащат" туда даты, суммы, и что-то еще из объективных операций (тоже ведь денормализация - дублирование)? Несложный анализ показывает, что это плохое архитектурное решение.
Думаю, что важной причиной недостатков "корпоративных систем" является подверженность проектировщиков влиянию прилагательных "бухгалтерский", "управленческий", "производственный" и др. к концепции "учета". То же самое можно сказать и о "планировании".
Парадоксально, но многие специализированные "учетные системы" (платформы), например, 1с, плохо приспособлены даже для бухгатерского (!) учета именно по той причине, о которой я сказал.
Для "аналитического учета" не нужно никаких проводок в принципе, даже "основных". Но для этого именно в операциях должны присутсвовать все данные. В частности, для "аналитического учета" по поставщикам, или, как Вы сказали "для ведения", но не 10-го, а активно-пассивного (или пассивного, если использовать 61) 60-го не достаточно Вашей "основной проводки". Получается не целостная картина. Далее: зачет налогов - это тоже операция, которая порождается автоматически при выполнении некоторых условий (конечно, не просто в связи с оплатой, но эта Ваша неточность не принципиальна), и используется в аналитических отчетах безо всяких проводок. И по этой операции делаются проводки, как и по операции оприходования.
"Почему не надо держать другие проводки в теле операции ?" - мне кажется не корректной постановкой вопроса. Правильнее объяснить себе почему суммы налога нет в операции, почему вообще нет операции зачета налога, и т.п. я против прилагательных к слову "учет", но "синтетический" и "аналитический" учеты (то есть то, что под ними традиционно понимается) намного лучше сосуществуют при размещении "проводок" в операциях, и т.д. Мне кажется Ваши решения концептуально не ориентированы на корпоративный уровень.
И еще раз повторю - надеюсь, что от проводок удастся избавиться полностью.
Теория и проектирование баз данных достаточно сложная область. Все, что я говорю, не является мимолетной идеей или мимолетной личной точкой зрения. Это результаты многолетних исследований. И теоретических, и экспериментальных. И мне это уже мало интересно - пройденный этап.
Формирование и удаление "проводок" во всех отношениях эффективнее когда "проводки" хранятся в "операции". Это факт.
31 авг 06, 01:47    [3074307]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
гм. пмсм, нет большой дразницы. "хранить проводки только в операции" - означает хранить где-то "[мета]"информацию о том, что те или иные поля операции - и есть проводка. Т.е. вы либо храните (централизовано или опять таки через одно место) информацию, о том, из каких полей каких таблиц (для реляционщиков) вы выбираете обороты по счетам (те самые "проводки"), либо храните сами проводки таким централизованным способом (т.е. - в отдельной табле). при этом ить можно "операции" орагнизовать скажем "звиздой" а в проводке хранить ссылку на центральную таблу звезды. таким образом, "проводка" является "частью" операции (подчиненная запись), вроде бы даже нет избыточности (нет необходимости в "операции" дублировать поля "проводки"), а с другой стороны - нет надобности хранить "[мета]"-информацию - она уже зашита в структуру "операция"<->"проводка".
31 авг 06, 11:59    [3075804]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
4321, здесь ключевое слово "хранить". Без разницы как. В иерархической БД - поднаборе, в реляционной - в отдельной таблице и т.д. и т.п. Если "не хранить", то вопрос соответствия одному из припципов бухучета (хронологичность) остается открытым. На него упорно Ч.А.Л. не хочет отвечать.
31 авг 06, 12:56    [3076286]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Мы говорим об "операциях" и "проводках", ModelR, а не об "остатках" и "размещениях".
Ммда.. Действительно, и какая между ними связь :).
31 авг 06, 13:02    [3076347]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3995
Резюме.
1. "Как и где хранить проводки?" - не суть важно, зависить от инструментов.
2. "Нужно ли формировать проводки в операциях(докуметах) или надо их генерировать по запросу" - нужно формировать в операциях(докментах) или в сурогаттных документах, потому что бухгалтерский учет по сути против расчетного восстановления фактов. Т.е. нельзя отказаться от проводок (пока существует ПБУ и отчетность в сегоднящнем виде).
3. Себестоимость, отнесение расходов на будущие/прошлые периоды, износ ОС, компенсационные счета, промежуточные счета (для ведения аналитики на синтетических счетах) и т.д. - плохо формализованы. Что то надо пересмотреть, а что то запретить.

Андрей любит темнит. Я тоже. Например, в алгоритмах МЕС. Но это другое дело. А в буховских делах нечего скрывать. Как он сам говорил, "усе тривиально" (если запретить изпользование одного и того же уровня дерева счетов и для синтеза, и для анализа и неконтролируемое создание транзитных счетов).
31 авг 06, 13:16    [3076477]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Сахават Юсифов
бухгалтерский учет по сути против расчетного восстановления фактов.

однозначно.

Сахават Юсифов
Андрей любит темнит

я бы сказал "увиливает"
31 авг 06, 13:28    [3076601]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
alvao
Member

Откуда:
Сообщений: 52
2 Чернышев А.Л.
В механизме "вычисления" проводок на основании хозяйственных операций, по поему мнению, есть недостаток, проявляющийся при изменении учётной политики, или при изменении статуса компании, например, компания стала проф. участником рынка ЦБ. Соответственно, одни и те же хозяйственные операции (продажа ЦБ) отражаются разными способами (до даты "Ч" через 91 счет, после - 90). Т.е. усложняется механизм, который описывает правила вычисления проводок (Дебет, Кредит, Сумма).

Касательно первоначального вопроса "Хранить ДебетКредитСумма в виде одной строки или двух строк". Удобнее хранить в виде Счет+Сумма, связав две записи идентификатором "транзакции" ("проводки"). Упрощяется процесс получения остатков/оборотов по счету. А также решается "проблема" вычисления корреспондирующего счета.
31 авг 06, 16:05    [3077780]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
iscrafm

Сахават Юсифов
Андрей любит темнит

я бы сказал "увиливает"

Напрасно мечете бисер...
Чернышев Андрей Леонидович
РСУБД с ее "таблицами" все равно нельзя использовать для "учетных систем" (если Вы помните, для этих СУБД вообще не нашлось примера подходящей задачи).

Чернышев Андрей Леонидович
Вот именно, если бы еще при использовании РМД данные от кода не отделялись, то вообще не о чем было бы говорить.

Чернышев Андрей Леонидович
А то получится то же, что и с РМД и "Р"СУБД, для которых никому так и не удалось ни придумать ни одной подходящей задачи, ни даже объяснить смысл этих "технологий" (из-за отсутствия их формального описания), как Вы помните

Ну и т.д.
Вот это тема, на которую ЧАЛ готов говорить без устали...
А Вы с ним про учетные системы... Да не знает он про них ни чего!!!
Вот ежели бы про "крах РМД"...
31 авг 06, 19:28    [3079063]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Очевидная избыточность, 4321, хоть со "звездой", хоть без. Причем бесполезная. А хранить "массу" в "операции" - означает хранить где-то "метаинформацию", что те или иные поля операции - и есть "масса". С этим не поспоришь.

Упорно отвечаю, iscrafm (то есть упорно считаю Вас порядочным человеком, списывая Ваше хамство на традиции sql.ru), что хранение "проводок" в "отдельной таблице" (с бесполезным дублированием дат и сумм, и бесполезной поддержкой "связей" по ключам) или в "операции" никак не связано с "одним из принципов бухучета". И не следует оправдывать Ваши ошибки (возникающие из-за объективной нехватки времени для исследований) моим "упорным молчанием". Хотите обсудить тему "хронологичности" ? Я не против - открывайте, обсудим.

Ваша ирония, ModelR, не вполне мне понятна. Но могу заметить, что хранение "проводок" с "операциями" вполне симметрично хранению "счетов" с материалами и складами. Тем не менее, способы хранения "остатков" не зависят от способов хранения "проводок", и наоборот.

Странное резюме, Сахават.
1. "Ничего не важно !" - зависит от инструментов. Так же тоже можно сказать, правда ?
2. Вот и iscrafm сказал "однозначно". Нет в проводках собственных данных. Но он же тащит дату из операции в каждую из 18 проводок, и 18 сумм тоже тащит. А Вы говорите "не важно".
3. Мы - не правительство.
В чем я "темню" ? Честно сказал, что создание и поддержка "отдельной таблицы" и "связей" с другими "таблицами" ради хранения кредитуемых и дебетуемых "счетов" - серьезная ошибка. А Вы говорите "темню".

Нет, alvao, механизм не усложняется, он учитывает "изменение учетной политики" так же примитивно, как и "изменение плана счетов", например.
Про хранение проводок Вы заблуждаетесь, видимо на Вас влияет несуществующая "проблема" вычисления корреспондирующего счета. В результате Вы храните проводки еще хуже, чем iscrafm.

Аргумент ### какой-то избитый, хотя и выглядит оригинально: "проводки" нужно хранить в "отдельной таблице", потому что ЧАЛ ничего не знает про учетные системы. Это сильнее, чем "нет практики" от iscrafm, но значительно слабее, чем "весь в дерьме" от Мимо пробегал, или "полумозг" от того же iscrafm.
31 авг 06, 23:27    [3079520]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович

Вот и iscrafm сказал "однозначно". Нет в проводках собственных данных. Но он же тащит дату из операции в каждую из 18 проводок, и 18 сумм тоже тащит.

Я сказал "однозначно" по другому поводу. Никто даты в записи проводок не "тащит". Для примера как работают отдельные таблицы проводок я Вам даже фильм снял, 25 кадров в секунду, реальное время. Немного усложнил задачу. Я сейчас в славном городе Киев, в районе под названием Подол. Сервер в клипе находится в Москве, проспект Мира. Данные за три года. Много. Прибавьте немного времени на доступ через интернет. Как не странно, "ошибочно спроектированные" системы и базы работают. Удивительно, да?
Собственно фильм.
1 сен 06, 00:20    [3079607]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Не удивительно, iscrafm, уже много раз повторил. Конечно, ошибочные решения тоже работают! Итак, даты в проводке нет, а есть только сумма из операции и два счета. Вы помещаете их зачем-то в отдельную таблицу, и радуетесь, что работает. Я же три раза повторил - правильно делаете; обязательно нужно пройти через размещение проводок в отдельной таблице.
А "однозначно" по "другому поводу", оказывается ? То есть в "проводках" Ваших есть данные (суммы), которых нет в операциях (Вы не просто "тащите" данные из операции, а рассчитываете новые данные по данным из операции) ? Это уже цирк, а не кино.
1 сен 06, 01:00    [3079669]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Не удивительно, iscrafm, уже много раз повторил. Конечно, ошибочные решения тоже работают! Итак, даты в проводке нет, а есть только сумма из операции и два счета. Вы помещаете их зачем-то в отдельную таблицу, и радуетесь, что работает. Я же три раза повторил - правильно делаете; обязательно нужно пройти через размещение проводок в отдельной таблице.
А "однозначно" по "другому поводу", оказывается ? То есть в "проводках" Ваших есть данные (суммы), которых нет в операциях (Вы не просто "тащите" данные из операции, а рассчитываете новые данные по данным из операции) ? Это уже цирк, а не кино.

Я не радуюсь, я зарабатываю :) Цирком можно назвать только то, что Вы до сих пор не ответили ни на один вопрос. Вы возомнили себе "гениальную" конструкцию и тешите себя этой мыслью. Ну-ну :) Я Вам уже говорил, что я тоже делаю в редких случаях то, чем Вы так гордитесь, в качестве превью.
А еще я храню в разных таблицах заголовки и спецификации накладных, описание проектов и деревья работ, текты договоров и план-графики работ по ним. Еще документы (операции) иногда архивируются, а отчетность бухгалтерская формируется. В общем кошмар. Выходите из танка уже, не гоже гениям сидеть в засаде.
1 сен 06, 01:17    [3079686]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
ps. Держите Андрей Леонидович еще небольшой ролик (чтобы Вы не сильно уж расстраивались по поводу "ошибочных систем") с проводками которые 1) (о чудо!) не хранятся в отдельной таблице и 2) которые хранятся вообще в другой СУБД пристыкованной внешней системы.

Собственно ролик :)
1 сен 06, 01:41    [3079703]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
###
Напрасно мечете бисер...

Меня это не напрягает :) Всегда была интересна психология. Но на всякий случай "до свидания" я уже сказал :)
1 сен 06, 02:16    [3079727]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
gybson
Member

Откуда:
Сообщений: 1107
С первым сентября. Что Вы как в детском саде то? Все давно знают, что реляционная структура ни на бумаге ни на сервере не обязана в точности отражать предмет. При определенных условиях можно даже хранить пол строки в одном поле, а другую в другом, who cares?
1 сен 06, 08:35    [3079883]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
gybson
С первым сентября. Что Вы как в детском саде то? Все давно знают, что реляционная структура ни на бумаге ни на сервере не обязана в точности отражать предмет. При определенных условиях можно даже хранить пол строки в одном поле, а другую в другом, who cares?

Вы просто не поняли о чем здесь разговор идет. То о чем Вы говорите выяснили и закрепили в первых сообщениях этого топика.
1 сен 06, 09:59    [3080188]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Честно сказал, что создание и поддержка "отдельной таблицы" и "связей" с другими "таблицами" ради хранения кредитуемых и дебетуемых "счетов" - серьезная ошибка.
И как же ее исправить-то в описанной ситуации для данных 150 единиц:

Управленческая, оперативная информация:
СтруктураСклада (Ячейка, СкладГдеНаходится) КЛЮЧ (Ячейка)

РазмещениеТовара(Ячейка, Товар,Количество) КЛЮЧ (Ячейка, Товар)
Я10, Т1, 100
Я11, Т1, 50

Бухгалтерская информация:
Остатки (Счет, Товар, Склад, Количество, Сумма) КЛЮЧ (Счет, Товар,Склад )
10/1, Т1, C05, 70
10/2, Т1, C05, 80

звиняйте за назойливость.
1 сен 06, 11:25    [3080908]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
Чернышев Андрей Леонидович
Очевидная избыточность, 4321
???
а можно по сущ-ву? или так и останемся на уровне декла'какций?
Чернышев Андрей Леонидович
А хранить "массу" в "операции" - означает хранить где-то "метаинформацию", что те или иные поля операции - и есть "масса". С этим не поспоришь.
а кито спорит. просто есть примитивное соображение - хранить "мета"информацию, о том, что конкретное поле _одной_ таблицы - есть масса - выгоднее, чем хранить такую же (мета)инфу, что перечень полей ааа.ххх - яяя.zzz таблиц {ааа-яяя} - есть масса. Кстати сказать, как правило, при столь простом устр-ве бд, эта инфа зашита в код (т.е. нет нужды _запрашивать_ в БеДе эту метаинфу - что попросту элементарно выгодно). если мы даже добавим некие "новые операции" с массой, масса в ней будет представлена _уже_ ранее определенным полем таблицы, о котором система уже "знает" , что это - масса. и уже умеет с ней работать, не перезапрашивая метаинфу в настроешных таблах.
1 сен 06, 11:31    [3080966]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
alvao
Member

Откуда:
Сообщений: 52
Чернышев Андрей Леонидович
Не удивительно, iscrafm, уже много раз повторил. Конечно, ошибочные решения тоже работают! Итак, даты в проводке нет, а есть только сумма из операции и два счета. Вы помещаете их зачем-то в отдельную таблицу, и радуетесь, что работает. Я же три раза повторил - правильно делаете; обязательно нужно пройти через размещение проводок в отдельной таблице.

Неужто по КАЖДОЙ операции формируется ТОЛЬКО одна проводка (ДебетКредитСумма)? Или у Вас НЕреляционная СУБД?
1 сен 06, 13:33    [3082031]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
alvao
Или у Вас НЕреляционная СУБД?

CACHE + MMS

2 Андрей Леонидович
-------
Зачем при при инсталляции (ИКС) лезть в стандартные шрифты и параметры сети? Установил на свою голову. Пришлось долго и упорно Windows XP после этого лечить. Лучше бы этим вопросом озаботились.
1 сен 06, 16:02    [3083369]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы хотите опять вернуться к идее "современных гетерогенных систем", так как не получается сделать "бухгалтерский учет" в "не бухгалтерской системе", iscrafm ? То есть не получается построить систему на корпоративной БД ? А говорили, что получается.
Чем же Вас привлекло хранение сумм из операций и счетов в "отдельной таблице проводок" ?
Итак, ДАТ В "ТАБЛИЦЕ ПРОВОДОК" НЕТ. Следовательно, чтобы сделать отчет по счету, например, 43, за период с 20.07 по 15.08, и показать в нем для каждой операции ее специфические данные (для выработки - номер смены, для отгрузки - номер автомобиля и т.п.), Вы будете обращаться к "таблицам операций" ? А не к тем "таблицам за три года", которые Вы "обрабатывали" в первой серии Вашего фильма ?
2 сен 06, 00:53    [3085072]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Да я не против назойливости, ModelR. Но Вы опять про "остатки". Приведите в точности "этот же" пример для "операций" и "проводок", а не для "остатков" и "счетов".
И потом, чем "склад" лучше "ячейки". Почему Вы провели "линию интересов" именно так ? Ну лежит товар часть в одной комнате, часть - в другой. Это логистику, менеджеру может и интересно, а бухгалтеру зачем ? И наоборот, почему Вы "прячете" от менеджера "сумму", а от бухгалтера "ячейки" ? А если это просто один человек ?
Но вернемся, все-таки, к теме "операции" и "проводки", пожалуйста...
2 сен 06, 01:05    [3085102]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
А я всегда "по сущ-ву" говорю, 4321. Но если Вы этого существа не замечаете, что же тут поделаешь ? Дата "операции" и суммы из "операции" у Вас в "таблице проводок" есть или нет ?
Хорошо про "метаинформации". Но хранение "проводок" в "операции" ничем не отличается от хранения "массы" в "операции".
2 сен 06, 01:20    [3085138]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Про СУБД давайте не будем, alvao. Здесь уже все знают "про СУБД". На предыдущей странице ### меня уже "упрекнул" за упоминание СУБД.
2 сен 06, 01:22    [3085144]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Нет, iscrafm, у нас вопрос - "операции" и "проводки".
2 сен 06, 01:23    [3085146]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Нет, iscrafm, у нас вопрос - "операции" и "проводки".

А сколько можно его мусолить. Я Вам привел живые примеры 3-х вариантов представления проводок, в том числе и без хранения в отдельной таблице. Что еще интересует?
2 сен 06, 11:40    [3085442]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
А Вы не мусольте. Ни одного примера хранения проводок Вы не привели (Вы привели интерфейсы пользовательские). Вы мусолите, а я конкретику из этого извлекаю. Вот она:

Итак, есть отдельная от операций "таблица проводок", причем ДАТ В "ТАБЛИЦЕ ПРОВОДОК" НЕТ. Следовательно, чтобы сделать отчет по счету, например, 43, за период с 20.07 по 15.08, и показать в нем для каждой операции ее специфические данные (для выработки - номер смены, для отгрузки - номер автомобиля и т.п.), Вы будете обращаться к "таблицам операций" ? А не к тем "таблицам за три года", которые Вы "обрабатывали" в первой серии Вашего фильма ?

Что Вы сделаете известно. Обведете в квадратик какое-нибудь предложение на свой вкус, и начнете отвлеченно "мусолить", но никогда не скажете зачем Вы повторно хранените суммы из операций в "отдельной таблице", но при этом дату оставляете в операции.
2 сен 06, 14:41    [3085742]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Андрей Леонидович, Вы же профессионал. Неужели тяжело разложить UI в с структуру?
3 сен 06, 00:38    [3086254]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Мимо пробегал...
Guest
Мысль #1
ЧАЛ в принципе идея то ясная. Храним данные об хозяйственных операциях, в операциях ставим галочку "учтено" и проставляем дату учета. Каждому типу хоз.операции однозначно соовествует фиксированный набор проводок, что дает возможность строить при необходимости проводки по операциям а не хранить их отдельно. Если все так - вай нот?

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

Конечно же это называется "бардак в конторе". Более того, я подозреваю, что если бы была нормальная система, то этого бардака возможно бы и не было, Но цель таких контор - работа и торговля и т.п. на автоматизацию они смотрят далеко не в первую очередь. И возможно , с их точки зрения это не бардак, а "гибкость".

Мысль#2
ЧАЛ, хочу отметить, что все системы автоматизации учета есть именно то, что сказанно "автоматизации учета". Другими словами учет - т.е описание хозяйтсвенной деятельности человека, существовал задолго до компьютеров. Еще раз повторю -учет - это описание хозяйтсвенной деятельности человека, описание того, что сделали и, по сути, некая модель. Если Вы внимательно читалли всякую литературу по БД и по моделированию, то должны были обратить внимание на то, что одна и та же предметная область может моделироваться по разному и с разными урованями абстракции. Так фот бухгалтерсий учте и оперативный учет - это разные абстракции, и разные модели, которые (еще раз повторю) появились задолго до компьютеров. Я не вижу, что в ближайшее время эти модели перестанут быть актуальными.

Насколько я смог Вас понять (может я не так понял, но что поделать, если Вы объяснят не умеете, а тока "каверзные" вопросы задаете), что бухгатерские данные могут быть получены из оперативных данных и нефига их хранить отдельно. Одноко для этого требуется самая малость , а именно - что бы бух. данные однозначно выводились из данных оперативного учета ( иначе данные бухгалтерии должны храниться, а не выводиться - потому что возможны случаи, когда их просто не из чего вывести).

ЧАЛ, честно - мне за мою недолгую карьеру такие однозначные предприятия не попадалось. Хотя, видимо, к этому надо стремиться.
3 сен 06, 12:16    [3086489]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Хорошо, iscrafm, на этом ("разложении UI в структуру") и закончим, чтобы не мусолить.

Спасибо, Мимо пробегал, за конструктивные мысли.
Мысль #1. Здесь мне сказать нечего. Это не бардак, и не гибкость. Это отказ от учета в принципе.
Мысль #2. Конкретизирую. Вы храните "бухгалтерские проводки" отдельно от "объективных операций", так как в них содержатся данные, которых нет в операциях. Приведите хотя бы один пример. Пока это никому не удалось, и можно сделать, прямо противоположный Вашему, вывод: "не однозначных предприятий" не существует.
3 сен 06, 20:18    [3086969]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Мимо пробегал...
Guest
ну что сказать.

ЧАЛ
....Это не бардак, и не гибкость. Это отказ от учета в принципе....Приведите хотя бы один пример...
.Алё, это был пример из жизни. Более того ,это был пример белого и очень законопослушного предприятия вполне успешно выдерживающего всякие налоговые проверки и внешние аудиты. И именно поэтому я бы не сказал, что там прямо так и не было учета. Проблема в том, что там было много разных и не связанных между собой учетов (хотя каждый из них сам по себе был вролне даже ничего).

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

В общем как обычно - истина где то посередине.
4 сен 06, 13:47    [3089367]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Да я не против назойливости, ModelR. Но Вы опять про "остатки". Приведите в точности "этот же" пример для "операций" и "проводок", а не для "остатков" и "счетов".
Замените имена таблиц и добавьте реквизиты Основание, Дата. Для целей топика достаточно.
Чернышев Андрей Леонидович

И потом, чем "склад" лучше "ячейки". Почему Вы провели "линию интересов" именно так ?
Каждый занят своим делом - корпоративная система однако.
Чернышев Андрей Леонидович
Ну лежит товар часть в одной комнате, часть - в другой. Это логистику, менеджеру может и интересно, а бухгалтеру зачем ?
Ну!
Чернышев Андрей Леонидович

И наоборот, почему Вы "прячете" от менеджера "сумму", а от бухгалтера "ячейки" ? А если это просто один человек ?
И все помещается в EXCEL.:)

Т.е. предлагается заставить и бухгалтера и склад перечислять товары и по счетам и по ячейкам.
Сомневаюсь я...
4 сен 06, 15:54    [3090267]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
alvao
Member

Откуда:
Сообщений: 52
Чернышев Андрей Леонидович
Про СУБД давайте не будем, alvao. Здесь уже все знают "про СУБД". На предыдущей странице ### меня уже "упрекнул" за упоминание СУБД.


Давайте рассматривать сферического коня в вакууме :-) Однако, Андрей Леонидович, для того чтобы "эффективно" хранить "проводки" прямо в "операции" мне придётся отказаться от использования MS SQL... Возможно, в случае использования Cache и эффективна Ваша модель данных...
4 сен 06, 19:50    [3091650]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы-то, конечно, не сказали бы, Мимо пробегал. Но учета нет, это очевидно, если Вы про пример из #1. Не учли очевидный факт. Нет учета.
А где же пример из жизни по #2 ? Когда в "операции" данных нет, а в "проводке" по этой "операции" данные вдруг появляются ? Опять общие рассуждения о том, что бухгалтер имеет право разрушить учет на предприятии и/или вести свой личный учет.

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

Не понял, alvao, при чем здесь Cache, MS SQL и "конь" ? Если Вы имеете в виду, что РМД (которую не поддерживают ни MS SQL, ни Cache) не позволяет хранить "проводки" в "операции", то это не так. РМД не накладывает никаких ограничений на типы.
4 сен 06, 21:44    [3091906]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Нет, ModelR...
Пример есть, контрпримера нет, выходит Да.
5 сен 06, 17:25    [3096049]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Мимо пробегал...
Guest
ЧАЛ
Но учета нет, это очевидно, если Вы про пример из #1
АГА. это в Вашем ЧАЛ понимании учета нет (и я понимаю, о чём Вы говорите). Но в понимании бухгалтера этой организации, который над каждой бумажкой дрожит, учет есть. В понимании налоговых инспекторов и аудитов учет тоже есть, потому как эта контора успешно и законно выдерживает проверки. Конечно находятся мелкие нарушения , начисляются кой-какие налоговые штрафы, куда без этого - но в целом ОК. Иностранные хозяева тоже довольны. Честно говоря, я еще более честной (белой и пушистой) конторы не встречал..... у них даже ПО и то - всё законно купленное =) Они - заказчики и под них надо подстаиваться. А если я, увидев такую картину, заявлю "да у вас учета нет" и "давайте главбух не будет иметь доступа к проводкам" я подозреваю, что они пошлют на китайский остров Х*й, тем самым продемонстрировав, что несмотря на принципиальную невозможность примера #2 опять же я Вас понимаю - например можно применять к хозяйственным операциям разные схемы учета да еще с параметрами, и указывать в операции вместе с датой учета схему учета (вместо того, что бы хранить проводки), он все таки побеждает :). Вот и решайте - либо благородные принципы(не спорю - они правда благородные), либо пивка с хорошей закусью. Такой вот я беспринципный.:)

автор
Рабочие, мастера, кладовщики и др. работники регистрируют операции. А проводки делаются автоматически
...идеальный мир... но тогда я вообще не понимаю о чем спор. Если Вы за то ратуете, что бы проводки аффтоматом делались, так оно так уже давно и есть. Взять например тот же Navision - в нем, если всё правильно настроить, рУками в проводки вообще лазить не надо. Они сами генеряться по учету всех операций.... пользователю же наплевать, храняться или вычисляются. Ну а что б кто-нить "бухгалтерию не спортил" надо таблицу от ручного редактирования закрыть и всё. Не вижу проблемы.
5 сен 06, 20:10    [3096688]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Мимо пробегал...
Не вижу проблемы.

Проблема глубже. У Андрея Леонидовича
Чернышев Андрей Леонидович
Даже "типовые проводки" не нужно описывать

т.е. тупо в скриптах каше все записано под типовые формы документов. Дешево и сердито, а главное никому не нужная экономия.
5 сен 06, 21:19    [3096807]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Рад за Navision, Мимо пробегал. Но в программном коде и Axapta, и Navision, и (прошу прощения за непатриотизм) 1с после "тщательных настроек" я встречал буквально счета, то есть данные. Большего кошмара трудно себе представить. Тем не менее я тоже не вижу никаких проблем. Хранить "проводки" в "отдельной таблице" - плохое решение, но оно работает. Разве я говорил, что есть какие-то проблемы ?
А кто у нас "принципный" ? Правители сказали, например: "а теперь два износа будете начислять", и все будут начислять как миленькие. Скажут три, все будут три начислять. Они правители, и под них надо подстраиваться. А то пошлют на остров по-настоящему. Здесь я Вас понимаю. Не будем забывать, что страх и безропотность - это русская национальная идея.
Но Вы подменяете один вопрос другим. Конечно же, бухгалтер может выполнить нужную его предприятию операцию (назовем ее "бухгалтерской"). Но это должна быть формализованная (для его же удобства) операция, по которой так же автоматически делаются проводки. Не понимаю о каком "идеальном мире" Вы говорите.
5 сен 06, 21:21    [3096810]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
###
Member

Откуда:
Сообщений: 571
Чернышев Андрей Леонидович
...
Они правители, и под них надо подстраиваться. А то пошлют на остров по-настоящему. Здесь я Вас понимаю. Не будем забывать, что страх и безропотность - это русская национальная идея.
....

Это называется законопослушание, бунтарь Вы наш...
5 сен 06, 21:30    [3096826]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
А как же, ###. Еще лучше - мудрость !
5 сен 06, 21:52    [3096848]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Андрей Леонидович, будьте мудрым. Откройте уже тайну, как Вы там в глобалях что храните и насколько это универсально для всех СУБД. Или уже давайте говорить в привязке к платформе. Так просто будет намного интересней.
6 сен 06, 00:52    [3097076]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
DmitryOrlov
Member

Откуда: Москва
Сообщений: 730
О, не бросайте такой интересный топик. Зачитался:)

Насколько я правильно понял (с учетом узости взгляда и шаблонности мышления),
Андрей Леонидович, предлагает каждый документ считать операцией или по-другому, каждая операция оформляется своим документом.
Например, купили материал, оформили документ оприходования на склад,
это операция Дт10-Кт60
Выделили НДС, для этого у нас служит запись - счет-фактура, в теле документа
операция Дт19 - Кт60
Зачли НДС, для этого существует документ - запись в книгу покупок, операция
Дт68-Кт19
и т.д.
Если хорошенько подумать, то все должно оформляться документами и, вероятно,
нет такой операции, которая не имеет основы в виде документа.
Из этого можно сделать вывод, что вынесение проводок в отдельную таблицу, наглядный пример лени разработчиков, которые не хотят анализировать и описывать все связи между документами и т.д.
Хотя может я и не прав и здесь скрывается какая-то страшная тайна. А кто ее узнает, сам виноват:)
13 сен 06, 01:58    [3127243]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321ё
Guest
DmitryOrlov
каждый документ считать операцией или по-другому, каждая операция оформляется своим документом.
...
Если хорошенько подумать, то все должно оформляться документами и, вероятно,
нет такой операции, которая не имеет основы в виде документа.
...
Из этого можно(????) сделать вывод, что вынесение проводок в отдельную таблицу, наглядный пример лени разработчиков, которые не хотят анализировать и описывать все связи между документами и т.д.
Хотя может я и не прав и здесь скрывается какая-то страшная тайна. А кто ее узнает, сам виноват:)
странная логика, не находите? мысел о документ-проводка вер-но пральная, но...
вот токо этта ваша правильная мысль хорошо моделируется _в_РБД_ снизкой таблиц-документов нанизанной на единую таблицу проводок (1-1), без дублирования значащих для проводки полей в полях таблиц-документов. что, в неком смысле, отвечает идее вынесения абстракции "проводка" в отдельную сучность, что и соответсвует принципу самого бух-учета (документ - всего лишь основание, проводка - собственно учет). т.е. таки никаких проблем с организацией проводок в сквозную таблицу нет, даже при "не слишком ленивой" разработке. Вопрос лишь в том, что ЧАЛ пользует не реляционную модель, а там, вполне вероятно, _удобнее_ (но не суть, что _единственно правильно_) пользовать какие-то внутренние структурки, а не сквозную структуру-сущность, связанную со всеми типами документов.

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

правда есть еще и всякие сопутствующие задачи. например - предоставить модель учета, при которой степень детализации уже произведенного учета может быть изменена потсфактум (после занесения проводки и без ее изменения). Это когда к готовой (т.е. "замороженной") "главной проводке" цепляются произвольное количество детализаций по "разрезам аналитики". что-то подобное видел в RS-Balance (и тут отсылка к статье напомнила). Так вот там, пожалуй, _удобнее_ этот механизм наворачивать вокруг одной (единой) таблицы проводок, а не вокруг сонмища, содержащих нечто общее. Я не готов утверждать, что задача уж столь актуальна, но спрос на нее кажется есть.
13 сен 06, 11:27    [3128576]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

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

Так что для меня система таблиц документов без таблицы проводок (полупроводок) не подходит (хотя идея очень хорошая). Обязательно когдато нада будет чтото "подчистить" без документа.
13 сен 06, 13:06    [3129488]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
DmitryOrlov
Member

Откуда: Москва
Сообщений: 730
mr.vetal
Обязательно когдато нада будет чтото "подчистить" без документа.

Есть такой документ - бухгалтерская справка. Он полностью синтетический, имхо. Но на основании этого документа делаются проводки по корректировке той или иной ситуации.
13 сен 06, 20:01    [3132699]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы заблуждаетесь, mr.vetal, не обратив внимания ни на 3091906 (второй абзац), ни на 3096810 (последний абзац).
Хранение "проводок" в "отдельной таблице" - плохое решение, независимо от модели данных.

Но дело не в лени, я думаю, DmitryOrlov, а во времени. Требуется довольно кропотливая работа, в том числе исследовательская. Быстрее "залепить" "бухгалтерский учет" по традиционной схеме.
13 сен 06, 22:13    [3133035]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
На основании "бухгалтерской справки" не должна делаться "просто проводка", например, по счету 10. Это разрушит целостность корпоративных данных.
mr.vetal вынужден смириться с тем, что на его предприятии пока невозможно создание корпоративной системы. Из-за отсутствия элементарной корпоративной культуры.
13 сен 06, 22:22    [3133055]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Вопрос для Андрея Леонидовича

Вы используете для каждого типа документов отдельные таблицы, или одни и те же (для реквизитов, табличной части, и т.д.) ?
13 сен 06, 23:26    [3133180]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Ответ для mr.vetal. Я "таблицы" не использую. Я использую теорию баз данных и правила пректирования баз данных, и нахожу оптимальный "баланс" между так называемой "нормализацией" и так называемой "денормализацией".
Иногда разные "типы документов" попадают в одну, пользуясь из уважения к Вам Вашей терминологией, "таблицу", иногда - в разные "таблицы". Иногда я ошибаюсь. И я Вам привел пример такой ошибки. Я разместил "проводки" в отдельной "таблице". Потом пришлось эту ошибку исправлять.
13 сен 06, 23:57    [3133245]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ScaleFactor
Member

Откуда: 4 часа полета от столицы
Сообщений: 64
Чернышев Андрей Леонидович
Я "таблицы" не использую. Я использую теорию баз данных и правила пректирования баз данных ...


Да уж, понятия "таблица" и "теория БД" вещи принципиально несовместимые :)
14 сен 06, 05:49    [3133440]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Я разместил "проводки" в отдельной "таблице".
Повторяюсь, но официальные документы не дают определения проводки. Какой состав информации того, что у Вас названо проводкой? Например
Проводка - это такая запись
(Дата,Счет БУ, Сторона счета, <список аналитических разрезов>, Основание, Валюта, Сумма), что данная сумма неделима для целей учета.
14 сен 06, 10:14    [3134062]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
ModelR
Какой состав информации того, что у Вас названо проводкой?

Нет у него нифига. Исследования.
14 сен 06, 11:23    [3134571]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Я вот щас пытаюсь понять

Чернышев Андрей Леонидович
Иногда разные "типы документов" попадают в одну .. "таблицу", иногда - в разные "таблицы". Иногда я ошибаюсь.


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

Чтото я не уловлю логику :(
14 сен 06, 17:50    [3138255]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Чернышев Андрей Леонидович
Я "таблицы" не использую. Я использую теорию баз данных и правила пректирования баз данных, и нахожу оптимальный "баланс" между так называемой "нормализацией" и так называемой "денормализацией"


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

Когда вы говорите, что уже не используете таблици, Вы конечно же желаете подчеркнуть что Вы испльзуете не только таблици, но и представления, функции, процедуры, правильно строите индексы, связи между таблицами, и т.п. А так же Вы правильно строите логику базы таким образом, чтоб максимально учесть правила нормализации ???
Или Вы просто не используете таблицы? :)
14 сен 06, 18:04    [3138343]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Интересный вопрос, ModelR, после того, как не менее пяти (!) раз было ясно сказано, что к объективной операции просто добавляются "кредитуемые и дебетуемые счета" (суммы и даты не говоря уже об "участниках" регистрируемых событий, которых Вы, видимо традиционно по-бухгалтерски, называете "аналитиками", уже есть в операции (связаны с операцией)). iscrafm близок к истине: "нет у меня нифига". Ведь "проводка" - это просто еще одна индексация операции. Действительно, до "нифига" остался один шаг (это я повторяю, заметьте, в третий раз, но мне и до десятого не лень дотянуть, если кто-то желает искренне что-то понять).
14 сен 06, 21:12    [3139003]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Поразительно, mr.vetal, как можно "не уловить логику" в предложении:

Иногда разные "типы документов" попадают в одну, ... "таблицу", иногда - в разные "таблицы".

"ТТН" и "Акт ... выполненных работ" по вполне понятным причинам могут попасть в одну "таблицу" (хотя это разные "типы"). А "Накладная на перемещение" вполне может в эту "таблицу" не попасть. Очень странные у Вас "вопросы".

"Если бы вырос сад, я бы сказал сад, но поскольку выросло дерево - зачем же мне врать ?"
Я просто не использую "таблицы". Использование "таблиц" было бы значительно более серьезной (я бы сказал - роковой) ошибкой, чем размещение "проводок" в отдельной "таблице". Конкретнее, чем я сказал, не представляю как можно сказать. Если Вы преподаете основы баз данных, то просто обязаны знать и понимать общую теорию и технологии баз данных (помимо частной "реляционной теории"; впрочем я пока не встречал человека, который понимал бы эту "самую распространенную" "реляционную теорию"). Тем более, что на сегодняшний день существует только одна целостная технология баз данных, и никаких "таблиц" в ней нет. Постепенно, в течение 30 лет, по мере эволюции SQL в процедурный язык "реляционная теория" приближается к статусу "технологии баз данных". Но из-за принципиального отсутствия идентификации, навигации и семантики ей никогда не суждено стать "технологией баз данных".
Однако это не значит, что "проводки" нужно размещать в "отдельной таблице". Я уже несколько раз повторял, что это ошибочное решение независимо от модели данных.
14 сен 06, 21:33    [3139035]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
2 Чернышев Андрей ЛеонидовичЯ не спрашивал, какая часть информации проводки уже есть в других объектах БД. Мне интересно знать, что в Вашем понимании есть проводка как нравственннная категория. На бумаге или в БД не важно.
Например, 4321ё развил идею о вычислимости еще дальше, но чтобы все это обсуждать нужно же определение обсуждаемого предмета. Или нет?
15 сен 06, 09:40    [3139916]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович

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

Бездоказательные утверждения в народе называют по-простому: демагогия.
15 сен 06, 12:31    [3141519]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
если хранить данные не в таблицах, то где их хранить ????
15 сен 06, 15:12    [3143123]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
mr.vetal
Member

Откуда:
Сообщений: 373
Кто еще из уважаемой общественности хранит данные не в таблицах ?

С ув. Виталий
15 сен 06, 15:13    [3143130]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
mr.vetal
если хранить данные не в таблицах, то где их хранить ????

1. На бумаге
2. В СУБД, в которой нет понятия таблицы
3. В голове, в качестве фантазий
15 сен 06, 15:30    [3143271]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
mr.vetal
Кто еще из уважаемой общественности хранит данные не в таблицах ?

С ув. Виталий
Дык, до сих пор где-то там спецы поCOBOL в ходу.
15 сен 06, 17:42    [3144219]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Я весьма подробно объяснил, ModelR, почему 4321e заблуждается. Задолго до его сообщения. Трудно как-то по-другому понять фразу "без дублирования значащих для проводки полей в полях таблиц-документов" ! Дата операции, или сумма из операции "значимы для проводки" ? Значит в операции их не будет ? Вы и 4321е все ставите с ног на голову, то есть все делаете "от счетов". Я это весьма подробно объяснил, и не могу поверить, что Вы чего-то не поняли. Я просто знаю, что помещать "проводку" в "отдельную таблицу" - плохое решение, а Вы этого просто не знаете. Возможно, правильным выводом будет интересная идея iscrafm: тот, кто бездоказательно хранит "проводки" в "отдельных таблицах" - грамотный специалист, а тот, кто обоснованно (я, во всяком случае, никогда бы не стал отказываться от хранения "проводок" в "отдельных таблицах" не обоснованно) хранит "проводки" в "операциях" - демагог.
16 сен 06, 00:51    [3145494]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
"Хранить" (речь идет о логическом уровне, конечно) данные в "таблицах" (наверное все понимают под "таблицами" отношения РМД), mr.vetal - плохое решение. Но даже в этом, для подавляющего большинства просто неизбежном по коммерческим причинам, случае хранить "проводки" в "отдельной таблице" - плохое решение.
16 сен 06, 00:54    [3145498]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

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

Не вижу обоснований Хоть одно покажите, тогда можно о чем-то серьезном говорить. Пока, больше чем на демагогию не тянет. Знаете как о гемморое говорят: не самому посмотреть, ни другим показать. Что, страшно?

p.s. Я Вам здесь не раз доказательства приводил, в том числе и без отдельных таблиц. Взрослый человек вроде, доцент...
16 сен 06, 01:46    [3145542]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
ModelR
2 Чернышев Андрей ЛеонидовичЯ не спрашивал, какая часть информации проводки уже есть в других объектах БД. Мне интересно знать, что в Вашем понимании есть проводка как нравственннная категория.
Чернышев Андрей Леонидович
Я просто знаю, что помещать "проводку" в "отдельную таблицу" - плохое решение, а Вы этого просто не знаете.
Дык откуда же мне знать про размещение проводок, если я даже не знаю, что есть "проводка" (у Вас) ? Или это тоже секрет?
16 сен 06, 12:33    [3145825]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
iscrafm

2. В СУБД, в которой нет понятия таблицы

Расшифровочку нарисовал. Если СУБД поддерживает хранение данных в виде многомерных массивов. Никаких таблиц тебе, и проводки с операциями "в одной таблице".

К сообщению приложен файл. Размер - 0Kb
16 сен 06, 13:22    [3145881]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Мне нетрудно повторить, конечно. Оптимистично даже не считаю издевательством Ваше, MojdelR, многократное игнорирование этих повторов.
"Проводка" это процедура индексирования операции с использованием "кредитуемых и дебетуемых счетов". В "структурном смысле" под "проводкой" можно понимать набор {кр.счет,деб.счет,сумма,дата}, однако даты и суммы объективно содержатся в операции без всяких "проводок".
16 сен 06, 14:43    [3145947]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Никаких доказательств у Вас, iscrafm, в принципе не может быть. Так как на эксперимент по размещению "проводок" в "операциях" у Вас просто нет времени. Вот про отсутствие времени - это, вероятно, было правдой, а про "доказательства" - очередная демагогическая увертка. Лишь бы не говорить ничего по существу обсуждаемого вопроса.
16 сен 06, 14:57    [3145959]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Никаких доказательств у Вас, iscrafm, в принципе не может быть. Так как на эксперимент по размещению "проводок" в "операциях" у Вас просто нет времени.

За 16 лет выхлопа разных систем, на разных СУБД и платформах времени экспериментировать с разными вариантами было достаточно, не переживайте. Только есть одно существенное дополнение. Эксперименты заканчивались промышленными системами. Продолжаете демагогию?
Сейчас бы впору спросить, что Вы понимаете под "индексирование операции". :)
16 сен 06, 15:29    [3145991]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Как же мне не переживать, iscrafm, если помимо демагогии Вы теперь начали просто лгать. Видимо надеясь, что я забыл про:
"Да здесь никто, кроме Вас пожалуй, не экспериментирует."
Нет у Вас никаких доказательств, потому что Вы никогда не сравнивали два рассматриваемых способа хранения "проводок". Это и не мудрено, раз Вы даже не знаете что такое "индексирование" (в той убогой технологии, которую Вы применяете - "индексирование отношений").
16 сен 06, 19:23    [3146197]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Как же мне не переживать, iscrafm, если помимо демагогии Вы теперь начали просто лгать. Видимо надеясь, что я забыл про:
"Да здесь никто, кроме Вас пожалуй, не экспериментирует."

Добравшись до доцента, могли бы понимать различия между настоящим и прошлым временем в обычном русском языке. Когда говорят в настоящем, то говорят "не эксперементирую". Когда говорят о прошлом, то "было время поэксперементировать". Вот так вот, "проффесор". Учится Вам нужно.

Чернышев Андрей Леонидович

Нет у Вас никаких доказательств, потому что Вы никогда не сравнивали два рассматриваемых способа хранения "проводок".

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

Чернышев Андрей Леонидович

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

Я то знаю, интересно узнать что у Вас на "уме" под этим понимается. А про технологии... Не думаю, что Вы видели хотя бы значимую часть того.
Так что ждем окончания демагогии и выдачи "на гора" гениальной методики индексации операций в целях формирования проводок финансовой бухгалтерии на основании данных о хозяйственных операциях предприятия.
16 сен 06, 22:53    [3146522]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Два - это "в отдельной таблице" и "в операции". Вранье (про целых три) продолжается по полной программе, но это уже совершенно предсказуемо.
17 сен 06, 11:17    [3146873]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Не знаю, ModelR, почему я должен предоставлять результаты формализации "бухгалтерского учета". Но раз уж я, в свое время, представил даже результаты формализации РМД, буду чуть подробнее и в этом "споре".

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

Логический уровень.
"Проводка" представляется (дополнительными) атрибутами сущности "операция". А не отдельной сущностью. Это полностью соответствует описанию "проводки" на концептуальном уровне.

Физический уровень.
Полноценный эксперимент в РСУБД трудно себе представить (повышение производительности в ОСУБД существенное). Так как существующие "Р"СУБД крайне бедны и в плане типов данных, и в плане типов индексов. Я ПРИЗНАЮ СВОЮ ОШИБКУ в отношении реализации (и изменения производительности) в "Р"СУБД. Раз само решение нельзя реализовать [я больше не буду настаивать, что это не так - специалистам по "Р"СУБД виднее], то нет и изменения производительности. То есть в "Р"СУБД "бухгалтерский учет" осложнен, так как нельзя явно реализовать концепцию "бухгалтерской проводки" (см. концептуальный и логический уровни).

Надеюсь, что никакого недопонимания не осталось. Хотя ничего нового (кроме признания своей ошибки относительно возможностей "Р"СУБД) я не сказал.
17 сен 06, 11:43    [3146903]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Концептуальный уровень.
"Проводка" - это ПРОЦЕДУРА, а не СТРУКТУРА.
Процедура дооформления (проведения, ...) бухгалтером совершенной операции.

Уважаемый, путаете предметы с действиями на ними.

Чернышев Андрей Леонидович

Так как существующие "Р"СУБД крайне бедны

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

автор
"Проводка" представляется (дополнительными) атрибутами сущности "операция". А не отдельной сущностью. Это полностью соответствует описанию "проводки" на концептуальном уровне.

Какие еще атрибуты, если Вы в своем концептуальном начале, сказали что проводка это процедура .

автор
Так как существующие "Р"СУБД крайне бедны и в плане типов данных, и в плане типов индексов.

Какие еще типы данных, для чего они Вам, если Вы в своем концептуальном начале, сказали что проводка это процедура .

Чернышев Андрей Леонидович

Надеюсь, что никакого недопонимания не осталось.

Да, не осталось, все диагнозы подтвердились.
17 сен 06, 13:13    [3147030]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы, iscrafm, не комментировали бы лучше то, что к Вам не относится. ModelR разберется без Вашей помощи. Что же Вы не обвели в прямоугольничек:

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

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

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

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

Поскольку Вы уже давно перестали хоть что-то говорить по существу темы "хранения проводок" (а то, что я "абсолютно ничего не понимаю ни по одному вопросу" уже итак все давно знают), я больше, если позволите, не буду обращать внимания на Ваши высказывания.
17 сен 06, 22:27    [3147836]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Вам просто не дано (ведь уже несколько недель прошло) понять, что "проводка" - это процедура, а не структура. Так и многим другим не дано - ничего страшного в этом нет. И вряд ли я в этом виноват.

Чернышев Андрей Леонидович

Поскольку Вы уже давно перестали хоть что-то говорить по существу темы "хранения проводок"


Когда сами с собой разберетесь, что такое проводка, действие или данные, то сможете и семинары организовывать.
Кстати, результатом процедуры Проводка что является?
18 сен 06, 00:57    [3148064]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Чернышев Андрей Леонидович
Вы храните этот "предмет" в отдельной "таблице" и совершаете над ним "действия".

Когда храню, когда нет. Проверьте конспекты, там есть пример без хранения проводок в отдельной таблице. Я надеялся Вы тщательней следите за материалом этой темы.
18 сен 06, 01:02    [3148068]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Не знаю, ModelR, почему я должен предоставлять результаты
Здесь никто никому ничего не должен. Хотите - общаемся. Нет так нет.
Чернышев Андрей Леонидович

"Проводка" это процедура индексирования операции с использованием "кредитуемых и дебетуемых счетов". В "структурном смысле" под "проводкой" можно понимать набор {кр.счет,деб.счет,сумма,дата}, однако даты и суммы объективно содержатся в операции без всяких "проводок"..
Чернышев Андрей Леонидович

Концептуальный уровень.
"Проводка" - это ПРОЦЕДУРА, а не СТРУКТУРА.
Процедура дооформления (проведения, ...) бухгалтером совершенной операции.
Понятно. Но ИМХО неверно отрывать проставление счетов от остальной части бухгалтерского труда. Бух учет - это экономическая классиификация операций исходя из принципов учета (см. например закон "О бухучете"), что сложнее просто индексирования бухсчетами кем-то уже перечисленных операций. В моем примере видно, что сама разбивка суммы в оперативном и бух. учете может быть не то чтобы более/менее детальной, а просто иной (150= 70+80=100+50). Что и приводит к структуре бухоперация (транзакционное понятие) --бухпроводки/полупроводки (суммовая разбивка).
Чернышев Андрей Леонидович

В связи с этим, часто используемый термин "полупроводка" - это "полупроцедура". Ни на концептуальном, ни на лигическом, ни на физическом уровне это понятие не имеет существенного практического смысла. И мне не понятно какая польза может быть хотя бы в научном плане от "полутранзакции".
Ну, где бузина и где дядька. Для процедур обычно используют слова проведение, генерация и т.д. Полугенерация действительно мне не встечалась. Полупроводки - часто.
Чернышев Андрей Леонидович


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

Надеюсь, что никакого недопонимания не осталось. Хотя ничего нового (кроме признания своей ошибки относительно возможностей "Р"СУБД) я не сказал.
Да общем-то расхождения вполне понятны. Было бы интересно увидеть запись в Вашей системе моего примера, но как уже сказано, никто никому ничего не обязан.
18 сен 06, 10:42    [3148738]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35366
Сейчас окажется, что контирование придумал Андрей Леонидович.
18 сен 06, 11:30    [3149013]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Я вроде не рассматривал "труд бухгалтера", "труд слесаря", "труд кладовщика", ModelR.
Я просто знаком с реализацией того, о чем говорю. Все, что нужно для "бухгалтерского учета", есть в операции, зарегистрированной слесарем или кладовщиком.
Вы говорили, что нигде нет определения "проводки". Я, основываясь на результатах исследований, определил для Вас что такое "проводка". Так что "полупроводка", в результате этого моего определения "проводки", становится бессмысленным понятием.
В примере из 3080908 нет "операций" и "проводок", а есть "остатки" (Вы, по непонятным причинам, принципиально не хотите говорить об "операциях" и "проводках").
В этом примере Вы умышленно не "связали" "ячейки" со "складами" ? Зачем Вы вообще ввели два эти понятия - разве "ячейка" - это не "маленький склад" ?
Для "складского работника" (и др.) существует склад С05 ?
Если "да", то сколько товара Т1 хранится на этом складе ?
Как выглядит операция прихода товара на склад С05 ?
Операция прихода в ячейку Я10 - это ДРУГАЯ "операция" (еще одна) даже когда физически была сделана ОДНА операция ?
Сложно понять Ваш пример с остатками, и, тем более, сложно понять какое отношение он имеет к способу "хранения проводок".
18 сен 06, 22:34    [3152715]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Результатом "процедуры Проводка", iscrafm, будет (и это Вы прекрасно понимаете) модифицированная операция - в ней будут добавлены значения пары "атрибутов". Результатом "процедуры Отмена проводки" будет модифицированная операция - в ней будут удалены значения пары "атрибутов".
В "Вашем случае" (если, конечно, у Вас реально есть операции, а не "счета-проводки-аналитики", как в "бухгалтерских системах) результатом "процедуры Проводка" будет добавление нескольких кортежей в отношение "Проводка", "связанных" внешними ключами со "Счетами" и с "Операцией".
18 сен 06, 22:49    [3152734]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
RENaissance
Member

Откуда: Муром->Москва
Сообщений: 10895

Мне непонятно, зачем Чернышев Андрей Леонидович так сотрясает воздух? Придумал некую свою структуру, в которой данные хоз.операций
хранятся вместе с данными " проводок" (некое условное понятие для Чернышева Андрея Леонидовича), считая при этом свою идею
революционно новой, а решения других людей - не более, чем классической устаревшей технологией... Извините конечно, но меня это
несколько улыбает....как улыбает взрослого человека, когда детский неокрепший ум пытается доказать какую-нибудь несостоятельность
жизненных устоев. Скажу более, Чернышев Андрей Леонидович подвергает сомнению, а точноее опровергает, решения по организации
бух.учета таких "монстров", как 1С, Парус, Галактика, Альфа Бухгалтерия и др., у которых проводки хранятся отдельно в таблице.
Поэтому, извините в очередной раз, читая топики Чернышеа Андрея Леонидовича, похожих на детский лепет (или врослый бред), можно
только улыбнуться... и не более того.
З.Ы Очень понравилось, как организован бух.учет в 1С. В свое время, создавая бух.учет на своем предприятии 8 лет назад, часть идей,
которые в последствии доказали свою работо- и жизнеспособность, была взята из 1С.


Posted via ActualForum NNTP Server 1.3

19 сен 06, 08:41    [3153335]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Сложно понять Ваш пример с остатками, и, тем более, сложно понять какое отношение он имеет к способу "хранения проводок".
OK, еще раз, для простоты рассматривается только приход.
Управленческая информация:
СтруктураСклада (Ячейка, СкладГдеНаходится) КЛЮЧ (Ячейка)
РазмещениеТовара(Дата, Ячейка, Товар,Количество) КЛЮЧ (Дата,Ячейка, Товар)
Движение_склад_приход (Основание, Дата, Ячейка, Товар,Количество)
Кстати, да, Дату я прошлый раз пропустил ошибочно. Что касается связи остатков и операций , мне казалось очевидным, что движение должно иметь как минимум те же разрезы, что и остатки. Т.е невозможно знать остатки по ячейкам, не регистрируя по ячейкам же движение. ОК, теперь сказано открытым текстом.
Данные:
СтруктураСклада (Я10, С05) 
СтруктураСклада (Я20, С05) 
Движение_склад_приход (Док200, 01-06-2006, Я10, Товар_33, 70)
Движение_склад_приход (Док200, 01-06-2006, Я20, Товар_33, 80)
Бухгалтерская информация:
Остатки (Счет, Товар, Склад, Количество, Сумма) КЛЮЧ (Счет, Товар,Склад )
Движение_бух (Основание, Дата, Дт, Кт, Количество, Сумма)
Движение_бух (Док200, 01-06-2006, Дт=(10/1,складС05,Товар_33),Кт=60, 100, ,,,,)
Движение_бух (Док200, 01-06-2006, Дт=(10/2,складС05,Товар_33),Кт=60, 50, ,,,,)
Вопрос: Не понимаю, как обойтись только двумя записями из Движение_склад_приход, лишь добавив туда контировку.
19 сен 06, 10:23    [3153957]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321ё
Guest
Чернышев Андрей Леонидович
Я весьма подробно объяснил, ModelR, почему 4321e заблуждается. Задолго до его сообщения. Трудно как-то по-другому понять фразу "без дублирования значащих для проводки полей в полях таблиц-документов" ! Дата операции, или сумма из операции "значимы для проводки" ? Значит в операции их не будет ?
гм. просветите меня, пжалста. вот имеем мы положим документ "накладная" в РСУБД. строки накладных (товарные позиции), в стандартном рсубдовом решении - это _отдельная таки таблица. Так что, по вашему, "значит в накладной товарных позиций не будет?" Ой ли.

И еще, если я предложил схему, где таблица проводок - мастер-таблица для таблиц операций - очевидно, что это означает, что любая операция (за исключением возможно недовведенной - NULL в значении ключа) будет иметь свою запись в таблице проводок - т.е. поля
ЧАЛ
Дата операции, или сумма из операции "значимы для проводки"
, что не мешает нам не заполнять (как мы _вполне можем решить_ поля "счет дебета" и "счет кредита" - т.е. "не проводить" документ (запись в таблице проводок уже будет - "со значащими полями операции", а "проведена" операция еще не будет. О как. Хотя этого же эффекта в такой схеме можно достичь и иначе (при требовании непустоты обоих полей на уровне констрайнта, что _привлекательно_ в случае Рсубд). Простым флагом статуса.

так я и нипонил, чо вы обиснили, кито заблюждаица, чиво ви там сибе мните...
19 сен 06, 11:13    [3154274]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
У Вас, я думаю, серьезная проблема со схемой данных в корпоративной (?) системе, ModelR, судя по Вашему примеру. Имеем три (например) детальных (это Вы упустили) операции по двум базовым (в которых 100 и 50):
70 в Я10
30 в Я20
И
50 в Я20
И именно просто "добавляем контировку".
А у Вас, судя по всему, какой-то "двойной учет".
19 сен 06, 21:55    [3158188]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Да, RENaissance, именно опровергаю. Аргументированно опровергаю. Пусть Вас это "улыбает", ведь по существу Вам нечего сказать. У "монстров" плохое решение. И я объясняю почему именно. А Ваши "аргументы" стандартны, и уже хорошо знакомы: "сотрясает воздух", "условное понятие", "детский неокрепший ум", "детский лепет".

Я, в случаях таких безответсвенных высказываний, всегда делаю простое предложение - очный семинар по тому или иному вопросу. Там нельзя будет врать и нести чепуху. И истиный уровень понимания "предмета" "монстрами" будет очевиден не только мне, но и всем участникам семинара. И будет понятно кто именно "сотрясает воздух" и "лепечет". И у меня создается впечатление, что именно страх перед тем, что ты будешь выведен на чистую воду со своим "классическим решением" - непреодолимое пряпятствие для организации таких семинаров. Я всегда готов, а Вы, RENaissance, никогда не готовы. Вместе с 1с, плохо приспособленной для бухгалтерского учета.
19 сен 06, 22:05    [3158208]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Что "ой ли", 4321е ? Это Вы "просветите". В операции (записи накладной), и в самой накладной даты и сумм не будет ? Они будут в "бухгалтерских проводках" ? А "не бухгалтерам" они не нужны ?
То, что Вы, действительно что-то не поняли, я уже понял. Но чем помочь - не знаю.
19 сен 06, 22:08    [3158214]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321ё
Guest
Чернышев Андрей Леонидович
Что "ой ли", 4321е ? Это Вы "просветите". В операции (записи накладной), и в самой накладной даты и сумм не будет ?
этто 5 (пать)!!!

так передернуть, и не покривиться.... я восхищен.

читаем внимательно вопрос (мою аналогию к вашему перлу): ~~ "считаете ли вы, что в накладной не будет товарных позиций (и собственно суммы накладной) ежели накладная в рсубд - это одна таблица, а товарные позиции накладных - другая?"
ответ ваш мы видели. скажите пжалста, отвечает ли этот ваш "ответ" на поставленный вопрос? или вы сами себе на что-то-там отвечаете, причем - не имеющее отношения к вопросу? и, на сей раз, ответьте пжалста именно на мой [этот] вопрос - вопрос о тайнах подбора вами тем для ответов, не содержащихся в поставленных вопросах. уж очень хочется получить хотя бы один прямой ответ.

Чернышев Андрей Леонидович
Они будут в "бухгалтерских проводках" ? А "не бухгалтерам" они не нужны ?
они будут в базе данных. и будут доступны всем, кому нужны "согласно должностным блаблабла". при этом они "_будут в операции_", но не как отдельные поля, а как строго типизированная сучность (ведущая таблица в звезде всегда содержит запись на подчиненную (связь 1-1, напоминаю), если объявить поле вторичного ключа подчиненной Not Null). Т.е получаем: поля в "документе" есть, но есть не как поля данной таблицы, а как выделенная сущность - "бухгалтерская проводка". что вы имеете против такого выделения набора полей в строго типизированную сущность (по всем разнородным таблицам "операций")?

Чернышев Андрей Леонидович
То, что Вы, действительно что-то не поняли, я уже понял. Но чем помочь - не знаю.
гыгыгы. см. мое недоумение выше, и попробуйте вывести это свое "понимание непонимания" из вашего же передергивания. Не веселит?
20 сен 06, 11:17    [3159725]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
У Вас, я
ошибочно
Чернышев Андрей Леонидович
думаю, серьезная проблема со схемой данных в корпоративной (?) системе, ModelR, судя по Вашему примеру. Имеем три (например) детальных (это Вы упустили) операции по двум базовым (в которых 100 и 50):
70 в Я10
30 в Я20
И
50 в Я20
И именно просто "добавляем контировку".
Вот это как раз то чего не существует в жизни и не должно быть в базе. Бухгалтер не должен заниматься ячейками, а склад контировкой ( и не будут конечно) только потому, что так было бы удобно программистам.
Чернышев Андрей Леонидович

А у Вас, судя по всему, какой-то "двойной учет".
Как уже говорил, учет у склада свой один, бухгалтера свой один же, и в целом один же : объединяющее их ограничение целостности 150=150 по данному основанию.
20 сен 06, 14:37    [3161742]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
"гыгыгы" - естественный результат непонимания "сущности" обсуждаемого вопроса, 4321е. "Спорить" безрезультатно я постараюсь Вам не позволить. Итак про:

"гм. просветите меня, пжалста. вот имеем мы положим документ "накладная" в РСУБД. строки накладных (товарные позиции), в стандартном рсубдовом решении - это _отдельная таки таблица."

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

Проводка - это процедура, а не структура. Пока Вы этого не поймете, так и будете бесплодно рассуждать о "классических РСУБДшных решениях".
20 сен 06, 22:05    [3164435]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Ваши заблуждения, ModelR, какие-то "показные", на мой взгляд. Просто удивительно, что Вы оспариваете очевидное.
приход 70 на склад С05 в Я10
приход 30 на склад С05 в Я20
приход 50 на склад С05 в Я20
это факты, которые Вы объявляете "не существующими в жизни". Потрясающе ! А ведь есть еще партии, МОЛ, отнесение стоимости услуг на стоимость материалов, и т.д. и т.п. (действительно не имеющие никакого отношения к "проводкам").
Итак Вы подтверждаете совершенно бессмысленный (убежден что Вы не сможете привести ни одного аргумента) двойной учет (один + один). Ничего другого я и не ожидал от "традиционного бухгалтерского учета".
20 сен 06, 22:11    [3164453]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
DmitryOrlov
Member

Откуда: Москва
Сообщений: 730
Я вот думаю, что мне теперь делать. У меня склад - это территориально удаленное подразделение. Приход товара на склад - это операция совершаемая на складе (в собственной базе данных, на собственном компьютере)
А проводки по этой операции попадают в бухгалтерскую базу данных с помощью героического труда бухгалтера. И все это удалено друг от друга. И каналов связи нет. И осталось мне только повеситься, потому что у меня неправильная корпоративная система, в которой операции совершаются на складе, а проводки бухгалтер лепит постфактум много позже и т.д.
Все, пошел плакать в угол. Наказан, блин.
20 сен 06, 23:42    [3164634]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Не глупите, DmitryOrlov. Толка ведь от этого не будет. И не плачьте. На нет и суда нет. У Вас две (как минимум) системы. Каналов связи нет. В "бухгалтерскую базу данных" попадают операции, а не проводки (здесь то уж могли бы ерунду не говорить). [И она, кстати, вполне может оказаться "корпоративной", к которой уже применимо все о чем здесь "спорят".] Делать Вам "теперь" ничего не нужно. Все что могли, Вы уже сделали, наверное.
21 сен 06, 08:34    [3165125]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
очевидное.
приход 70 на склад С05 в Я10
приход 30 на склад С05 в Я20
приход 50 на склад С05 в Я20
это факты, которые Вы объявляете "не существующими в жизни".
Именно! Такой разбивки, набора фактов в природе не существует. Вам приходится их выдумывать чисто чтобы было куда вставить контировку. А можно было (только незачем) и так:
приход 20 на склад С05 в Я10
приход 50 на склад С05 в Я10
приход 80 на склад С05 в Я20
и еще многими способами.
Чернышев Андрей Леонидович
Потрясающе ! А ведь есть еще партии, МОЛ, отнесение стоимости услуг на стоимость материалов, и т.д. и т.п. (действительно не имеющие никакого отношения к "проводкам").
Итак Вы подтверждаете совершенно бессмысленный (убежден что Вы не сможете привести ни одного аргумента) двойной учет (один + один). Ничего другого я и не ожидал от
подставьте правильное слово:)
21 сен 06, 13:32    [3167356]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321ё
Guest
Чернышев Андрей Леонидович
"гыгыгы" - естественный результат непонимания "сущности" обсуждаемого вопроса, 4321е. "Спорить" безрезультатно я постараюсь Вам не позволить. Итак про:
преамбула завораживает силой посылки. но... расплывчата и бессмысленна (беспредметна).
Чернышев Андрей Леонидович
"гм. просветите меня, пжалста. вот имеем мы положим документ "накладная" в РСУБД. строки накладных (товарные позиции), в стандартном рсубдовом решении - это _отдельная таки таблица."
И? иде атвет на вапрос?
Я вас спрашиваю! :0)
и не увиливайте - там же специально помещена просьба отвечать на поставленные вопросы, а не на домыслы. (даже сущ-во впроса - и то опустили).


ладненько. посмотрим на ваши собственные экзерсисы.
Чернышев Андрей Леонидович
Теперь добавляем "проводку" (в том числе по отгрузке - эта "операция" как раз "строка товарной накладной") в "отдельной таблице, как строго типизированную сущность. Итак, где в этом решении, например, дата отгрузки, в какой из трех "таблиц" ? Все суммы по "товарной позиции накладной" в третьей таблице, так ? А почему "количества" не в четвертой, разве "количества" - это не "строго типизированная сущность" ? И т.д.
а вот это все зависит от того, какой набор атрибутов мы считаем "проводкой". (от определения содержимого проводки вы уворачиваетесь). Например если мы договариваемся, что проводка по счетам может иметь _детализацию_ по тем или иным аналитическим признакам, и эта детализация нам нужна _в бухгалтерском_ учете, а не скажем в складском, то количества будут либо в самой таблице проводок (с заполненным признаком аналитики "номенклатура", полем "значение номенклатурного справочника" (т.е. с указателем на номенклатуру товарной позиции) и значением "количество" в поле для числового показателя; это - если заведомо ограничить возможное число аналитических разрезов одной проводки на этапе проектирования - см. напр. 1С - до 3-х разрезов аналитики) либо в той "четвертой таблице" "проводок аналитики" о которой вы упомянули (в этом случае число разрезов не ограничено, и пополнение информации о разрезах постфактум не влияет на саму проводку (по счетам) - а только на ее детализацию (по номенклатуре разрезов)). Встречаются и такие решения. (т.е. "проводка" в ней уже не плоская структура, но структура с подчиненными записями детализации см RS-Balance). То же и с вопросом про дату - конечно можно дату вынести в еще более корневую таблу, чем собсно проводка (ее обычно и называют таблицей "хозяйственных операций" - в _бухгалтерском_ смысле, и дают из нее ссылки на записи журналов "первичных документов" - оснований бухгалтерсокй "хозоперации"), и именно на эту таблу зазвездить собственно "хозяйственные операции" в изначальном смысле (т.е по сути - учет разнородной первички). Но, по размышлении, в ней, в этой табле "бухгалтерских хозопераций" зачастую значимым остается только поле "дата" (остальные отъезжают на уровень либо проводок, либо, если таковой есть, уже на уровень аналитики). Т.ч. можно ,видимо, не городить этого огорода с "бух-хоз-операцией", а смириться с дублированием даты в табле проводок для операций, порождающих множество проводок (что дает возможность индексировать проводки по (датам,счетам) в рсубд). Но можно и городить (есть свои прелести).

Чернышев Андрей Леонидович
Проводка - это процедура, а не структура.
вашу мантру я уже слышал. не внушает.

Ваша "процедура" - это собственно "проведение" (может звучать в русском и как "проводка") хоз.операции по счетам бухгалтерского учета, а вот "запись на счетах БУ" - тоже, кстати сказать - "проводка" - это уже данные (структура) - собственно бухгалтерское "отражение операции" в бух учете. При "процедуре" проводки вы попросту определяете что же записать в "структуры" проводок. :0) За это могут отвечать справочники, но они перестраиваемы. Структуры же не изменямы после закрытия периода учета.
21 сен 06, 16:17    [3168849]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы, ModelR, умышленно что ли "не понимаете"? Какими еще "способами" ???
Я говорю исключительно о фактах. Фактах, понимаете ???
Когда приходовали 100, 70 из них поместили именно в Я10, а 30 именно в Я20.
Вы что издеваетесь что ли ? Зачем же Вы себе голову изначально морочили с "ячейками" ? Я факты в БД регистрирую, никак не зависящие от "бухгалтерского учета". Не нужно мне знать о "контировках" вообще. Они сами по себе автоматически делаются по любым реальным операциям.
Вы просто детский сад настоящий устроили из своего собственного примера.
21 сен 06, 22:19    [3170210]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы уже просто неправду начали говорить, 4321е ("увиливаете", "уворачиваетесь"). Это нехорошо. Содержимое "проводки", если рассматривать ее (для Вашего "удобства") как "структуру", очевидно и МНОГОКРАТНО приведено. Нет необходимости "договариваться". "Аналитики" (участники события отгрузки) содержатся в операции (связаны с операцией) безо всякого "бухгалтерского учета". А Вы опять талдычите про 1с и "бухгалтерский учет". Советую Вам совсем отказаться от прилагательных в своем лексиконе, может быть это Вам поможет.
"Ваша" мантра (она же "общепринятая") не просто "не внушает", а является ошибкой. Что еще за "запись на счетах БУ" ? Вы говорите о транзакции, в которой данные записываются в БД ? Что еще за "структура", которая тоже "проводка" ? "Структуры" для хранения "остатков" и/или "отклонений" (приращений) (например, Балансовый счет - Имеет отклонение за - День) - это тоже "проводки" ??? Остатки материала на конец периода, или долга перед партнером - это тоже "проводки" ??? Моя "мантра" очевидна, и основана на результатах анализа, а Ваша в чем заключается Вы и сами не знаете:

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

То есть - проектирование базы данных - это творческий процесс. И замечательно. Полностью согласен. И несколько раз порекомендовал хранить "проводки" в "отдельной таблице". Вы с этой моей рекомендацией не согласны что ли ?
21 сен 06, 22:37    [3170225]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Вы просто детский сад настоящий устроили из своего собственного примера.
Как говорил некто Гегель, истина конкретна. И на детсадовском примере все стало яснее ясного. По крайней мере я уже ничего нового добавить не могу.
22 сен 06, 10:41    [3171258]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321ё
Guest
Чернышев Андрей Леонидович
Что еще за "запись на счетах БУ" ? Вы говорите о транзакции, в которой данные записываются в БД ? Что еще за "структура", которая тоже "проводка" ? "Структуры" для хранения "остатков" и/или "отклонений" (приращений) (например, Балансовый счет - Имеет отклонение за - День) - это тоже "проводки" ??? Остатки материала на конец периода, или долга перед партнером - это тоже "проводки" ???

1. "запись на счетах" - это основа БУ. Его атом. Такоже назывется "проводкой" (в случае двойной записи по счетам, предложенной еще черт знает когда неким макаронником). Можете почитать буквари по БУ. Именно эти атомы и записываем. В соотвествующе построенные структуры рсубд. (например - выделив эти структуры из общего "тела" (вернее "тел") по разному структурированных "операций в общехозяйственном смысле" - чтобы "избежать дублирования информации".

2. Рад за вас. Вот вы и признались в денормализации. (дублировании данных, что для не рсубд точнее). И остатки-то на конец/начало периода вы храните отдельно, и прочие агрегаты за день. А что ж так. Это ж все расчетные величины. Лихко считаются из остатков на _начало учета_ (от царя гороха) и оборотов за весь этот период. Или таки считаете возможным не всегда хранить данные "в одном месте". Чтобы на это пресловутое "одно место" приключений не нашлось, по причине неудовольствия пользователей? Шутка.

Так все таки вопрос вк вам. Как вы для себя обосновываете необходимость _хранить_ нечто (а все, что хранится - данные, а не процедуры), не являющееся самостояельными данными? Это ж вроде бы расходится с вашей парадигмой. Нет?
22 сен 06, 12:07    [3171967]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
DmitryOrlov
Member

Откуда: Москва
Сообщений: 730
Я все-таки не понимаю. В документе (накладной) что является операцией?Строки документов? Но в документе может быть сотни строк, а документов также может быть тысячи. Для корпоративной системы это нормально. То есть у меня получается операций может быть десятки и сотни тысяч. Бухгалтеру же достаточно получать агрегированые данные по документу, а не построчно. А остальную аналитику вытаскивать можно отдельно, тогда когда она нужна.
А так получается что, в каждом строке документа я должен хранить дополнительные поля с бухгалтерскими счетами. Да плюс еще налоговые счета.
И в чем же здесь правильность?
1.С определенного момента у меня база начнет пухнуть гораздо быстрее, чем если бы я хранил агрегированые записи по операциям в отдельной таблице.
2. Производительность системы для получения бухгалтерской отчетности (вероятно, при большом объеме записей) значительно снизится.
3. Генерация огромного количества операций ни чуть не производительнее, чем генерация агрегированых данных в отдельную таблицу(и получение информации из нее)
4. Разработка решения где данные по операциям(и соответственно проводкам) храняться в документах ничуть не менее сложно(ведь на каждую операцию должна быть отдельная строка-документ со своими правилами учета) и имхо не более надежно, чем запись агрегированых бухгалтерских данных в отдельную таблицу.
22 сен 06, 14:04    [3172918]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Новый круг, 4321е, и опять неправда. Я за Вас не рад, ведь о разумной денормализации я говорил изначально.
Конечно, "лихко считаются", когда я говорил, что "не лихко" ? Особенно элегантно выглядит Ваше "и оборотов [!] за весь [!!] этот [!!!] период" - это я оценил.

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

Что еще за "парадигма" ? Я про эффективное совмещение OLTP и OLAP много раз высказывался в других (соответствующих) темах. К "хранению проводок" это не имеет никакого отношения, ведь "проводка" - это процедура, а не структура, и ее нельзя хранить ни в "оперативной" части БД, ни в "агрегированном хранилище". А вот "остатки" и "обороты" по "счетам" - можно. Но не обязательно. Ничем не отличается от индексов - можно хранить, а можно и не хранить, если и так "все хорошо".
Я не первый раз настоятельно рекомендую Вам хранить "проводки" в "отдельной таблице", но чувствую, что это Вам не нравится. А почему ?
22 сен 06, 23:47    [3175555]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вот как, DmitryOrlov ! Значит Вы, все-таки, храните "проводки" вместе с "операциями", а не в "отдельной таблице" !
Только сначала Вы группируете операции в "группы операций". Объединяете, например, в приходном ордере материалы с одинаковым "бухгалтерским типом" в одну "группу". И помещаете в "отдельную таблицу" (не находящуюся, заметьте, даже в первой нормальной форме) первичный ключ этой группы (внешний ключ), первичный ключ ПО (внешний ключ), дату прихода, вычисленные суммы (без налогов и налоги) по операциям, входящим в эту "группу операций" (причем разные суммы в разные записи этой дополнительной таблицы) и т.д. И "проводки" в ЭТОЙ ЖЕ ТАБЛИЦЕ !
И при этом говорите, что "операции" + "группы операций" проще (не сложнее), чем просто "операции". Но я то знаю, что именно сложнее, просто потому (знаю), что сам использую вариант с "группами" для некоторых операций.
Хранение "бухгалтерских данных" в операциях проще, чем в "группах операций". БД при этом не "пухнет", а корпоративная производительность не снижается, а наоборот повышается.
23 сен 06, 00:08    [3175596]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
DmitryOrlov
Member

Откуда: Москва
Сообщений: 730
автор
Значит Вы, все-таки, храните "проводки" вместе с "операциями", а не в "отдельной таблице" !

Неужели я это сказал?;)
25 сен 06, 11:12    [3178383]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
FullZero
Member

Откуда: Украина, г.Изюм
Сообщений: 312
какой-то нефильтруемый поток сознания...
26 сен 12, 20:39    [13228373]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
FullZero
какой-то нефильтруемый поток сознания...

А Вам про это понимать не нужно:) Так что не переживайте:)
26 сен 12, 20:54    [13228431]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Нашел и пристрелил ЧАЛа
Guest
чуть мозг не взорвался
2 окт 12, 15:47    [13256620]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Нашел и пристрелил ЧАЛа
чуть мозг не взорвался

Это как и при физической нагрузке для неподготовленного человека. Вы думайте сначала по 5 минут в день. И постепенно нагрузку повышайте:) Может быть тогда Вам будет что сказать по существу темы, а не про свой бедный мозг:)
2 окт 12, 20:11    [13258242]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Нашел и пристрелил ЧАЛа
Guest
Бредятина, я как погляжу вы данный момент как раз тужитесь на тренировках по своему методу :) и стараетесь попасть немного в тему, но выходит какая-то одноименная с вашей подписью хрень :)
FullZero
какой-то нефильтруемый поток сознания...

особенно последнее сообщение ЧАЛа:)
2 окт 12, 20:59    [13258347]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Нашел и пристрелил ЧАЛа
Бредятина, я как погляжу вы данный момент как раз тужитесь на тренировках по своему методу :) и стараетесь попасть немного в тему, но выходит какая-то одноименная с вашей подписью хрень :)
FullZero
какой-то нефильтруемый поток сознания...

особенно последнее сообщение ЧАЛа:)

Это конструкторское решение (насколько я понимаю Вы у себя в системе храните бухгалтерские проводки в одной таблице с операциями) - ошибка:) Пока Вы считаете правильное решение некой "одноименной хренью", но объяснить это свое понимание не можете. Или не хотите:) А скорее всего, просто пишите что-то из-за обиды на свое непонимание вопроса:) Здесь так очень многие поступают. Это стиль sql.ru. Цель этого стиля мне не вполне понятна. Но Вам, наверное, понятна:)
2 окт 12, 21:08    [13258368]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Konstanrtin
Member

Откуда:
Сообщений: 113
Бредятина
Это конструкторское решение - ошибка:)

Вот ЧАЛа на вас не хватает! :) Он бы зарядил.
Это конструкторское решение
. Решения тут как не было так его и нет. Последнее его сообщение - как будто бы завеса тайны открывается, но больше похоже на
какой-то нефильтруемый поток сознания...
3 окт 12, 13:16    [13261306]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Нашел и пристрелил ЧАЛа
Guest
Бредятина
Это стиль sql.ru. Цель этого стиля мне не вполне понятна.
Из-за этого непонимания Вы, создав новый стиль, отвечаете так же - обидившись, но при этом после каждого предложения ставите смайлик :) Похвально.
Пока Вы считаете правильное решение...
Тут никакого другого нового решения пока не было опубликовано явно, поэтому все до сих пор, и я в том числе, продолжают считать верным способ хранения проводок в отдельной таблице.
3 окт 12, 13:28    [13261404]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Konstanrtin
Решения тут как не было так его и нет. Последнее его сообщение - как будто бы завеса тайны открывается, но больше похоже на какой-то нефильтруемый поток сознания...

Сложно рассчитывать что, даже и такие простые вопросы проектирования БД, будут понятны всем читающим. Вам не понятны. Но они Вас и не интересуют - это же очевидно. Если бы интересовали, то разобрались бы что к чему:) Поэтому (раз не понятны) нужно пнуть обязательно того, кому понятны. Это стандартный стиль sql.ru. То есть, это нормально:)
3 окт 12, 13:55    [13261652]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Нашел и пристрелил ЧАЛа
Из-за этого непонимания Вы, создав новый стиль, отвечаете так же - обидившись, но при этом после каждого предложения ставите смайлик :) Похвально.

Я не создавал стилей, а всего лишь предпочитаю обсуждать вопрос по существу, чего Вы предпочитаете избегать:) Обидеться проще всего. Смысла в этом нет никакого. Поэтому я не обижаюсь принципиально:)
Нашел и пристрелил ЧАЛа
Тут никакого другого нового решения пока не было опубликовано явно, поэтому все до сих пор, и я в том числе, продолжают считать верным способ хранения проводок в отдельной таблице.

Отлично.
3 окт 12, 14:02    [13261718]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Я
Guest
Ужас! Какойто бред типа "О влиянии лунного света на рост телеграфных столбов"
3 окт 12, 15:26    [13262491]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Я
Ужас! Какойто бред типа "О влиянии лунного света на рост телеграфных столбов"

Это точно:)
3 окт 12, 16:14    [13262828]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Раз уж вернулись к этой, очень интересной теме, промежуточный итог:
1) Никто так и не ответил какие характеристики добавляет "проводка" к "операции". Для меня очевидно, что два БС, один из которых кредитуется, а другой дебетуется (в простой и обычной ситуации, когда для проводки используется одна конкретная сумма из операции).
2) Что именно (какие характеристики каких объектов) "перетаскивается" в таблицу "проводок" в рамках процедуры денормализации (дублирования)? Вероятно, все, что нужно для более производительного выполнения бухгалтерских отчетов, таких, как отчет по БС. Следовательно, туда "перетаскиваются" (вычисляемые характеристики производительность не повысят, в общем случае) значения характеристик не только из операции, по которой делается проводка, но и из других, связанных с операцией, объектов (типов сущностей, таблиц).
3) Таким образом, единственным логичным объяснением хранения "проводок" в отдельной таблице является - денормализация (причем, весьма существенная) для повышения производительности некоторых отчетов. Одной из возможных альтернатив (в рамках простой модели из п. 1)) являются связи:
Операция <-- Кредитует/Кредитуется при выполнении -- Балансовый счет
Операция <-- Дебетует/Дебетуется при выполнении -- Балансовый счет
4 окт 12, 23:19    [13270856]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
DmitryOrlov
Я вот думаю, что мне теперь делать. У меня склад - это территориально удаленное подразделение. Приход товара на склад - это операция совершаемая на складе (в собственной базе данных, на собственном компьютере)
А проводки по этой операции попадают в бухгалтерскую базу данных с помощью героического труда бухгалтера. И все это удалено друг от друга. И каналов связи нет. И осталось мне только повеситься, потому что у меня неправильная корпоративная система, в которой операции совершаются на складе, а проводки бухгалтер лепит постфактум много позже и т.д.
Все, пошел плакать в угол. Наказан, блин.

Только не "неправильная корпоративная", а не корпоративная. Это же очевидно:)
4 окт 12, 23:21    [13270862]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Author the new one
Member

Откуда:
Сообщений: 251
Все, все красавцы - прицепились к нездоровому человеку со сверхценной идеей. Стыдно, товарищи.
1 янв 13, 19:39    [13714251]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Member

Откуда: Москва
Сообщений: 1657
Author the new one
Все, все красавцы - прицепились к нездоровому человеку со сверхценной идеей. Стыдно, товарищи.

Еще один здоровый товарищ с идеей "отключения внешних ключей для правильного расчета баланса")))
1 янв 13, 20:35    [13714389]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
londinium
Member

Откуда: Киев
Сообщений: 961
Ну всех с Новым Годом и новым флудом ))

Многоликому господину ЧАЛу предлагаю отойти от книжек Медведева М.Ю и компании "регистрация событий в теории учета" и прочего тяжелого бреда и поразмышлять над вопросом: есть карточный счет Иванова И.И, с которого он снял 100 рублей. Как будем крутиться без таблицы проводок? Просьба ответить по существу, а не растекаться мысью по древу.
1 янв 13, 21:43    [13714603]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Member

Откуда: Москва
Сообщений: 1657
londinium
Ну всех с Новым Годом и новым флудом ))

Многоликому господину ЧАЛу предлагаю отойти от книжек Медведева М.Ю и компании "регистрация событий в теории учета" и прочего тяжелого бреда и поразмышлять над вопросом: есть карточный счет Иванова И.И, с которого он снял 100 рублей. Как будем крутиться без таблицы проводок? Просьба ответить по существу, а не растекаться мысью по древу.

Всех здоровых и умных товарищей, способных только нажимать клавиши в случайном порядке, с Новым годом!
Так держать)))
1 янв 13, 21:54    [13714663]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Member

Откуда: Москва
Сообщений: 1657
Если 100 рублей со счета снял Медведев М.Ю., то проводки не нужно хранить в отдельной таблице, а если Иванов И.И. - то нужно))) Удивительный, все-таки, праздник - Новый год. После него всегда появляется свежий взгляд на, казалось бы, вдоль и поперек изученный вопрос)))
1 янв 13, 22:27    [13714753]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
PAPA_RimskY
Member

Откуда: СПб
Сообщений: 52
Хотел узнать как по-хорошему(а не так как у меня) сделать остатки в бд, а получил знание о других именах знаменитого бредятины.
23 апр 15, 15:48    [17554793]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Preacher
Member

Откуда:
Сообщений: 2
Есть задача - 1С УТ без проводок.
Отобразить проводки на основании документов, "проводки не нужно хранить в отдельной таблице" - условие выполнено...
24 авг 17, 23:14    [20748108]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Preacher
Member

Откуда:
Сообщений: 2
И оно работает... Вопрос о "подводных камнях"...
Картинка с другого сайта.
25 авг 17, 00:14    [20748143]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 33583
mr.vetal
Я просто имел ввиду кто как хранит это в таблицах.


Слушай, по этой теме горы статей в инете есть.

Кратко -- есть (можно делать) половинные проводки и полные. В полных проводках счёт кредита, счёт дебета и сумма.
В кратких -- счёт, дебит или кредит, сумма (таких записей на одну проводку две, поэтому и половинная).
29 авг 17, 15:16    [20756422]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 33583
ААААА удалите все мои сообщения в топике за этот год!
29 авг 17, 15:17    [20756427]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10 .. 12      [все]
Все форумы / Проектирование БД Ответить