Может, я и детский лепет решила писать. Если что, извиняюсь, но просто уже "Крик души".
В чьих базах совершены ошибки, я озвучивать не буду. Но по помощи студентам "база ошибок" есть, и буду понемногу добавлять здесь.
Типичные ошибки:
1. Поле объекта не обнаружено
2. Метод объекта не обнаружен
3. Неверный параметр "ИзмеренияОсновногоРегистра" (измерение 1 не соответствует ни одному из измерений основного регистра)
4. Запись не верна! Вид субконто "ВидНоменклатуры" не доступен для данной записи (Регистр бухгалтерии: Хозрасчетный; Номер строки: 1)
Регистр расчета.
Начнем про неверные параметры регистра расчета. Проводим начисление зарплаты, и вылетает такой Привет.
Если нажать Подробно и Конфигуратор, то выкинет на соответствующий вид расчета, где и была ошибка. А теперь вчитываемся по буквам в Массив Измерений и в данные регистра, думаю, все теперь ясно.
Здесь, конечно, нарушены и стандарты разработки. Режет глаз. Но поскольку это чисто набросок, то думаю, этот стандарт мы все же опустим. На итоговой кураторы, думаю, точно такого не допустят, если студент до неё дойдет, конечно)))
Регистр бухгалтерии
Запись не верна! Вид субконто "ВидНоменклатуры" недоступен для данной записи (Регистр бухгалтерии: Хозрасчетный; Номер строки: 1)
Здесь типичная ошибка платформы. И это не новинка. Слетают настройки субконто. У регистра расчета, к слову, тоже могут слетать настройки планов видов расчета. Не встала база для данного вида расчета и дело с концом. Ошибки не вылезет, просто результат будет 0 или null. Найти это можно только в процессе отладки.
PS: Живой пример, когда мы создаем ВидРасчета, например, Премия, который зависит от базы (оклада). Так вот, когда мы ставим базовые виды Расчета для той же Премии, они могут не встать, в итоге база Null и результата нет, либо результат 0, если мы вооружились на нужное нам числовое поле функцией ЕстьNull(). В процессе отладки мы найдем, что база нулевая, но ведь мы в конфигураторе все настройки сделали! Но увы, и в предприятии нужно проверять.
Переходим к субконто, мы настроили в конфигураторе:
Но, о чем сказано выше, полезли в предприятии
А там пусто, в связи с чем и вылазит данная ошибка. Причем, может, предприятие скорее всего не даст создать данное субконто, так как ключ уже есть (в конфигураторе) и создать его вновь в предприятии будет дублем неуникальности. Такие ошибки нужно переделывать в конфигураторе и следить, чтоб все встало в предприятии. Или даже если пробовать через предприятие, то в конфигураторе все равно нужно убрать.
Поехали дальше)
Очередная молчаливая ошибка, просто пустой отчет. Здесь нужно копать за признаки учета.
Мы вроде бы сделали самый простой отчет по регистру бухгалтерии, где мы передаем &МассивСубконто и Счет = &Счет. Но у нас пусто.
Для начала посмотрим признаки учета.
Признак учета нам нужен для выбора на счетах.Это Количественный, если нам нужно на каких то счетах считать количество или суммовой, если где-то по счетам нужно считать сумму.
Заводятся они в плане счетов и определяются в целом для счета. Ставим этот признак после создания только на тех счетах, где оно нам нужно.
Есть еще Признак Учета субконто, данный признак нужен для ведения учета в разрезе субконто.
Например, нам нужно счет 41 товары вести количественный учет, значит нам нужен для данного счета признак учета количественный.
Но на данном счете есть субконто Номенклатура, нужно на данном счете закрывать суммовой учет по номенклатуре, а значит нам нужен признак учета субконто Суммовой.
Данные признаки должны быть связаны с ресурсами регистра бухгалтерии.
Регистр сам по себе должен быть связан с планом счетов. А ресурсы нужны для связи с признаками учета. нужно писать Количество - нужен для ресурса Количество признак учета Количественный. нужен суммовой учет в разрезе субконто, связываем ресурс сумму с признаком учета Субконто.
Сумма обязательно должна быть с галочкой балансовый и так же должна стоять галочка корреспонденция в настройках регистра. Так как сумма сама по себе гулять не может где попало, она проходит и по Дебету и по Кредиту. Вы получили зарплату, сумма к вам пришла, от предприятия ушла. Потратили деньги в магазине, сумма от вас ушла и на выручку магазина пошла.
Поехали теперь в настройки счета. У нас отчет по покупателям совершенно пуст, хотя мы вроде все сделали правильно.
Налицо слет настроек субконто.
Если ресурс, например Количество не будет связан с признаком учета Количественный и галки количественный в признаках учета не будет отмечена для того счета, где вам нужно писать количество, то вам при проведении документов выдаст Ошибку: Поле количество должно быть пустым.
В данном случае косяк за пользовательским режимом. Настройки в предприятии не принялись, в итоге это для программы как отсутствие настройки. То есть суммовой учет типа не ведется по контрагентам, так что мы хотим?
Как и с проблемой выше, программа не даст в пользовательтском режиме сделать настройку, может ругнуться на дублирование ключа. Лечим аналогично. Идем в конфигуратор - сбрасываем галки и обновляем базу, после этого опять возвращаемся в конфигуратор и снова обновляем базу. Идем в ПР и проверяем, если все встало, то отчет сформируется без проблем. Всегда нужно смотреть при проблемах с бухрегистром вовсюда: Это настройки счета, признаки учета, связь с ресурсами и если там все норм, тогда уже по модулям в отладчике ищем.
Регистры накопления.
Поле объекта не обнаружено
Если выдает кнопки Подробно и Конфигуратор, то лучше по ним пройтись, там сразу выкинет в нужное место кода.
Если всмотреться, то у объекта не поля Записать, есть Свойство Записывать(), который ставим в истину для того, чтобы осуществлялась запись в регистр методом Записать().
Опять ошибка. По ходу человек решил скопировать движения с одного регистра для другого регистра, не всмотревшись в их структуру. Первый регистр был с типом остатки. Мы же сейчас пишем данные в регистр с типом обороты. У оборотного регистра нет Вида Движения, как и остатков соответственно, поэтому и ошибка. Данную строку можно просто удалить, так как оно не нужно в данном случае.
Итого нас выкинет через подобно на строку:
Движение.Склад = Склад;
Смотрим скриншот выше и смотрим структуру регистра, куда пишем.
То, что слева Движение... это данные регистра, то, что после знака = это данные вашего документа. В документе видим склад есть - оптовый, но в регистре где склад? Потому и ошибка.
Также хочется поговорить о привязках процедур в модулях.
Спрашивается, откуда это? Мы всего лишь нажали кнопку Добавить на форме.
Преобразование значения к типу Число не может быть выполнено
{ОбщийМодуль.Расчеты.Модуль(12)}:СтоимостьСоСкидкой = Сумма - Скидка;
{Документ.РеализацияТоваровИУслуг.Форма.ФормаДокумента.Форма(17)}:Массив = Расчеты.РассчитатьСтоимость(Элементы.Товары.ТекущиеДанные.ЦенаРеализации,Элементы.Товары.ТекущиеДанные.Количество);[ОшибкаВоВремяВыполненияВстроенногоЯзыка, ОшибкаИспользованияВстроенногоЯзыка]
Процедуры на форме состоят из нескольких имен. К имени поля клеится еще событие, а если есть ТЧ, то вставляется имя табличной части. Например СкладПриИзменении, ТоварыКоличествоПриИзменении, ТоварыСуммаПриИзменении. Привязывается процедура в свойствах на закладке События. Выделяем соответствующее поле и жмем лупу.
В данном случае мы при изменении табличной части уже обратились к подсчету себестоимости для... расчета данных о товаре, который еще не внесен. В данном случае у нас значение отсутствует, без типа данных это Null. Поэтому выскакивает данная ошибка. Null это отсутствие значения, которое непонятно даже платформе. То есть расчет стоимости и скидки мы делаем ПриИзменении() соответствующих полей, но тут оно излишне, это вариант как в каждую бочку затычка, но лучше взвешивать подобное.
Итого, такие вещи сразу убираешь. Этот код должен быть для подсчета, но в процессе вылезает еще одна ошибка
Проверяем.. На форме имя правильное, в объекте тоже:
Интересно, в документе у нас ЦенаРеализации, в общем модуле просто Цена. Но процедура в привязке стоит ТоварыЦенаПриИзменении(), то есть мы сначала создали реквизит, привязали процедуру, а потом переименовали реквизит. Так лучше не делать. Кроме того, что вызов на форме не на месте, так как она должна вызываться при изменении другого поля. Другой раз неправильная привязка к событию может давать хорошие баги. Как здесь например вызов расчета себестоимости при изменении каждого поля. Добавлю следующее:
Когда вызываем процедуру из общего модуля, то переменные должны сопоставляться по типу в строгой последовательности.
Плюс учитывая в общем модуле Директиву &НаКлиенте, я бы все таки делила бы эти вещи отдельно на клиентские и серверные. Хоть и в типовых бывает что объединяют, но без знания дела эти вещи могут закончиться багами, поэтому лучше делить.
Про Вариант Null так же добавлю, что все что платформе неизвестно, любое отсутствие значения это Null, Поэтому всегда прописываем тип данных. А если есть риск отсутствующего значения, то есть функция ЕстьNull(), с помощью которой можно так же вывести число 0 или даже текст, если вдруг нужно. Оговаривается данных функционал по теме запросов.
Настройки Сервер, Клиент, ВызовСервера, Экспортные функции
Также другой раз не всегда соображаем, куда копнуть при вызове процедур из общих модулей.
Как это не вызвать? Полезли в общий модуль.
Галки Сервер и вызов сервера есть. Если стоит Сервер и клиент, то писала выше, что на начальном этапе изучения лучше делить. В Типовых совмещают, но как.. рано или поздно может поймем, но пока лучше по отдельности изучать для понимания.
Итого галки все нужные стоят, переменные по порядку сделаны как надо.. А... Мы для вызова процедуры из общего модуля забыли её сделать экспортной. То есть по сути в общих модулях мы ставим процедуры экспортными, чтоб к ним обращаться с любого места и не кодить в каждой справке/документе один и тот же код. Прописываем ЭКСПОРТ
Это как минимум тех ошибок, которые просматриваешь каждый день, помимо своей Итоговой работы. Но куда ж без помощи студентам)))
