v7: Способ обновления при изменении структуры документа в 1С 7.7. #696628

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

шарик , ты балбес (с) м/ф трое из Простоквашино

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

Если неважно что в реквизитах, зачем добавлять вообще?

обоснуй

по этому документу отчетов не делается, а движения документа по регистрам не меняются, отчеты делаются по регистрам

по этому документу отчетов не делается, а движения документа по регистрам не меняются, отчеты делаются по регистрам (c) --- Код обновления данных документа вставить в процедуру ПриОткрытии: при открытии существующего документа новые реквизиты будут заполнены, а при записи документа они будут записаны.  (с) ЗЫ не вижу причин обосновывать, достаточно внимательно прочитать ... ;)

Если выводишь реквизит в журнале документов то будет фигня: у одних заполнен у других нет.

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

мну не ТС , мну и так все понятно ;))) и даже более ...

этих реквизитов не будет в журнале

кончай общаться намеками, прямо говори в чем будут косяки, я же прямо спросил: "Какие могут всплыть минусы в этом варианте?"

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

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

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

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

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

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

ну и вставь переключатель в форму "По старому По новому". Пусть руками и выбирают.

Если все так, как ты здесь расписал, то все будет нормально. Лучше старые документы всегда открывать в режиме просмотра. В форме добавить кнопку "Редактировать". И в этот момент открывать для редактирования и перезаполнять реквизиты.

гыгы, попробуй объянить пользователям открывать старые документы в режиме просмотр чере правую кнопку мыши)))

запрет редактирования рулит

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

Хорошая трава

Нет, ничего обяснять не надо. В процедуре ПриОткрытии Если Форма.ТолькоПросмотр = 0 Тогда Если флЭтоСтарыйДокумент = 1 Тогда

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

И каким образом кнопку "Изменить" нажимать если форма в режиме только просмотр.

Как раз только кнопки доступны в режиме ТолькоПросмотр. А реквизиты формы недоступны.

Продаешь?

Трава как трава. Сам такую курил.

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

где афффтор?

ща, дай 10 мин., длинную петицию пишу, может поможет разъяснить ситуацию

даже если форма в режиме только просмотр, что меняется? реквизит объекта поменялся при открытии, возникнет модифицированность...

Так реквизит менять не при открытии, а при интерактивном нажатии на кнопку "Редактировать".

да, так, наверно, еще можно

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

много букв, типовые решения для 77 еще не инопланетяне писали

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

залипуха, сам таким иногда занимаюсь. Если пользователь открывает документ и нажимает ОК, то вся ответственность ложится на него, иначе оставляем как было, и программист тоже ни причём

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

> Раньше данные для движений вычислялись ... сложным образом. Теперь мы решили это упростить и часть из этих данных будет заполнять пользователь. / все что юзвери делают руками - все криво и требует постоянного контроля. там где контроль над данными вносимыми юзером - невозможен - всегда будут ошибки, которые либо приводят к правдоподобнйо отчетности либо к неверной - но те или иные ошибки - не видно. отчетность недостоверная, фирма в жпс.. все удивляются.. потом - виновать программист.. ;-)

Если нет УРБД - чего париться? Даже если 100500 документов - все можно выполнить меньше чем за минуту

переведи на русский, что ты имеешь ввиду

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

+ "...обработку заполнения, которая при старте, можно запустить в фоновом сеансе..." Обработка заполнения не сможет "вычислить" значения всех новых реквизитов. Ну например если рассмотреть тот же ВидТМЦ. Раньше при проведении документа использовалось значение из номенклатуры, которое вводилось один раз при создании номенклатуры и не менялось. Недавно понадобилось его менять для разных документов. Пользователи долго не думая сделали просто: для 1-го документа установили одно значение ВидаТМЦ в номенклатуре - провели документ, потом для 2-го документа установили другое значение - провели 2-ой документ. И так работают уже несколько недель. Потом вдруг кто-то из них захотел перепечатать 1-й документ. И увидел что данные вида ТМЦ печатаются другие: в движениях одно значение стоит, а в печатной форме - другое. Когда это обнаружилось, решили реквизит ВидТМЦ перенести в документ. И как теперь при автоматическом заполнении вида ТМЦ в 1-м документе "вспомнить" какое значение использовалось на момент проведения? "...при наличии нескольких тысяч документов, которые надо, открыть, отредактировать и сохранить..." Не надо тысячи документов открывать и редактировать. Из старых документов интересуют только те, которые надо по какой-то причине перепечатать. Остальные трогать никто не будет, движения у них верные.

Мну вообще в корне не нравится вариант, когда проведение документов зависит от реквизитов, не являющихся шапкой/ТЧ самого дока... . Если проведение дока зависит от типа Если Док.Договор.ТипДоговора = 1 Тогда... . д.б. имхо . Если Док.ТипДоговора = 1 Тогда... . или если есть в алгоритмах проведения доков ссылки на реквизиты ссылок-реквизитов документа - то надо блокировать их изменение.. типа как - меняешь в настройках системы валюту упр учета - а оно тебе - фиг, т.к. используется уже где-то... . правда как такую блокировку ставить - непонятно... Док.Договор.ТипДоговора - может быть упомянут только в алгоритме - и как при этом блокировать Договор.ТипДоговора на изменение..? - в алгоритме заполнять таблицу "неприкасаемых" реквизитов - ну так нихрена не получится - ктото при написании кода заполнит, а кто-то забъет.. с другой тсороны умная система - при сохранении кода модуля - парсит/анализирует - еслинаходит такую "ссылку" - автоматом добивает код блокировки такого реквизита н аизменение... . бред..???

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

"...даже если 100500 документов - все можно выполнить меньше чем за минуту..." Ну для большинства старых документов наверно получится автоматически вычислить новые реквизиты по движениям документа. Но не для всех. И что делать с теми доками где однозначно невозможно определить эти реквизиты?

Утвердить алгоритм, по нему заполнить все, что можно однозначно определить. В документе дополнительный реквизит - флажок "РеквизитыЗаполненыПрограммноИОднозначноПоУтвержденномуАлгоритму". И выдавать сообщение пользователю при открытии, или при печати.

Телапатирую.. Речь об алкоголе, в документы пихают код АП и ЯПроизводителя/импортера.. да ?

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

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

КГ/АМ, не придумывай вейлосипед... Все ровно сведется к одному:   - у тебя всегда должен быть исходник МД файла с последним изменение до новых изменений   - далее сравниваешь старое с новым и вперед :)    Какие еще могут быть попытки обновления? Самописные не обновляются, а дописываются или попросту вбрасываются и все делается по новому в новой БД :) + Самописаное, это как правило уже написанное от 1С и допилиное до нужно которки :)

Хе-хе-хе... вот у меня было при этом более 20 удаленных баз, и изменения в структуру вносились довольно часто. Поэтому вариант с постоянной реструктуризацией был исключен. Поэтому один раз в МД-шник был залит код, для подключения TurboMD.dll и 1cpp.dll и принудительно запускается при старте пустая обработка. Далее, при необходимости какой-либо реструктуризации, модуль формы этой обработки переписывался через турбоМД, и в "ПриОткрытии" SQL-командами создавались нужные дополнительные таблицы (разумеется с СтатусВозврата в конце процедуры). И затем через тот же турбоМД рисовались новые формы документа, и код, который при открытии собирает данные из доп. таблиц в реквизиты формы, а при записи - сохраняет их. Только с табличной частью документов дело обстоит несколько сложнее.

У меня вопрос не об обновлении конфигурации. А об обновлении данных информационной базы после обновления конфигурации, что в типовых делает обработка при старте "ОбновлениеИБ"

Все просто и тут же сложно. Обычно когда 20 БД, то все пытаются причесать к единому формату. Ибо, когда все 20 и все разные, то у тебя нехватит сил и средств на сопровождения этого зоопарка :)

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

переносите эти реквизиты в партию +доп реквизиты ТЧ в Приходе и ... всё собственно. Достаточно поменять в приходе партию и привет - всё будет ровно во всех расходах.

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

Где я писал, что "все разные"? Наоборот, все одинаковые. Только расскажи мне, как делать реструктуризацию одновременно на 20-40 объектах, с размерами баз - в 3-15 гБ. в каждой и на небыстрых серверах (специально посмотрел - 53 гБ центральная база весила). Ну и режим работы 14/7 (а за 10 часов реструктуризация не успеет закончится) никто не отменял. И не программисты, а 1 (один) программист. З.Ы. Скоро 2 года как на 8-ку перешли, но там свои тараканы...

ровно будет если перепровести все расходы после изменения партии

+ ну и все-таки вопрос в большей степени не в том куда перенести эти реквизиты, а как их заполнить после изменения структуры для уже существующих документов

Нахрена ?

Не надо ничего перепроводить. Ежели это конфа на основе ТиС/Комплексной, то там Партия - элемент справочника.. Ничего перепроводить не надо будет.. вообще.

Создаешь в Партии новые реквизиты, в приходе - текстовые поля для отображения/изменения этих реквизитов в ТЧ дока.. (при записи дока - запись реквизитов в Партию) Усё..

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

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

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

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

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

на пустоту надежи нет, лучше если явный признак будет

как это ?

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

А из движений значение параметров восстановить нельзя ? Просто - движения документа же можно просмотреть.

ну например... если партия.реквизит1 = "какое-то значение" тогда     движение.наценка = 5 конецесли я же привел пример с реквизитом "ВидТМЦ", по-моему все конкретно

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

так делать нельзя. Нужно заводить реквизит1 в самом документе.

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

в таком случае.

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

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

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

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

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

продолжение будет?

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

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