- Как мне из 1С достать начисления и оплаты покупателей в разрезе договоров? - поинтересовался он.
- Оборотно-сальдовая ведомость по счету 62 - ответил я.

И тут же пришло понимание, что для него эта фраза прозвучала, как какое-то заклинание. Понятно, что человек, увлеченный прогрессивными технологиями, в этом не виноват. Появится больше времени - поделюсь, покажу, научу...

Огорчает другое. Как далеки все эти надутые как пузырь современные парадигмы со всеми своими, по сути второстепенными, шашечками от реального мира. А в реальном мире технарям, и не только им, очень полезно разбираться в экономике и бухгалтерии...

←41 | заметка 42

Итак, нужно у автоматически создаваемых документов подправить стандартные проводки и добавить еще несколько новых. Больше всего для решения подходит вполне себе типовой механизм ручной корректировки. Тут 1С-ники использовали неудачный термин. Вручную делать это вовсе необязательно...

//Сначала заполненный программно документ проводим как обычно,
//чтобы кроме проводок записались все необходимые регистры
НовыйДокумент.Записать(РежимЗаписиДокумента.Проведение);

//Затем меняем реквизит ручной корректировки и записываем уже без проведения
НовыйДокумен.РучнаяКорректировка = Истина;
НовыйДокумен.Записать(РежимЗаписиДокумента.Запись);

//Перебираем существующие проводки, заменяем счет и субконто
Для Каждого Движение из НовыйДокумен.Движения.Хозрасчетный Цикл
	Если Движение.СчетКт = НеправильныйСчет Тогда
		Движение.СчетКт = ПравильныйСчет;
		
		//Перед установкой субконто обязательно очищаем имеющуюся коллекцию:
		//и виды, и значения
		Движение.СубконтоКт.Очистить();
		
		//Устанавливаем нужные субконто (допустим счет у нас взаиморасчетный)
		Движение.СубконтоКт.Контрагенты = НужныйКонтрагент;
		Движение.СубконтоКт.Договоры = НужныйДоговорКонтрагента;
		Движение.СубконтоКт.ДокументыРасчетовСКонтрагентами = НужныйДокумент;
	КонецЕсли;
КонецЦикла;

//Фрмируем новые проводки (например нужно частично сторнировать поступление)
Для Каждого СтрокаНачислений из МассивСтрокНачислений Цикл
	НовоеДвижение = НовыйДокумен.Движения.Хозрасчетный.Добавить();
	НовоеДвижение.Период = НовыйДокумен.Дата;
	НовоеДвижение.Регистратор = НовыйДокумен.Ссылка;
	НовоеДвижение.Активность = Истина;
	НовоеДвижение.СчетДт = Счет20_01;
	НовоеДвижение.ПодразделениеДт = НужноеПодразделениеЗатрат;
	НовоеДвижение.СубконтоДт.НоменклатурныеГруппы = СтрокаНачислений.НоменклатурнаяГруппа;
	НовоеДвижение.СубконтоДт.СтатьиЗатрат = СтрокаНачислений.СтатьяЗатрат;
	НовоеДвижение.СчетКт = Счет60_01;
	НовоеДвижение.СубконтоКт.Контрагенты = НужныйКонтрагент;
	НовоеДвижение.СубконтоКт.Договоры = НужныйДоговорКонтрагента;
	НовоеДвижение.СубконтоКт.ДокументыРасчетовСКонтрагентами = НужныйДокумент;
	НовоеДвижение.Организация = НужнаяОрганизация;
	СуммаБезНДС = СтрокаНачислений.СуммаБезНДС;
	НовоеДвижение.Сумма = -СуммаБезНДС;
	НовоеДвижение.СуммаНУДт = -СуммаБезНДС;
	НовоеДвижение.СуммаНУКт = -СуммаБезНДС;
	НовоеДвижение.Содержание = "Реализация услуг";
КонецЦикла;

//Записываем проводки
НовыйДокумен.Движения.Хозрасчетный.Записать();

Вот и все. В результате получается проведенный документ с нужными нетиповыми проводками. Иногда, сейчас уже очень редко, это нужно. А ломать стандартный механизм проведения или создавать новый вид документов не пришлось.

P.S. Только важно помнить, что у помеченных на удаление документов с ручной корректировкой проводки остаются. У них просто переключается свойство Активность в положение Ложь. И понятно для чего так сделано. Чтобы при снятии пометки удаления все восстановилось как было. Поэтому в запросах не к виртуальным таблицам, а напрямую к записям регистра бухгалтерии (и других регистров) надо не забывать это учитывать (обязательно добавлять условие "Активность = Истина"). В примере ниже данные не выведутся:

Выбрать * Из РегистрБухгалтерии.Хозрасчетный
Где Регистратор Ссылка Документ.РеализацияТоваровУслуг
и Регистратор.ПометкаУдаления = Истина и Активность = Истина

←40 | заметка 41 | 42→

Итак имеем таблицу, например табличную часть документа, где главная колонка - номенклатура. Например:

1. Помидор
2. Огурец
3. Редиска
4. Лук
5. Укроп

Допустим хотим удалить Помидор и Редиску. И для этого у нас заполнился МассивИндексовДляУдаления с соответствующими индексами 0 и 2...

Возьмем цикл с прямым обходом:

Для Каждого Индекс из МассивИндексовДляУдаления Цикл
	Таблица.Удалить(Индекс);
КонецЦикла;

При этом удалятся Помидор и Лук. Потому что после удаления строки помидора, строка лука станет третьей (с индексом 2). Эта ошибка известна всем.

Хорошо, тогда давайте сделаем цикл с обратным обходом, ну или проще, отсортируем наш массив индексов по убыванию:

Список = Новый СписокЗначений;
Список.ЗагрузитьЗначения(МассивИндексовДляУдаления);
Список.СортироватьПоЗначению(НаправлениеСортировки.Убыв);
МассивИндексовДляУдаления = Список.ВыгрузитьЗначения();
Для Каждого Индекс из МассивИндексовДляУдаления Цикл
	Таблица.Удалить(Индекс);
КонецЦикла;

Удалились Помидор и Редиска. Все работает, все отлично. Но давайте порассуждаем дальше. Зачем нам удалять строки? Вероятно срабатывает какая-то проверка, которая по какому-то условию находит лишнее и заполняет массив для удаления. А если мы потом добавили еще одну проверку. И какая-то строка была настолько отвратительной, что не прошла обе проверки и в итоге в массив для удаления ее индекс добавится дважды. Ведь мы же обязательно забудем проконтролировать дубли :-) Как сработает наш код, если попробовать дважды удалить Редиску? А удалятся Редиска и Лук. Без какой-либо сигнализации об ошибке. И всплывет это счастье вовсе не на тестах, а уже в эксплуатации когда успеет много чего испортить.

Поэтому всегда следует удалять строки не по индексу, а по значению. То есть в массив для удаления нужно добавлять сами строки таблицы:

Для Каждого СтрокаТаблицы из МассивСтрокДляУдаления Цикл
	Таблица.Удалить(СтрокаТаблицы);
КонецЦикла;

Это же даже проще. Синтаксис такой-же, а направление обхода теперь не важно. Ну а если в массиве появится задвоение, удалить уже удаленную строку не удастся, поэтому будет вызвано исключение, пользователю выведется информация об ошибке, при этом ничего не испортится. Программист добавит проверку массива на дубли и все будет хорошо.

Ну то есть, этот конкретный пример подталкивает нас к использованию двух фундаментальных принципов:

←39 | заметка 40 | 41→

К сожалению в расширении нельзя убрать объекты из интерфейса. Но можно и, на первое время, нужно поставить "заглушки". Заимствовать в расширение форму, а в модуле написать:

&НаСервере
Процедура ПрефиксИмен_ПриСозданииНаСервереВместо(Отказ, СтандартнаяОбработка)
	Сообщить("Этот бред устарел и отключен! Вместо него используйте другой...");
КонецПроцедуры

&НаКлиенте
Процедура ПрефиксИмен_ПриОткрытииВместо(Отказ)
	ЭтаФорма.Закрыть();
КонецПроцедуры

Все отлично и наглядно, но ведь обязательно придет время физического удаления ненужных обработок. И тогда важно не забыть удалить заглушки из расширения, а то оно не применится. А если оно большое и в нем все активно используется, если кучу пропавших механизмов и элементов интерфейса заметят пользователи, а что будет если наоборот не обратят внимания и получат кривые записи в базе данных...

Ну и тут на ум приходит простое очевидное правило из заголовка статьи. Заглушки и любые другие изменения в объектах, которые скоро или когда-нибудь потом будут удалены, нужно делать в отдельном специальном расширении. Не применится, ну и ладно. Во всяком случае ничего сильно страшного не произойдет. Конечно лучше вообще таких ситуаций не допускать, например с помощью чек-листа с проверками. Но в реальной жизни возможны любые накладки. И если сбой потенциально возможен, пусть он будет безобидным.

←38 | заметка 39 | 40→

База данных маленькая, служебная. Вид деятельности (сдача в аренду нежилых помещений) ну никак не предполагает стремительного роста объема данных. В итоге позволил себе написать в запросе такой кусок:

Где Регистратор.Основание.ПоказателиОборота.НомерСтроки в (1)

Несколько разыменований, лайфках определения пуста ли таблица с помощью проверки есть ли в ней строка с номером один. В общем выглядит это ужасно. Но оно работает и обратите внимание, синтаксис почти повторяет текст задания. Да и писать это - несколько секунд. Лучше потратить время на получение основных данных, а не этого вспомогательного поля.

Через какое-то время оно к сожалению упало, когда у основания одного из регистраторов тип стал составным. Наругалось так:

Нельзя обращаться к вложенной таблице через поле составного типа

Но эта ошибка (в простом и понятном коде) очень легко обнаружилась и исправилась. Буквально за пару минут. Надо было просто привести составной тип к нужному:

Где Выразить(Регистратор.Основание Как Документ.РегистрацияДоговоровАренды).ПоказателиОборота.НомерСтроки в (1)

Теперь не сломается никогда.

Даже не знаю, зачем это пишу, что и кому хочу доказать. Понятно, что надо учитывать масштабирование, рост объема данных и возможные будущие тормоза. Но на практике на нагруженных системах чаще встречаются инциденты из-за неправильной архитектуры и применения медленных алгоритмов. И это бывает у тех же авторов, которые идеально и многоэтажно (без разыменований, с кучей явных соединений) пишут запросы. Примеры:

• Дополнительный интеграционный код, хранящийся в дополнительных реквизитах (в другой таблице без индекса).
• Сервис часто отдающий объемные одинаковые данные (изменение номенклатуры и цен) сотням клиентов, вместо горизонтального масштабирования и кеширования в виде публикации готового файла.
• Падение файловых магазинных розничных баз из-за блокировок типовых планов обмена.
• Программный перебор ячеек экселевской таблицы, вместо загрузки целой области или вообще работы с CSV.
• Массовая запись в регистр сведений (сегменты номенклатуры) без использования транзакций.

Понимаете, пройдет время, выйдут новые версии 1С и СУБД, выполнение запросов с разыменованиями будет оптимизировано и ускорено, а архитектурные просчеты и медленные циклические операции так и будут приводить к деградации производительности учетных систем. Как-то так...

←37 | заметка 38 | 39→

Как же обойти значения от большего к меньшему? Раньше применял что-то подобное:

Для СчетчикЦикла = 1 По Всего Цикл
	НужноеЗначение = Всего - СчетчикЦикла + 1;
	...
КонецЦикла; 

Особенно бесила эта дурацкая плюс единица, из-за которой надо было внимательно проверять как оно будет работать, особенно если речь идет о коллекции с индексами.

А тут внезапно, в поисковике проскочила оригинальная идея:

Для СчетчикЦикла = -Всего По -1 Цикл
	НужноеЗначение = -СчетчикЦикла;
	...
КонецЦикла;

Ну согласитесь, что это красота! И главное, в таком подходе невозможно ошибиться.

←36 | заметка 37 | 38→

При интеграции из другой системы прилетает массив расчетных показателей. Их много. Записывать их отдельно в какой-нибудь таблице в своей базе данных необязательно. Для работы нужны 2-3 из 100, не более. Поэтому такой массив временно хранится в строке с разделителями, примерно так:

СуммаОборота; СуммаОборотаСНДС; ээНачальныеПоказания; ээКонечныеПоказания

Так вот, на каком-то этапе некий парсинг ищет в этой строке. Как искать правильно? Допустим простое решение в лоб:

Если Найти(СтрокаПоказателей, СтрокаПоиска) Тогда

Но ведь косяк же. Видите его? Честно признаюсь, я несколько раз больно натыкался. Например:

Если Найти(СтрокаПоказателей, "СуммаОборота") Тогда

Поиск будет неожиданно успешным если суммы оборота в показателях нет, зато есть сумма оборота с НДС. Обидно. Что делать в таких случаях?

Понятно, что если перед поиском строку переделать в массив и искать в нем, все будет в порядке. Но тратить на это время, особенно если таких строк много и наш парсинг работает в цикле, такое себе решение.

Добавить в строку поиска разделитель? Но у последнего элемента разделителя же нет. Ну так в чем проблема, давайте его добавим и в строку показателей (один раз прямо перед поиском):

СтрокаПоказателей = ХранящаясяСтрокаПоказателей + ";";

Если Найти(СтрокаПоказателей, СтрокаПоиска + ";") Тогда

Вот теперь все хорошо.

Еще один важный момент. Понятно, что к поиску надо всегда относится аккуратно. Ну а наименование любых сущностей надо продумывать с удвоенной внимательностью. Что такое эта наша СуммаОборота? Какая она, с НДС или без НДС, ведь это же неочевидно, это почему-то надо помнить, и программистам, и пользователям. А вот если бы было явно: СуммаОборотаБезНДС, СуммаОборотаСНДС, то ошибки поиска бы не возникло. В итоге вырисовывается полезное правило:

←35 | заметка 36 | 37→

Смотрю подкаст со счастливым адептом, умиляюсь, завидую. А ведущий возьми, да и поинтересуйся: "Вот у вас нет переменных, в смысле переменные не могут менять значения. Как же так. К примеру, как вы в таком случае реализуете алгоритм сортировки?". А гуру и говорит: "Так это же в готовой библиотеке сделано, естественно нормально. Там переменные значения меняют". О как! Получается, стандартные вещи у них решены удобно, а для собственных разработок зачем-то нужно мучиться.

Да ну его, подумал я, взял, да и выключил этот бред. В общем не сложилось у меня с функциональщиной.

←34 | заметка 35 | 36→

Причем это очень популярное заблуждение теоретиков от программирования. Почему-то считается, что надо одновременно бороться с дублирующим и зависимым (связанным) кодом. Типа с помощью декомпозиции (повторного использования кода путем вынесения его в отдельную процедуру или функцию) можно добиться изоляции (когда доработки ничего не ломают). Но как же так. Ведь даже в обычной жизни очевидно, что нельзя быть за все хорошее против всего плохого. Нельзя выступать за низкие налоги и одновременно за высокие социальные льготы, потому что такое просто невозможно.

В проекте с идеальной декомпозицией без дублей кода, с огромным количеством маленьких процедур, функций, методов, которые стремительно вызывают друг друга, изоляция невозможна, потому что все зависит от всего. Одно небольшое исправление может как эффект бабочки привести к самым неожиданным последствиям. А уж зависимость от сторонних разработок (библиотек) у большинства из нас вызывает яркие воспоминания об отказах после обновлений, описать которые можно только на эмоциональном русском языке. Наоборот, изолированный (несвязанный) код процедуры, функции, метода должен содержать в себе важные фрагменты, которые могут встретиться где-нибудь еще. Лишь бы изменение, добавление, обновление в одном месте системы не повлияло на другие отлаженные механизмы. Изоляция также может быть на уровне модулей с заимствованием (дублированием) служебных процедур и функций из других модулей и стандартных (сторонних) библиотек. Например, чтобы легко перенести модуль в другой (новый или наоборот устаревший) проект.

То есть, получается, что декомпозиция и изоляция - антагонисты и взаимодействие между ними - это шкала:

Декомпозиция <-------------------------> Изоляция

Ну или если вам не нравится такое представление, можно наоборот:

Изоляция <-------------------------> Декомпозиция

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

Так что же делать, где на рассматриваемой шкале поставить свою точку? Тут-то и сказывается опыт разработчика, который примет приемлемое решение исходя из задачи. Если нужно написать какую-нибудь утилиту для чего-нибудь очень специфического, в качестве Open Source или может речь идет о внутренней офисной системе с большими технологическими окнами (нерабочее время и целые выходные), то здесь вполне можно блеснуть передовыми технологиями и декомпозицией. А если у вас интеграция розничных продаж с банками, где возможны прямые финансовые потери вкупе с трудоемким неочевидным интеграционным тестированием и неотзывчивой техподдержкой, то ну его на фиг, пусть все методы будут максимально изолированными даже с дублирующим кодом. Чтобы при добавлении нового, не упало то что работало.

Можно конечно пообещать себе и вселенной, что любой рефакторинг для улучшения декомпозиции обязательно пройдет процесс полного подробного тестирования. Но мы же взрослые люди, прекрасно понимаем, что это вранье.

Вы все еще не согласны со мной? А если скажу, что ставшая популярной микросервисная архитектура (в противовес монолиту) - это отчаянная попытка добиться изоляции, с пониманием, что раз сервисы разные, значит и одинаковый код, просочившийся в каждый из них, больше не под запретом! Ну разве это не забавно...

Может показаться, что не стоит читать книги с сомнительными советами или крайне осторожно выбирать техническую литературу. Это не так. Просто не надо относится к писателям, как небожителям. Они обычные люди, такие же как мы. Они делятся своими знаниями и естественно могут заблуждаться. Просто не надо слепо верить написанному. Читайте, пробуйте, делайте собственные выводы. Придет время и может оказаться, что вы разобрались в теме лучше, чем написано в книге.

←33 | заметка 34 | 35→

Все просто. Создаем еще одно временное расширение, в него заимствуем ту же процедуру ПередЗаписью() и собственно разрешаем писать. Казалось бы, чего тут извергать из себя буквы. Но обратите внимание как неожиданно работает возврат. Вот простой пример...

В конфигурации:

Процедура ПередЗаписью(Отказ)
	Сумма = 1000; //любой код
КонецПроцедуры

В первом расширении:

&После("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ)
	Если Истина Тогда //какое-нибудь условие
		Отказ = Истина;
		Возврат;
	КонецЕсли;
	
	Сумма = 2000; //этот код не выполняется
КонецПроцедуры

Во втором расширении:

&После("ПередЗаписью")
Процедура Расш2_ПередЗаписью(Отказ)
	Отказ = Ложь; //этот код
	Сумма = 3000; //выполняется	
КонецПроцедуры

То есть, возврат производится только из процедуры в конкретном расширении, но не из процедуры вообще. И это не баг, а фича, нужная как раз для подобных задач. Иногда такое поведение огорчает. Например, если охота не после, а перед стандартной процедурой проверить условие и вообще ее не выполнять:

&Перед("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ)
	Если КакоеНибудьУсловие Тогда
		Возврат;
	КонецЕсли;
КонецПроцедуры

Но нет, такой возврат вовсе не предотвращает исполнение стандартного кода, хотя казалось бы. В этом случае необходимо использовать &Вместо:

&Вместо("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ)
	Если КакоеНибудьУсловие Тогда
		Возврат;
	Иначе
		ПродолжитьВызов(Отказ);
	КонецЕсли;
КонецПроцедуры

Механизм расширения конфигураций очень удобен, нужно только понимать некоторые тонкости...

←32 | заметка 33 | 34→