Как пользоваться LSMW я уже рассказал тут: Закачка начальных данных в LSMW
Главными преимуществами LSMW над собственной программой (с пакетным вводом или BAPI)являются:
- тюнинг в продуктивной системе без переносов
- использование без привлечения ABAP-разработчиков
Собственная программа даёт большую гибкость, поэтому я предпочитаю ABAP-код: трудозатраты примерно сравнимы. Но я скорее опытный разработчик, чем консультант.
Но если от консультанта будет постановка на разработку, то условные затраты будут в три раза выше: время разработчика + время консультанта + издержки коммуникации.
Теперь о нескольких напутствиях начинающим:
1. Вручную или LSMW
Вот вы сначала думаете: вот у меня мало строк – я могу их сделать вручную.
Подумайте заранее – может понадобится ли это ещё в будущем. В будущем могут появиться новые данные, может понадобиться повторение этих данных в другой системе или в другом манданте – в этом случае пакетный ввод имеет преимущество перед ручным вводом.
С другой стороны, можно потратить много времени на разбор частных случаев. Например: для транзакции FB01 в общем случае я бы не рекомендовал использовать LSMW – возникает много нюансов. Вводить их вручную – тоже собачья работа. Своя программа и BAPI тут удобнее будет.
2. Помните о длине полей
Не полагайтесь на приблизительные догадки касательно длины полей, и не делайте поля “с запасом” – указывайте точную длину.
EMAIL CHAR(20), HKONT CHAR(30), WRBTR(13) – это плохие идеи.
Во-первых, может быть неприятно если поле молча обрежется.
Во-вторых, в определённых случаях рассинхрона выгрузчика и загрузчика по длине полей можно получить неожиданные последствия вроде исчезновения в LSMW заполненных полей начиная с конца.
LSMW не очень красиво выглядит внутри – не давайте ему шанса споткнуться.
3. Помните о масштабе
Чем больше предполагается источников, тем внимательнее надо готовить шаблон. Если у вас 20 филиалов, то шаблоны надо готовить в 10 раз внимательней. Если есть бюрократия или географическая удалённость, то надо готовить в 100 раз внимательней – и иметь механизмы проверки или ограничения ввода “на взлёте”, а не “на подлёте”. Здесь могут быть варианты как с загрузкой и проверкой данных с проверкой в промежуточной Z-таблицу, так и макросы и прочие навороты Excel.
Каждый ваш недотраченный час может аукнуться несколькими часами в будущем, потраченными на выправление последствий. Технический долг, бла-бла-бла.
4. Не спрашивайте, если знаете
Не спрашивайте у пользователей “Технический счёт для закачки начального сальдо”. Вы его знаете, а они – не знают. Не спрашивайте дату и вид документа, если точно знаете.
5. Не спрашивайте два раза
Задайтесь вопросом – если есть два поля “Сумма по документу” и “Сумма во внутренней валюте”, то каковы шансы, что пользователи введут несовпадающие значения.
Не спрашивайте признак резидентства, если у вас есть признак страны.
Не спрашивайте “дебет или кредит” для второй стороны проводки, если пользователь говорит об этом в первой стороне проводки.
6. Спрашивайте то, что они знают
Если есть простая возможность спросить у пользователей то, что они знают вместо того, чего они не знают – выбирайте первое.
Вместо того, чтобы спрашивать их “Код проводки” (40 или 50) спросите их (+ или –).
Если пользователь плохо отличает дебитора от кредитора, то не спрашивайте вообще – по счёту остатка в главной книге их легко можно отделить друг от друга.
На начальном этапе пользователи легко могут ошибаться при выборе контрольного счёта. Даже в лучшем случае они будут выбирать счёт остатка, даже если этот счёт авансовый. Не спрашивайте, а проработайте заранее схему контрольных и альтернативных счетов.
При начальной загрузке не имеет смысл не запрашивать код ОГК. Если вы знаете счет, то вы можете проверить, связан ли этот счет с каким-либо ОГК.
7. Пробивайте все справочники
Само собой, если пользователю хочет ввести номер счёта и у него есть план счетов, то он всё равно может ввести несуществующий счёт. По разным причинам.
8. Держитесь корней
Если вы грузите основные данные при переходе со старой системы на новую – обязательно в шаблонах основных данных должно быть поле вроде “старый номер”. Это поле должно быть уникальным для исходной системы. Это поле очень легко заполнить, зато оно может потом помочь при разборе полётов.
По контрагентам этот номер не надо бояться тянуть в новую систему – для этого есть специальное поле. В плане счетов также есть поле аналогичного характера.
В основных средствах всё проще – роль “старого номера” выполняет инвентарный номер – он обязан быть уникальным и в старой системе, и в новой.
9. Контрольные цифры
Если у вас есть в системе процедуры расчёта корректности вводимого номера (налоговые номера, лицевые счета) – то желательно включение аналогичных проверок ещё “на взлёте”. Для Казахстана это могут быть поля РНН, БИН, IBAN. Причём первые два – собственная настройка, а последнее – стандартное и не отключается.
10. Больше проверок
Логические проверки не помешают.
Вот в качестве примера: страна уже *надцать лет как перешла на МСФО, а бухгалтеры на начало года могут попытаться показать начальное сальдо по счёту доходов.
Бухгалтер может дать остатки по счетам главной книги, в которых сумма по дебету (читай: активы) не равна сумме по кредиту (читай: пассивы).
Бухгалтер может дать отрицательное сальдо по счёту учёта материалов.
Бухгалтер может дать один остаток по главной книге, и другой остаток в разрезе аналитики (A+D+K+M).
11. Упорядочивайте проекты
Давайте правильные имена проектам и объектам LSMW. Давайте пояснения в исходной структуре.
Удаляйте тестовые, временные и неактуальные проекты. Если есть сомнения – экспорт, архив, проектная папка.
Проекты LSMW не пишутся в запрос автоматически – поэтому выберите одну систему в качестве оригинала (например: тестовую) и если есть важный тюнинг в продуктивной системе, то изменения необходимо повторить и в тестовой.