I have created a custom Business Object using Transaction BOBX. I would like to implement Change documents for this BO to keep record of all the transactional data changes made to this BO. These Change Documents should contain all the relevant information like the changed object dataset, old & new values, date & time of change along with the person name who has made the changes.
Is it possible?
Thanks in advance.
If you really wanna use SAP Change Documents, SAP provides a reusable BO /BOFU/CHANGE_DOCUMENT which allows to implement to recored all changes of your BOs. On Business Suite systems the BO is part of the Business Suite Foundation Layer, on S/4 systems it is part of the S/4 Foundation layer. For more details regarding how you can integrate it please check the official help (Using the Change Document Adaptor).
Related
I'm new to transport management in SAP. How does it work when customizing requests are imported into PROD? Do the customizing tasks get imported by order of creation?
Say that a released customizing task makes a change to a specific table record. After that, I want to correct the change made before so I create a 2nd customizing task to change the exact same record. Is there any risk that the 1st (wrong one) task gets imported after the 2nd (right one)?
Thanks.
It depends on transport strategy.
From your words one can assume you talk about Import Queue strategy with mass transports about which SAP Help clearly says:
All requests are imported into the target systems in the order they
were exported.
Single transports approach imply you are doing imports manually in whatever order you need.
So yes, the order matters.
Has anyone ever created a BAPI to create or edit a vendor in SAP R/3 4.6c in the background? I found two BAPIs: BAPI_VENDOR_CREATE and BAPI_VENDOR_EDIT, but both only work online (they call transactions XK01 and XK02).
Basically I need a way to call a function module that would do the same work as transactions XK01 and XK02 but don't need to be called online.
Looking on the SAP community forums, I found a lot of people with the same needs as me, but the answer was never complete.
Could someone give me a suggestion?
As you have discovered, SAP doesn't provide BAPIs for vendor creation/change that can be called in the background (this is, unfortunately, still the case in newer releases).
You have a few possible options:
Create your own BAPI, using (unreleased) SAP function modules for the vendor update.
Create your own BAPI, creating/changing the vendor via a BDC session.
I'd go with option 2. No, BDCs are never ideal and they have a lot of downsides but even a lot of SAP standard function modules for vendor creation seem to go that route and you'll at least be certain that the data in your system is consistent, unlike if you use something like function module VENDOR_INSERT, which does direct table updates without application validation.
Check if the standard vendor data transfer program (RFBIKR00) is in your system - it uses batch input so could be a very useful starting point for your BDC.
I am not able to figure out that how should I store system related information in Moqui.
For example, if I am using the HiveMind application for a particular organization (ABC Corp), I have to hard code the value while making records for the particular organization. I could not find any suitable entity that will allow me to handle this particular case.
So is there any method by which I can handle this particular case?
For example, when I am creating users and clients in the HiveMind application, there is no record in the database that will specify that the Users are employees of a particular organization.
For clients they are just stored in the Organization entity and no relationship exists that will specify that. I can handle that case by creating a party relationship whenever a new user or client is created.
But I will have to hard code the value of the Party with which I want to create the relationship. Suppose ABC corp is using the HiveMind application, I would have to hard code ABC corp's party Id whenever I create a new user or client. Rather that hard coding this value, it would be more efficient for me to fetch this particular value from the database. Whenever a new Organization wants to use the application, I will just change it in the database and the service code will remain as it is.
This is really an application design question and not an aspect of the framework, but I'll share some thoughts on it.
Business level configuration should generally be done in the database in structures (entities) that are designed for the purpose. Sometimes it general values are needed, but this should be the exception and only rare cases. In Moqui the way to handle user or user group preferences is to use the UserPreference and UserGroupPreference, and for all users use the ALL_USERS group that is standard in Moqui (all users are automatically part of this group). This can be done directly on the entities or using the relevant methods on the UserFacade (ec.user).
That said, from a business and application design perspective for apps based on Mantle (for others reading in, this is the business artifacts project based on Moqui) I wouldn't recommend doing it this way. If you want to support multiple organizations when creating an employee you should have a field on the form to select which organization the employee is part of (and then create the PartyRelationship record as you implied).
In HiveMind there can be multiple vendor organizations with people in different roles associated with them. When creating a project you select the vendor and client organizations for the particular project so we know who to bill from and to, which users are involved with different aspects of the project, etc.
If you do want to support just one vendor organization you may as well hard-code it and not make it visible or selectable anywhere in the application, and make it part of the "seed" data of the app in the more strict sense of the term seed data as data that code depends on directly (i.e. uses "hard-coded", though that term has negative implications that are often unjustified, directly use string values are often quite useful and improve clarity and maintainability).
I am working on a VSTO-Excel-Addin (VB.NET) that we are about to sell to different companies.
The addin will (hopefully) be used by a couple of users of each customer. We are using ClickOnce for a web-based deployment.
The addin provides some default-settings - that is no problem with the app.config. User-specific Settings are also working fine with ClickOnce.
However what makes quite some headache is how to store settings per customer. Database-connectionstrings for example cannot be stored on the application-level but it would also be painfull for all users to change the Connection-string manually. What I would imagine is another layer (per Company) where this sort of Setting can be stored.
One alternative would be to create one VSTO-Project per customer but this would bring a lot of disadvantages since we are updating the addin quite regularly.
I would be happy about any ideas!
Regards,
Julian
I would show Excel's built in connection properties dialog and let each client configure this themselves.
You really shouldn't be distributing connection strings for all your clients as part of a shared package. It'll be a maintenance nightmare.
http://office.microsoft.com/en-nz/excel-help/connection-properties-HA010175443.aspx
What about storing the settings as custom properties in Book.xltx and copy it to
C:\Users\username\AppData\Roaming\Microsoft\Excel\XLSTART
This is how you can programatically read and create Custom Properties in Excel.
When a new workbook is created then all the properties from Book.xltx will be available for New Workbook as well. But this solution may not work if the existing workbooks are opened so yo might have to explicitly add these properties when any existing workbooks are opened using the above solution.
Ok, I think I understand the problem. :)
How about storing all the settings in an offsite database that you maintain and using a webservice to allow the settings to be read and set and giving each client a unique license number that would allow them to access this webservice.
That way the individual users would only need a license number to set it up.
I would like to know whether there is any RFC or BAPI functions to display change documents (transaction RSSCD001) based on input query in SAP. The customer requirement is to implement a java monitor system on SAP without adding any ABAP functions on the SAP server.
I tried to make use of 'RFC_READ_TABLE' functions, which is deprecated according to the official documents, to read the CDPOS and CDHDR table and join them. But as vwegert said, to traverse the table CDPOS is really time-costing, as it contains billions of table entries.
My intention of this query is to find changes to all bank details of vendors.
Any other thoughts?
Many thanks in advance!
The least resource-consuming way to do this would be to use the workflow runtime system to actively notify the java application whenever a change document is written. You don't have to write any ABAP functions to do this, just setup the workflow engine (using the automatic customizing) and customize the event generation (documentation). Then, you write a java service that connects to the SAP system using JCo and registers as an RFC server using a destination of Type TCP/IP and a registered program ID. This java server program has to provide a function module handler that can be called using tRFC from the SAP system. Finally, add a linkage entry that will tell the workflow runtime system to call your java program each time a change document is written.
Of course, this will only record the changes that happen after installation, not the historical changes.
warning : I'm not very familliar with this field.
The RFC function BAPI_VENDOR_FIND (BAPI Vendor) seems to be used to find vendor based on values in table. You could use it to check gainst the modification date. This is not perfect, as there is no relationnal operator, only equals, and you'll have to check against several dates...
hopes this helps
Guillaume