Михаил, да. Это самый корректный вариант для массового применения в компании.

И упомянем самый правильный вариант - настроить SSO. В этом случае все пользователи создаются без пароля. Пользователи не могут забыть пароль, не могут заблокировать учётную запись многократным неправильным вводом пароля, пользователям не придётся периодически менять пароль и, главное, не смогут передать свой пароль другому сотруднику.

можно также использовать возможности команды Shortcut или сделать свой файл .bat
 
1. Открываем командную строку
Win+R
 
2. Вводим sapshcut -sysname=SYSTEM_NAME_IN_SAPLOGON -client=100 -user=USER_NAME -pw=PASSWORD -language=RU

Оно то конечно про голову классно, но когда систем вагон, правила формирования паролей разные в разных системах разные, короче никакой головы не хватит и остается или хранить в ярлыке или на листочке (телефоне, нотпаде и т.д.)

Сейчас как раз находимся в процессе внедрения. Стандартное решение до сих пор содержит ошибки, к сожалению.
 
Отвечая на вопрос Артема, могу сказать, что наличие строк в журнале в общем-то не нужно (исходя из опыта эксплуатации). Вся информация тянется автоматически из основной записи материала (или можно легко дозаполнить в BADI) и проблем не вызывает. Исключение - это поля по заявлению о ввозе из стран ТС, почему-то в стандартном решении ничего по этой теме не предложено. Раньше хоть российский блок отслеживания ГТД использовался, сейчас же всё убрали.
Вся информация о строках хранится в виде XML прямо в SAP, и используется, например, для выписки дополнительных ЭСФ путем обратного восстановления информации из XML.
 
Большой минус в стандарте - нет достаточного количества точек расширения, чтобы изменять логику, приходится выкручиваться. Например, поиск позиций оригинального документа к дополнительному у нас не работает (по-другому построен сбытовой поток).
 
Не соглашусь с автором в том, что в настройке интеграции с ИС ЭСФ консультант принимает минимальное участие. Базису нужно сказать что именно делать, по крайней мере у нас такая картина.

Да оно по большому счету почему-то и не на больших актуально: sapforum.biz/index.php
 
Вот тут разбор такой ситуации.

Со стороны сбыта я с таким не сталкивался, а вот в закупках и на больших объемах это должно быть актуально

Да вот как раз расхождения между SAP и 1С из-за вот этой вот точности используемых чисел и возникают, ну по крайней мере в закупке, когда на той стороне документ рассчитан и напечатан в 1С.

Нет, это пока последняя.

Олег,
 
Я обращаю внимание на то, что значения будут "расходиться с калькулятором" когда пользователь проверяет значения в печатной форме, не обращая внимания на то, как они были расчитаны. В этом случае ошибки возникают в основном из-за округления до копеек на каждом шаге рассчета. Ошибки округления, связанные с точностью из-за типа переменной, также возможны, но, на мой взгляд, значительно реже.