aav
Администратор
Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург |
Добавлено: 16.10.2007 16:09 Заголовок сообщения: Синхронизация справочников учетных измерений
| Dmitry Pestov в своем блоге писал(а): |
| Довольно часто в Scala заводится две компании — одна для российского и одна для западного учета. В этом случае справочники учетных измерений могут существенно совпадать. Получается, что нужно заводить, редактировать и удалять новые значения сразу в нескольких места. Это не очень удобно.
Существует несколько способов решения. Например, можно сделать SQL-скрипт, который будет синхронизировать нужные справочники и регулярно запускать его (руками либо запланировать job). Еще можно сделать триггер, который будет выполнять такую работу. Вот и займемся созданием такого триггера.
|
Ой и скользкая эта тема… И тем более я не стал бы с такой легкостью об этом писать в открытом месте. И вовсе не из соображений "секретности"…
Во-первых, любой сотрудник хотлайна узнав про наличие триггера умоет руки и откажется помогать клиенту и на 100% будет прав
Во-вторых, существует довольно много методологических нюансов, которые требуется учесть, а они автором не учтены, например, можно ли и нужно ли удалять учетные измерения в "принимающей" компании, если они удаляются в исходной? Я уж не говорю о том, что в исходной компании по удаляемому учетному измерению могло не быть проводок, а в принимающей они могли быть и в этом случае удаление записи из GL03 таблицы однозначно неправильно.
При всей очевидной пользе, триггеры — как инструмент хирурга: можно получить пользу, но иногда, летальный исход. Именно поэтому я не согласен с тем, чтобы подобные советы публиковались "для всех". Вдруг их прочтет тот, у кого "очумелые ручки", но нет понимания методологических нюансов  |
Dmitry Pestov
Заслуженный форумщик
Зарегистрирован: 21.06.2007
Сообщения: 94
Откуда: Москва, ApicoSoft |
Добавлено: 19.10.2007 13:56 Заголовок сообщения: Синхронизация справочников учетных измерений
| aav писал(а): |
| Ой и скользкая эта тема… И тем более я не стал бы с такой легкостью об этом писать в открытом месте. И вовсе не из соображений "секретности"…
Во-первых, любой сотрудник хотлайна узнав про наличие триггера умоет руки и откажется помогать клиенту и на 100% будет прав |
Ну отключаем его на время проверки. Да и слишком широко применяются триггера, чтобы хотлайновцы не знали про них. По крайней мере триггер, висящий на PL01/SL01 и заполняющий учетное измерение конрагенты есть много у кого. Я и хотел начать сначала с него.
| aav писал(а): |
| Во-вторых, существует довольно много методологических нюансов, которые требуется учесть, а они автором не учтены, например, можно ли и нужно ли удалять учетные измерения в "принимающей" компании, если они удаляются в исходной? Я уж не говорю о том, что в исходной компании по удаляемому учетному измерению могло не быть проводок, а в принимающей они могли быть и в этом случае удаление записи из GL03 таблицы однозначно неправильно. |
Этот триггер не более чем пример. Никто не мешает подкорректировать его под свои нужды. Проверять же в триггере наличие проводок нельзя — он должен работать быстро. Нужно просто решить нужно ли удалять.
| aav писал(а): |
| При всей очевидной пользе, триггеры — как инструмент хирурга: можно получить пользу, но иногда, летальный исход. Именно поэтому я не согласен с тем, чтобы подобные советы публиковались "для всех". Вдруг их прочтет тот, у кого "очумелые ручки", но нет понимания методологических нюансов |
Ну я тут не вижу никакой опасности — если у "очумелых ручек" есть доступ к БД, позволяющий создавать триггеры, то здесь ничего не поможет, т.к. такой компании уже не до методологических нюансов 
Да, триггера вещь не всегда тривиальная, не совсем удобная в плане отладки, но именно поэтому и нужны примеры.
_________________
Dmitry Pestov
Блог ScalaHelp.RU — практические вопросы использования Scala |
aav
Администратор
Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург |
Добавлено: 06.11.2007 22:43 Заголовок сообщения: Про триггеры (страшная история)
Свое отношение к триггерам vs стандартная функциональность хочу проиллюстрировать фрагментом переписки, имевшей место 13 апреля 2004 года, когда я ещё работал экспертом Скалы. Самое первое письмо было адресовано всем консультантам СНГ, что, собственно, и заставило меня отреагировать достаточно резко.  Фамилии участников переписки мной опущены:
| Консультант по имени Сергей писал(а): |
| Коллеги, позвольте предложить вашему вниманию механизм, который может помочь обойти ограничение в 40 кодов автоучета в логистических модулях при списании материалов на различные счета. Механизм пока только тестируется, но, может быть, кого-нибудь из вас заинтересует уже сейчас или кто-нибудь уже имеет опыт (положительный или отрицательный) работы с триггерами в этом направлении.
Назначение триггера:
1)При вводе заказа на продажу для всех строк заказа ставит тот же учетный код, что и у внутреннего покупателя. Для этого в триггере есть специальный раздел, в котором идет проверка: покупатель внутренний или нет. Это помогает обойти ограничение в 40 кодов автоучета. При наличие триггера есть уверенность, что для каждой строки заказа стоит код автоучета из карточки покупателя, а не суммарный код.
2)Кроме того, в триггере выполняется проверка на предмет того, срабатывал ли он уже для этой позиции. Если триггер срабатывал, то
ничего не поисходит. Это дает возможность для отдельных строк вручную менять код автоучета не боясь, что триггер затрет эти изменения.
Идикатором того, что триггер срабатывал для этой позиции служит символ "1" в начале учетной строки. Он виден через интерфейс как единица в номере счета.
3)ИМЕЕТ СМЫСЛ ДЛЯ ВСЕХ ТИПОВ ЗАКАЗОВ, КРОМЕ 2 и 7, поскольку в них склад отрабатывает сразу. В конце предусмотрен блок для обхода этой ситуации со своими ограничениями (см. комментарий к этому блоку).
Изначально он не работает и закомментирован.
Для работы этого механизма не требуется установка дополнительного ПО, или какие-либо манипуляции со стороны пользователя — он работает в автоматическом режиме при вводе заказа на продажу.
Устанавливается очень просто: его надо запустить 1 раз из Query Analyzer на той базе, в котрой установлена Скала, предварительно поменяв номер компании в указанных местах. После этого он начинает действовать.
Изначально файл составлен для компании 03.
С уважением,
Сергей |
| Эксперт по имени Алексей писал(а): |
| Уважаемые коллеги, Сергей,
Мне кажется, что прежде всего следовало бы разобраться с тем, кому и по какой причине не хватает 41 учетного кода при списании запасов с помощью внутреннего покупателя, а уже потом пытаться искать конкретные пути решения этой проблемы. Для этого мне представляется логичным поговорить с теми, для кого эта проблема не нова и у кого накопились различные варианты ее решения.
Если кто-то не знает, кого спрашивать, могу назвать имена наиболее опытных консультантов в этой области или лучше адреса электронной почты (в алфавитном порядке):
Olga.[Фамилия]@scala.ru
Victor.[Фамилия]@scala.ru
Svetlana.[Фамилия]@scala.ru
Alexei.[Фамилия]@scala.ru
Мне кажется, что при нормальном плане счетов многое может быть разрешено стандартными средствами.
Второе замечание: Мне кажется, что стоит обратиться к Анатолию [Фамилия системного администратора] с просьбой создания специального списка по темам, что-то вроде #CIS Logistics Consultants, #CIS Financial Consultants (для того, чтобы не "грузить" всех темами, явно узкоспециализированными), разумеется, если это не противоречит политике компании.
Теперь по существу предлагаемого решения:
1. Триггер работает незаметно для клиента и это не достоинство, а огромный недостаток. Клиент должен отчетливо понимать, на что он идет, принимая решение подключить триггер: при возникновении каких-либо вопросов ни один здравомыслящий консультант хотлайна не возьмется консультировать такого клиента, ибо здесь не работает функциональность Скалы, за которую мы несем ответственность, а работает нечто, что хотлайн контролировать не может.
2. Заказы 3 и 7 типов здесь вообще ни при чем, так как не создают проводок по складу. Аналогом заказа 2 типа, где сразу делаются проводки, является заказ 8 типа, а не 7-го.
3. Ничего не сказано о том, что выбрано в качестве цены для внутреннего покупателя. Здесь, очевидно, имеется в виду, что цена продажи устанавливается равной нулю. А как быть, если работает другое правило?
4. Это только то, что лежит на поверхности, я не анализировал сам код триггера.
5. Уж если совсем никак не обойтись без "веревочной петли и палки", то существуют другие более изящные "внешние" решения, работающие уже непосредственно с таблицей журнала главной книги модуля "Управление запасами" (SC25).
6. Еще раз повторюсь, давайте пытаться перевести все на стандартную функциональность. Есть вопросы? На это есть эксперты. В конце концов, давайте обратимся к разработчикам. Я давно предлагал небольшое усовершенствование, которое могло бы (аналогично тому, как код НДС в заголовке заказа имеет более высокий приоритет) устанавливать код Автоучета для всех строк заказа равным учетному коду в заголовке заказа. Давайте сначала обсуждать проблему, а уже потом предлагать решения в виде конкретных программных кодов.
Alexei Vasiliev,
Scala Expert,
Scala CIS
Representation in St.Petersburg |
| Старший консультант по имени Дмитрий писал(а): |
Злой ты, Доцент, как собака.
Но я с тобой полностью согласен и мысленно тебе аплодирую |
| Руководитель проектов по имени Ольга писал(а): |
Леш, ты язва)))
Опустил [Фамилия консультанта] ниже плинтуса!
Даже типы заказов отметил))) |
| Эксперт по имени Алексей писал(а): |
| Как ты меня ласково
Ну не хотел я никого опускать, просто это нехороший пример для молодых консультантов: они, во-первых, будут обращаться к Сереже за советами, а во-вторых, подумают, что все проблемы следует решать триггерами. |
Не поймите, что я считаю, что "в жизни нет места триггерам" Я сам их иногда использую. Но только тогда, когда все другие варианты уже испробованы и не дали требуемого результата, а кроме того, я сам теперь — клиент и понимаю, к чему мои триггеры ведут и что я (и только я) несу за них всю ответственность.
|
