Как сформировать RecId

[Arahnid]

Цель учебная (Далеко посылать не надо, там я была и мне там не понравилось)

Пишу в Query Anal...(Это рабочий пакет - можно запустить. Задачка выполнима на типовой Аксапте)
Тут в принципе следующее
1. На входе передаются зачения переменных (в будущем они должны передаваться из аксапты)
2. Создаю в табличке строчку RTSLSessionTrans
3. Создаю в табличке строки LedgerTrans
(Условно - это будет что-то вроде трансляции)
Как бы хорошо, но одна проблема - как получить RecId для новых строк? (Если это не единственная проблема , то скажите, чего я еще не поняла)
Я увидела таблицу SystemSequences. Не понимаю значения строк и столбцов. Подскажите, что они значат? Может я маюсь над легкой задачей.

use AxTest

DECLARE @DateFrom     dateTime,
	@DateTo       dateTime,
	@AreaIdFrom   varchar(3),
	@AreaIdTo     varchar(3),

	@DateTSL         datetime,
	@TimeTSL         int,
	@TimeTSLTo       int,
	@UserTSL         varchar(5),
	@MODIFIEDTSID    varchar(4),
	@SessionTransId  varchar(20),
	@RuleGroupId     varchar(20)

SET	@DateFrom     = '2008-1-1'
SET	@DateTo       = '2008-1-10'
SET	@AreaIdFrom   = '01d'
SET	@AreaIdTo     = 'My'

SET     @DateTSL        = '2008-1-1'
SET     @TimeTSL        = 48534
SET     @TimeTSLTo      = 48534
SET     @UserTSL        = 'myna'
SET     @MODIFIEDTSID   = 150
SET     @SessionTransId = 'NC12154'
SET     @RuleGroupId    = '2008New'


INSERT  INTO bmssa.RTSLSessionTrans
		(
		FromDate,ToDate,StatusImport,StatusExport,NumTrans,SessionTransId,RuleGroupId,
		ClassId, InDate,
		MODIFIEDDATE,MODIFIEDTIME,MODIFIEDBY,MODIFIEDTRANSACTIONID,
		CREATEDDATE,CREATEDTIME,CREATEDBY,RECID,DataAreaId	
		)
VALUES		(
		@DateTSL,@DateTSL, 1,        1,           100,    @SessionTransId,@RuleGroupId,
		16475,@DateTSL,
		@DateTSL,@TimeTSL,  @UserTSL,@MODIFIEDTSID,
		@DateTSL,@TimeTSLTo,@UserTSL,50897999,@AreaIdFrom
		)				


INSERT  INTO bmssa.LedgerTrans 
		(
		TransDate, Voucher, Txt, AmountMst, AmountCur, CurrencyCode, 
		Posting, Correct,Crediting,PeriodCode,AmountMSTSecond,BondBatchTrans_RU,BondBatch_RU,
		Dimension, Dimension3_,Dimension4_,Dimension5_,Dimension6_,Dimension7_,Dimension8_,		
		--change coloumn
		MODIFIEDDATE,MODIFIEDTIME,MODIFIEDBY,MODIFIEDTRANSACTIONID,
		CREATEDDATE,CREATEDTIME,CREATEDBY,CREATEDTRANSACTIONID,	
		inDate,
		Dimension2_,
		RTSLFromCompanyID,
		RTSLSessionTransId,
		RTSLFromTransId,
		AccountNum,
		DataAreaId,
		recId
		)

	SELECT  TransDate, Voucher, Txt, AmountMst, AmountCur, CurrencyCode, 
		Posting, Correct,Crediting,PeriodCode,AmountMSTSecond,BondBatchTrans_RU,BondBatch_RU,
		Dimension, Dimension3_,Dimension4_,Dimension5_,Dimension6_,Dimension7_,Dimension8_,	
		--change coloumn
		@DateTSL,@TimeTSL,@UserTSL,@MODIFIEDTSID,--MODIFIEDTRANSACTIONID
		@DateTSL,@TimeTSLTo,@UserTSL,@MODIFIEDTSID,--CREATEDTRANSACTIONID	
		TransDate,       	--cahnge inDate,
		@AreaIdFrom,		--change Dimension2_
		DataAreaId,		--change RTSLFromCompanyID,
		@SessionTransId,        --change RTSLSessionTransId,
		recId,			--change RTSLFromTransId,
		AccountNum,
		@AreaIdTo,		--change DataAreaId
		recId + '18000'
	FROM bmssa.LedgerTrans AS LT1
	where   LT1.TransDate >= @DateFrom
	  and   LT1.TransDate <= @DateTo
	  and   LT1.DataAreaId = @AreaIdFrom	
          and   LT1.PeriodCode = 1 
	  and   LT1.RecId NOT IN (SELECT RTSLFromTransId FROM bmssa.LedgerTrans)

[oip]

А что-то типа такого не пойдет для генерации RecId?

-- Генерация RecId. На выходе не 0 если всё Ok и 0, если что-то не так
-- Входные параметры: код компании и шаг
-- Пример: exec AX_GETRECID 'dat', '25'

CREATE PROCEDURE [dbo].[AX_GETRECID] (@dataAreaId VARCHAR(3), @hop INT)
AS
SET NOCOUNT ON
DECLARE @RecID INT
SET @RecID = NULL
UPDATE SYSTEMSEQUENCES SET  @RecID = A.NextVal,
    NextVal = A.NextVal + @HOP
FROM SYSTEMSEQUENCES A WHERE A.Id = -1 AND A.DATAAREAID = @dataAreaId
SELECT ISNULL(@RecID, 0) AS RecId
RETURN ISNULL(@RecID, 0)
GO

[gl00mie]

Quote:

Originally Posted by Arahnid

Тут в принципе следующее
1. На входе передаются зачения переменных (в будущем они должны передаваться из аксапты)
2. Создаю в табличке строчку RTSLSessionTrans
3. Создаю в табличке строки LedgerTrans
Как бы хорошо, но одна проблема - как получить RecId для новых строк?

Про выделение RecId давным-давно писалось тут: Вставка строк в таблицы Аксапты сторонними средствами
Но расскажите, пожалуйста, зачем вы в LedgerTrans что-то создаете из SQL, минуя фигову тучу бизнес-логики, которая связана с созданием финансовых проводок? Чего вы такого хорошего планируете получить от вставки записей средствами SQL, что хотите отказаться от штатных аксаптовских механизмов?
К слову, у вас реально куплено 8 финансовых аналитик? А если потом 9-ю купите, то что, будете переписывать код вставки?

PS. К слову, при "ручном" выделении себе RecId для той или иной компании с целью вставки новой записи в табличку нужно учесть, что DataAreaId в SystemSequences может отличаться от DataAreaId для создаваемой записи, если табличка, в которой создается запись, относится к виртуальной компании. Разруливать, для какой именно компании в том или ином случае выделять RecId, вы будете тоже в хранимой процедурке? Оно, конечно, несложно, только вот стоит ли овчинка выделки...

[Russland]

Quote:

Но расскажите, пожалуйста, зачем вы в LedgerTrans что-то создаете из SQL, минуя фигову тучу бизнес-логики

Согласен с gl00mie. Опишите вашу задачу подробнее. Возможно вам необходимо работать с бизнес-коннектором, используя уже готовые классы Аксапты.

"Ручное" создание строк - это очевидная, однако, тупиковая идея.

[Михаил Андреев]

Есть штатная функциональность, которая создаёт проводки по ГК "без излишеств" - консолидация. Можно её поковырять или даже взять за основу.

[oip]

Я отвечал исходя из того, что у формирования записи вручную - "Цель учебная". Просто научиться их формировать. Полностью согласен, что в LedgerTrans ни в коем случае нельзя формировать записи вручную. Записи средствами SQL вручную обычно можно вставлять только в какие-либо относительно отдельные (не участвующие в бизнес-логике) таблицы, которые специально для этого сделаны. Я такие таблицы использовал, например, при интеграции с какими-либо внешними системами.

[Russland]

Quote:

Записи средствами SQL вручную обычно можно вставлять только в какие-либо относительно отдельные (не участвующие в бизнес-логике) таблицы, которые специально для этого сделаны.

Золотые слова

[Михаил Андреев]

Полностью согласен. А для специально созданной таблицы и генерировать RecId "по уму" необязательно

[Russland]

Скажу больше: даже для специально созданной таблицы/таблиц, логичней пользоваться методами и классами Аксапты и уже коннектором манипулировать ими.

В идеале: избегать бизнес-логики вне Аксапты.

[oip]

Это если коннектор куплен.

[Arahnid]

1. Коннектора нет
2. Цель реально учебная - на данный момент
3. В реальности хотелось попробывать создать замену трансляции. У нас счет - в счет, ну это почти. Есть отклонения и они впоследствии из базы-приемника не выковыриваются.
4. Не до конца понимаю проблем. Я просто сделаю копию проводок, поменяв идентификатор - dataAreaId на нужную компанию. Пересчитаю итоги. Типа готово.
Попутно заполню табличку RTSLTRANSLOG, ledgertrans and SYSTEMSEQUENCES.
Почему вы говорите, что это плохо. Какие еще выполняются операции при Трансляции?
А что касается консолидации - так она делается медленно тоже, а переделав ее, я получу фактически трансляцию по времени. Средства SQL выполняют данную операцию за 10 секунд.

[egorych]

SYSDATABASELOG не заполняете? Или историю по этим табличкам не ведете ?

[Arahnid]

Quote:

Originally Posted by egorych

SYSDATABASELOG не заполняете? Или историю по этим табличкам не ведете ?

мы не ведем.

Товарищи, которые не рекомендовали так делать, объясните - почему вы все же не рекомендуете так делать?
Пока не увидела ни одной веской причины, что у меня не будет работать.

[gl00mie]

Quote:

Originally Posted by Arahnid

объясните - почему вы все же не рекомендуете так делать?

В условиях работоспособности вашего варианта решения слишком много "если":

• если не вести логирование И
• если правила трансляции останутся счет - в счет И
• если не понадобится навесить доп.логику на создание проводок в LedgerTrans И
• если ...

плюс, оно "дороже" в плане сопровождения - тому, кто будет поддерживать такое решение, надо будет:

• уметь писать хранимки на T-SQL или PL/SQL;
• иметь соотв. доступ к базам (разработческой, тестовой, рабочей);
• не забывать переносить отдельно еще и эти хранимки при обновлениях кода;
• не забыть перенести их на новую базу, если понадобится тиражировать ваше решение;
• etc...

А в остальном, никто, конечно, не утверждает, что ваше решение не будет работать. Работать оно будет - вопрос лишь, при каких условиях и ценой каких затрат...

PS. Вот еще, вспомнились Безболезненные функциональные спецификации Джоэла Спольски:

Quote:

Хуже всего, что программист, который потратил 2 недели на написание определенного кода, привязывается к нему душой, независимо от того, насколько тот неправильный. Неважно, что скажут начальник и заказчики Быстряковой. Они не убедят ее выбросить прекрасный код конвертера, даже если он имеет не самую лучшую архитектуру. В результате конечный продукт имеет тенденцию становиться компромиссом между изначально неправильной разработкой и идеальной разработкой. Это было «лучшей разработкой, которую мы могли получить, учитывая то, что мы уже написали весь этот код, и мы просто не хотим его выбрасывать». Это звучит не так хорошо, как «самая лучшая разработка, которую мы могли получить. Точка».

Так что не торопитесь реализовывать ваше решение, подумайте...

[Arahnid]

Все мило. Но какова альтернатива трансляции?

Если даже вообще убрать все условия и просто отмножить проводки, то получается порядка 40 минут. Если использовать SQL время идет секундами. Мне не хотелось лезть в СКУЛЬ, но альтернатива где? Не вижу. Как не изощеряйся средствами аксапты , вставка строк идет очень медленно.

Может кто пдскажет тогда альтернативное решение трансляции с полученим того же результата, что и трансляция. ПРоблема ремени стоит у нас остро.

[gl00mie]

Quote:

Originally Posted by Arahnid

Если даже вообще убрать все условия и просто отмножить проводки, то получается порядка 40 минут. Если использовать SQL время идет секундами. Может кто пдскажет тогда альтернативное решение трансляции с полученим того же результата, что и трансляция. Проблема ремени стоит у нас остро.

Обычно на вставке кучи записей тормоза в Аксапте бывают по нескольким причинам:

• куча тяжеловесных проверок или сопутствующей логики на insert();
• настроенное логирование таблицы;
• выполнение кода, переключающегося в другую компанию (на удивление тормозная операция);

Видимо, в вашем случае дело в последнем пункте, если вы не написали кучу кода в LedgerTrans.insert() и не включали логирование этой таблицы. Тогда выходом может быть оптимизация алгоритма трансляции с тем, чтобы он работал не по одной проводке за раз, а сразу на пачке проводок (с использованием, к примеру, RecordInsertList как буфера-накопителя создаваемых проводок), тем самым сокращая число переключений между компаниями. Посмотрите, к примеру, на методы validateTrans() в классах-наследниках RTSLLedgerConvert (RTSLLedgerTransConvert, RTSLDimensionConvert, RTSLCurrencyConvert) - там дергается changecompany(), и это, получается, происходит по несколько раз для каждой транслируемой проводки. Неудивительно, что процесс трансляции при этом даже на простейших правилах проходит очень долго.

[sukhanchik]

Если смотреть с т.з. консалтинговой конторы - то чем меньше модификаций придется делать - тем это менее затратно (более рентабельно). Т.е. чем больше решение для одного клиента подходит для другого - тем лучше.
Соответственно - чем ближе к стандартному функционалу решение - тем лучше (более обще) - т.к. каждый клиент начинает отталкиваться от стандарта (он известен).
Поэтому консалтинговая контора не заинтересована финансово в таком решении.
Однако вариант - удовлетворить клиента и уйти - тоже не исключен - если это единственный способ избежать убыточности проекта.

Если смотреть с т.з. клиента - то часто распространена позиция "главное шоб работало". Клиенту неважна какая система у него работает - главное - что работает. Однако часто при этом забывается - что при отклонении от стандарта - затрудняется дальнейшее обновление версии. Т.е. получается, что обновить версию становится дороже, чем вручную запрограммировать то, что запрограммировали в Микрософте в новой версии, при условии что это вообще сделать можно (ядро не перепишешь).

Т.е. Ваше решение - оно правильное, работоспособное - и приведет к сиюминутному результату. Вот только все должны адекватно понимать - что оно будет лишено развития со стороны Микрософта. Т.е. это будет не Аксапта - а решение, сделанное на платформе Аксапты.

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

[Arahnid]

Что проблема в смене компаний - посмотрю,но мне не удалось поменять трансляцию так, чтобы использовать массовый ввод. Проще переписать.

[gl00mie]

Quote:

Originally Posted by Arahnid

мне не удалось поменять трансляцию так, чтобы использовать массовый ввод.

Посмотрите в метод \Classes\RTSLLedgerTranslation\processRules. Там идет, насколько я понимаю, выборка исходных проводок LedgerTrans в соответствии с заданными критериями, затем формируется запись во временной таблице и передается на обработку в метод processTransaction(). Этот метод, в свою очередь, делает по большому счету следующее:

1. проверяет исходную запись по переданному правилу;
2. проверяет по логу RTSLTransLog, что запись LedgerTrans, на которую ссылается переданная на обработку запись временной таблицы, не была уже обработана;
3. собственно выполняет трансляцию в соответствии с указанным правилом, формируя новую запись во временной таблице;
4. обновляет лог RTSLTransLog по обработанной записи.

Здесь пункты 1, 2, 4 выполняются в текущей компании, а вот п.3 (конвертирование с проверками) как раз приводит к многчисленным переключениям в другую компанию (одну и ту же). Какие тут могут быть варианты:

• накапливать все записи, выбираемые в цикле метода processRules(), перед их последующей обработкой;
• в таблицу RTSLTransLog добавить поле "код компании", а у самой таблицы сделать SaveDataPerCompany == No, чтобы вести лог можно было, не заботясь о переключениях между компаниями;
• выполнять одним этапом проверку накопленных ранее записей по переданному правилу и отсеивать записи, не прошедшие проверку;
• выполнять одним этапом конвертирование записей, прошедших проверку, переключившись предварительно в нужную компанию.

Quote:

Originally Posted by Arahnid

Проще переписать.

Это кажущаяся простота. Пока правила трансляции у вас остаются "счет - в счет", можно, конечно, нарисовать что-то свое "сбоку", но если понадобится усложнять правила трансляции, то вы фактически будете писать заново то, что уже реализовано в стандартном функционале.