trdm
возможно вам удастся облапошить покупателя и всучить ему систему, но перед анализом нормального спеца она капитулирует.

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

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

Спасибо за поддержку. Я не ожидал такой реакции здесь. Тем более будет интересно посмотреть на реакцию, когда я закончу. Но это не очень скоро.

v_danilov Это ДАЛЕКО не учетная система, а наколенная разработка.

Это ИМЕННО учетная система, которая выполняет следующие функции - учитывает информацию первичных документов, систематизируя ее, и позволяет формировать любые отчеты по интересующим разрезам аналитики. Если для вас это - не учетная система, значит мы говорим в разных терминах. Я практик, мне нужен толковый продукт, который будет мне давать безглючную оперативную и итоговую финансовую отчетность и обладать способностью к быстрой модификации при приложении минимума усилий и средств. Ни Навижн, ни 1С мне такой возможности не дали. Моя разработка дает УЖЕ. Вот и все.

v_danilov
КАК??? КАК может финансовый аналитик решать подобные задачи??? И ведь это с согласия руководства! О какой компетентности может идти речь???

Вы, видимо, очень крупный специалист как в учетных системах, так и в методах управления предприятием и персоналом. Ведь это же нонсенс! Чтобы финансовый аналитик занимался чем-то там в IT!!! Неправильно! Нас не так учили!!! У нас же график! С 9:00 до 18:00 с ОБЯЗАТЕЛЬНЫМ часовым перерывом на обед!!! Тьфу...
Я - полностью справляюсь со своими функциональными обязанностями, а разработка эта идет не в ущерб моей работе, а в помощь как мне, так и руководству, потому что в конечном итоге результаты моего труда ложатся на стол босса в виде распечатанной аналитики, на основании которой принимаются серьезные решения.
И первый вопрос, который мне он задал, был именно о том, насколько универсально решение, которое я делаю. И именно благодаря гибкости, которая, кстати, была оценена не мной, и было принято положительное решение по внедрению и дальнейшей разработке системы.
Ну а по поводу компетентности... Человек руководит судоходством, горнорудной компанией, фермой, ведет венчурные разработки (не мои, другие), имеет диплом MBA в довесок к базовому. Так что поверьте, все там нормально с компетентностью.

antares0
Немножко поподробнее про событийно-ориентированную систему и логику на таблицах правил.
Можно в личку.

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

Компания
Документ
Событие
Учетная единица
Системная точка движения
Физическая точка движения
Информационная точка движения
Аналитическое измрение

В общем-то вот и весть принцип. Подробнее пока объяснять не буду. Рано.

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

v_danilov
за счет чего?? за счет указанного выше минимума?? приведите пример в три связанных таблицы в рамках "обычной" системы и Вашей.


Я лучше сделаю по другому. Передо мной была поставлена задача автоматизации учета на одной из ферм - на свиноферме. Первичка выглядела примерно так:

6.02.08 г. Опоросилась свинья №-12. Принесла 14 шт. Пропали 3 шт. Осталось 11 шт. Общее количество поросят = 76 шт. Общее количество свиней = 152 шт.
6.02.08 г. Чушка №-6 погиб один поросёнок. Общее количество поросят = 75 шт.
Общее количество свиней = 151 шт.
7.02.08 г. Чушка №- 12 погиб один поросёнок. Чушка №- 10 погибло 5 поросят.
Общее количество поросят = 69 шт. Общее количество свиней = 145 шт.
7.02.08 г. Чушка №-10 погибло 2 поросёнка. Чушка №- 4 погиб 1 поросёнок. Общее количество поросят = 66 шт. Общее количество свиней = 142 шт.
8.02.08 г. Чушка №-4 погиб 1 поросёнок. Чушка №- 6 погиб 1 поросёнок. Общее количество поросят = 64 шт. Общее количество свиней = 140 шт.
9.02.08 г. Чушка №-12 погибло 2 поросёнка. Общее количество поросят = 62 шт. Общее количество свиней = 138 шт.
9.02.08 г. Опоросилась свинья №-13. Принесла 4 шт. Общее количество поросят = 66 шт. Общее количество свиней = 142 шт.


Пример учета реализации:

РЕАЛИЗАЦИЯ ВТОРОГО ПОТОКА

1 - общий вес = 94.4 кг (мясо с ливером) сумма = 14848.0 р. Реализация 6.06.08 г.
Средняя стоимость = 157.0 р.

2 - общий вес = 195.0 кг (мясо с ливером) сумма = 30615.0 р. Реализация 8.06.08 г.
Средняя стоимость = 157.0 р.

2 – общий вес = 169.3 кг (мясо с ливером) сумма = 26241.5 р. Реализация 13.06.08 г.
Средняя стоимость = 155.0 р.


Пример отчета по затратам:

Вет.обслуживание:
КРС = 600.0 р.
Св.матки = 2 000.0 р.
2 поток = 3 000.0 р.
3 поток (142 шт.) = 14 400.0 р.
4 поток (144 шт.) = 7.200.0 р.
шт.)

Эл.энергия 2.300.0 р.

ГСМ аренда а/м 500 р. х 4 раза/мес. х 12 мес. 2 400.0 р.

Покупка кормов на 2009 г. (50 дней):

- 21 плем. х 6.0 кг х 50 дн. = 6 300 кг
- 144 откорм. х 5.0 кг х 50 дн. = 36 000 кг
- 75 поросят х 2.0 кг х 50 дн. = 7 500 кг
- КРС 5 х 4.0 кг х 50 дн. = 1 000 кг
6 х 3.0 кг х 50 дн. = 900 к
ИТОГО: 51 700 кг х 7.6 р. = 392 920.0 р.


Нужно формировать отчетность по следующей схеме:

Доход (реализация):
За месяц / квартал / год /произвольный период
Голов / кг / по средней цене / по среднему весу / на сумму

Расход (затраты)
За месяц / квартал / год /произвольный период
Корма (показать соответствие / несоответствие нормам)
Зарплата
Ветобслуживание
Электроэнергия
ГСМ
Налоги
Прочее
Систематизировать по категориям

Прибыль / убыток
За месяц / квартал / год /произвольный период

На каждую введенную дату:
Поголовье стада (маточного и откормочного)
График изменения поголовья

Учет денег в кассе, в банке
Текущий остаток по счетам
История операций



Так вот. Ответьте, как бы вы решали эту задачу? Сколько таблиц бы использовали? Сколько связей? Так, навскидку. А потом я вам скажу, как эту задачу решил я. Причем решил за 4.5 часа.

v_danilov
ПС: Наверное это не про Вас, и не про Ваше руководство.

Наверное...

Вы мне ответите про задачу учета по свиноферме?

v_danilov
О применимости такого подхода говорить надо?

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

Вот скрин решения:

http://www.zmx.ru/pigs.JPG

SeVa
Рекламировать эту систему среди программистов - пустая трата времени

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

v_danilovSeVaПохоже, что это еще одно "универсальное решение" c весьма спорной идеей - объединить ОLTP и OLAP воедино.

+1
Без геморроя жить можно ТОЛЬКО при НУ ОЧЕНЬ маленьких объемах.

При каких? Например, можно ли считать маленьким объем в 900 000 записей? Это фактический архив операций в Навижне в финрегистре за почти 5 лет работы. Пусть в 1 500 000. Этот объем обрабатывается без проблем на SQL Server. Я то ведь работаю только с Recordset-ами. Скажите, где технологическое ограничение SQL Server по объему записей таблицы, имеющей, например 40 полей, с общим объемом одной записи 4632 байт?

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

СисойЕстественно.
Историю из жизни Альтшулера в начале топика - выучить как мантру. Заказчик покупает не программный продукт, а свои ожидания . Способы решения конкретной функциональной задачи на самом деле мало кого интересуют.

За эту историю отдельное спасибо сказать забыл автору.

Возможно вы и правы. Но пока я полон сил и уверенности. Я не хочу ЗАРАБОТАТЬ на этой системе. Я хочу, чтобы эта система ПОМОГАЛА в работе другим компаниям на том уровне, на котором ее можно будет использовать. Если это сработает, деньги появятся сами. Если не получится сделать из нее что-то тиражируемое - будут единичные инсталяции. Но то, что они будут - не сомневаюсь.

trdm
Как планируете реализовывать конкурентный доступ?

Через создание временного слепка базы обрабатываемого в интерфейсе Recordsetа и сравнении его с текущим состоянием базы перед записью изменений. Если мы об одном и том же.

SeVa ...a Axapta имеет средства для построения кубов и их просмотра...

А у меня данные сразу в кубах хранятся. Мне - проще.
И да - анализ делается по этим кубам.

v_danilovInfinity CreatorНапример, можно ли считать маленьким объем в 900 000 записей? Это фактический архив операций в Навижне в финрегистре за почти 5 лет работы.
ДА

А сколько - много? И еще, если не затруднит, ответьте на это:

Infinity Creatorv_danilovSeVaПохоже, что это еще одно "универсальное решение" c весьма спорной идеей - объединить ОLTP и OLAP воедино.

+1
Без геморроя жить можно ТОЛЬКО при НУ ОЧЕНЬ маленьких объемах.

При каких? Например, можно ли считать маленьким объем в 900 000 записей? Это фактический архив операций в Навижне в финрегистре за почти 5 лет работы. Пусть в 1 500 000. Этот объем обрабатывается без проблем на SQL Server. Я то ведь работаю только с Recordset-ами. Скажите, где технологическое ограничение SQL Server по объему записей таблицы, имеющей, например 40 полей, с общим объемом одной записи 4632 байт?

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

v_danilov
При чем тут SQL-сервер? Я говорю про сам подход "объединить ОLTP и OLAP воедино".

При том, что единственное техническое ограничение для системы - скорость обработки таблиц указанного объема. Объединить воедино не мешает вообще ничего, потому что физически куб - та же самая таблица, и использование простых реляционных связей между кубами и просто, и намного эффективней с точки зрения сложностей связей и обработки данных, чем реализовывать хранение и обработку того же объема и структуры информации в обычном OLTP. То, что на уровне SQL сервера будет выглядеть как 2 таблицы, связанных друг с другом при связи двух кубов, в OLTP может быть офигенно непростой схемой связей между дюжиной таблиц. Как, кстати, и построены пресловутые Навижн и 1С. Тока в Навижне таблиц несколько сот.
И не вижу ваще ничего порочного в идее объединения этих технологий, в одной из которых великолепно реализованы механизмы связей, а в другом - механизмы фильтрации информации.