SAPфорум.RU
https://www.sapboard.ru/forum/

STVARV vs Z-таблица
https://www.sapboard.ru/forum/viewtopic.php?f=13&t=96062		 Страница 1 из 2
Автор:  tanyxa [ Чт, фев 15 2018, 12:24 ]
Заголовок сообщения:  STVARV vs Z-таблица
Всем здравствуйте. Такой вот концептуальный вопрос.

Есть документ который формируется сабмитом отчета. Отчет существует в 2 импостасях - стандартный, и его Z-копия слегка модифицированная.
В зависимости от года формирования запускается либо стандарный, либо Z с разными вариантами.
Пока разветвлений было не много - до 2015 года - стандарт с вариантом VARI1, после 2016 - Z отчет с вариантом VARI2.

Недавно поступило требование с 2015 по 2016 формировать Z-отчет с вариантом VARI2, а с 2017 - с вариантом VARI3.
До этого имена отчетов и вариантов хранились как параметры в STVARV, я подумала что неплохо было бы свести это все в настроечную табличку на случай если варианты формирования будут множиться.

Теперь собственно вопрос:

Табличка получается простая - годы "с", "по", имя отчета, имя варианта. По сути ПК будет представлять собой сочетание всех полей. получается при необходимости внести изменения - нужно будет удалить всю запись и ввести ее по новой - некрасиво. Можно пойти другим путем - сделать какой-то синтетический ПК и возложить проверку корректности на абап-код в событиях ракурса - например при вводе новой записи - предыдущая должна ограничиваться подобно инфотипам в HR, не допускается перекрытие диапазонов "год с-по".

В общем стоит ли завязываться с таблицей, или просто добавить третий параметр в STVARV?
Автор:  Yozhhhhh [ Чт, фев 15 2018, 14:15 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Оба поля "с" и "по" в ключ никогда не вставляют.
У Вас в результате запросто может сложиться ситуация
запись 1: с 2015 по 2018
запись 2: с 2016 по 2017
Оставим в стороне, что это натуральное вредительство и т.д. Такое реально.

Лучшим вариантом было бы, на мой взгляд, вообще иметь отдельную запись на каждый год. Тогда в ключе останется только год формирования, а отчет и вариант можно заменить всегда.
Добавление новой записи в таблицу можно было бы сделать простейшим шагом закрытия года, это не отнимает много времени.
Автор:  tanyxa [ Чт, фев 15 2018, 15:11 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Yozhhhhh, спасибо за ответ.

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

Вариант ПК = год хорош, но с точки зрения пользователя может возникнуть недовольство "почему я должен исправлять имя варианта 3 раза" :D
Автор:  Yozhhhhh [ Чт, фев 15 2018, 15:35 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
tanyxa написал(а):
Насчет ключа не совсем согласна, весь HR модуль работает на концепции что каждая запись существует только в каком-то периоде жизни и в ключе всегда дата начала и дата конца.


Я ни разу не видел в сапе, чтобы временно зависимые данные содержали в ключе обе даты.
Все модули с временно зависимыми данными работают только на каком-то периоде жизни, но в ключе обе даты нигде не присутствуют. Наличие одной единственной даты позволяет эту задачу успешно решать.
Самые "матерые" примеры:
ADRC (таблица адресов), в ключе только дата с.
ANLZ (временные данные основного средства), в ключе только дата по.
CSKS (МВЗ), в ключе только дата по.
Так везде, повторюсь.

tanyxa написал(а):
Вариант ПК = год хорош, но с точки зрения пользователя может возникнуть недовольство "почему я должен исправлять имя варианта 3 раза"

Ну тут как с грибком и пенечком. Зато данное решение позволяет править вызываемый отчет и вариант без удаления записи или разбивки старого интервала на новые.

Ну сделайте тогда вот так: в ключе дата с. Тогда при наступлении следующих лет ничего менять не придется.
В программе, внутри которой происходит submit, поиск нужной строки осуществляться мог бы через read первой записи во внутренней таблице комбинаций "год - отчет - вариант", предварительно считанной и отсортированной по полю "Дата с" по убыванию, при этом "дата с" должна быть <= году запуска. При таком раскладе хотя бы нет пересечения интервалов, как в изначально предложенном Вами варианте.
Автор:  Кодер [ Чт, фев 15 2018, 15:57 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Yozhhhhh написал:
Я ни разу не видел в сапе, чтобы временно зависимые данные содержали в ключе обе даты.

Смотрите стандартные таблицы HR, Как сказала ТС. Например, PA0001, PA0002 и т.д.
Автор:  Kuranov.Dmitry [ Чт, фев 15 2018, 16:09 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Кодер написал(а):
Yozhhhhh написал:
Я ни разу не видел в сапе, чтобы временно зависимые данные содержали в ключе обе даты.

Смотрите стандартные таблицы HR, Как сказала ТС. Например, PA0001, PA0002 и т.д.

Стандартные таблицы инфотипов иногда и позволяют делать перекрытия.
та же HR таблица T512W имеет только поле ENDDA в ключе, так как там недопустимы перекрытия
Автор:  AFH [ Пт, фев 16 2018, 06:23 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
В общем случае даже если одна дата в ключе перекрытия возможны. Всё равно надо контролировать программно.
Автор:  Kengur [ Пт, фев 16 2018, 10:36 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Хозяйке на заметку. Еще есть способ хранения в поле -( секунды с эпохи - секунды ). Таким образом SELECT UP TO 1 выдает всегда самую "последнюю" актуальную запись. Используется вроде в таблицах процентов в осах.
Автор:  pberezin [ Вс, фев 25 2018, 11:50 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
раз варианты начали множиться - подумайте сразу насчёт 4го параметра: номер и класс сообщения из SE91.
потом, когда розыски в системе надо провести - где что в разрознееных кусках кода наворотили под каждый вариант, очень помогает включение в начале каждого такого условного блока кода псевдосообщений вроде, IF 1 = 2 THEN MESSAGE X001(ZZ1) ENDIF, где 001 и ZZ1 соответственно Ваш номер и класс сообщения, ссылка на который сохранена в Вашей настроечной таблице.
Значительно облегчает поиски и ревес-инжиниринг по системе.

Главное только всех абаперов на проекте приучить к такому стилю написания кода.
Автор:  Yozhhhhh [ Вс, фев 25 2018, 17:19 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
AFH написал(а):
В общем случае даже если одна дата в ключе перекрытия возможны. Всё равно надо контролировать программно.


Это, извиняюсь, КАК?

1. Действует с 01.01.1900 Отчет А Вариант 1
2. Действует с 01.01.2000 Отчет Б Вариант 1
3. Действует с 01.06.2009 Отчет В Вариант 69

Где тут перекрытия?
Вторую дату для такой Z-обработки вообще не только в ключ не надо вносить, но и вообще в таблицу.
Последняя внесенная запись будет автоматически действовать, пока не будет определена новая.
А программная обработка всегда нужна, раз есть нечто, что сабмитит отчет.
Автор:  Kengur [ Пн, фев 26 2018, 09:41 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Yozhhhhh написал:
Вторую дату для такой Z-обработки вообще не только в ключ не надо вносить, но и вообще в таблицу.
Последняя внесенная запись будет автоматически действовать, пока не будет определена новая.
А программная обработка всегда нужна, раз есть нечто, что сабмитит отчет.

это только если условие взаимоисключающее и не надо делать например интервал в котором значение отсутствует (не было настроено). но так сложно сделать программную выборку на базе запроса, т.е. надо поднимать на уровень приложения уже.
Автор:  Kuranov.Dmitry [ Пн, фев 26 2018, 09:55 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Kengur написал(а):
Yozhhhhh написал:
Вторую дату для такой Z-обработки вообще не только в ключ не надо вносить, но и вообще в таблицу.
Последняя внесенная запись будет автоматически действовать, пока не будет определена новая.
А программная обработка всегда нужна, раз есть нечто, что сабмитит отчет.

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

Почему сложно?
таблица:
Code:
mandt   begda            val
-----------------------------------
200   01.01.2017   y2017
200   01.01.2018   y2018
200   01.01.2019   y2019
200   01.02.2020   y2020
200   01.02.2021   y2021



Code:

data ls TYPE ztimetest.


select  *  INTO ls FROM ztimetest UP TO 1 rows  WHERE begda <= '20200301' ORDER BY begda DESCENDING.

write ls-val.
ENDSELECT.
Автор:  Kengur [ Пн, фев 26 2018, 10:17 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Kuranov.Dmitry написал(а):

select * INTO ls FROM ztimetest UP TO 1 rows WHERE begda <= '20200301' ORDER BY begda DESCENDING.


только сначала работает up to 1 а потом уже по нему order by

https://stackoverflow.com/questions/119 ... r-ordering
Автор:  Kuranov.Dmitry [ Пн, фев 26 2018, 10:21 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
O_o

Ну тогда можно убрать UP TO 1 ROWS и вставить EXIT.
Дырки можно реализовать используя строки с меткой что это дырка.
Автор:  Rizor [ Пн, фев 26 2018, 12:19 ]
Заголовок сообщения:  Re: STVARV vs Z-таблица
Kengur написал(а):
Kuranov.Dmitry написал(а):

select * INTO ls FROM ztimetest UP TO 1 rows WHERE begda <= '20200301' ORDER BY begda DESCENDING.


только сначала работает up to 1 а потом уже по нему order by

https://stackoverflow.com/questions/119 ... r-ordering


По ссылке речь идёт про SQL.

В open SQL судя по документации для UP TO n ROWS и практическому опыту, всё работает нормально:

Цитата:
If the addition ORDER BY is also specified, the rows of the hit list are sorted on the database server and only the number of sorted rows specified in n are passed to the results set.
If the addition ORDER BY is not specified, n arbitrary rows that meet the WHERE condition are passed to the results set.
Страница 1 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/