Регистры накопления. Виртуальные таблицы. Часть №1: Обороты

20.05.19

Разработка - Механизмы платформы 1С

Описание работы платформы 1С:Предприятие 8.2 с виртуальной таблицей "Обороты" регистров накопления.

О регистрах накопления

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

Материалы созданы во времена платформы 8.2, поэтому некоторые моменты могут быть уже не актуальными, но основные принципы работы остались неизменными.

 
 Это информация из старого блога DevelPlatform.ru

Конкретно в этой статье речь идет о виртуальной таблице "Обороты" регистров накопления в базе данных. Все примеры из публикации Вы можете найти на GitHub.

Виртуальные таблицы

В статье "Регистры накопления. Структура хранения в базе данных" мы рассматривали таблицы, которые использует платформа для хранения движений в регистрах накопления, а также его итоговых оборотов или остатков в зависимости от вида регистра ("Остатки" или "Обороты"). Также были подробно рассмотрены действия платформы с таблицами остатков и оборотов при записи движений в регистр.

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

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

  1. "Обороты".
  2. "Остатки".
  3. "Остатки и обороты".

Последние две становятся доступными только если вид регистра установлен как "Остатки". 

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

Далее в статье проанализируем SQL-запросы платформы 1С:Предприятие 8.2 при обращении к виртуальной таблицам. При этом будем выполнять запросы при различных комбинациях параметров.

Сторона СУБД

Отмечу, что для экспериментов использовал простую тестовую конфигурацию, ссылка на которую приведена в конце статьи. В конфигурации созданы два регистра накопления различного вида, а также два документа для выполнения + и - движений по регистрам. Узнать подробнее о составе объектов тестовой конфигурации Вы можете либо скачав файл конфигурации, либо прочитав статью "Регистры накопления. Структура хранения в базе данных". Используемая версия платформы 8.2.17.153.

Начнем анализ с виртуальной таблицы "Обороты", так как она присутствует вне зависимости от вида регистра.

Виртуальная таблица "Обороты"

Виртуальная таблица "Обороты" есть, как у регистра накопления с видом "Обороты", так и с видом "Остатки". Рассмотрим оба варианта. Начнем с последнего.

Вид регистра "Остатки"

Посмотрим состав полей таблицы оборотов на примере регистра "ОстаткиНоменклатуры".

В нем содержатся поля каждого из измерений, а также поля "Приход", "Расход" и "Оборот" для каждого из ресурсов в регистре. В нашем случае у нас два измерения ("Номенклатура" и "Склад"), а также три поля "КоличествоПриход", "КоличествоРасход" и "КоличестоОборот".

Главной особенностью любой виртуальной таблицы является возможность указать параметры. Установленные параметры кардинальным образом могут изменить SQL-запрос платформы к базе данных, поэтому понимать их назначение - это обязанность любого разработчика на платформе 1С:Предприятие.

В зависимости от установленного параметра "Периодичность" в состав доступных полей вирт. таблицы будут добавляться соответствующие периоды ("ПериодДень", "ПериодМесяц" и т.д.).

Теперь напишем простой запрос для получения оборотов по номенклатуре за период. В параметрах виртуальной таблицы установим поля "НачалоПериода" и "КонецПериода", а в условия добавим отбор по складу "Склад №1". При выполнении запроса платформа сформирует два SQL-запроса к базе данных. Первый запрос получает настройки регистра накопления:

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

"exec sp_executesql N'
|SELECT"+
// Поля виртуальной таблицы ""Обороты""
" T1.Fld22RRef,     // Номенклатура
| T1.Fld23RRef,     // Склад
| T1.Fld24Turnover_,// КоличествоОборот
| T1.Fld24Receipt_, // КоличествоПриход
| T1.Fld24Expense_  // КоличествоРасход"+
// Получаем обороты с помощью вложенного запроса
"FROM ("+
// -- Начало вложенного запроса --
" SELECT
|  T2._Fld23RRef AS Fld23RRef, // Склад
|  T2._Fld22RRef AS Fld22RRef, // Номенклатура"+
// Если вид записи (""RecordKind"") равно 0, тогда это ""Приход"",
// иначе ""Расход"". ""Приход"" берется положительным, ""Расход"" 
// с отрицательным знаком.
// 1. Поле ""КоличествоОборот"" получает значение оборота с
// соответствующим знаком. Значение поля суммируется
// в разрезе группировок
"  CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
|           THEN T2._Fld24 
|        ELSE -T2._Fld24 END
|          ) AS NUMERIC(22, 8)) AS Fld24Turnover_,"+
// 2. Поле ""КоличествоПриход"" формируется по тому же принципу,
// за исключением случаев для вида записи ""Расход"". Для него
// берется значение 0.
"  CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
|      THEN T2._Fld24 
|       ELSE 0.0 END) AS NUMERIC(22, 8)
|            ) AS Fld24Receipt_,"+
// 3. Поле ""КоличествоРасход"". Формируется по тем же принципам, 
// что и предыдущие поля, за исключением вида записи ""Приход"".
// Для нее берется значение 0.
"  CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
|      THEN 0.0 
|       ELSE T2._Fld24 END
|            ) AS NUMERIC(22, 8)) AS Fld24Expense_"+
// Для получения данных по оборотам для регистра вида ""Остатки""
// используется таблица движений регистра ""AccumRg[n]""
"  FROM _AccumRg21 T2 WITH(NOLOCK)"+
// Во вложенном запросе в секции ""WHERE"" указываются отборы 
// в соответствии с установленными параметрами виртуальной таблицы.
"  WHERE T2._Period >= @P1     // НачалоПериода
|   AND T2._Period <= @P2      // ОкончаниеПериода
|   AND T2._Active = @P3          // Активность
|     AND ((T2._Fld23RRef = @P4)) // Условие отбора по складу"+
// Группировки результата вложенного запроса по полям:
"  GROUP BY T2._Fld23RRef,     // Склад
|           T2._Fld22RRef      // Номенклатура"+
// Условия отбора во вложенном запросе на сгруппированный результат
// Проверяется, чтобы хотя бы один из выбираемых ресурсов
// (""КоличествоОборот"", ""КоличествоПриход"", ""КоличествоРасход"")
// не равнялся значению 0.
"  HAVING (CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
|       THEN T2._Fld24 
|        ELSE -T2._Fld24 END
|                 ) AS NUMERIC(22, 8))) <> @P5 
|  OR (CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
|       THEN T2._Fld24 
|       ELSE 0.0 END
|                 ) AS NUMERIC(22, 8))) <> @P5 
|  OR (CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
|       THEN 0.0 
|       ELSE T2._Fld24 END
|                 ) AS NUMERIC(22, 8))) <> @P5"+
// -- Окончание вложенного запроса --
" ) T1', // Присваиваем синоним для таблицы, в
|     // которую поместим результат вложеного запроса"+
// Установим типы и значения параметров, передаваемых в запрос
"N'@P1 datetime,   // Параметр ""НачалоПериода""
|@P2 datetime,     // ""КонецПериода""
|@P3 varbinary(1), // Активность записи, т.е. влияет ли она на итоги
|@P4 varbinary(16),// Парам. ""Склад"", используемый в парам. вирт. таблицы
|@P5 numeric(1,0)',// Значение для проверки ресурсов на знач. 0. 
|{ts '4013-01-01 00:00:00'}, // Значение ""НачалоПериода"" 
|{ts '4014-01-01 00:00:00'}, // ""КонецПериода""
|0x01,                       // Активность записи
|0xBE923860773387FD11E2D2B47CD2CB1E, 
|0                           // Проверка на знач. 0 для ресурсов
|" 

Старался подробно разобрать весь запрос. Если будут непонятные моменты, то прошу в комментарии. Исходный текст запроса на языке 1С:Предприятия выглядит следующим образом:

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОстаткиНоменклатурыОбороты.Номенклатура,
| ОстаткиНоменклатурыОбороты.Склад,
| ОстаткиНоменклатурыОбороты.КоличествоОборот,
| ОстаткиНоменклатурыОбороты.КоличествоПриход,
| ОстаткиНоменклатурыОбороты.КоличествоРасход
|ИЗ
| РегистрНакопления.ОстаткиНоменклатуры.Обороты(
|                                              &НачалоПериода, 
|                                              &КонецПериода, 
|                                              , Склад = &Склад) 
|                         КАК ОстаткиНоменклатурыОбороты";

В случае, если для виртуальной таблицы также устанавливается параметр "Периодичность", например, в значение "Месяц", то SQL-запрос немного видоизменится:

	"exec sp_executesql N'
	|SELECT"+
	// Новое поле "Period" ("Период")
	" T1.Period_,
	| T1.Fld22RRef,
	| T1.Fld23RRef,
	| T1.Fld24Turnover_,
	| T1.Fld24Receipt_,
	| T1.Fld24Expense_
	|FROM (
	|     SELECT"+	
	// Получаем период во вложенном запросе вместе с остальными данными.
	// Значение периода вычисляется из таблицы движений "AccumRg[n]"
	// преобразуется к началу периода в зависимости от периодичности.
	// Например, для периодичности "Месяц" период приводится к началу
	// этого месяца. Также учитывается тот факт, что в таблице движений
	// год в значении периода больше текущего года на 2000 лет.	
	"      DATEADD(DAY,1.0 - 1,DATEADD(MONTH,CAST(DATEPART(MONTH,T2._Period) 
	|      AS NUMERIC(4)) - 1,DATEADD(YEAR,(CAST(DATEPART(YEAR,T2._Period) 
	|      AS NUMERIC(4)) - 2000) - 2000,{ts ''4000-01-01 00:00:00''}))) 
	|                                                               AS Period_,
	|      T2._Fld22RRef AS Fld22RRef,
	|      T2._Fld23RRef AS Fld23RRef,
	|      CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
	|                       THEN T2._Fld24 
	|                    ELSE -T2._Fld24 END) 
	|           AS NUMERIC(22, 8)) AS Fld24Turnover_,
	|      CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
	|                       THEN T2._Fld24 
	|                    ELSE 0.0 END) 
	|               AS NUMERIC(22, 8)) AS Fld24Receipt_,
	|      CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
	|                       THEN 0.0 
	|                    ELSE T2._Fld24 END) 
	|               AS NUMERIC(22, 8)) AS Fld24Expense_
	|     FROM _AccumRg21 T2 WITH(NOLOCK)
	|     WHERE T2._Period >= @P1 
	|           AND T2._Period <= @P2 
	|           AND T2._Active = @P3 
	|           AND ((T2._Fld23RRef = @P4))
	|     GROUP BY "+
	// Для получения оборотов в соответствии с заданной периодичностью
	// результат вложенного запроса группируется по полю период и по
	// другим измерениям.     
	"      DATEADD(DAY,1.0 - 1,DATEADD(MONTH,CAST(DATEPART(MONTH,T2._Period) 
	|         AS NUMERIC(4)) - 1,DATEADD(YEAR,(CAST(DATEPART(YEAR,T2._Period) 
	|         AS NUMERIC(4)) - 2000) - 2000,{ts ''4000-01-01 00:00:00''}))),
	|      T2._Fld22RRef,
	|      T2._Fld23RRef
	|     HAVING (
	|         CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
	|                           THEN T2._Fld24 
	|                       ELSE -T2._Fld24 END) AS NUMERIC(22, 8))) <> @P5 
	|         OR (CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
	|                           THEN T2._Fld24 
	|                           ELSE 0.0 END) AS NUMERIC(22, 8))) <> @P5 
	|         OR (CAST(SUM(CASE WHEN T2._RecordKind = 0.0 
	|                           THEN 0.0 
	|                           ELSE T2._Fld24 END) AS NUMERIC(22, 8))) <> @P5
	|    ) T1', 
	|N'@P1 datetime,
	|@P2 datetime,
	|@P3 varbinary(1),
	|@P4 varbinary(16),
	|@P5 numeric(1,0)', 
	|{ts '4013-01-01 00:00:00'}, 
	|{ts '4014-01-01 00:00:00'}, 
	|0x01, 
	|0xBE923860773387FD11E2D2B47CD2CB1E, 0"

Если в виртуальной таблице периодичность установлена "Авто", то в SQL-запросе будут содержаться поля периода для каждой из получаемой в запросе периодичности ("День", "Месяц", "Год" и т.д.). Причина, по которой платформа хранит значения периода с увеличением части даты "Год" на 2000 лет мне не известна. Если кто из читателей подскажет, буду благодарен.

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

Вид регистра "Обороты"

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

Как и в предыдущем случае, в зависимости от параметра "Периодичность" в составе доступных полей появятся соответствующие периоды.

И так, выполним несколько запросов к таблице "Обороты" и проанализируем SQL-запросы платформы. Первый запрос на языке запросов платформы:

Запрос = Новый Запрос;
Запрос.Текст = "
|ВЫБРАТЬ
| ДвиженияНоменклатурыОбороты.Номенклатура,
| ДвиженияНоменклатурыОбороты.Склад,
| ДвиженияНоменклатурыОбороты.КоличествоОборот
|ИЗ
| РегистрНакопления.ДвиженияНоменклатуры.Обороты(
|                                        &НачалоПериода, 
|      &КонецПериода, 
|      , 
|      Склад = &Склад) 
|                         КАК ДвиженияНоменклатурыОбороты" 

Запрос принимает также три параметра: "НачалоПериода", "КонецПериода" и "Склад". Как начало периода возьмем начало 2012 года, конец периода - 13 апреля 2013 00:00:00. Склад пусть будет "Склад №1".

Первым делом платформа 1С:Предприятие получит настройки регистра накопления, к которому выполняется запрос. Запрос будет идентичный рассматриваемому ранее примеру, пойдем дальше. Сформированный платформой SQL-запрос тогда будет такой:

"exec sp_executesql N'
|SELECT"+
// Результатирующие поля выборки
" T1.Fld27RRef,      // Номенклатура
| T1.Fld28RRef,      // Склад
| T1.Fld29Turnover_  // КоличествоОборот"+
// Получаем необходимые данные с помощью вложенных запросов
"FROM ("+
//    Выполняем запрос к вложенной таблице, в которой
//    получаем данные по итогам оборотов, а также 
//    обороты по тем записям, которые не учтены в итогах
"     SELECT
|      T2.Fld27RRef AS Fld27RRef,    // Номенклатура
|      T2.Fld28RRef AS Fld28RRef,    // Склад
|      CAST(SUM(T2.Fld29Turnover_)   // КоличествоОборот
|           AS NUMERIC(38, 8)) AS Fld29Turnover_
|     FROM ("+
// ++++++++++ ДАННЫЕ ПО ЗАПИСЯМ ИТОГОВ ++++++++++
//         Первым запросом получаем данные по оборотам
//         из таблицы итогов оборотов "AccumRgTn[n]"
//         по месяцам
"    SELECT
|           T3._Fld27RRef AS Fld27RRef, // Склад
|           T3._Fld28RRef AS Fld28RRef, // Номенклатура
|           CAST(SUM(T3._Fld29)         // КоличествоОборот
|          AS NUMERIC(33, 8)) AS Fld29Turnover_
|          FROM _AccumRgTn30 T3 WITH(NOLOCK)"+
//         Накладываем условия на выборку записей
//         В эту секцию входят все параметры виртуальной
//         таблицы "Обороты", которые задает разработчик
//         в тексте запроса платформы. ИСКЛЮЧЕНИЕ:
//         параметр P2 - это не конец периода, а начало 
//         месяца параметра "КонецПериода"
"          WHERE T3._Period >= @P1 // Начало периода
|       AND T3._Period < @P2 // Ограничение для итогов
|       AND ((T3._Fld28RRef = @P3)) // Склад"+
//         Группируем результат выбранным в запросе измерениям
"          GROUP BY T3._Fld27RRef, // Склад
|                   T3._Fld28RRef  // Номенклатура"
//         Проверяем, чтобы значения выбранных в запросе ресурсов
//         не равнялось 0
"          HAVING (CAST(SUM(T3._Fld29) 
|             AS NUMERIC(33, 8))) <> @P4"+
// --------- ДАННЫЕ ПО ЗАПИСЯМ ИТОГОВ ---------
//
//         Объединяем результаты по записям итогов и движений            
"    UNION ALL"+
//
// ++++++++++ ДАННЫЕ ПО ЗАПИСЯМ ДВИЖЕНИЙ ++++++++++
//         Вторым запросом получаем данные по оборотам
//         из таблицы движений  "AccumRg[n]" за период
//         с начала последних рассчитанных итогов и по 
//         значение параметра "Конец периода"
"          SELECT
|           T4._Fld27RRef AS Fld27RRef, // Склад
|           T4._Fld28RRef AS Fld28RRef, // Номенклатура
|           CAST(CAST(SUM(T4._Fld29)    // КоличествоОборот
|               AS NUMERIC(27, 8)) 
|        AS NUMERIC(27, 2)) 
|                                   AS Fld29Turnover_
|          FROM _AccumRg26 T4 WITH(NOLOCK)"+
//         Условия выборки записей аналогичны запросу
//         к итогам, за исключением:
//         - параметра P2 = начало месяца от значения 
//         параметра "Конец периода"
//         - добавилось условие на активность записей
"          WHERE // Ограничение для периода движений
|                 T4._Period >= @P2 
|    AND T4._Period <= @P5 // Конец периода
|    AND T4._Active = @P6 // Активность записей
|    AND ((T4._Fld28RRef = @P3))"+ // Склад
//         Группировки и условия выборки аналогичные
//         запросу по итогам
"          GROUP BY T4._Fld27RRef,
|                   T4._Fld28RRef
|          HAVING (CAST(CAST(SUM(T4._Fld29) 
|              AS NUMERIC(27, 8)) 
|           AS NUMERIC(27, 2))) <> @P4"+
//
// ---------- ДАННЫЕ ПО ЗАПИСЯМ ДВИЖЕНИЙ ----------
"   ) T2" +
//    Группируем результат запроса ко вложенной таблице по
//    выбранным измерениям
"     GROUP BY T2.Fld27RRef, // Номенклатура
|              T2.Fld28RRef  // Склад"+
//    Проверяем, чтобы хотя бы одно значение из
//    выбранных в запросе ресурсов
//    было не равно 0. В регистре из примера один ресурс,
//    поэтому условие одно.
"     HAVING (CAST(SUM(T2.Fld29Turnover_) 
|          AS NUMERIC(38, 8))) <> @P4
|) T1', 
|N'@P1 datetime,  // НачалоПериода
| // Начало месяца от значения 
| // параметра ""КонецПериода""
|@P2 datetime,      
|@P3 varbinary(16), // Склад
| // Проверка на 0 для полученных записей
|@P4 numeric(1,0),   
|@P5 datetime, // Конец периода
|@P6 varbinary(1)', // Активность
|{ts '4012-01-01 00:00:00'}, // Начало периода
| // Начало месяца от значения 
| // параметра ""КонецПериода"" 
|{ts '4013-04-01 00:00:00'},
|0xBE923860773387FD11E2D2B47CD2CB1E, // Склад
|0, // Проверка на 0 для полученных записей
|{ts '4013-04-13 00:00:00'}, // Конец периода
|0x01 // Активность"

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

Если в запросе на языке платформы мы добавим использование параметра "Периодичность" (например, поставим значение "Месяц"), то SQL-запрос платформы изменится аналогично рассмотренному примеру для регистра накопления с видом остатки. Будут добавлены поля выбранных периодов ("ПериодДень", "ПериодМесяц" и т.д.) в секции запроса "SELECT" и "GROUP BY". Для нашего примера это месяц. Поля и группировки будут добавлены для всех вложенных запросов и, конечно, содержаться в результатирующей выборке. В нашем примере, выражения в поле запроса для получения периода будет таким:

"DATEADD(DAY,1.0 - 1,
|        DATEADD(MONTH,
|                CAST(DATEPART(MONTH,T3._Period) 
|                             AS NUMERIC(4)) - 1,
|                     DATEADD(YEAR,(CAST(DATEPART(YEAR,T3._Period) 
|                             AS NUMERIC(4)) - 2000) - 2000,
|                     {ts ''4000-01-01 00:00:00''}
|                )
|        )
|) AS Period_" 

Принцип получения значений периода был описан выше для регистра с видом "Обороты".

Заключение

Эксперименты с регистром показали, что для виртуальной таблицы "Обороты" платформа 1С:Предприятие 8 имеет разный принцип построения SQL-запросов к базе данных в зависимости от вида регистра накопления ("Остатки" или "Обороты"). Если вид регистра - "Остатки", то SQL-запрос получает данные по оборотам непосредственно из таблицы движений. В случае, если вид регистра "Обороты", то тогда уже используется таблица итогов оборотов и запрос работает более оптимально, нежели чем для регистра остатков.

Если представить действия SQL-запросов схематично, то выглядеть это будет примерно так:

display: block; margin-left: auto; margin-right: auto; По схеме видно, что наиболее оптимальным образом платформа работает с виртуальной таблицей "Обороты" для регистра накопления с видом "Обороты", поскольку использует рассчитанных итоги по оборотам в разрезе месяцев. И лишь в тех случаях, когда рассчитанных итогов для периода нет, тогда использует таблицу движений. Для регистра вида "Остатки" всегда используется таблица движений вне зависимости от настроек хранения итоговых записей. Именно поэтому следует внимательно отнестись к настройке вида регистра накопления при проектировании структуры метаданных конфигурации.

Интересен тот факт, что если для регистра накопления отключить использование итогов, то тогда запрос к виртуальной таблице "Остатки" станет невозможным. Будет появляться такая ошибка:

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

Что дальше

В следующих статьях будет рассмотрена работа платформы с виртуальными таблицами "Остатки" и "Остатки и обороты". Также коснемся работы агрегатов регистра накопления.

Спасибо за внимание! :)

Другие ссылки

платформа регистры накопления SQL-запросы внутреннее устройство

См. также

Поинтегрируем: сервисы интеграции – новый стандарт или просто коннектор?

Обмен между базами 1C Администрирование СУБД Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

В платформе 8.3.17 появился замечательный механизм «Сервисы интеграции». Многие считают, что это просто коннектор 1С:Шины. Так ли это?

11.03.2024    3564    dsdred    48    

66

Как готовить и есть массивы

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

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

24.01.2024    5032    YA_418728146    25    

62

Планы обмена VS История данных

Обмен между базами 1C Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?

11.12.2023    6160    dsdred    36    

110

1С-ная магия

Механизмы платформы 1С Бесплатно (free)

Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?». 

06.10.2023    18196    SeiOkami    46    

116

Дефрагментация и реиндексация после перехода на платформу 8.3.22

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Начиная с версии платформы 8.3.22 1С снимает стандартные блокировки БД на уровне страниц. Делаем рабочий скрипт, как раньше.

14.09.2023    11766    human_new    27    

72

Валидация JSON через XDTO (включая массивы)

WEB-интеграция Универсальные функции Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

При работе с интеграциями рано или поздно придется столкнуться с получением JSON файлов. И, конечно же, жизнь заставит проверять файлы перед тем, как записывать данные в БД.

28.08.2023    8555    YA_418728146    6    

139

Внешние компоненты Native API на языке Rust - Просто!

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Внешние компоненты для 1С можно разработывать очень просто, пользуясь всеми преимуществами языка Rust - от безопасности и кроссплатформенности до удобного менеджера библиотек.

20.08.2023    6195    sebekerga    54    

93

Все скопируем и вставим! (Буфер обмена в 1С 8.3.24)

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассмотрим новую возможность 8.3.24 и как её можно эффективно использовать

27.06.2023    15525    SeiOkami    31    

103
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. nvv1970 20.05.19 08:11 Сейчас в теме
Причина костыля 1с со смещением года в mssql и типе datetime, который имеет ограничение по диапазону дат. Так даты не могут быть меньше 1753 года.
Несколько лет назад 1с плавно перешла на datetime2, который не имеет такого ограничения, однако, по привычке все продолжают использовать смещение для новых баз... и правильно делают. Кто знает где вылезет недописанный код платформы и старый формат?

Пс: почему версия 8.2.17 в статье? Статья - древняя копипаста?)) Может нужно было актуализировать? Вот например вычисление начала периода изменилось в последних версиях.

ППС: часть по агрегаты будет?
YPermitin; +1 Ответить
2. пользователь 20.05.19 08:26
(1) да, статья из старого блога. В начале статьи я предупредил:)

В основном все осталось прежнее со времен 8.2.

По агрегатам тоже будет :)
6. user688024_amirdinov 06.02.20 12:37 Сейчас в теме
Здравствуйте!
(1)
Вот например вычисление начала периода изменилось в последних версиях.


Подскажите а где можно об этом подробнее почитать?
7. nvv1970 06.02.20 13:06 Сейчас в теме
(6) Поведение "ядра" 1с не документируется. Код платформы - закрыт. Поэтому и почитать не где.
Зачем это программисту? Платформа выполняет свою работу как положено? Ну и ладно. Результат ведь тот же.
А для любознательных все открыто.... Инфа есть в трассировке, в ТЖ. Инфа обсуждалась на партнерке...
3. wowik 884 20.05.19 09:13 Сейчас в теме
+1 не глядя, потом почитаю.
Gaster; user1227864; kuzyara; YPermitin; +4 Ответить
4. пользователь 20.05.19 09:26
(3) спасибо за аванс :) Пишите если что.
5. rystam_atai 16.10.19 16:18 Сейчас в теме
Картинка для Вид регистра "Остатки" кажется не вполне корректная - слишком много там параметров.
8. timm00 139 05.11.20 12:52 Сейчас в теме
На самом деле попробуйте создать базу с нулевым смещением дат и записать какой-нибудь объект с пустым реквизитом типа Дата. Получите ошибку SDBL, на MS SQL точно, на остальных не проверял.
9. пользователь 01.10.21 07:14
Сообщение было скрыто модератором.
...
10. echo77 1868 17.04.22 07:56 Сейчас в теме
Статья, классная! Интересно, для регистров бухгалтерии, можно сделать те же выводы, что для регистров с видом "Остатки"?
Оставьте свое сообщение