Текущее время: Вс, май 27 2018, 16:04

Часовой пояс: 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
Сообщения: 916
Откуда: Москва
Пол: Мужской
Оба поля "с" и "по" в ключ никогда не вставляют.
У Вас в результате запросто может сложиться ситуация
запись 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
Сообщения: 916
Откуда: Москва
Пол: Мужской
tanyxa написал(а):
Насчет ключа не совсем согласна, весь HR модуль работает на концепции что каждая запись существует только в каком-то периоде жизни и в ключе всегда дата начала и дата конца.


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

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

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

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


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

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

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

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


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

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

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

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


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

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


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

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

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


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

Зарегистрирован:
Чт, мар 29 2007, 12:51
Сообщения: 133
Откуда: 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
Сообщения: 916
Откуда: Москва
Пол: Мужской
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
Сообщения: 1062
Yozhhhhh написал:
Вторую дату для такой Z-обработки вообще не только в ключ не надо вносить, но и вообще в таблицу.
Последняя внесенная запись будет автоматически действовать, пока не будет определена новая.
А программная обработка всегда нужна, раз есть нечто, что сабмитит отчет.

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

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


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

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

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


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

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


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

Сейчас этот форум просматривают: Google [Bot]


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

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