on 04-02-2009 5:08 PM
Hi everybody:
I am implementing some data validation on 2007 A PL 47 using SBO_SP_TransactionNotification, but the variable @object_type apparently holds the value '10000011' for every transactional document. I do correctly have '2' in that variable for business partners, and '171' for employees, but when the transaction is a purchase invoice, sales credit note or sales invoices, the @object_type variable always holds '10000011' and leaves me no way of verifying the object type that i'm dealing with. Is this a bug or something that I can fix?
Thanks for any insight,
Joerg.
ALTER proc [dbo].[SBO_SP_TransactionNotification]
@object_type nvarchar(20), -- SBO Object Type
@transaction_type nchar(1), -- [A], <u>, [D], [C], C[L]
@num_of_cols_in_key int,
@list_of_key_cols_tab_del nvarchar(255),
@list_of_cols_val_tab_del nvarchar(255)
AS
begin
-- Return values
declare @error int -- Result (0 for no error)
declare @error_message nvarchar (200) -- Error string to be displayed
select @error = 0
select @error_message = N'Ok'
-----------------------------------------------------------------------------------
-- ADD YOUR CODE HERE
-----------------------------------------------------------------------------------
IF (1=1) BEGIN
select @error = 1
select @error_message = @object_type
END
-- Select the return values
select @error, @error_message
end
Note: This issue seems to be related to the database, not the server itself, as I have copied that database to another server (from one MS SQL 2005 Server to SQL 2005 Express on my laptop) and have the same issue, while at the same time the issue does not happen on my other databases of the laptop...
Edited by: Joerg Aldinger on Apr 2, 2009 8:40 PM
Thanks for the various responses. I have already opened a support message with SAP so they can look into it. Will post back once I have a solution for this.
Thanks again,
Joerg.
PS: I reviewed the notes, but found nothing useful...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear
Testing with following codes:
if @object_type = 13 begin
select @error = 1
select @error_message = @object_type
end
adding a sales invoice, it will return 13.
it seems in the transactionnotification, there would be two object_type returned if there is vat code selected. the first one 10000011 will be vat transaction.
therfore, we still can use the SBO_SP_TransactionNotification to
notify about DB changes, cannot act as an approval mechanism and
database update process. refer to note 1011154
best regards,
xiaodan an
Dear Xiaodan:
Thank you for your help. You are indeed right with your analysis and I can now analyze the correct transaction if I take into account that the SP may be executed more than once during a single transaction. As to the SAP Note that you refer to (1011154) I understand it is outdated and according to SAP Note 1305742 it is now indeed allowed to set error values and cause the transaction to rollback. Part of the note, dated February 15, 2009, says:
Until 2007 release, the partner was allowed to enter his own code in the transaction notification stored procedure (SP), but he was not allowed to change the Error Code returned by the transaction notification and to prevent the transaction from being committed to the database. The only use of the SP was to receive the notification on the transaction execution.
...
Starting from release 2007 (A and B), it is allowed to set an Error Code different from zero and cause the transaction to rollback.
The SBO_SP_TransactionNotification must return two values - @error and @error_message.
If the returned @error is different from zero, the transaction will rollback.
This response solves my issue, so I am going to mark this question as answered.
Thanks for all your help,
Joerg.
Dear,
Please Check SQL like this:
EXECUTE SBO_SP_TransactionNotification N'13',N'A',1,N'DocEntry',N'1'
May be have many Select in Procedure
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You may need to check the field property for ObjType. It had been changed between B1 2005 and 2007.
Thanks,
Gordon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Gordon.
How would I check the field property? Do you refer to the @list_of_key_cols_tab_del variable?
If it's that, I can't rely on it, because it holds the same value for different types of oject (e.g. DocEntry is the key for both sales invoices and purchase invoices).
What I think is strange is that it works on some databases but not on others, even on the same server and with the same client...
Thanks,
Joerg.
The thread that you linked lists the different Object numbers as they relate to objects. I have those numbers as part of the SDK documentation, that is not the problem. The problem is that when the SP is called, I have '10000011' as the object type and not the number that is listed in the linked thread or in the SDK documentation.
And I do not know where this issue is coming from or how to correct it. In another test database this works as expected...
The thread that you linked lists the different Object numbers as they relate to objects. I have those numbers as part of the SDK documentation, that is not the problem. The problem is that when the SP is called, I have '10000011' as the object type and not the number that is listed in the linked thread or in the SDK documentation.
And I do not know where this issue is coming from or how to correct it. In another test database this works as expected...
Hi Jeorg,
I'd agree with Alexey, the most likely cause is that the database is corrupted in some way. Log it with SAP Support and they'll ask for a copy of the database to test.
Please note, the statement above is incorrect. @object_type was numeric in earlier versions of SBO but should now be nvarchar to cater for non-numeric UDO and UDT objects.
Kind Regards,
Owen
User | Count |
---|---|
108 | |
12 | |
11 | |
6 | |
5 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.