Но зи-за того, что она включает ответы сразу на несколько вопросов, и одновременно является предложением ко всем участникам, я решил вынести ее в отдельную ветку.
Для начала обсудим постулаты бухучета, вокруг которых разгарелся спор...
Итак. "Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого.". Уберем из этого определения плохо детерминированное понятие хозоперация и введем понятие проводка. Так всем будет понятнее. Получится: "Каждая проводка подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого.".
Зададимся вопросом – что же означает слово отражению? В данном случае — это означает, что проводка должна изменять остаток на обоих счетах. Точнее она должна уменьшать остаток на одном счете и увеличивать на другом. Если мыслить примитивно, то нам понадобится ввести сущность (объект, если кому так больше нравится) "счет" и физически хранить для нее остаток. Но тут возникает вопрос, а на какую дату нужно хранить остаток? Или это должен быть остаток вообще (за весь период жизни предприятия)? Ответ – нет, так как и бухгалтеру и управленцу нужно получать остатки на определенную дату. Более того им нужны еще и обороты. Правильно? Думаю – да. И тут нужно обратить внимание на брошенное мною, походу дела, слово: получать!
Это слово было сказано не спроста. Дело в том, что хранить остатки и обороты совершенно не нужно. Их и так можно посчитать в любой момент времени. Правильно?
Слышу тихий ропот: при некоторых объемах эти расчеты просто несерьезно делать каждый раз пересчитывая все с самого начала. Нужны срезы... Правильно, но это всего лишь отдельный вопрос производительности. И решать его нужно отдельно от вопроса структуры хранения информации. Индексированные/материализованные view прекрасно решают проблему производительности сервера (да и программиста). Если вы еще не перешли на SQLServer 2000 или Oracle, то это ваши личные проблемы. Да и на других серверах можно создать грамотные таблицы содержащие агрегированную информацию. Главное, что это не повод для нереляционного хранения данных в реляционной СУБД. И не повод для заявлений делаемых George_Seryakov. Ну, да ладно... продолжим разбор полетов. :)
Ответим на вопрос alexm1202 (Является ли нормализованной таблица описанная им и мной?). Ответим также и на другой вопрос. Можно ли в этой таблице хранить проводки отвечающие принципам двойной записи?
Каждая запись в таблице отражает информацию только об одной сущности – проводке. Данная таблица не будет иметь ни одной повторяющейся записи, из таблицы нельзя вынести данные в другие (ссылочные) таблицы. Вроде все говорит – о том, что таблица соответствует самым жестким требованиям нормализации. Значит на первый вопрос отвечаем положительно (Если есть возражения, просьба возражать по существу, а не уходить от темы).
Теперь ответим на второй вопрос...
Каждая проводка содержит информацию о дебетовом и кредитовом счете/аналитическом признаке (в виде ссылки). Причем в ней отражен дебетуемый и кредитуемый счета. С эти вроде спорить бесполезно? Или как?
Проводка содержит дату ее совершения и сумму. Общая совокупность даты проводки, суммы и направление перемещения денег дает нам возможность записывать, таким образом, нормальные бухгалтерские проводки удовлетворяя всем требованиям двойной записи. Просто, вместо учета изменения счетов мы начали учитывать изменения этих самых счетов во времени. Никто не запрещает записывать проводку как два отдельных изменения счетов (дебетового и кредитового), но тогда и появляется та самая проблема с "нереляционностью" и "нерормализованностью".
Чтобы не быть голословным я создал маленькую тестовую базу состоящую из двух таблиц (я буду пользоваться синтаксисом SQL Server 2000, но он довольно близок к SQL 9x). Первая хранит некие аналитические признаки. Упростим задачу и предположим, что это просто бухгалтерские счета. Вот ее описание на SQL:
CREATE TABLE Z
(
idZ int NOT NULL PRIMARY KEY,
ZName varchar(100) NOT NULL
)
Вторая таблица – это таблица содержащая проводки:
CREATE TABLE Oper
(
idOper int IDENTITY (0, 1) NOT NULL PRIMARY KEY,
Db int NOT NULL FOREIGN KEY REFERENCES Z,
Cr int NOT NULL FOREIGN KEY REFERENCES Z,
OperDate datetime NOT NULL,
OperSum float NOT NULL
)
А вот описание этих таблиц в виде ER-диаграммы:
Как видно из ее определения поля Db, Cr являются ссылками на аналитическую таблицу. В принципе каждая запись аналитической таблицы может содержать неограниченное количество дополнительных аналитических признаков, но суть от этого не изменится. Главное, что мы совершаем перевод денег с одной единицы аналитики на другую (равнозначную по глубине/уровню). Посчитать остатки/обороты для такого вида таблиц довольно просто. Для начала заполним наши таблицы данными:
Insert into Z(idZ, ZName) Values(1, 'OC')
Insert into Z(idZ, ZName) Values(2, 'Амортизация ОС')
Insert into Z(idZ, ZName) Values(10, 'Склад материалов')
Insert into Z(idZ, ZName) Values(41, 'Товоры')
Insert into Z(idZ, ZName) Values(46, 'Реализация')
Insert into Z(idZ, ZName) Values(50, 'Касса')
Insert into Z(idZ, ZName) Values(51, 'Расчетный счет')
Insert into Z(idZ, ZName) Values(60, 'Поставщики')
Insert into Z(idZ, ZName) Values(71, 'Овансовые отчеты')
Insert into Z(idZ, ZName) Values(75, 'Учт.кап.')
SET DATEFORMAT dmy
Insert into Oper(Db, Cr, OperDate, OperSum) Values(51, 75, '01.01.2002', 1000)
Insert into Oper(Db, Cr, OperDate, OperSum) Values(50, 51, '02.01.2002', 300)
Insert into Oper(Db, Cr, OperDate, OperSum) Values(71, 50, '03.01.2002', 100)
Insert into Oper(Db, Cr, OperDate, OperSum) Values(10, 71, '04.01.2002', 55)
Insert into Oper(Db, Cr, OperDate, OperSum) Values(50, 71, '04.01.2002', 40)
Insert into Oper(Db, Cr, OperDate, OperSum) Values(60, 50, '05.01.2002', 200)
Insert into Oper(Db, Cr, OperDate, OperSum) Values(41, 60, '06.01.2002', 180)
Insert into Oper(Db, Cr, OperDate, OperSum) Values(51, 60, '06.01.2002', 20)
Insert into Oper(Db, Cr, OperDate, OperSum) Values(50, 71, '07.01.2002', 5)
Теперь можно создать упращенный вариант расчета оборотной ведомости. Для простоты выбросим расчет остатка на промежуточную дату и обороты (их не трудно добавить, но это усложнит понимание основного принципа).
Итак, рассчитать оборотку для некоторого уровня аналитики можно в два приема. Сначала нужно выделить уровень аналитики для которого необходимо произвести расчет, а потом произвести агрегацию соединив таблицу проводок и аналитики. В нашем, простейшем случае, есть только один уровень аналитики, а значит дополнительный запрос на выборку и агрегацию аналитики не требуется. То есть мы можем рассчитывать обороты и остатки на основании данных из таблицы проводок.
Общий алгоритм совсем прост нужно выбрать необходимые записи (за некоторый период) из таблицы проводок и посчитать их сумму для дебета и кредита каждого из счетов. К сожалению записать это одним запросом (без подзапросов) невозможно (если кто извернется, то покажите как). Я знаю два обхода данной проблемы. Первый известный мне способ – мы можем создать основной запрос который будет возвращать список аналитических признаков, а обороты и остатки подсчитывать в простых подзапросах. Второй – можно произвести агрегацию отдельно для дебетовых и кредитовых признаков и соединить полученные запросы с помощью FULL OUTER JOIN. Я продемонстрирую второй подход:
SELECT IsNull(DbS.Db, CrS.Cr) AS Z,
IsNull(CrS.CrSum, 0) AS Db,
IsNull(DbS.DbSum, 0) AS Cr
FROM
(SELECT Cr, SUM(OperSum) AS CrSum
FROM Oper
GROUP BY Cr) as CrS
FULL OUTER JOIN
(SELECT Db, SUM(OperSum) AS DbSum
FROM Oper
GROUP BY Db) as DbS
ON CrS.Cr = DbS.Db
Данный запрос содержит два подзапроса (выделенных жирным) которые рассчитывают обороты по дебету и кредиту аналитических признаков.
Если нужно вычислять оборот и остаток за определенный период, нужно добавить в подзапросы фильтрацию необходимого периода. Приведенный выше запрос должен будет сам стать подзапросом. Дело в том что для полноценной оборотки нужно рассчитать остаток на начало периода и оборот за период. Техника тут будет примерно такая же, так что вряд ли ее стоит касаться. Тот же FULL OUTER JOIN по аналитическим признакам... Остаток на конец рассчитывается путем сложения остатка на начало периода и оборота за период.
Если нужно добавить название аналитического признака, то можно сделать еще одну вложенность и JOIN со справочной таблицей. Вот вариант для нашего примера:
SELECT sb.Z, sb.Db, sb.Cr, Z.ZName
FROM Z INNER JOIN
(SELECT IsNull(DbS.Db, CrS.Cr) AS Z,
IsNull(CrS.CrSum, 0) AS Db,
IsNull(DbS.DbSum, 0) AS Cr
FROM
(SELECT Cr, SUM(OperSum) AS CrSum
FROM Oper
GROUP BY Cr) as CrS FULL
OUTER JOIN
(SELECT Db, SUM(OperSum) AS DbSum
FROM Oper
GROUP BY Db) as DbS
ON CrS.Cr = DbS.Db
) as sb ON Z.idZ = sb.Z
Вот результат выполнения запроса на приведенных данных:
В данном случае большая вложенность запросов не будет приводить к понижению производительности, так как только самые глубокие запросы занимаются действительно серьезной обработкой данных. Остальные уже работают с относительно небольшим количеством агрегированных данных.
Стоит так же обратить внимание на то, что при соединении результата с записями из таблицы аналитики применяется INNER JOIN. INNER JOIN более эффективен, да и если применить OUTER JOIN, то в запрос попадут "лишние записи" (аналитики для которой не было оборотов).
Willi задал вопрос: W>Все это конечно очень здорово (без всякой иронии). W>Но вот простой пример, я хочу получить баланс, причем не просто по счетам, но и с W>группировкой по аналитикам. Что-то вроде:
Товары на складе 1000
Продукты питания 200
Вобла 50
Пиво "Lowenbrau" 150
Одежда 400
Джинсы 250
Майки 150
Обувь 400
Кроссовки 200
Ласты на каблуках 200
W>Здесь W>"Товары на складе" — это счет, W>"Продукты питания", "Одежда", "Обувь" — аналитики типа "Вид товара" W>все остальное — аналитики типа "Товар" W> W>Если данне хранятся в виде
SELECT
SUM( entry_volume )
...
GROUP BY
account_id,
analytic_0_id
analytic_1_id
...
analytic_N_id
W>мы тут же получим нужный нам результат. W>А как быть в случае с более универсальным хранением аналитических атрибутов?
Первое что хочется здесь заметить – это то что пример не очень удачен. Дело в том, что в данном примере определяются не атрибуты проводки, а атрибуты номенклатуры. Количественный учет – в некотором смысле учет в другом измерении. Не в денежном, а в количественном. Точнее в количественно-денежном. Стало быть мы получаем не аналитические признаки проводки (по дебету или кредиту), а атрибуты единицы измерения. Тип товара это аналитика именно еденицы измерения. И пожалуй не следовало бы причислять ее к дебету или кредиту. Более того я бы даже посоветовал не хранить ее в проводке. В проводке нужно хранить только сумму в деньгах. Количественный учет лучше вынести в отдельную таблицу содержащую ссылку на проводку. При этом можно будет добавлять несколько количественно-суммовых записей для одной проводки, а проводка будет содержать общую суму по всем этим записям. Таким образом проводка будет похожа на простую накладную, что очень хорошо отражает реальную жизнь. Назовем таблицу в которой будут лежать детали проводки OperDet (детали операции). Номенклатура в этом случае учитывается как ссылка (поле в таблице количественно-суммового учета) на таблицу(ы)-справочник номенклатур. Вот ее описание и описание сопутствующих таблиц:
create table "Product" (
"idProd" INT IDENTITY NOT NULL PRIMARY KEY,
"ProdName" varchar(100) NOT NULL,
"ProdGroup" varchar(20) NOT NULL)
go
create table "OperDet" (
"idOper" INT NOT NULL,
"idProd" Int Not Null,
"DetCount" FLOAT NOT NULL,
"DetPrice" FLOAT NOT NULL)
go
alter table "OperDet"
add constraint "OperDet_PK"
primary key ("idOper", "idProd")
alter table "OperDet"
add constraint "Oper_OperDet_FK1"
foreign key("idOper")
references "Oper" ("idOper")
А вот ER-диаграмма:
При этом, правда, появляется необходимость синхронизировать сумму операции (проводки) с суммой по соответствующим деталям операции, но это можно сделать в триггерах или в middleware. При этом вопреки заблуждению Willi-а замечательное структурирование (продемонстрированное им) не породило множество аналитических признаков. По сути признак один – номенклатура. А деревце нарисованное им всего лишь структурирование самих признаков. Можно хранить такой справочник как дерево (в виде специальной реляционной структуры) и перед агрегацией выбирать необходимые листья этого дерева (которые и являются номенклатурой), а затем делать соединение с таблицей деталей проводки и с самой таблицей проводки.
Но вопрос может быть связан не обязательно с количественно-суммовым учетом. Каждый тип z-объекта может иметь различную структуру и количество аналитических признаков. Как быть в этой ситуации? Я вижу два выхода создать универсальную структуру для хранения неограниченного количества аналитических признаков и создавать (лучше всего динамически) отдельные таблицы для хранения аналитической информации для отдельных типов z-объектов. Честно говоря до сих пор я не могу отдать предпочтение одному из вариантов. Динамические таблицы сложнее в реализации, за то дают возможность хранить атрибуты не только ссылочного типа, но и обычные атрибуты (текстовые, числовые, булевы, даты). С другой стороны несколько усложняется полиморфные запросы (запросы возвращающие информацию сразу по нескольким типам z-объектов. В любом случае наиболее часто используемые атрибуты есть смысл хранить или непосредственно в таблице хранящей z-объекты или в таблице описывающей их типы (например, в ней можно хранить бухгалтерский счет). При этом для z-объекта будет иметься полиморфная запись в универсальной таблице хранящей z-объекты и в специализированной таблице для конкретного типа z-объектов. Связь между этими таблицами должна быть один к одному. Собственно это очень похоже на то, что предлагал George_Seryakov только в этом случае имеется связующая таблица хранящая информацию о проводке. По сути – это тоже самое, но приведенное в нормальную реляционную форму.
Второй вариант тоже подразумевает наличие полиморфной таблицы z-объектов, но вместо динамического создания таблиц для каждого их типа использует одну универсальную таблицу. Вот схема (на рисунке она имеет название Z2Ref):
Ref – это справочная таблица. В реальной жизни ее место должны занять таблицы реализующие универсальную (необходимой навороченности) модель справочников (в которой можно динамически добавлять справочники). По сути между таблицей Ref и Z появляется связь многие ко многим, т.е. с любым z-объектом можно ассоциировать любой элемент справочника и наоборот. Это позволяет добиться максимальной гибкости и при этом не создавать лишние таблицы (как в предыдущем случае).
Теперь усложнив и запутав все что можно я попробую показать, как в этом случае можно получать агрегированные результаты в разрезе некоторого набора элементов универсального справочника.
Для начала нам нужно заполнить таблицы Ref и Z2Ref начальными значениями. Так как до реальной жизни этому всему далеко я заполнил эти таблицы тем что пришло к голову:
create table "Ref"
(
"idRef" INT IDENTITY NOT NULL PRIMARY KEY,
"RefName" varchar(100) NOT NULL
)
create table "Z2Ref"
(
"idRef" INT NOT NULL,
"idZ" INT NOT NULL
)
alter table "Z2Ref"
add constraint "Z2Ref_PK"
primary key clustered ("idZ", "idRef")
Insert into Ref(RefName) Values('Васек')
Insert into Ref(RefName) Values('Склад 1')
Insert into Ref(RefName) Values('Петек')
Insert into Ref(RefName) Values('Склад 2')
Insert into Ref(RefName) Values('Касса 1')
Insert into Ref(RefName) Values('Касса 1')
Insert into Ref(RefName) Values('Нюрка')
Insert into Z2Ref(idRef, idZ) Values(3, 10)
Insert into Z2Ref(idRef, idZ) Values(3, 41)
Insert into Z2Ref(idRef, idZ) Values(1, 50)
Insert into Z2Ref(idRef, idZ) Values(3, 60)
Insert into Z2Ref(idRef, idZ) Values(7, 60)
Insert into Z2Ref(idRef, idZ) Values(1, 71)
Insert into Z2Ref(idRef, idZ) Values(3, 71)
Insert into Z2Ref(idRef, idZ) Values(1, 75)
Предположим теперь, что нам нужно получить обороты для Васька и Петька, т.е. для записей 1 и 3 из таблицы Ref. Чтобы создать такой запрос достаточно несколько модернизировать предыдущие запросы:
SELECT Agr.Z, Ref.RefName AS Name, Agr.Db, Agr.Cr
FROM (SELECT IsNull(DbS.idRef, CrS.idRef) AS Z,
IsNull(CrS.CrSum, 0) AS Db,
IsNull(DbS.DbSum, 0) AS Cr
FROM (SELECT Z2Ref.idRef,
SUM(Oper.OperSum) AS DbSum
FROM Oper INNER JOIN
Z ON Oper.Db = Z.idZ
INNER JOIN
Z2Ref ON Z.idZ = Z2Ref.idZ
WHERE (Z2Ref.idRef IN (1, 3))
GROUP BY Z2Ref.idRef
) DbS
FULL OUTER JOIN
(SELECT Z2Ref.idRef,
SUM(Oper.OperSum) AS CrSum
FROM Oper INNER JOIN
Z ON Oper.Cr = Z.idZ
INNER JOIN
Z2Ref ON Z.idZ = Z2Ref.idZ
WHERE (Z2Ref.idRef IN (1, 3))
GROUP BY Z2Ref.idRef
) CrS
ON DbS.idRef = CrS.idRef
) Agr
INNER JOIN Ref ON Agr.Z = Ref.idRef
Результат выполнения запроса:
Как и в более простых предыдущих запросах их основу составляют два агрегирующих подзапроса которые вычисляют обороты по дебету и кредиту выбранных аналитических признаков. Задание признаков в этом примере сделанное через оператор in(), в реальных запросах может быть и результатом подзапроса.
Конечно в реальной жизни к этому и так немаленькому запросу прибавятся еще не мало дополнительных прибамбасов. Это может привести к тому, что запросы станут плохо читаемы. Поэтому для их создания следует применять шаблоны или даже некий псевдоязык который будет скрывать сложность реальных запросов. Можно так же попросту разбить запрос на несколько отдельных запросов, а связывание этих запросов производить средствами TSQL (PLSQL для Oracle) или в middleware. Главное учитывать, что дебетовый подзапрос есть "зеркальное" отражение кредитового, а первый уровень всего лишь добавляет текстовые описания к аналитическим признакам.
Заключение
Все проблемы с формированием базы и запросов разрешимы. Я больше задумываюсь над тем, что к универсальной структуре базы нужны универсальные механизмы работы. В далеком 96-м мы решили создать набор компонентов который стал бы оберткой над этой универсальной структурой и смог бы быть дополнительным уровнем абстракции. Первую попытку мы сделали в 97-ом. В качестве объектной модели мы выбрали COM и ActiveX. В качестве первого средства реализации использовалась Delphi. Мы сделали набор визуальных компонентов для работы со справочниками, тестовую версию которых можно скачать с нашего сайта http://www.optim.ru/Software/rus/invoice/download.asp. Опыт разработки таких компонентов показал, что для их создания нужно применять middleware-слой (первые компоненты были сделаны в двухуровневой технологии клиент-сервер) и нужна независящая от языка и имеющая ряд особенностей технология доступа к данным. Одной из особенностей такой технологии является возможность передачи и динамического изменения метаданных для каждого элемента курсора. Второй вывод сделанный нами – нужна инфраструктура позволяющая динамически создавать пользовательский интерфейс. Именно тогда мы приняли решение создать ascDB и ascContainer. В виду серьезных ограничений накладываемых (особенно в те времена) Delphi (вернее VCL) мы приняли решение использовать для создания этих компонентов VC и ATL (тогда еще толи 1 толи 2). Мы назвали эти компоненты нижнем слоем ядра конструктора учетных систем, а сам подход проблемно ориентированными компонентами. Собственно сначала даже не планировалось делать эти библиотеки коммерческими (они предназначались только для внутреннего использования).
В ближайшее время мы планируем начать работу над следующим слоем – над новой версией набора компонентов для работы со справочниками (в которой будут учтен опыт полученный нами в пилоном проекте). И над так называемом ядром. Это ядро будет организовано по описанным выше принципом, но будет содержать кучу дополнительных технологий которые нужны для полнофункциональных учетных систем. Так там будет работа с валютой, расчет оборотов и остатков, работа со справочниками (с помощью набора компонентов о котором говорилось выше) и многое другое. Конечной идеей является многоуровневого конструктора позволяющего "собирать" приложения прямо на глазах у заказчика. В этот конструктор будут подключаться модули которые вместе с расширениями для ядра должны позволить создавать системы из модулей независимых производителей.
Так вот, ... к чему я виду? Не хочет ли кто присоединится к этому проекту. Минимум, что нужно это более детально сформулировать идеи (на бумаге) и обсудить эти технологии. Так же было бы интересно заполучить алфа- и бета-тестеров которые помогали бы нам в создании этого конструктора. Ну, и естественно мы не отказались бы от сотрудничества с заинтересованными фирмами (особенно с богатыми) и частными лицами. В зависимости от доли участия первая версия этого продукта вам будет передана или вообще бесплатно или с большой скидкой, с теми кто готов но болшее сотрудничество участие и выгоду можно обговорить отдельно. Ну, и естественно вы получите возможность получать ответы на свои вопросы и использовать беты для создания пилотных версий ваших продуктов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Эта тема частично является ответом на вопросы поставленные в
[skip]
Здорово. Теперь немного жизни.
Приходишь ты в контору устанавливать свою бухгалтерию. Тебе говорят — щас закончим период, подобъём баланс и начнём вводить остаточки...
Вопрос — куда их тут вводить, или вдалбливать все проводки от Великой Октябрьской Революции?
VD>В ближайшее время мы планируем начать работу над следующим слоем – над новой версией набора компонентов для работы со справочниками (в которой будут учтен опыт полученный нами в пилоном проекте). И над так называемом ядром. Это ядро будет организовано по описанным выше принципом, но будет содержать кучу дополнительных технологий которые нужны для полнофункциональных учетных систем.
(шёпотом) Влад, вебсервисы. Вебсервисы, Влад.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Здорово. Теперь немного жизни. IT>Приходишь ты в контору устанавливать свою бухгалтерию. Тебе говорят — щас закончим период, подобъём баланс и начнём вводить остаточки... IT>Вопрос — куда их тут вводить, или вдалбливать все проводки от Великой Октябрьской Революции?
Ну, это азы бухучета... Остатки вводятся простыми проводками. Заводится специальный аналитический объект... В зависимости от необходимого уровня аналитики создаются ответные объекты. И делаются проводки... в предшествующем необходимому периоде... и в корреспонденции с другими аналитическими объектам.
"Уровень аналитики" – означает, что если, например, нужна информация в разрезе каждого подотчетника, то придется завести по объекту (и по проводке) на каждого из них, а если достаточно остатков на счетах, то аналитические объекты должны соответствовать бухгалтерским счетам (но обычно это от лени...)
VD>>В ближайшее время мы планируем начать работу над следующим слоем – над новой версией набора компонентов для работы со справочниками (в которой будут учтен опыт полученный нами в пилоном проекте). И над так называемом ядром. Это ядро будет организовано по описанным выше принципом, но будет содержать кучу дополнительных технологий которые нужны для полнофункциональных учетных систем.
IT>(шёпотом) Влад, вебсервисы. Вебсервисы, Влад.
Вот ты издеваешься, а ведь действительно прийдется даже вводить конвертер чего попало в XML. ^(
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
IT>>(шёпотом) Влад, вебсервисы. Вебсервисы, Влад.
VD>Вот ты издеваешься, а ведь действительно прийдется даже вводить конвертер чего попало в XML. ^(
Влад я тебе по дружбе и по секрету могу продать генератор проксей вебсервисов для не-.NET приложений, типа WSDL.exe, который генерит классы обёртки lkz C++. Но только при условии, что ты забудешь про DCOM как про страшный сон
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте VladD2, Вы писали:
VD>В ближайшее время мы планируем начать работу над следующим слоем – над новой версией набора компонентов для работы со справочниками (в которой будут учтен опыт полученный нами в пилоном проекте). И над так называемом ядром. Это ядро будет организовано по описанным выше принципом, но будет содержать кучу дополнительных технологий которые нужны для полнофункциональных учетных систем. Так там будет работа с валютой, расчет оборотов и остатков, работа со справочниками (с помощью набора компонентов о котором говорилось выше) и многое другое. Конечной идеей является многоуровневого конструктора позволяющего "собирать" приложения прямо на глазах у заказчика. В этот конструктор будут подключаться модули которые вместе с расширениями для ядра должны позволить создавать системы из модулей независимых производителей.
VD>Так вот, ... к чему я виду? Не хочет ли кто присоединится к этому проекту. Минимум, что нужно это более детально сформулировать идеи (на бумаге) и обсудить эти технологии. Так же было бы интересно заполучить алфа- и бета-тестеров которые помогали бы нам в создании этого конструктора. Ну, и естественно мы не отказались бы от сотрудничества с заинтересованными фирмами (особенно с богатыми) и частными лицами. В зависимости от доли участия первая версия этого продукта вам будет передана или вообще бесплатно или с большой скидкой, с теми кто готов но болшее сотрудничество участие и выгоду можно обговорить отдельно. Ну, и естественно вы получите возможность получать ответы на свои вопросы и использовать беты для создания пилотных версий ваших продуктов.
Я так понял твои слова, что то, что выложено на www.optim.ru — это как раз и есть пилотный проект? И все это будет переписано с нуля? В таком случае можно поподробнее про присоединение к проекту? Как ты себе это видишь? Особенно интересует статус кода, полученного в ходе такого сотрудничества в смысле имущественных прав на этот код прошу прощения за меркантильные вопросы.
Здравствуйте VladD2, Вы писали: VD>Так вот, ... к чему я виду? Не хочет ли кто присоединится к этому проекту. Минимум, что нужно это более детально сформулировать идеи (на бумаге) и обсудить эти технологии. Так же было бы интересно заполучить алфа- и бета-тестеров которые помогали бы нам в создании этого конструктора. Ну, и естественно мы не отказались бы от сотрудничества с заинтересованными фирмами (особенно с богатыми) и частными лицами. В зависимости от доли участия первая версия этого продукта вам будет передана или вообще бесплатно или с большой скидкой, с теми кто готов но болшее сотрудничество участие и выгоду можно обговорить отдельно. Ну, и естественно вы получите возможность получать ответы на свои вопросы и использовать беты для создания пилотных версий ваших продуктов.
Собственно есть некторый опыт создания объектов учета, но для 1С. Как-то появлялась идея сделать их в ActiveX виде, но как-то не нравится мне все это — слишком маленький спрос (другое дело в 1С). Более поробно см. на vtools.narod.ru, раздел БыстрыеРегистры (аналог стандартным регистрам 1С, но переписанных для использования с произвольными БД и значительно быстрее работающие)
Здравствуйте IT, Вы писали:
IT>Здравствуйте VladD2, Вы писали:
IT>>>(шёпотом) Влад, вебсервисы. Вебсервисы, Влад.
VD>>Вот ты издеваешься, а ведь действительно прийдется даже вводить конвертер чего попало в XML. ^(
IT>Влад я тебе по дружбе и по секрету могу продать генератор проксей вебсервисов для не-.NET приложений, типа WSDL.exe, который генерит классы обёртки lkz C++. Но только при условии, что ты забудешь про DCOM как про страшный сон
Ты серьезно (про DCOM)? Я думаю пока .Net не окрепнет среди внутриофисных решений у него конкурентов нет. WSDL — это для внешних связей. Будет тормозить да и там все стэтлес.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте alexm1202, Вы писали:
A>Я так понял твои слова, что то, что выложено на www.optim.ru — это как раз и есть пилотный проект? И все это будет переписано с нуля?
Почти. Есть новые технологии и много обкатанных идей.
A>В таком случае можно поподробнее про присоединение к проекту?
Конечно. Собственно о том и речь. Мы конечно попытаемся справится и одни, но боюсь постареем раньше.
A>Как ты себе это видишь? Особенно интересует статус кода, полученного в ходе такого сотрудничества в смысле имущественных прав на этот код прошу прощения за меркантильные вопросы.
Если честно, то сотрудничество в плане кода ядра, в денежном плане, я пока себе вообще никак не представляю. Как сотрудничать на уровне модулей, концептуально описано на нашем сайте, а вот с ядром? Общая идея кто что сделал тот это и продает. Плюс возможность продавать интегрированные решения (естественно отписывая сторонним разработчикам). Но ядро — это базис которое очень трудно разделить. Здесь нужно обсуждение.
Обсуждение нужно и в стратегическом плане. Те технологии на которые мы делали ставки 5 лет тому назад потихоньку уступают место новым, но вот стоит ли прыгать? Короче, вопросов намного больше чем ответов. Думаю со всего этого нужно и начать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте IPetrov, Вы писали:
IP>Собственно есть некторый опыт создания объектов учета, но для 1С. Как-то появлялась идея сделать их в ActiveX виде, но как-то не нравится мне все это — слишком маленький спрос (другое дело в 1С). Более поробно см. на vtools.narod.ru, раздел БыстрыеРегистры (аналог стандартным регистрам 1С, но переписанных для использования с произвольными БД и значительно быстрее работающие)
В 1С мне очень нравится маркетинговая идея. Хотя вру не очень, мне не нравится, то что все замкнуто на них. Я конечно их понимаю, но работать на дядю (даже Нуралиева) у меня желания нет. Я и без него неплохо на жизнь зарабатываю.
Если сделаем достойный продукт, то 1С первым придет с идеей дистрибуции, если нет то и говорить не о чем.
Технически 1С-предпиятие (его ядро) — это очень слабый продукт. Причем главные проблемы в идеологии. Там ее попросту нет. Идея плоских таблиц, да и та реализованная хуже чем в Access. Только алгоритмы промежуточных расчетов и заслуживают внимания.
Ну, а задумка того что я предлагаю — это далеко не ActiveX-ы. Это главным образом расширяемое ядро. Причем сделанное на высоком технологическом уровне. Большинство идей описано на нашем сайте.
Если интересно, то давайте попробуем обсудить все это в живую. Мне пред началом работ нужно многое уточнить и опыт людей работавших с конструкторами очень интересен. Надеюсь что в течении двух-трех лет мы сделаем продукт который заставит многих отказаться не только от 1С-а, но и от "крутых" интегрированных систем. Ах... мечты... мечты...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
IT>>Влад я тебе по дружбе и по секрету могу продать генератор проксей вебсервисов для не-.NET приложений, типа WSDL.exe, который генерит классы обёртки lkz C++. Но только при условии, что ты забудешь про DCOM как про страшный сон
VD>Ты серьезно (про DCOM)? Я думаю пока .Net не окрепнет среди внутриофисных решений у него конкурентов нет. WSDL — это для внешних связей. Будет тормозить да и там все стэтлес.
Вот стейтлес это как раз правильное ограничение. Если тебе нужен какой-нибудь постоянно живущий объект, то делай себе NT сервис и вперёд. Клиенты к нему будут подконекчиваться и узнавать всё, что нужно.
Единственное действительно серьёзное ограничение — отсутствие калбэков и коннекшинпоинтов вместе с ними. Но это не всегда и надо, а если надо, то можешь стоит подумать и всё-таки решить что не надо.
Скорость я пока только замерял на локальной тачке — для стэйтлес объектов DCOM быстрее всего в каких-нибудь 2 нещастных раза, с COM+ не проверял. На удалённой тачке ещё неизвестно как всё это себя поведёт. Плюс это чистый эксперимент на производительность вызовов, добавь туда один SQL запрос и разницы не заметишь.
Но!!! Никакого гемороя с деплойментом. Т.е. абсолютно. Не надо ничего нигде регистрировать, перерегистрировать, разрегистрировать, загрузил программу и всё. Серверная часть пишется на порядок легче и проще, никаких забот о том какой тип строки использовать, где кастинги ставить, когда _ATL_MIN_CRT добавлять и т.п. Клиент тоже не шибко усложняется, даже упрощается в сравнении с COM, обёртка выглядит как обычный C++ класс с методами.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте VladD2, Вы писали:
VD>Ну, тогда уж я вместо COM-а .Net возьму. Там все еще проще, а со строками проблем нет по поределению.
И это правильно, только у меня такой возможности нет. На сервере делай что хочешь, а клиентских машин слишком много, что бы все в раз проапгрейтить. Да и софт существующий в один день не переделаешь. Но мы будем переходить на .NET и на клиентах, будем переходить мелкими перебежками
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте VladD2, Вы писали:
VD>Конечно. Собственно о том и речь. Мы конечно попытаемся справится и одни, но боюсь постареем раньше.
Я бы хотел принять участие в подобном проекте. Но не как представитель фирмы, на которой я работаю (у нас здесь в данный момент задачи не учетные — транспортные), а как энтузиаст-одиночка Ну и со всеми вытекающими.
A>>Как ты себе это видишь? Особенно интересует статус кода, полученного в ходе такого сотрудничества в смысле имущественных прав на этот код прошу прощения за меркантильные вопросы.
VD>Если честно, то сотрудничество в плане кода ядра, в денежном плане, я пока себе вообще никак не представляю. Как сотрудничать на уровне модулей, концептуально описано на нашем сайте, а вот с ядром? Общая идея кто что сделал тот это и продает. Плюс возможность продавать интегрированные решения (естественно отписывая сторонним разработчикам). Но ядро — это базис которое очень трудно разделить. Здесь нужно обсуждение.
А ты не думал о том, чтобы сделать ядро свободным?
VD>Обсуждение нужно и в стратегическом плане. Те технологии на которые мы делали ставки 5 лет тому назад потихоньку уступают место новым, но вот стоит ли прыгать? Короче, вопросов намного больше чем ответов. Думаю со всего этого нужно и начать.
Мое личное имхо — прыгать стоит. По параллельным сообщениям я понял что ты в сомнениях на этот счет?
BR, Alex.
Re[3]: Проектирование учетных систем ][
От:
Аноним
Дата:
27.02.02 10:34
Оценка:
VD>В 1С мне очень нравится маркетинговая идея. Хотя вру не очень, мне не нравится, то что все замкнуто на них. Я конечно их понимаю, но работать на дядю (даже Нуралиева) у меня желания нет. Я и без него неплохо на жизнь зарабатываю. VD>Технически 1С-предпиятие (его ядро) — это очень слабый продукт. Причем главные проблемы в идеологии. Там ее попросту нет. Идея плоских таблиц, да и та реализованная хуже чем в Access. Только алгоритмы промежуточных расчетов и заслуживают внимания. VD>Ну, а задумка того что я предлагаю — это далеко не ActiveX-ы. Это главным образом расширяемое ядро. Причем сделанное на высоком технологическом уровне. Большинство идей описано на нашем сайте.
Я хотел только одно сказать, что я также как и вы делаю что-то похожее. И это похожее — есть расширение ядра 1С (оказывается платформа 1С позволяет делать это). Но так как расширение — это отдельная программа (так называемая внешняя компонента), то нет никакой проблемы переделать в ActiveX для доступа из других программ. Но главная проблема — зачем? Кто будет за это платить деньги? Кроме того — минусы ActiveX технологи очень медленная передача данных (по сравнению со встроеной компонентой скорость упадет на порядок).
Моя идея заключается в том, чтобы создать расширение ядра 1С для тех задач, в которых 1С не справляется (в силу медленного движка или неоптимально выбранного сервера БД).
Т.е. есть рынок — верхний слой пользователей 1С, которым даже SQL версии не спасают. Им нужны решения (по другому говоря они готовы платить деньги). Они хотят иметь решение сейчас. Они не хотят переучиваться для другой программы и т.п.
Разве я неправ? Я не хочу два года работать в пустую... Кстати причем здесь работать на дядю Нуралиева? Мы будем сами разрабатывать ядро, другое дело что для платформы 1С, почему 1С см. выше...
Здравствуйте Аноним, Вы писали:
А>Я хотел только одно сказать, что я также как и вы делаю что-то похожее.
Всетаки Вы меня неправильно поняли. Мы хотим создать нечно иное. Учетное яддно, нод которым уже будет строиться нечтно похожее на конструктор 1С.
А>Кроме того — минусы ActiveX технологи очень медленная передача данных (по сравнению со встроеной компонентой скорость упадет на порядок).
Вы используете термин ActiveX некорректно. Лучше говорить "нипроц-сервер" или "dll-сервер" и exe-сервер. А вместо ActiveX применьт термин COM.
А>Моя идея заключается в том, чтобы создать расширение ядра 1С для тех задач, в которых 1С не справляется (в силу медленного движка или неоптимально выбранного сервера БД).
Ядро 1С — это кривая реализация приметивной идей. Уж извените за грубость. Можно даже сказать, что уних нет ядра. Покрайте мере в моем понимании этого термина. Уних есть завуалированные под документы таблицы, приметивный механизм работы со справочниками и медленный (о чем Вы говорите сами) и неудобный движок для подсчета остаткаов и создания запросов. Это Access переросток, с плохим генеротором отчетов. Расширять или улучшать его я считаю бесперспективным занятием.
Под ядром я понимаю полиморфную структуру которая бы позволяла учитывать (и получать статистику) любые учетные данные. Причем такая структура должна хранить не "документы", а тарзакции (операции). Полиморфность подразумевает, что на некотором уровне агрегацию (ну, и анализ) данных можно производить не взирая на то кто их создавал и какого типа эти данные. Прикладные решения должны быть модулями (плагинами) которые решают прикладные проблемы, т.е. являются сменными програмными (и пользовательскими) интерфейсам, и хранилещами бизнеслогики. Конфигурации 1С — это законченные решения которые очень трудно (а порой и невозможно) интегрировать друг сдругом. Они хранят данные отдельно и для общего их онализа прийдется писать код. Причем такой код будет невозможно использовать повторно.
А>Т.е. есть рынок — верхний слой пользователей 1С, которым даже SQL версии не спасают.
Ну, и зачем делать припарки безнадежно больному?
А>Они хотят иметь решение сейчас.
Хотеть не вредно...
А>Они не хотят переучиваться для другой программы и т.п.
Это их проблемы. Мы хотим сделать более удачное решение и когда оно будет сделано (ну, и если конечно будет ), то выбор у ни будет примерно такой же как сейчас у тех кто сидит под DOC. Или они держутся за старье, или развивают свой бизнес в рюду передовых компаний.
А>Разве я неправ?
Хороший вопрос? В том что с 1С можно сшибить бабок (по легкому) замазывая их дыры и глупость? Конечно правы. Только, как я уже сказал, это не тоже самое, что хочу я.
А> Я не хочу два года работать в пустую...
А кто-то заставляет?
Прсто у нас разные понятия о том что называть работать впустую. Да и к тому же я привык получать от работы удовольствие, а получать удовольствие смотря на лам который клепают в 1С я не могу. Ну, раздаражет меня это все.
А> Кстати причем здесь работать на дядю Нуралиева?
А притом, что работать с ним на равных нельзя. Это его игра и он там устанавливает правила. Его правила просты и неприхотливы твоя роль всегда вторая. Без спроса не суйся. Сеть продаж наша вот и не петюкай. Это все для тех кто не может заработь денг сам, т.е. не для меня.
Мы будем сами разрабатывать ядро, другое дело что для платформы 1С, почему 1С см. выше...
Я так и не увидел зачем это нужно. А разрабатывать ядро для продукта который нужно переписывать с нуля я не вижу необходимости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте alexm1202, Вы писали:
VD>>Конечно. Собственно о том и речь. Мы конечно попытаемся справится и одни, но боюсь постареем раньше.
A>Я бы хотел принять участие в подобном проекте. Но не как представитель фирмы, на которой я работаю (у нас здесь в данный момент задачи не учетные — транспортные), а как энтузиаст-одиночка Ну и со всеми вытекающими.
Ну, что-же. Остается выяснить как можно кооперироваться и какими возможностями (знаниями) ты обладаешь.
VD>>Если честно, то сотрудничество в плане кода ядра, в денежном плане, я пока себе вообще никак не представляю. Как сотрудничать на уровне модулей, концептуально описано на нашем сайте, а вот с ядром? Общая идея кто что сделал тот это и продает. Плюс возможность продавать интегрированные решения (естественно отписывая сторонним разработчикам). Но ядро — это базис которое очень трудно разделить. Здесь нужно обсуждение.
A>А ты не думал о том, чтобы сделать ядро свободным?
Вот даже сейчас думаю. Есть только одна загвоздка я не верю в то, что полностью открытый проект может дать возможность зарабатывать деньги. А деньги зарабатывать нужно. Хотя бы для того чтобы кормить программистов. Они сейчас не дешивы. Хотя будь моя воля только и занимался бы созданием ПО, причем бесплатно.
С другой стороны ближайшие два года на неньги можно даже и не рассчитывать.
В закрытом виде сотридничество с отдельными программистами я себе вижу или как работу по контракту (задача против денег), или если программист берет на себя большой кусок работы и получает (в будущем) долю от прибыли соотвествующую этому куску.
Если проект станет открытым, то сотридничество может идти только в рамках доброй воли, а на счет денег (как я уже говорил) я даже и заикаться не буду. Тут темный лес.
VD>>Обсуждение нужно и в стратегическом плане. Те технологии на которые мы делали ставки 5 лет тому назад потихоньку уступают место новым, но вот стоит ли прыгать? Короче, вопросов намного больше чем ответов. Думаю со всего этого нужно и начать.
A>Мое личное имхо — прыгать стоит. По параллельным сообщениям я понял что ты в сомнениях на этот счет?
Здравствуйте VladD2, Вы писали:
A>>Я бы хотел принять участие в подобном проекте. Но не как представитель фирмы, на которой я работаю (у нас здесь в данный момент задачи не учетные — транспортные), а как энтузиаст-одиночка Ну и со всеми вытекающими.
VD>Ну, что-же. Остается выяснить как можно кооперироваться и какими возможностями (знаниями) ты обладаешь.
Как кооперироваться. Имхо, обсуждаем построение системы, режем ее на части, договариваемся об интерфейсах, реализуем, тестируем, реализуем, тестируем, тестируем... По поводу возможностей — ну, могу CV прислать. Можно просто по аське пообщатся (#22065541, лучше поближе к вечеру).
A>>А ты не думал о том, чтобы сделать ядро свободным?
VD>Вот даже сейчас думаю. Есть только одна загвоздка я не верю в то, что полностью открытый проект может дать возможность зарабатывать деньги. А деньги зарабатывать нужно. Хотя бы для того чтобы кормить программистов. Они сейчас не дешивы. Хотя будь моя воля только и занимался бы созданием ПО, причем бесплатно.
Ну, я возможно неточно выразился, я не предлагаю весь проект делать свободным, и не все компоненты, которые на твоей диаграмме на http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp помечены как ядерные и низкоуровневые. К примеру, свободный визуальный конструктор — это, имхо, перебор. Но библиотека доступа к данным и еще какие-то низкоуровневые компоненты, как мне кажется, вполне могут быть открытыми, это только на пользу проекту будет.
VD>С другой стороны ближайшие два года на неньги можно даже и не рассчитывать.
Вот, я тоже об этом же. Как мне кажется, стоит попытаться начать проект на свободной основе и посмотреть что из этого будет получаться.
VD>В закрытом виде сотридничество с отдельными программистами я себе вижу или как работу по контракту (задача против денег),
А такая схема реальна в данный момент?
VD>или если программист берет на себя большой кусок работы и получает (в будущем) долю от прибыли соотвествующую этому куску.
Тут все зависит от того, насколько большим будет этот кусок.
VD>Если проект станет открытым, то сотридничество может идти только в рамках доброй воли, а на счет денег (как я уже говорил) я даже и заикаться не буду. Тут темный лес.
Если честно, я просто не вижу сейчас альтернативы. Может, я ошибаюсь.
VD>>>Обсуждение нужно и в стратегическом плане. Те технологии на которые мы делали ставки 5 лет тому назад потихоньку уступают место новым, но вот стоит ли прыгать? Короче, вопросов намного больше чем ответов. Думаю со всего этого нужно и начать.
A>>Мое личное имхо — прыгать стоит. По параллельным сообщениям я понял что ты в сомнениях на этот счет?
VD>Да? Ну, тогда я сейчас открою новую ветку http://www.rsdn.ru/forum/message.asp?mid=32159&only
Здравствуйте VladD2, Вы писали:
VD>"Уровень аналитики" – означает, что если, например, нужна информация в разрезе каждого подотчетника, то придется завести по объекту (и по проводке) на каждого из них, а если достаточно остатков на счетах, то аналитические объекты должны соответствовать бухгалтерским счетам (но обычно это от лени...)
Проясните, пожалуйста, вот что. Для количественного учета все понятно (ящик варенья, бочка печенья...). Остатки на складе получаются обороткой за период.
А если необходимо учитывать единицы товара, скажем, холодильники, этот метод применим? Как — детализацией типа "одна позиция — одна накладная"? Или я чего-то не понимаю?
Требования:
Уникальная итендификация каждого товара (например, выводить его инвентарный номер в накладных).
Целостность данных (нельзя продать дважды один и тот же товар, нельзя продать единицу товара до того, как она получена и т.д).
Получение развернутых отчетов о продажах, складе, приходе и т.д.
Если это решается только полной детализацией проводок, то возникает еще один вопрос: насколько это накладно для современных БД, ведь объем данных возрастает многократно?
Если нам не помогут, то мы тоже никого не пощадим.
прошу прощения за меркантильные вопросы.
