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

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

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

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

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

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

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

По поводу: будут «расходится с калькулятором» - На самом деле все зависит от калькулятора. Стандартно калькулятор и библиотека расчетов 1С (до версии 8, сейчас не знаю как), считает суммы исходя из представления числа как float, а вот SAP считает исходя из представления double persistent, т.е. плавающая точка двойной точности, соответственно для калькулятора, ну если он более менее вменяемый, нужно переключить точность расчета, после чего расхождения с калькулятором уйдут. А вот что делать с 1С, не подскажу.

Добрый день,
А четвертая часть будет?
Какая часть будет последняя?
 
Спасибо

Спасибо, поправили.