vk fb tw rss

Анатомия регистра накопления. Виртуальная таблица «Обороты»

Виртуальная таблица обороты
В статье «Анатомия регистра накопления. Внутреннее устройство и структура хранения.» мы рассматривали таблицы, которые использует платформа для хранения движений в регистрах накопления, а также его итоговых оборотов или остатков в зависимости от вида регистра («Остатки» или «Обороты»). Также были подробно рассмотрены действия платформы с таблицами остатков и оборотов при записи движений в регистр.
В данной статье проанализируем 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-запросе будут содержаться поля периода для каждой из получаемой в запросе периодичности («День», «Месяц», «Год» и т.д.).
 
Мы с Вами рассмотрели 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-запросов схематично, то выглядеть это будет примерно так:
Получение данных для виртуальной таблицы "Обороты" в зависимости от вида регистра накопления ("Остатки" или "Оброты")
Получение данных для виртуальной таблицы «Обороты»
в зависимости от вида регистра накопления («Остатки» или «Обороты»)
По схеме видно, что наиболее оптимальным образом платформа работает с виртуальной таблицей «Обороты» для регистра накопления с видом «Обороты», поскольку использует рассчитанные итоги по оборотам в разрезе месяцев. И лишь в тех случаях, когда рассчитанных итогов для периода нет, тогда использует таблицу движений. Для регистра вида «Остатки» всегда используется таблица движений вне зависимости от настроек хранения итоговых записей. Именно поэтому следует внимательно отнестись к настройке вида регистра накопления при проектировании структуры метаданных конфигурации.
Интересен тот факт, что если для регистра накопления отключить использование итогов, то тогда запрос к виртуальной таблице «Остатки» станет невозможным. Будет появляться такая ошибка:
Ошибка получения данных виртуальной таблицы "Обороты" при отключенных итогов регистра накопления
Ошибка получения данных виртуальной таблицы «Обороты»
при отключенных итогах регистра накопления

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

 

 

Друзья, давайте не будем теряться на просторах интернета! Если вы хотите регулярно получать материалы по оптимизации, подпишитесь на новости!

 



Лучшие материалы по теме

Расскажите своим друзьям
Вам ничего не стоит, а им будет интересно
Подпишитесь на обновления
Ваш e-mail: * Ваше имя: *


Обсудить Вконтакте


Обсудить в Facebook

1 комментарий: Анатомия регистра накопления. Виртуальная таблица «Обороты»

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *