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

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

А теперь вот в УТ некоторые процедуры выполняются автоматически уже при формировании отчетов юзерами. Какие тут могут быть подводные камни? Не получится, что после действий, описанных в первом абзаце юзер получит чуточку разные цифры в ЦБ и в ПБ?

Неактуальная / неинтересная тема ? Непутево спросил? Дал мало информации?

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

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

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

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

Нет это не так.... В УПП например каждый раз нажимая кнопку ОК в документе расчет себестоимости можем получать разные циферки.

дык вот и я о том же. По-хорошему, чем меньше ПБ вносит свои коррективы, тем лучше. Вопрос в том, что если уж что-то переформировывается время от времени, не стоит ли переформировывать то же самое регулярно в ЦБ для нивелирования влияния ПБ?

Но так можно дойти до постоянного перезакрывания одних и тех же месяцев! Где истина?

ап

(3) А в УТ-11 после закрытия месяца разве остается возможность менять документы , которые лежат в закрытых периодах?

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

ап

Естественно что он будет получать разные цифры пока данные полностью не синхронизируются. При полной синхронизации юзеры должны получать одинаковые цифры.

(8) после полной синхронизации хотелось бы, чтобы дальнейшие пересчеты если и происходили, то только в центральном узле. Уже писал в (0), что опасаюсь, теория не совпадает с реальностью. Вот и в (2) подтверждают...  Или я ошибаюсь и узел, в котором, например, закрывают месяц, неважен?

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

к (9) "По идее, данные в нем" = "По идее, данные в периферийном, который территориально к буху ближе,"

ап. повторюсь:

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

(3) истина в целесообразности действий

(12) хорошо. тогда по порядку. формировать отчет в ПБ, зная, что это автоматически приведет к "актуализации расчетов" в нем, целесообразно?

Отвечу сам, ибо ответ "на поверхности": конечно целесообразно. Нафига нужна периферийная база, если пользующиеся ею специалисты в удаленном офисе не могут получать необходимые им цифры?! И правильно теперь "актуализация" перед формированием отчета сама автоматически выполняется. Раньше если юзер в ПБ не нажимал кнопку "актуализация" перед формированием отчета, то цифры в нем (в отчете) были некорректны, несмотря на то, что в ЦБ актуализация выполнялась каждые несколько часов регламентным заданием, и результат этого по идее должен был тут же кочевать в ПБ, дабы не утруждать юзеров необходимостью "актуализировать" перед получением отчетов.

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

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

+(14) и еще есть такая штука как RDP, если уж так важно все время видеть на 100% достоверную инфу по всем филиалам

(0) С распределенкой сейчас у программистов 1С не все просто...
Как они перешли на 8.2 у них крышу снесло. Теперь можно ожидать всего чего угодно.
Так что - только тесты, только хардкор.

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

(16) /Как они перешли на 8.2 у них крышу снесло/

у программистов? :)

(18) Ну я даже не знаю кто там пишет код (в УПП точно).

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

(19) ааа Вы про разработчиков типовых, а то как то непонятно звучит "программисты 1С" :) Им тоже не легко угадать все что кому то понадобиться, хотя и ляпы у них конечно же есть, они не Боги... но и ругать их не вижу смысла - можешь сделать лучше делай, не можешь - нефиг ругать...

(19) кстати а что конкретно с УПП не так?

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

Описанная ситуация наблюдалась в УТ11 до того, как разрабы ввели "автоактуализацию" непосредственно перед формированием отчета

(23) правильно нафига нагружать систему, тем более она в принципе все еще на стадии доработок...

(22) Посмотри как партионка работает в случае распределенной ДБ.
До перехода на 8.2 запись в последовательность отрабатывала автоматически платформой.
После перехода на 8.2 запись в последовательность программная, но во всех документах при загрузке данных из узла, стоит игнорирование регистрации в последовательности.

Сегодня обновлял копию базы для буха (без своих доработок) что б можно было делать справку 2НДФЛ для сотрудника. В 48 релизе ошибка в написании строки в форме. В 49 еще хуже ошибка. В общем расстраиваюсь уже второй год. А началось все в конце 2012 года.
Такое ощущение что основную команду кинули на ERP, а тут остались студенты.

(21) никто не ругает разработчиков. Чтобы критиковать, надо сначала до конца понять суть механизма. Когда у меня возникает ощущение, будто я чего-то не понимаю, я начинаю искать информацию в документации и совета у более опытных коллег.

К сожалению, подробных рекомендаций по использованию УРБД я не нашел. Поэтому, если придется организовывать удаленный узел в такой конфигурации, как, например, Бухгалтерия предприятия, я даже и не знаю, что отвечать на вопрос бухгалтера "Можно ли работать преимущественно в периферийном узле, если это территориально более удобно юзеру?", если таковой будет мне задан. Придется, как справедливо замечено в (20), исходить из необходимости, т.е. из практики: если при закрытии месяца в ПБ, результаты будут некорректны в ЦБ, придется ответить бухгалтеру "нет". Ну или может быть мне повезет, и я как-то определюсь в этом вопросе на основании общения с уважаемыми форумчанами.

(26) ну не знаю, я бы бухню вообще урбдшную не стал делать, если конечно в ней не ведется весь учет по предприятию

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

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

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

(29) /Получаю подтверждение своим опасениям/

я ни в чем на 100% не уверен, даже если б мне кто то это прогарантировал:)

а про бухни я написал не из-за опасений, а как раз таки из соображений целесообразности(на мой взгляд конечно) и плюс к этому если это бухня то обязательно, если б даже это была распределенка, то однозначно ЦБ там где работает ГБ

кстати, аську посмотрите

(28) Последовательность восстанавливать только в ЦБ. В ПБ нормально мигрирует (на данные последовательности в ПБ можно не смотреть).
Главное отслеживать что б в закрытый период не лазили в ПБ.
Сейчас лечим проблему путем принудительного сбивания последовательности в ЦБ на период заведомо раньше чем могли входить. Потом восстанавливаем последовательность в ЦБ.
Жду когда исправят.
Еще в середине прошлого года написали письмо в 1С и демо базы им отослали с воспроизведением ошибки. Пока тишина.

(32) а закрывать период не предлагать?

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

(30) однозначно ЦБ там где работает ГБ
жаль... у меня как раз ситуация, когда бухгалтер работает в удаленном офисе, хотя пока УРБД для БП не требовали...
(31) понял, сек...

(32) т.е. то, о чем я писал в (3)

Кстати, если кто-то видел где-то информацию по теме в какой-то из "желтых книжек" или еще где-то, подскажите, пожалуйста.

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

если открывали для одного а делали другое тому кто делал по рукам

(36) Так и есть. Но последовательность сбивают :(
(35) У нас это редко происходит. Обычно в ПБ если сбивают, то не больше чем на месяц. И их сейчас так выдрессировали, что все боятся в закрытый период лазить. Ну разве что зам ГБ постоянно норовит поправить документ прошлого года.

(38) /Ну разве что зам ГБ постоянно норовит поправить документ прошлого года./

Вот всегда не понимал))) А смысл? Это не к Вам вопрос, это вопрос космосу :)

(38) в идеале хотелось бы, чтобы ПБ сбивал не дальше текущего месяца. Тогда еще можно было бы жить, но на практике - увы.

(39) ну.. наверное такие бухи редко встречаются. Большинство все-таки старается не трогать закрытые периоды