День добрый,

Очень нужна помощь коллективного разума.

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

Согласно этому условию, счета, выставленные с 01 по 05 календарный день месяца должны быть оплачены не позднее первого календарного дня следующего месяца. Если же в месяце 31 день, то счёт должен быть оплачен 31 числа текущего месяца.

САП ответил стандартно (типа, нам ну оооочень жаль, но помочь не можем, стандартом это не предусмотрено).

Народ, может есть какие-нибудь экзиты, функциональные модули (и иже с ними), с помощью которых можно расчитать дату к оплате в зависимости от количества календарных дней месяца?

Буду очень признательна за любую информацию.

Наводящий вопрос : фактуры выставленные с 06 по последний день месяца когда должны быть оплачены?

Ок, вся раскладка выглядит следующим образом:

1-5 // оплата 01 числа следующего месяца //в месяцах с 31 днём оплата 31 числа того же месяца

6-10 //оплата до 05 числа следующего месяца

11-16 //оплата до 10 следующего месяца

17-19 // оплата до 16 следуюшего месяца

20-26 // оплата до 20 следующего месяца

27-31 // оплата до 26 следующего месяца

Всё выглядит несложно, за исключением первого значения...

Стандартом такое не реализовать. Задача интересная.

ТЕОРЕТИЧЕСКИЙ способ :
Можно создать 7 новых условий платежа. Попробовать подменять их динамически в SD (например экзитом RV60AFZC, хотя зависит от того что вызывает фактуру).

В зависимости от дня месяца из даты фактуры и кол-ва календарных дней в месяце (определить через ФМ HR_E_NUM_OF_DAYS_OF_MONTH) выбрать соответствующее условие:

1.Для оплаты 31-го текущего месяца V_T052-ZSTG1 = 31 и V_T052-ZSMN1 = ` ` - в этом случае 31 означает конец месяца, не обязательно 31е число.
2.Для 1-5го следующего V_T052-ZSTG1 = 1 и V_T052-ZSMN1 = `1 `,
3.для 6-10го V_T052-ZSTG1 = 5 и V_T052-ZSMN1 = `1 `
4.для 11-16го V_T052-ZSTG1 = 10 и V_T052-ZSMN1 = `1 `
5.для 17-19го V_T052-ZSTG1 = 16 и V_T052-ZSMN1 = `1 `
6.для 20-26го V_T052-ZSTG1 = 20 и V_T052-ZSMN1 = `1 `
7.для 27-31го V_T052-ZSTG1 = 26 и V_T052-ZSMN1 = `1 `

Удачи!

А почему вы все решили, что для фактур, выставленных с 6 по последнее число текущего месяца, отсрочка будет пропорционально сдвигаться?:)
Автор этого не писал. Задача стоит только в подмене срока платежа для месяцев, в которых 31 день.

Почему бы в exit не анализировать число дней в текущем месяце и рассчитывать дату платежа, после чего использовать условие платежа, настроенное без сдвигов и отсрочек, которое будет равно базовой дате. Она в итоге и будет содержать актуальное значение срока, при деблокировании в FI все значения уйдут в специальную группу полей, которые задействованы при расчете чистого срока платежа (забыл название ФМ, что-то типа ...NET_DUE_DATE).
В итоге в FI-документе у Вас в поле "Базовая дата" и будет актуальный срок платежа, условие без сдвигов и отсрочек (с нулями в соответствующих полях, их 4).

Если же в exit анализ дней в месяце вернул < 31, то использовать нормальное условие платежа.

Весь вопрос сводится к поиску нужного exit. Если же условием в сбыте можно пожертвовать (платеж все равно будет в финансовой бухгалтерии), то тогда вообще на втором моменте (он в RW-интерфейсах работает) анализируйте число дней обычным замещением и перебивайте нужное значение в данной группе полей.

Не решил. Отсрочка это в V_T052-ZTAG1, а я говорю о фиксированной дате V_T052-ZSTG1.

Ваш подход гораздо более эффективен (дешево, сердито) если фактур мало или если последствия "подмен" в документах FI типа даты или кол-ва дней никого не интересуют. Ну там аналитика, KPI всякие и т.д. Если исходящих фактур много, то надо делать правильно (т.е. качественно, дорого и долго).

А как мой способ коррелирует с количеством фактур?) Система будет сама делать за Вас, работа юзер-экзитов и замещений не должна волновать пользователя. Кроме того, я не слышал, чтобы на основе сбытовых фактур кто-то рассчитывал хоть какие-то показатели, особенно где фигурировала бы своевременность оплаты. Наконец, не обязательно доводить до FI (тем самым, действительно, заполучать неконсистентность между SD и FI). Условие платежа, выраженное конкретной датой, - это такое же полноценное и полноправное условие платежа. Дата фактуры измениться не может, поэтому перед данным условием не стоит требование гибкого пересчета: рассчитали дату оплаты - подставили константой в базовую дату (базовая дата - это полноценное поле в SD, потом это же значение условия и базовой даты пойдет в FI).

И все эти кренделя достаточно делать только в том случае, если: (дата выставления фактуры с 01 по 05) И (в текущем месяце 31 день). Для всего остального существует мастер кард:)

В мастере не разгуляешься. 1 клиент = 1 условие платежа. В задаче 7 ФИКСИРОВАННЫХ разных дат в месяце. Как вы все остальные случаи решите с помощью мастера?

Вообще-то я просто процитировал рекламу из перерыва Лиги Чемпионов А Вы о каком мастере говорите?)
По поводу 7 условий платежа, я с Вами соглашусь, я действительно проморгал второе сообщение от автора темы, прошу прощения.
7 разных условий - самое то.

Говорил о синонимах Customer master card = Customer master file = Customer master data и т.д.