Apico Soft / АПИКО Софт



Спонсором блога ScalaHelp.RU является компания АПИКО Софт.

Мы предоставляем:
- Качественный ERP консалтинг.
- Внедрение и сопровождение системы.
- Российские формы первичных документов, бухгалтерская и налоговая отчетность.

- Разработка корпоративной отчетности.

Наш телефон 8 (495) 961 98 48
Сайт http://www.apicosoft.ru/

Позвоните нам, мы сделаем все, чтобы помочь Вам.

вторник, октября 16, 2007

Синхронизация справочников учетных измерений

Довольно часто в Scala заводится две компании - одна для российского и одна для западного учета. В этом случае справочники учетных измерений могут существенно совпадать. Получается, что нужно заводить, редактировать и удалять новые значения сразу в нескольких места. Это не очень удобно.

Существует несколько способов решения. Например, можно сделать SQL-скрипт, который будет синхронизировать нужные справочники и регулярно запускать его (руками либо запланировать job). Еще можно сделать триггер, который будет выполнять такую работу. Вот и займемся созданием такого триггера.

Текст триггера (проверено iScala 2.2 SR1):

create trigger GL03SYNC_ ON [dbo].[GL03]
for insert, update, delete
as

begin

set nocount on

declare @DelCount int, @InsCount int, @DimList as nvarchar(100)

-- список УИ, все 'BCDEFGHIJ'
set @DimList = 'BCDE'

select @DelCount = count(*) from deleted
select @InsCount = count(*) from inserted

-- Update
if @DelCount > 0 and @InsCount > 0
begin
update s set
GL03001 = i.GL03001, GL03002 = i.GL03002, GL03003 = i.GL03003, GL03004 = i.GL03004, GL03005 = i.GL03005,
GL03006 = i.GL03006, GL03007 = i.GL03007, GL03008 = i.GL03008, GL03009 = i.GL03009, GL03010 = i.GL03010,
GL03011 = i.GL03011, GL03012 = i.GL03012, GL03013 = i.GL03013, GL03014 = i.GL03014, GL03015 = i.GL03015,
GL03016 = i.GL03016, GL03017 = i.GL03017, GL03018 = i.GL03018, GL03019 = i.GL03019, GL03020 = i.GL03020
from GL03 s
join inserted i on i.GL03001 = s.GL03001 and i.GL03002 = s.GL03002
where charindex(i.GL03001, @DimList) > 0
end

-- Delete
if @DelCount > 0 and @InsCount = 0
begin
delete s
from GL03 s
join deleted i on i.GL03001 = s.GL03001 and i.GL03002 = s.GL03002
where charindex(i.GL03001, @DimList) > 0
end

-- Insert
if @DelCount = 0 and @InsCount > 0
begin
insert into GL03
select * from inserted i where charindex(i.GL03001, @DimList) > 0 and not exists
(select * from GL03 s where i.GL03001 = s.GL03001 and i.GL03002 = s.GL03002)
end

end

В приведенном тексте нужно:


  • Заменить <C1> на код компании-источника
  • Заменить <C2> на код исходной компании-приемника
  • Заменить <YY> на финансовый год (2 символа)
  • Отредактировать список учетных измерений, подлежащих синхронизации - переменная @DimList

Триггер требуется повесить на все таблицы GL03 в компаниях-источниках (обычно компания российского учета). При заведении нового года нужно не забывать добавлять и новый триггер.

После установки триггера, все операции в синхронизируемых справочниках желательно проводить только в компании-источнике, иначе возникнет расхождение.

3 комментария:

  1. Очень тонкий момент проверки обновления. Например в передающей компании происходит обновление, а впринимающей ввод нового значения. Данный текст приведет к ошибке.

    ОтветитьУдалить
  2. Согласна с предыдущим комментарием, использование данного script приведет к ошибке. Удаленное значение (для случая delete) удаляет значение из справочника, но при этом не происходит анализа в GL06 (проводки главной Книги) на существование проводок с удаляемым значением. В результате получаем проводки с отсутствующим кодом учетного измерения. Дальнешие развития событий: После запуска стандартной функции "Перестройка файла сальдо" система все подобные проводки отнесет на счет 999999. Т.е. таким образом вы получите "кашу" и поплывший баланс модуля Главная Книга.

    ОтветитьУдалить
  3. Полностью согласен с предыдущими ораторами :)
    И при этом буду утверждать - решение имеет право на жизнь и оно реально уменьшает количество проблем с учетными измерениями.
    Главное правило - учетные измерения, для которых включена данная процедура, нужно изменять строго в основной компании. Проблема же с удалением не такая актуальная - во-первых, при удалении УИ в основной компании будет сделана проверка на присутствие его в проводках, во-вторых и при неправильном удалении никаких проблем восстановить УИ позже нет.

    ОтветитьУдалить