ОУ, БУ, СПР
Спасибо.
ОУ : в приходной накладной нет проверки на вид товара.Думаю это одна из тех проверок, который пользователь сам должен проверить. Иначе можно много всего проверять - на дубли, на незаполненность, на пустые строки.
В расходной накладной нет блокировки на РН Партии. В одном из примеров с описанием специально не блокировался второй регистр т.к. блокирован первый регистр и невозможно работать с РНПартии и не работать с регистром ОстаткиНоменклатуры. Нет документов, которые бы работали только с РНПартии
Согласен - надо или блокировать, или писать комментарий
Сортировать нужно по МоментуВремени()ОК. Но вопрос - если просто сортировать по документу(по ссылке), то при этом не происходит ли автоматически сортировка по моменту времени этого документа?
При расчете себестоимости нет проверки на равенство КолОст нулю.ОК.
При обращении к ПартииОстатки нужно брать на МоментВремени() если не оперативное проведение, либо на нулевую дату если оперативноеВ данном случае Граница(МоментВремени()
Проверять на оперативное-неоперативное при установке момента времени по отзывам - вроде спорно. Экономии времени почти нет.
А в конце обработки проведения Движения.Партии.Записать() конкретно в вашем решении лишнее.Согласен, но я думаю это не должно быть ошибкой.
БУ : в расходной накладной Движения.Управленческий.БлокироватьДляИзменения = истина - лишнее.Есть какое-то обсуждение что таким образом блокируются старые движения на случай отмены транзакции при проведении
В запросах не опеределены типы субконто. Согласен, ошибка.
Проводку Дт «Покупатели» - Кт «Прибыли и убытки» на сумму в продажных ценах делаете в цикле, а нужна одна на документ.
Согласен, ошибка.
зачем на ПланеСчетов признак учета ФлСумм и признак учета субконто ФлКол?Подумал - не нужны.
В отчете тоже не определены типы субконто. ОК
На счетах Покупатели и Поставщики вы поставили субконто Контрагенты, это лишнее, если что-то не указано в задаче, не нужно усложнять себе жизнь 
.Согласен.
СПР : но в ПВР ДопНачисления зависимость от базы по периоду действия, а не регистрацииНаверное всё же "период действия" т.к. к тому же в задании указано что могут быть разные периоды
Не реализовано учловие "В одном документе могут быть данные за разные расчетные периоды.", т.е. в ТЧ нужен реквизит ПериодРегистрации и значение оклада брать по нему. С этим не согласен. Пока обсуждения и ответ сдавшего сводятся что период регистрации в ТЧ это совсем лишнее.
Вместо Движения.ОсновныеНачисления.Записать() и Движения.ДополнительныеНачисления.Записать() нужно - Движения.Записать(). Наверное так лучше. Но как у меня это не должно быть ошибкой.
Зачем в общем модуле вы обращаетесь к тч документа? все,что можно получить из документа нужно делать на модуле объекта, .т.е. в обработке проведения. Я же обращаюсь в запросе к ТЧ в базе данных. А как по-другому? Обращаться к движениям.
В запросе соединение внутреннее, это не правильно, нет проверки на NULL. В чём неправильное? Во внутреннем соединении нет NULLов
Не реализовано условие " При решении задачи необходимо учитывать, что на момент начала ведения учета в информационной базе у сотрудника уже может быть стаж отличный от нуля.", нужен еще один регистр сведений со стажем. Вы стаж вычисляете не в запросе, по мне оптимальнее по максимуму все рассчитывать в нем. Стаж хранится в справочнике сотрудники и я его учитываю.
Насчёт оптимальности в запросе не уверен - что так, что этак суммировать. Красивее наверное вычислить в запросе.
Но мне проще отлаживать в программе.
По-моему это не ошибка.
В РР ОсновныеНачисления лишний реквизит Подразделение.Есть же условие "Каждый сотрудник может работать только в одном подразделении" - значит лучше учитывать
