Это предостережение для тех, кто пользует конфу 1С:Предприниматель 7.7, устанавливая константу ПризнаниеРасходовПоДоходамПрошлыхПериодов в положение "Нет" (что требует современное толкование НК и ГК).
Есть в гл.модуле замечательная ф-я глДвиженияПоРасходамМатериальныхРесурсов - по сути выполняет списание партий ТМЦ. В эту ф-ю передается (среди прочих) параметр СобственныйЗапрос.
Если этот параметр равен 0, то в ф-и просто берутся конечные остатки партий ТМЦ на позицию проводимого документа. Если не 0, то строится чёрный запрос от начала года до проводимого документа, который якобы вытягивает обороты партий за период с начала года. Я сказал "якобы", потому что на самом деле он обороты вытягивает неправильно. В тексте запроса применена конструкция "Условие (Запрос.Количество > 0)" (ошибочно?), которая приводит к тому что ф-и Приход/Расход в запросе (те самые обороты) возвращают результат в виде 0 либо искаженным.
Может, это было так и задумано разработчиками, но я не могу понять для чего... Это, во-первых.
На последствия конструкции "Условие (Запрос.Количество > 0)" мне глаза открыл многоуважаемый Ёпрст, за что я его от всей души благодарю. В основном, именно за это, а не за многочисленные тексты прямых запросов, полученных от него, которые в большинстве случаев не работали :)))
Во-вторых, при групповом проведении документов постоянное выполнение чёрного запроса в случае, когда СобственныйЗапрос <> 0, приводит к резкому замедлению, примерно на порядок, проведения документов [напомню, "на порядок" значит "в 10 раз"] и к лавинообразному заполнению оперативной памяти и, как следствие, к аварийному завершению программы с ошибкой "Out of memory"
В-третьих. Я сделал анализ, в каких случаях и для чего используется параметр СобственныйЗапрос, не равный 0, в ф-и глДвиженияПоРасходамМатериальныхРесурсов.
Начнем с "для чего". Чёрный запрос якобы (почему "якобы" - написано выше) вытягивает Обороты, чтобы выяснить, какая часть из конечных остатков партий оплачена поставщику в текущем году, а какая в прошлом или ранее (налоговый период для ИП - год). Т.е. конечные остатки партий в таблице (ТаблицаОстатков), возвращаемой из данной ф-и расщепляются на пару строк, признак оплаты поставщику данной доли остатка (текущий/прошлый год) кладется в колонку этой таблицы "ПериодОплатыПоставщику".
Теперь выясним "в каких случаях".
Ф-я глДвиженияПоРасходамМатериальныхРесурсов используется в модулях проведения многих документов, и только один из них - "Реализация ТМЦ" - в качестве параметра СобственныйЗапросможет (если константа ПризнаниеРасходовПоДоходамПрошлыхПериодов /синоним "Отражать доходы и расходы по операциям прошлого года"/ равна "Нет") передавать значение, не равное 0. Значит, только этот вид документа может вызвать выполнение паразитного чёрного запроса.
Проанализируем как документ "Реализация ТМЦ" использует таблицу, возвращенную ф-ией глДвиженияПоРасходамМатериальныхРесурсов. Напомню, что чёрный запрос был призван, чтобы заполнить колонку "ПериодОплатыПоставщику" в возвращаемой ф-ией таблице.
Анализ привел к выводу, что расщепление конечных остатков партий товаров в зависимости от "ПериодОплатыПоставщику" в обработке проведения документа "Реализация ТМЦ"... никак не используется.
Честно признаться, от такого вывода я оторопел.
Т.е. самое обидное из всей ситуации с бесполезным чёрным запросом это "во-вторых": "приводит к резкому замедлению, примерно на порядок, проведения докуметов и ... к аварийному завершению программы с ошибкой "Out of memory""
Мои теоретические измышления я подтвердил практикой (только этим весь день и занимался) - перепровел базу за два года, отключив этот чёрный запрос, и сравнил результат проведения с прошлым результатом, когда лопатился этот запрос. Финансовый результат стал отличным на 5 копеек при 140 млн. руб. оборота за год! ((( Т.е. практика подтвердила выжеизложенную теорию. (5 коп. скорее всего возникли из-за неполной чистоты эксперимента - я попутно исправил мелкую ошибку).
И все-таки, я начал глубже анализировать логику проведения документа "Реализация ТМЦ", силясь понять тайный замысел разработчиков.
Единственное упоминание на необходимость разделения оплат партий ТМЦ поставщику по годам, я нашел только в виде комментария:
// Если оплата поставщику была в этом году, а аванс от покупателя поступил в прошлом году
за которым следует код, который никак не использует полученное разделение.
Анализируя этот комментарий и следующий за ним код, я смог допустить лишь следующее:
Разработчики хотели признать в доходы оплату от покупателя, полученную в прошлом периоде (году) и одновременно признать расходы по оплате поставщику, если оплата поставщику была произведена также в прошлом периоде. Если же оплата поставщику была произведена в текущем периоде (при оплате покупателю в прошлом), то для налогового учета мы не можем признать ни доходы, ни расходы.
На самом деле такая позиция несостоятельна, мы не можем признать оплату от покупателя прошлого года, даже если партия товара была также оплачена поставщику в прошлом периоде. Видимо, и разработчики также пришли к этому выводу и не стали использовать разделение оплат поставщику в модуле проведения документа "Реализация ТМЦ". Но при этом забыли исключить паразитный чёрный запрос в гл. модуле.
Значит, остается эту оплошность исправить самим (и надеяться, что кто-нибудь сможет достучаться по хотлайну до ЗАО "1С", чтобы они исправили это у себя в будущих релизах 1С:Предпринимателя - прошу прощения за наивность).
Итак, все исправления делаются в обработке проведения документа "Реализация":
1) из текста
Если НеПризнаватьРасходовПоПрошлымДоходам = 0 Тогда
СписокРегистров.ДобавитьЗначение("Расходы");
КонецЕсли;
убираем условие - получается:
// Если НеПризнаватьРасходовПоПрошлымДоходам = 0 Тогда
СписокРегистров.ДобавитьЗначение("Расходы");
// КонецЕсли;
это чтобы ф-я глДвиженияПоРасходамМатериальныхРесурсов могла обратиться к регистру партий (Расходы) и вытянуть остатки.
2) Чтобы заблокировать выполнение чёрного запроса строку
Если глДвиженияПоРасходамМатериальныхРесурсов(Контекст, ТаблицаСтоимости, ОбщРег,, НеПризнаватьРасходовПоПрошлымДоходам) = 0 Тогда
меняем на:
Если глДвиженияПоРасходамМатериальныхРесурсов(Контекст, ТаблицаСтоимости, ОбщРег) = 0 Тогда
Уточню, НеПризнаватьРасходовПоПрошлымДоходам - это СобственныйЗапрос в параметрах данной ф-и.
И это всё.
Теперь конфигурация будет проводиться на порядок быстрее и не валиться с ошибкой "Out of memory"! Причем требуемый функционал данной конфы сохранится в полном объеме.
