Переход со старых релизов платформы 1С:Предприятие 7.7 на более новые — задача, с которой часто сталкиваются специалисты, привыкшие работать с современными конфигурациями на платформе 1С:Предприятие 8. Основная сложность заключается в фундаментальных различиях механизмов обновления и сравнения конфигураций в этих двух поколениях систем. При обновлении «семерки» крайне легко допустить ошибку и случайно стереть критически важные доработки, сделанные предыдущими программистами.
В рамках данной статьи мы подробно разберем типичную ситуацию: после обновления конфигурации «1С:Торговля и Склад 7.7» (ТиС) с релиза 7.70.948 на релиз 7.70.996 в документах реализации перестали формироваться суммовые движения по регистру Учет партий ТМЦ. Мы выясним технические причины этого сбоя, проанализируем внутреннее устройство партионного учета в ТиС 7.7 и рассмотрим пошаговый алгоритм исправления ситуации.
Для того чтобы эффективно локализовать проблему, сначала разберем, как в типовом решении 1С:ТиС 7.7 устроен механизм партионного списания. В отличие от современных решений на управляемых формах, где логика проведения документов распределена по специализированным модулям менеджеров и подсистемам проведения, в платформе 7.7 ключевую роль играет Глобальный модуль.
При проведении документа «Реализация» (или любого другого документа, списывающего материальные ценности) система обращается к экспортным процедурам Глобального модуля. Главной из них является процедура глСписаниеПартийТМЦ. Она отвечает за:
Учет партий ТМЦ в количественном и суммовом выражении.В типовом (оригинальном) коде конфигурации номенклатура с типом «Услуга» не имеет материального выражения. Соответственно, по ней принципиально не ведется партионный учет. Программа по умолчанию не рассчитывает себестоимость услуг и не делает по ним суммовых движений в регистре партий. Если в вашей организации до обновления по услугам формировалась себестоимость (например, списывались сопутствующие расходные материалы или учитывались дополнительные затраты), это означает только одно — конфигурация была существенно доработана под нужды бизнес-логики.
Когда программист, имеющий опыт преимущественно в «восьмерке», берется за обновление старой базы 1С 7.7, он может использовать стандартный режим «Объединение конфигураций». Однако в 1С 7.7 этот механизм работает гораздо грубее. Если в 1С 8.3 мы можем детально, построчно объединять модули, визуально контролируя каждое изменение, то в 1С 7.7 при неаккуратном обновлении Глобальный модуль типового релиза может просто полностью перезаписать существующий рабочий модуль, стерев весь кастомный код.
Давайте проанализируем шаги по локализации неисправности.
Прежде чем приступать к анализу кода, необходимо убедиться в том, что в базе верно заполнены ключевые константы и параметры учетной политики. Проверим, задан ли метод расчета себестоимости для фирмы, от имени которой выписываются документы.
В коде проведения документов обязательно присутствует проверка заполнения метода расчета. Если метод не задан, проведение документа полностью блокируется со следующим уведомлением в окне сообщений:
Если ПустоеЗначение(МетодРасчетаСебестоимости)=1 Тогда
глНеПроводить(Конт,"Не определен метод расчета себестоимости для юр. лица """+Фирма.ЮрЛицо.Наименование+"""");
Возврат;
КонецЕсли;
Если подобных ошибок при проведении документов не возникает, а сами документы проводятся без предупреждений, но при этом регистр Учет партий ТМЦ остается пустым в части сумм, переходим к следующему шагу.
Откроем модуль документа «Реализация» (или иного документа, по которому отсутствуют движения) в конфигураторе и найдем строку вызова глобальной функции списания партий. Она должна выглядеть следующим образом:
глСписаниеПартийТМЦ(Контекст,ТаблицаТМЦ,СписокПараметров,ВремПартииНаличие,ТаблСписПартий,ТаблСписПартийКом);
Убедимся, что данная строка не закомментирована (не «заремарена») и передаваемые в нее параметры заполнены корректно. Если вызов функции присутствует, значит, проблема кроется непосредственно внутри тела самой процедуры в Глобальном модуле.
Поскольку проблема возникла сразу после обновления с релиза 948 на релиз 996, со стопроцентной вероятностью был утерян нетиповой алгоритм, внедренный ранее. Для восстановления работоспособности нам потребуется архивная копия базы данных, сделанная ДО процедуры обновления.
Проведем процедуру сравнения и восстановления кода по следующему алгоритму:
old_vendor.md).old_vendor.md.В процессе сравнения обратим особое внимание на процедуру глСписаниеПартийТМЦ. Скорее всего, в старой конфигурации в теле этой процедуры или перед ней находился блок кода, обрабатывающий номенклатуру с типом «Услуга» или принудительно рассчитывающий себестоимость по определенным видам ТМЦ.
Типичный пример доработки, которую затирают при обновлении, выглядит как обход стандартного ограничения на списание партий для услуг:
// Пример кастомного кода, который мог быть удален при обновлении:
Если ВременнаяТаблицаТМЦ.Номенклатура.ТипНоменклатуры = Перечисление.ТипыНоменклатуры.Услуга Тогда
// Здесь располагался алгоритм принудительного расчета себестоимости услуги
// или списания связанных с ней материалов со склада.
КонецЕсли;
Аккуратно скопируем все найденные различия из старого Глобального модуля и перенесем их в Глобальный модуль новой рабочей конфигурации. После сохранения изменений выполним монопольный запуск системы и проведем пересчет бухгалтерских итогов, а также перепроведение документов за период, в котором возникла проблема.
Чтобы избежать подобных критических ситуаций в будущем, рекомендуем придерживаться строгих правил при обновлении устаревших платформ: