Билет 1. Спец по платформе V8

[Clition]

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

Никак. Пишем, считаем, чистим.

[Байт]

Коллеги, прошу покритиковать решение.

[qwentra]

БП из первого билета должен выглядеть вроде так, но я не пойму где ошибка - пользователю не отображается его текущая невыполненная задача, как и его задачи в целом. Помогите, пожалуйста.
UPD. Пошарил по форуму, понял ошибку, фактически получается, что на каждого пользователя должно быть по 2, а иногда и больше записей в РС.
Цитата: ""Если в задании присутствуют строки указывающие например на выполнение пункта всем подразделением без должности, а так же по должности без подразделения, то в РС адресация должны быть записи "Петров / ОтделЗакупок / ", "Петров / / Кладовщик", такая вот особенность системы. ""

[Hatfieldx]

Добрый день!

Решение первого билета с учетом "новых" условий.
Кому не сложно просьба проверьте пожалуйста

[Ender]

ОУ: все хорошо, но ты в параметрах выбора ТЧ уже отсекаешь услуги, движения можно и конструктором сделать для скорости,но и так можно, просто дольше.
ОУ: в запросе для партий в итогах лишнее поле - СУММА(СуммаОстаток)
то же и в БУ: МАКСИМУМ(СуммаПродажи)
к этому могут придраться, лучше не получать то, что потом не используешь.

В отчете по БУ используешь один параметр МассивСубконто для двух таблиц, для таблицы Себестоимость нужен параметр субконто с одним значением: ПВХ Номенклатура, т.к. себестоимость без учета сроков годности. Тоже и в док. РасходнаяНакладная.

В общем модуле ОбращениеКДанным:Движения.ДополнительныеНачисления.Записать();
пропущен параметр только запись.

И еще в модуле формы документа "НачислениеЗарплаты" в процедуре РассчитатьНаСервере ты перед расчетом полностью заполняешь РР, не знаю обращают ли на это внимание, так то ты оклад и результат потом получаешь в общем модуле и получается, что ты просто так заполняешь реквизиты, которые потом рассчитаешь и все равно заменишь.
а так вроде все хорошо, смотрел только код.

[Hatfieldx]

ОУ: все хорошо, но ты в параметрах выбора ТЧ уже отсекаешь услуги, движения можно и конструктором сделать для скорости,но и так можно, просто дольше.
ОУ: в запросе для партий в итогах лишнее поле - СУММА(СуммаОстаток)
то же и в БУ: МАКСИМУМ(СуммаПродажи)
к этому могут придраться, лучше не получать то, что потом не используешь.

В отчете по БУ используешь один параметр МассивСубконто для двух таблиц, для таблицы Себестоимость нужен параметр субконто с одним значением: ПВХ Номенклатура, т.к. себестоимость без учета сроков годности. Тоже и в док. РасходнаяНакладная.

В общем модуле ОбращениеКДанным:Движения.ДополнительныеНачисления.Записать();
пропущен параметр только запись.

И еще в модуле формы документа "НачислениеЗарплаты" в процедуре РассчитатьНаСервере ты перед расчетом полностью заполняешь РР, не знаю обращают ли на это внимание, так то ты оклад и результат потом получаешь в общем модуле и получается, что ты просто так заполняешь реквизиты, которые потом рассчитаешь и все равно заменишь.
а так вроде все хорошо, смотрел только код.

Спасибо большое за комментарий!!

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

Параметр "Только запись" необходимо устанавливать только если у РР использует ПериодДействия (чтобы не пересчитывать ВТ ДанныеГрафика). В данном случае этого делать не нужно.
Вот из СП выдержка:
<ТолькоЗапись> (необязательный)
Тип: Булево.
Определяет режим записи набора. Истина - производится только запись набора; Ложь - производится пересчет фактического периода действия и ввод записей перерасчетов.
По умолчанию при записи набора производится не только собственно запись, но и пересчет периода действия (для регистров расчета с поддержкой периода действия) и ввод записей перерасчета (если необходимо).

Но возможно я не прав.


"В отчете по БУ используешь один параметр МассивСубконто для двух таблиц, для таблицы Себестоимость нужен параметр субконто с одним значением: ПВХ Номенклатура, т.к. себестоимость без учета сроков годности. Тоже и в док. РасходнаяНакладная."

Данный параметр определяет порядок субконто и отбор по счетам по субконто. В данном случае это не имеет значения.

Еще раз спасибо за проверку!

[Макаров]

Решение билета 1 с учетом изменений. Буду рад критике.

[Ender]

ОУ. для РН ОстаткиНоменклатуры - используешь новую методику проведения - здесь управляемая блокировка не нужна.
БУ. ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Субконто1", "Номенклатура") - вместо "Субконто1" следует явно описать субконто: ПланыВидовХарактеристик.ВидыСубконто.Номенклатура (пользователь может менять порядок субконто и блокировка не будет работать).
ПредставлениеНоменклатуры в итогах можно не использовать, будет работать и так.

д.Операции: можно еще добавить установку активности записей при пометке удаления.

[Макаров]

ОУ. для РН ОстаткиНоменклатуры - используешь новую методику проведения - здесь управляемая блокировка не нужна.
БУ. ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Субконто1", "Номенклатура") - вместо "Субконто1" следует явно описать субконто: ПланыВидовХарактеристик.ВидыСубконто.Номенклатура (пользователь может менять порядок субконто и блокировка не будет работать).
ПредставлениеНоменклатуры в итогах можно не использовать, будет работать и так.

д.Операции: можно еще добавить установку активности записей при пометке удаления.

Огромное спасибо!

[lyao]

БП из первого билета должен выглядеть вроде так, но я не пойму где ошибка - пользователю не отображается его текущая невыполненная задача, как и его задачи в целом. Помогите, пожалуйста.
UPD. Пошарил по форуму, понял ошибку, фактически получается, что на каждого пользователя должно быть по 2, а иногда и больше записей в РС.
Цитата: ""Если в задании присутствуют строки указывающие например на выполнение пункта всем подразделением без должности, а так же по должности без подразделения, то в РС адресация должны быть записи "Петров / ОтделЗакупок / ", "Петров / / Кладовщик", такая вот особенность системы. ""

Выходит, что в решениях по БП реализована адресация только по исполнителю? Достаточно ли реализации такого функционала для зачета задачи  по БП?

[Gleb_1c]

Добрый день, смотрю актуальные билет номер 1 задача БУ и в нем есть такое предложение : "При проведении документа анализируется наличие этого товара в организации. Если товара не достаточно документ не проводится." По идее я понимаю что должно быть измерение "Организация" в  разрезе которого смотри остатки. Так вот смотрю на форуме эатлонное решение и не могу найти это измерение. В чем я ошибаюсь , можете посдказать.

[Clition]

В чем я ошибаюсь , можете посдказать.

В условии ничего не сказано о том, что бух. учет должен вестись параллельно и независимо по нескольким организациям, поэтому измерение не нужно, как в билете 4. В общем случае для добавления измерения в РБ на то нужны веские причины, т.е. этот разрез должен быть актуален для большинства (если не для всех) счетов.

[Dmitry_K]

В чем я ошибаюсь , можете посдказать.

В условии ничего не сказано о том, что бух. учет должен вестись параллельно и независимо по нескольким организациям, поэтому измерение не нужно, как в билете 4. В общем случае для добавления измерения в РБ на то нужны веские причины, т.е. этот разрез должен быть актуален для большинства (если не для всех) счетов.

Опять таки по памяти, во всех билетах кроме 4го измерения Организация не нужно заводить.
В четвертом это легко понять по условию "по каждой организации нужно вести свой баланс" .

З.ы. Clition ты когда экзамен сдаешь?)

[Clition]

Clition ты когда экзамен сдаешь?)

Жду результаты.

[yurstein]

Сделал Билет 1 с учетом дополнений. Просьба покритиковать