БП - обратится к содержимому проводок в процессе проведения
 

Возможно-ли такое? То есть по аналогии с 7.7,после Операция.Записать()

Дело в том-что мне нужно проанализировать в документе ТребованиеНакладная результат проведения и опираясь на эти данные сформировать движения по регистру.То есть чтобы после основного проведения документа он проанализировал результат своего проведения и допровёлся ещё по одному регистру.

По сути мне нужны данные о кол-ве и сумме списанных материалов, то есть заполненная ТЗ по функции
Функция ПолучитьСуммуСписанияАктивов(ТекДокумент)
из общего модуля БухгалтерскийУчет.

В каком месте кода мне к ней обратиться, чтобы ТЗ была заполнена. Попытка обратиться в конце Процедуры ОбработкаПроведения() модуля документа ТребованиеНакладная выдаёт пустую ТЗ,то есть функция не видит проводок.

качественный вброс :)
чувствуется рука мастера

(2)а если по существу? подскажите, пожалуйста.

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

(4)ага, жду, удачного похода

Возможно

(6) через подписку на событие ПриЗаписи - правильное решение?

(6)прошу помочь советом, как это правильно сделать

8-Looking > Так вообще не правильно делать. Документ отвечает движениями согласно только своему содержимому. За себя отвечает. Потому и имеет свойство перепроведения, в т.ч. для восстановления движений.
Что придает всей системе некую предсказуемость и надежность.
А для обработки общего состояния обычно конструируют отдельные сущности. Типа [em]ЗакрытиеМесяца[/em] и т.п.

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

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

+(10)если конкретнее, то по документу Требование-накладная в типовом механизме происходит списание материалов в разрезе мест хранения по рассчитанной типовым механизмом стоимости.
в то время как в табличной части документа добавлен реквизит - Сотрудник, то есть информация более детальна, чем списываемая по бух.учёту.
Таким образом количество для детализации по Сотрудникам мне нужно взять из ТЧ, а суммы для этой более детальной информации нужно взять из бух.учёта.

11-Looking > Ты подумай-подумай...
Юзер1 Генерит твои документы. Юзер2 тоже генерит. Юзер1 спохватывается "Ах я забыла..." и возвращается к документу1, тогда как юзер2 уже закончил и провел документ2, который, в свою очередь, учел движения документа1. Когда документ1 будет "поправлен", кто будет перепроводить документ2 и т.д.? А если юзер1 начнет "поправлять" после ввода всей "своей пачки"? И "сверху вниз"?
Ах, оне так "делать не будут"... Нуну. Закладываем переменные свойства юзера с неопределенной и неконтролируемой характеристикой... Удачи.

(12)стоп, какое отношение описываемое имеет к моей ситуации?
ещё раз более подробно, есть ТЧ:
Строка 1: Гайка ЦентральныйСклад Иванов 1 шт
Строка 2: Гайка ЦентральныйСклад Петров 1 шт

по документу с такой ТЧ по бух.учёту формируется проводка
Гайка Центральный склад 2шт 100 руб

Мне нужно получить данные из этой проводки,посчитать среднюю цену Гайки = 100/2 = 50

и добавить движения по регистру
Гайка ЦентральныйСклад Иванов 1 шт 50 руб.
Гайка ЦентральныйСклад Петров 1 шт 50 руб.

Если документ и перепроведется, то и суммы проводок изменятся, соответственно и по регистру суммы тоже изменятся, так ведь?
Или я какой-то момент не понял из (12)?

+(13)теоретически можно ведь и не добавлять доп.регистр и движения по нему не регистрировать, достаточно в отчёте брать данные о сотрудниках из ТЧ документа, а о суммах из проводок документа, высчитывая по каждому документу среднюю цену списания и получая сумму списания по сотруднику путём умножения средней цены на количество.
Но разумно-ли это? Да - пи этом типовой код совсем не затрагивается, но ведь отчёту придётся в разрезе каждого документа средние цены высчитывать?

А нахрена вообще нужна переменная и записываемая сущность "средняя цена", когда ее можно получить одним арифметическим действом с известными "стоимость на данный момент" и "количество на данный момент"?
И что предполагается делать, если вдруг окажется, что:
средняя цена на данный момент <> (стоимость на данный момент / количество на данный момент) ?

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

под средней ценой я понимаю "среднюю цену для сотрудника", полученную как "сумма проводки документа по материалу"/"количество проводки документа по материалу"

то есть это не среднескладская или среднефирменная цена, а среднедокументная.

(0) [em]"нужно проанализировать в документе ТребованиеНакладная результат проведения и опираясь на эти данные сформировать движения по регистру"[/em]
ИМХО не нужно анализировать [b]результат проведения[/b], а нужно найти место в коде, где [b]подготавливаются[/b] данные для формирования проводки. И по этим же данным сформировать регистр. После чего результатом проведения будут и проводки, и движения по регистру.

(17)такой вариант я озвучивал в (10), всё-таки он наиболее рационален?

[em]можно пытаться идти другим путём - собрать суммы, которые попадают в проводки до их записи и генерировать движения по регистру одновременно с проводками. Но при этом код будет более громоздким, более глубокое вмешательство в типовой код.[/em]

18-Looking > Не наиболее рационален, а единственно корректен (ИМХО). Почему - уже объяснил VZ.

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

Вот будет веселуха, когда в конце месяца корректировка стоимости списания перепилит проводки и данные БУ и новорожденного регистра разъедутся.

ну мастер наш столбик - умеет метко пнуть в самые ....... ниже пояса

20-Looking > О Господи... У нас же не только приход, у нас же и расход. У нас же не один юзер сидит. И обработка их ввода одновременная. С неизбежными конфликтами, коллизиями, и блокировками.
Ну и какое будет чтение регистров для выяснения "средней цены"? "Грязное", или нет? Если нет, то накладывается блокировка другим юзерам, проводящим в это время документы, работающие с этими регистрами. Например, расхода.
А запись посчитанной "средней цены" также будет блокировать действия других документов...
И, между прочим, разрешение коллизий блокировке общего объекта никак не связан с размещением этих документов на временной оси. И с их назначением.
Ты об этом думал? Наверняка - нет. Вот представил себе благостную картину, и "хочу-хочу-хочу хорошего".

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

(21), (22) ну это само собой, либо писать отдельный документ, разбрасывающий по пропорции суммы корректировок между Сотрудниками, либо не обращать на это внимания и опираться на суммы списания "по скользящей" себестоимости

(23)[em]У нас же не только приход, у нас же и расход. [/em]

у меня как-раз таки [u]только расход[/u], это регистр накапливает расход материалов в разрезе сотрудников

(23)[em]Ну и какое будет чтение регистров для выяснения "средней цены"? "Грязное", или нет? Если нет, то накладывается блокировка другим юзерам, проводящим в это время документы, работающие с этими регистрами. Например, расхода.
А запись посчитанной "средней цены" также будет блокировать действия других документов...
И, между прочим, разрешение коллизий блокировке общего объекта никак не связан с размещением этих документов на временной оси. И с их назначением.
Ты об этом думал? Наверняка - нет. Вот представил себе благостную картину, и "хочу-хочу-хочу хорошего". [/em]

то есть в варианте (17) всех озвученных проблем удастся избежать?

[em]не нужно анализировать результат проведения, а нужно найти место в коде, где подготавливаются данные для формирования проводки. И по этим же данным сформировать регистр. После чего результатом проведения будут и проводки, и движения по регистру. [/em]

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

(24), ну отчего-же под идиота-то, вот на Мисте нашли решение

[url]http://www.forum.mista.ru/topic.php?id=592466[/url]

(26) Так так. Ну ка сообщи нам тип регистра?

А на мисте ты такой не один хотя бы. Ископаемый походу искренне верует, что пока транзакция не закрыта - запросы результатов действий, произведенных в рамках транзакции, не увидят... Вроде тертый 1Сник, а все равно

(30)Регистр Накопления, вид - Остатки

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

[em]пока транзакция не закрыта - запросы результатов действий, произведенных в рамках транзакции, не увидят.[/em]

да пусть видят - кому от этого хуже-то? я-же [u]не буду уже сформированные записи править[/u], а [u]только добавлю движения[/u] по дополнительному регистру, на который всегда происходит только приход, расход с него не осуществляется.

(24) А я еще сомневался... надо как то избавляться от патологической наивности...

(32)ну вот о чём-ты? хоть-бы уж тогда в лоб написал - где я по-твоему пишу неправду :(

(32)обидные вещи пишешь безо всякой аргументации, ИМХО не заслужил я этого :(

А если идти путём
[em]нужно найти место в коде, где подготавливаются данные для формирования проводки. И по этим же данным сформировать регистр.[/em]

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

И второй момент - допустим я заполнил нужную мне ТЗ в общем модуле, а как мне к ней обратиться из модуля документа ТребованиеНакладная?

(12)
[em]Юзер1 Генерит твои документы. Юзер2 тоже генерит. Юзер1 спохватывается "Ах я забыла..." и возвращается к документу1, тогда как юзер2 уже закончил и провел документ2, который, в свою очередь, учел движения документа1. Когда документ1 будет "поправлен", [u]кто будет перепроводить документ2 и т.д.?[/u] А если юзер1 начнет "поправлять" после ввода всей "своей пачки"? И "сверху вниз"?[/em]

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

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

Вариант2. Получить те-же самые значения сумм, но за счёт модификации типового кода, и затем также как в Вариант1 добавить записи по регистру.

Я никак не пойму - [u]в Вариант1 и Вариант2 суммы могут получиться разными при каких-то условиях?[/u]

Ведь в обоих Вариантах получение информации об остатках и расчёт средней стоимости абсолютно идентичны и производятся типовым кодом - абсолютно одинаковым. Отличается только способ, которым мы далее эти одинаково запрошенные и одинаково рассчитанные типовым механизмом суммы, запрашиваем для своих нетиповых нужд.
В чём причина, по которой суммы запрошенные по Вариант1 будут отличаться от сумм запрошенных по Вариант2?

Вот что получилось

Создал свою подписку на события

[em]Источник: ДокументОбъект.ТребованиеНакладная
Событие: ОбработкаПроведения
Обработчик:ДвиженияПриходаПоРегиструРасходПоСотрудникамОС.ПодпискаНаСобытие1ОбработкаПроведения


Процедура ПодпискаНаСобытие1ОбработкаПроведения(Источник,Отказ,РежимПроведения) Экспорт

ТЗПроводок = Источник.Движения.Хозрасчетный.Выгрузить();

ТЗПроводок.Свернуть("СубконтоКт2","КоличествоКт,Сумма");
ТЗПроводок.Колонки.Добавить("ЦенаСр",,,);
Для Каждого СтрТЗПроводок Из ТЗПроводок Цикл
ПеремЦенаСр=0;
ПеремКол=СтрТЗПроводок.КоличествоКт;
Если ПеремКол<>0 Тогда
ПеремЦенаСр=СтрТЗПроводок.Сумма/ПеремКол;
КонецЕсли;
СтрТЗПроводок.ЦенаСр=ПеремЦенаСр;
КонецЦикла;

СтрКолТЗТЧ = Новый Структура;
СтрКолТЗТЧ.Вставить("Номенклатура", "Номенклатура");
СтрКолТЗТЧ.Вставить("ОсновноеСредство", "ОсновноеСредство");
СтрКолТЗТЧ.Вставить("Сотрудник", "Сотрудник");
СтрКолТЗТЧ.Вставить("Количество","Количество");
ТЗТЧ = ОбщегоНазначения.СформироватьЗапросПоТабличнойЧасти(Источник, "Материалы", СтрКолТЗТЧ).Выгрузить();
ТЗТЧ.Свернуть("Номенклатура,ОсновноеСредство,Сотрудник", "Количество");
ТЗТЧ.Колонки.Добавить("Сумма",,,);
Для Каждого СтрТЗТЧ Из ТЗТЧ Цикл
ПеремНоменклатура=СтрТЗТЧ.Номенклатура;
ПеремКоличество=СтрТЗТЧ.Количество;
СтрЦены = ТЗПроводок.Найти(ПеремНоменклатура, "СубконтоКт2");
Если СтрЦены = Неопределено Тогда
ПеремЦенаСр=0;
Иначе
ПеремЦенаСр = СтрЦены.ЦенаСр;
КонецЕсли;

Движение = Источник.Движения.СписаниеНоменклатурыНаСотрудниковиОС.ДобавитьПриход();
Движение.Активность = Истина;
Движение.Период = Источник.Дата;
Движение.Регистратор = Источник;
Движение.Номенклатура=ПеремНоменклатура;
Движение.Сотрудник=СтрТЗТЧ.Сотрудник;
Движение.ОсновноеСредство=СтрТЗТЧ.ОсновноеСредство;
Движение.Количество=ПеремКоличество;
Движение.Сумма=ПеремКоличество*ПеремЦенаСр;
КонецЦикла;

КонецПроцедуры
[/em]