Текущее время: Сб, авг 18 2018, 16:56

Часовой пояс: UTC + 4 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: STVARV vs Z-таблица
СообщениеДобавлено: Чт, фев 15 2018, 13:24 
Начинающий
Начинающий
Аватара пользователя

Зарегистрирован:
Сб, дек 05 2015, 00:11
Сообщения: 7
Всем здравствуйте. Такой вот концептуальный вопрос.

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

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

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

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

В общем стоит ли завязываться с таблицей, или просто добавить третий параметр в STVARV?


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Чт, фев 15 2018, 15:15 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Ср, фев 21 2007, 09:50
Сообщения: 968
Откуда: Москва
Пол: Мужской
Оба поля "с" и "по" в ключ никогда не вставляют.
У Вас в результате запросто может сложиться ситуация
запись 1: с 2015 по 2018
запись 2: с 2016 по 2017
Оставим в стороне, что это натуральное вредительство и т.д. Такое реально.

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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Чт, фев 15 2018, 16:11 
Начинающий
Начинающий
Аватара пользователя

Зарегистрирован:
Сб, дек 05 2015, 00:11
Сообщения: 7
Yozhhhhh, спасибо за ответ.

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

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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Чт, фев 15 2018, 16:35 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Ср, фев 21 2007, 09:50
Сообщения: 968
Откуда: Москва
Пол: Мужской
tanyxa написал(а):
Насчет ключа не совсем согласна, весь HR модуль работает на концепции что каждая запись существует только в каком-то периоде жизни и в ключе всегда дата начала и дата конца.


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

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

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

Ну сделайте тогда вот так: в ключе дата с. Тогда при наступлении следующих лет ничего менять не придется.
В программе, внутри которой происходит submit, поиск нужной строки осуществляться мог бы через read первой записи во внутренней таблице комбинаций "год - отчет - вариант", предварительно считанной и отсортированной по полю "Дата с" по убыванию, при этом "дата с" должна быть <= году запуска. При таком раскладе хотя бы нет пересечения интервалов, как в изначально предложенном Вами варианте.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Чт, фев 15 2018, 16:57 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 16:38
Сообщения: 1142
Yozhhhhh написал:
Я ни разу не видел в сапе, чтобы временно зависимые данные содержали в ключе обе даты.

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

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Чт, фев 15 2018, 17:09 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Ср, сен 06 2017, 00:56
Сообщения: 328
Кодер написал(а):
Yozhhhhh написал:
Я ни разу не видел в сапе, чтобы временно зависимые данные содержали в ключе обе даты.

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

Стандартные таблицы инфотипов иногда и позволяют делать перекрытия.
та же HR таблица T512W имеет только поле ENDDA в ключе, так как там недопустимы перекрытия


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Пт, фев 16 2018, 07:23 
Специалист
Специалист

Зарегистрирован:
Чт, мар 25 2010, 10:02
Сообщения: 207
В общем случае даже если одна дата в ключе перекрытия возможны. Всё равно надо контролировать программно.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Пт, фев 16 2018, 11:36 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 19:21
Сообщения: 1124
Хозяйке на заметку. Еще есть способ хранения в поле -( секунды с эпохи - секунды ). Таким образом SELECT UP TO 1 выдает всегда самую "последнюю" актуальную запись. Используется вроде в таблицах процентов в осах.

_________________
я твой сап эфай внедрял
BAdI-позитив


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Вс, фев 25 2018, 12:50 
Специалист
Специалист

Зарегистрирован:
Чт, мар 29 2007, 12:51
Сообщения: 141
Откуда: Yugorsk.RU
Пол: Мужской
раз варианты начали множиться - подумайте сразу насчёт 4го параметра: номер и класс сообщения из SE91.
потом, когда розыски в системе надо провести - где что в разрознееных кусках кода наворотили под каждый вариант, очень помогает включение в начале каждого такого условного блока кода псевдосообщений вроде, IF 1 = 2 THEN MESSAGE X001(ZZ1) ENDIF, где 001 и ZZ1 соответственно Ваш номер и класс сообщения, ссылка на который сохранена в Вашей настроечной таблице.
Значительно облегчает поиски и ревес-инжиниринг по системе.

Главное только всех абаперов на проекте приучить к такому стилю написания кода.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Вс, фев 25 2018, 18:19 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Ср, фев 21 2007, 09:50
Сообщения: 968
Откуда: Москва
Пол: Мужской
AFH написал(а):
В общем случае даже если одна дата в ключе перекрытия возможны. Всё равно надо контролировать программно.


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

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

Где тут перекрытия?
Вторую дату для такой Z-обработки вообще не только в ключ не надо вносить, но и вообще в таблицу.
Последняя внесенная запись будет автоматически действовать, пока не будет определена новая.
А программная обработка всегда нужна, раз есть нечто, что сабмитит отчет.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Пн, фев 26 2018, 10:41 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 19:21
Сообщения: 1124
Yozhhhhh написал:
Вторую дату для такой Z-обработки вообще не только в ключ не надо вносить, но и вообще в таблицу.
Последняя внесенная запись будет автоматически действовать, пока не будет определена новая.
А программная обработка всегда нужна, раз есть нечто, что сабмитит отчет.

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

_________________
я твой сап эфай внедрял
BAdI-позитив


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Пн, фев 26 2018, 10:55 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Ср, сен 06 2017, 00:56
Сообщения: 328
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.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Пн, фев 26 2018, 11:17 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 19:21
Сообщения: 1124
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

_________________
я твой сап эфай внедрял
BAdI-позитив


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Пн, фев 26 2018, 11:21 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Ср, сен 06 2017, 00:56
Сообщения: 328
O_o

Ну тогда можно убрать UP TO 1 ROWS и вставить EXIT.
Дырки можно реализовать используя строки с меткой что это дырка.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: STVARV vs Z-таблица
СообщениеДобавлено: Пн, фев 26 2018, 13:19 
Ассистент
Ассистент

Зарегистрирован:
Пт, фев 01 2013, 11:27
Сообщения: 25
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.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 4 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB