Создал новый вид фактуры ZF2 с помощью копирования стандартной фактуры F2. В новой фактуре схема калькуляции такая же как и в F2. Однако, при сохранении ZF2 не формируется бухгалтерский документ. Как оказалось это из-за того, что в ZF2 стоимость нетто осталась нулевой, хотя схема калькуляции идентичная и сам расчет внутри схемы проходит правильно.
Кто-нибудь сталкивался с такой проблемой?
Повторюсь, что схема калькуляции и расчет внутри схемы, а также настройка видов документов как у ZF2, так и у F2 абсолютно идентичные.

в смысле в схеме указана цена, тоннаж, а стоиомсть нолевая? объясните. плиз, поподробней, правда стало интересно

Цена то хоть в позиции ZF2 не не нолевая?

Я же говорю, в ZF2 всё так же как и в F2. Цена есть, стоимость условия цены тоже есть. Разница только в одном - в поле "Нетто" в фактуре ZF2 стоит ноль.

1. Пошерстите анализ расчета цен.
2. Провалитесь в фактурах в каждый вид условия и сравните настройки.
3. Проверьте экзиты. Они могут быть написаны с привязкой к конкретному виду фактуры (поубивав бы таких абаперов )

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

Интересно, а как еще можно сделать, если не так, ну например в такой ситуации:

Для конкретной технологии был разработан вид фактуры. Для него требуется влазить в ценообразование. И как писать екзит, не прописав в нем вид фактуры?

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

ЗЫ я не отрицаю, что иногда по-другому и не сделать, - накипело, вот и прокамментил. Достали ситуации, когда из-за экзитов и отчетов, где только и анализируется, что конкретные виды документов/коды проводок/номера счетов/деловых партнеров/материалов, - поменять что-либо в настройках и процессе оооочень проблематично. Будешь вылавливать тараканов еще полгода. Ну ведь работает 90% стандартного кода абстрагированно от конкретики.
Поэтому мое мнение - чем таких экзитов и отчетов меньше, тем и проблем, и работы по актуализации на мою голову тоже меньше.

Очень просто - по принципу "смотри на САП, делай как САП"
1. Абапер делает для этой задачи z-настроечную таблицу со столбцом "вид фактуры", генерит к ней ракурс ведения
2. Абапер в эксите делает селект к этой таблице с проверкой, есть ли там строка с тем типом фактуры, который в данный момент обрабатывается.
3. Консультант при помощи транзакции simgh добавляет к стандартному дереву настроек в спро свою настройку с этой таблицей. Там же кратко документируем: что за настройка, в каком эксите используется, на что влияет.
4. Консультант через spro добавляет в таблицу строку с нужным видом фактуры

На все про все при наличии опыта этих действий уйдет по 15 минут у абапера и у консультанта. Зато плюсы налицо.

согласен с LKU - плохо бывает не от использования пользеровских расширений, а от того КАК их используют отдельные люди и КАКУЮ документацию после себя оставляют... и оставляют ли вообще

Да САП может и делает такое, но для каких-то общих моментов, на которые можно гибко и быстро влиять этими настройками.
Если собственно разрабатываемая технология не подразумевает изменений, это все лишнее.
Если в результате эксплуатации и возникнет необходимость в изменениях, все равно лезть в екзит неизбежно.

15 минут ну ну
Особенно я думаю будет информативна и исчерпывающа документация, если на все четыре пункта уйдет 15 мин.