Почему модули движений по регистрам не писать в модулях регистров? #206463

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

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

Не придерайся к словам, если есть что по существу: буду рад услышать

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

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

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

фантазер!

ИМХО, проведение документа по регистру - это преобразование данных из формата, удобного для ввода/просмотра/редактирования данных, в формат удобный для построения отчетов. Преобразование данных без знания формата исходных данных делать было бы странно, поэтому код проведения по регистрам лучше привязывать к документам.

Все фигня. Кроме пчол

да и пчолы фигня

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

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

"зато преобразование данных без знания формата конечных данных делать не странно..."Я такого не говорил :(.

Это очень сложно придумать и реализовать, хотя возможно, что именно такими должны быть технологии будущего. Я был весной на семинаре Navision+Axapta, там чувак с представительва MS намекал на подобные идеи.Наличие единого и неделимого конфигуратора, на мой взгляд, является одним из главных недостатков 1с.

Тогда надо рассуждать не о том, в какой модуль (в смысле, хранилище текста), что засунуть, а как разделить функционал 1С на модули (в смысле программные объекты с определенным функционалом) с возможностью эти модули произвольным, удобным и ПРОСТЫМ способом соединять. Ну сделает 1С модуль регистров и шо?

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

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

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

Модуль Склад. Приходован товар. Надо запоминать помимо параметров товара поставщика, дату, документ поступления в приходе и контролировать жестко расход с учетом этих параметров?Если этот товар гвозди?Если этот товар лекарство?Если этот товар водка?

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

Что-то никто меня не поддержит, даже странно... (может я плохой?)

Плохой, плохой... ;-)

Не понял в чем смысл вопроса, зачем все это?

Это предложение архитектурных изменений платформы, чтобы решения могли легко комбинироваться образуя необходимый фуекционал.И если технических трудностей нет, то как говориться "зачем дело встало?"

Фигня все это. Не взлетит (и никому не нужно)Пользуйся конструкторами :)

Почему так легко складывать кубики?Потому что они не связаны друг с другом.

Валера, не тупи. В какой-то мере автор прав. Модульность принцип построения практически любой большой системы.Была она заложена и в восьмерке.И вполне возможно к ней еще вернутся.

вряд ли существующие решения будт переписаны... Кролики жрут - чего же боле?.Может быть, в новых решениях что и будет, но для этого нужно сменить1. Команду разработчиков2. Наладить управление проектами3. Просто иметь опыт создания таких систем.Сомнительно, чтобы фирма в существующих условиях тратилась на это.

Боря, я не отрицаю принцип модульности. И как любой нормальный прог, всегда стремлюсь к универсальности, поелико возможно и не тягостно в конкретном случае.Но для системы модульность, сделанная по принципу "а не сотворить ли нам, гениям..." обернется пшиком ;) Это скучный, долгий, занудный стандарт... Требующий немало денег. И который, кстати, не удасться запантентовать (ну ты понимаешь...)

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

Мешает то, что тогда модули регистров будут свалкой всего в непредсказуемом порядке.

А нам, например, надо, чтобы при приемке видеть то, что заказывали.

никто не говорит, что распространяемые модули на 100% вам подойдут.Главное: вместе со складом не купите вагон и ещё тележку ненужных объектов.Но и здесь есть свой плюс: по каждому виду учета модулей будет много (их легче писать) и вы сами выберите самый близкий к своему учету.

Вы же ведь когда хотите поменять картинку на рабочем столе не переустанавливаете Windows. А в систему ставите только те программы, которые вам нужны.P.s. По умному это называется технология COM

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

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

Есть модуль ТОРГОВЛЯ (конфигурация «торговля и склад»), есть модуль Бухгалтерия (конфигурация «Бухгалтерия»), эти модули (конфигурации) существуют не один год, но до сих пор нет единого универсального механизма, по объединению этих двух модуле, т.е. по переносу информации из одного модуля в другой.

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

Вот заведу я заместо модуля регистра "ТымТыгыдым" общий модуль под названием "МодульДвиженийПоРегиструТымТыгыдым". Запихаю туда все алгоритмы для создания движений по этому регистру. Определю точки входа. И шо? Сразу всем ЩАЗЗТЬЕ наступит? Сразу можно различные учетные модули делать? Ну-ну...

Суть в том, что никто не будет делать совместимость ради завтрашней выгоды. Например, есть заказ реализовать модуль Логистика для ТиС, клиент не будет платить разработчику, чтобы этот модуль был совместим с комплексной, или с другими конфигурациями. Разработчик, ради того, что кто-то, может быть, попросить этот модуль добавить в комплексную, разрабатывать бесплатно его тоже не будет. Отсюда получается, что некто не гарантирует совместимость этого модуля с моей версией программы.В качестве примера возьмем FAR и Total Commander. Оба поддерживаю модульное расширение (плагины), но почему-то никто не делает совместимые модули работающих в обоих программах. Так почему же тебе кажется что в среде 1С будет все по другому?

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

комплексные, Пубы и прочая нечисть исчезнут. Клиент сам соберет себе конфу из модулей Если так, то и настоящий продукт продавать не стоит... я тебе на этот вопрос уже отвечал: ты его задал в . Будь оригинальнее

А я тебе ответил, что могут. См. опять . Но это простое деление ничего не даст.

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

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

Просто Алеша пОпов видит не больше параметров, чем есть в почтовых сообщениях...

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

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

2 значит доработке в платформе подлежат не только регистры :) только как перенести логику в регистр. как типизировать все документы? чтобы регистр всегда понимал что это за документ и чего с ним делать?

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

Ты открыл нам всем глаза!

<Главное, чтобы 1с разработал стандарты названий документов и реквизитов.> Мечтатель :), у них в бух и усн, в одной конфе НазваниеОрганизации, в другой НаименованиеОрганизации. И таких фишек много, хоть бы здесь прибрались. Глянь НайтиПоКоду/Наименованию парам ФлагПоиска, здесь 0 там 1.

2 вы знаете у нас все не на уровне творчества программистов, а все на уровне творчества владельцев предприятий, руководителей различного уровня и правительства :) так что вопрос можно смело адресовать им

да я не спорю, что всем нужен разный функционал! Спорю с тем, как мы этот функционал продаем и настраиваем!

Не хотелось писать, но Леша Попов вынудил. Есть понятие "данные", есть понятие "программа" или "код". Это разделение для ряда сред программирования является условным, есть даже такое понятие, как прогамма управляемая данными. Например в Foxpro вы можете почти любую часть кода вынести в таблицы, тем самым структурировав свое приложение, конфигурировать его интерфейс и математику с помощью файлов базы данных.В этом случае код как бы слит с данными, но он управляем последними.В идеале код должен быть изолирован от данных, некий объект, воспринимающий входы и генерирующий некие выходы, в соответствии с тем, что от него просят.Что мы имеем в 1с? Конфигуратор. Метаданные. Метаданные сплетены друг с другом в клубок (вспомним справедливое замечание VZ про кубики), они все переплетены. Вы никогда не вырезали что-нибудь лишнее из конфы, попробуйте оставить в ней один документ из 70? Объект метаданных - это не код, это не данные, это не код, управляемый данными, это код и интерфейс, натянутые на данные, не существующие без них, гремучая неразделимая смесь.И если АП не понимает, что даже с ООП достаточно сложно создавать бизнес-кирпичики, то утверждаю, что с концепцией монолитно-неразделимого MD файла это В ПРИНЦИПЕ не возможно.ты программировал на ООП языках?

(17,54) 99% согласен, но можно было бы даже на базе технологической платформы 7.7,8.0 сконструировать связку между кубиками "бизнес-кирпичиков"Не обязателен ООП, достаточно к примеру: доработать механизм УРБД, настройки миграции элементов метаданных и реквизитов, разрешить обмен между разными конфигурациями - частями одной большой мета-конфигурации, в в именном пространстве которой ведется контроль изменений, уникальности идентификаторов, контроль коллизий.

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

и что ты хотел этим сказать? Читай внимательнее, что люди пишут, я ничего не предлагаю решать. ООП позволяет создавать объекты с вполне определенным интерфейсом, именно используя его как кирпичик. Это очень сложно. Но ООП лучше приспособлен, чем конфигуратор 1С, вот и всею Но при этом я нигде не заявил, что возможно решение поставленной в ветке задачи.с замечаниями полностью согласен

Просто можно создавать новые объекты, в том то и дело, что можно:)

"и что ты хотел этим сказать?"-что я программировал на ООП"ООП позволяет создавать объекты с вполне определенным интерфейсом, именно используя его как кирпичик" -как? реквизиты у объекта суть другие объекты, поэтому никакой выгоды здесь от ООП нет. По этому вопросу готов полимизировать."Но ООП лучше приспособлен, чем конфигуратор 1С" -для чего приспособлен? Чтобы каждый свои объекты создавал, а потом всем миром гадали его загадки? Написано же по-русски: Стандарт -это громадный ПЛЮС! Вот конфигуратор это и есть первый круг стандарта (набор объектов и методов). Я предлагаю ещё сильнее зажать мохровое изобретательство! И после этого "зажатия" можно будет перейти к модулям...

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

Ну, вот так-то лучше, а то в дакой бред был написан, что у меня остатки волос вывалились...

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

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

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

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

а по существу можно?

не понимаю в чем обиды? Сам в первый накатил, а теперь сопли распускает...

А по существу ты флудер.Есть мысли, как (конкретно!) делать? Поделись. Сделай. Продай. Не знаешь? Так чего развел "А вот хорошо бы!!"

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

Не трынди:) И веди себя поприличнее, не на базаре. Что ты со всеми цапаешься, понять не могу? И грохный рык его пронесся, и содрогнулисб горы и сосны:)

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

(alekseychulkov)Да уж, люди сотни книг пишут/читают, пытаясь разобраться, что же есть ООП, а оказывается, пришел Алексей, и подвел итог одним предложением."С помощью ООП единственно можно создать новые объекты и их дальше использовать, как встроенные. И всё!"Буча на свалку!!!Как раз ООП и позволяет создавать "кирпичики", легко связываемые между собой, и не зависящие от внутренней реализации друг-друга. Инкапсуляция и полиморфизм рулят.

Поддержу автора! В 1С 7.7 придумали такой механизм как 1С++. И это практически тоже самое, что предлагает автор. Что делаем? создаем класс на базе ТЗ например. Из модуля проведения документа создаем его и кидаем в него строки с колмичеством. В классе написан общий алгоритм распределения по партиям, тот же модуль регистра. Так что все уже готово.