I am writing a custom Fiori to access sales data from an SAP ERP backend system using a Gateway.
The use case is "customer logs in launchpad, opens Fiori app and sees all his/hers sales items based on the customer id". The customer id is stored in kna1-kunnr and has to be included in a select on the vbak table in SAP. Nothing fancy.
Now I ask myself: how do I get the customer id / kunnr? What do I get at all from the currently logged in user? When debugging my Gateway project code, is it actually the name stored in sy-uname or can I get something better?
How should I continue to get the customer id / kunnr? Are there some function modules like GET_CUSTOMER_ID_OF_USER to call in the SAP ERP?
Or are the actually other / better ways to get the sales documets for one user?
Update
Thank you for your answers so far. I am going to check the default Fiori implementations to get some inside. But, since we are already here, I want to specify my question a little bit more:
Giving I create an OData model in my Component.js like that:
var oModel = new sap.ui.model.odata.ODataModel("[...]/sap/opu/odata/sap/Z_MYODATA_SRV/",
false, "user", "password" );
user and password are supposed to be the ones currently entered as user credentials in the Fiori Launchpad. How can I access those? Are there some SAPUI5 api like getCurrentUser or getCurrentSession ? Do I actually have to do this user check?
You are correct that to identify all of the sales orders for a customer you need to read them from VBAK (or use BAPI_SALESORDER_GETLIST, etc).
The relationship between logged in user and customer is not something that's the same in every SAP ECC system. You may find that the logged in user is the same as the customer number, but with a prefix - for example, logged in user C12345678 for customer 0012345678. Or there may be some other type of relationship that's store in a custom field on the customer master itself. The best option is to check with the person responsible for the configuration in Sales and Distribution. Only then can you know how to determine the customer for a logged in customer user.
Answering your question
Now I ask myself: how do I get the customer id / kunnr? What do I get at all from the currently logged in user?
It is done on backend with standard customizing, not via OData methods like you intend to do it.
Mikael gave you the rough idea, but didn't finished it so I will give a more comprehensive answer.
We need to differentiate between front-end and back-end authorizations, for Fiori app functioning you need to types of roles/authorizations:
The SAP Fiori roles that define which Fiori apps are displayed to the user
Launchpad authorizations
General OData authorizations
Trusted RFC back-end connectivity authorizations
Back-end authorizations and roles which contain authorizations to display the related business data
This concept is depicted on this figure:
The assignment of the front-end is described here and is out of scope now. Now we are focusing on bullet 2.
Every Fiori app has its role model and one should follow the implementation given in app description. Let's consider how it is done based on Sales Order creation app (F0018) sample:
OData service that returns business-data is SRA017_SALESORDER_CREATE_SRV, so to run it one needs frontend role SAP_SD_BCR_FIELDSALESREP_X1 and backend role SAP_SD_SO_CRE_APP
Also app description give us the following prerequisits:
Before implementing the Create Sales Order app, you must ensure the following:
That an employee master record is created with the following attributes:
If you have implemented SAP ERP HCM and maintained employees in the HCM personnel records, ensure that the employee personnel record has the infotype Communication, with a subtype of System User Name (SY-UNAME) (Infotype 0105, Subtype 0001).
If you have not implemented SAP ERP HCM, implement the Sales and Distribution configuration around Use Sales Employees with HR (Tcode: PULT). This IMG setting copies the appropriate HCM tables from the 000 Client and allows the setup of the employee record with the Infotype Communication and a Subtype of System User Name (SY-UNAME) (Infotype 0105, Subtype 0001).
It associates the USERID of the employee with the personnel number assigned as a partner function sales employee in the customer master.
After implementing the above customer SAP user id will be bound to his employee ID (PERNR), and his employee ID consequently will be bound to partner function in XD02.
And that's not all, what comes next?
THe following order parameters should be maintained in in SIMGH tcode in order customer to see his orders and can create the new ones.
Call transaction SIMGH to open the Create Sales Orders node and configure user information in Customizing activity Define Configuration Parameters using the parameters listed below. For more information, see the documentation available for the Customizing activity.
Document Type (DOCTYPE)
By default, the app uses the standard order document type (technical key TA resp. OR). Changing this to something other than a sales order may significantly impact the functionality of the application.
Order Period (ORDPERIOD)
This defines how many days into the past sales orders are retrieved. The suggested value is 30 days.
Search Period (SEAPERIOD)
This defines how many days into the past a search must look for sales orders that match the search criteria. The suggested value is 90 days.
Ship To Party (SHIP_TO/PARTNER_ROLE)
This defines which partner role in the customer master is used for the ship-to party. The suggested value is WE.
Forwarding Agent (FORWARDING_AGENT/PARTNER_ROLE)
This defines which partner role in the customer master is used for the forwarding agent. The suggested value is SP.
and even that's not all
App description gives the following BADIs to implement in order to enable such linking
Implement the following BAdIs:
Customer Association to Employee
You can use this BAdI to associate employees with specific customers.
Only after all the above steps the customer will be able to order and/or view his sales items.
The moral: always check the app description thoroughly because the role model varies per-app.
Have a look at the standard Fiori applications. For example, in Create Sales Order, there is a BADI provided to implement the relation you are looking for (but for an employee to a customer). In the standard setup, the partner functions of the customer master is used to map what customers are visible to an employee.
Most likely, you have a similar setup already in place if your customers actually have user accounts in your system. If could be as a parameter of the user or as a (custom?) partner role.
http://help.sap.com/saphelp_fiorierpx1_100/helpdata/en/6d/135652f9c21457e10000000a445394/content.htm
Related
I'm developing an app using the low code platform SLINGR. I need to set permissions by the company an user belongs to.
What would be the best approach to implement this?
Any help would be greatly appreciated.
The best way to achieve this is by using permissions with a filter of type By user field. For example, you can create an entity called people with the following structure:
- user
- company
Then, in Application > Settings in the app builder, you have to configure this entity as the one used for extended fields (https://slingr-stack.github.io/platform/app_development_app_settings.html#user-extended-fields). Once you do that, you will be able to filter by the company of the current user. For example, let's suppose you have an entity called tasks with the following structure:
- number
- title
- company
- description
Then, in the permissions for this entity, you will add a filter by user field where the field tasks.company is equals to people.company. This way, users will only see tasks that belong to the company they also belong to.
I am working on system that will manage orders. Orders can be created via admin or via customer. Employee can take orders and change it's status.
My system should have three global types of users:
Admin - this type of users mostly uses WEB interface. Admins have different access levels, so some of them can only create orders, and others - edit core info about pricing and so on.
Customer - this type of users uses customer's mobile app. Main action is to add and cancel orders.
Employee - this type of users uses employee's mobile app. Employees can see open orders, assign themselves to orders and change order statuses.
Also, Customer and Employee can be authorised with phone number, that can be changed at some time (independently of each other). Admins can be authorised with uname + pword.
Current solution has one table for Admins, one for Customers and one for Employees.
So first part of question is how to structure database properly?
The second part is about authorising in REST api. In current solution I have three endpoints, that are authireses usertype independently.
admins/auth
customers/auth
employees/auth
And my thoughts is to keep three tables as is, because each usertype is slightly different concept and really independent. And keep authorisation as is, but add something like roles and privileges to auth token to restrict access for some resources.
I recently started developing for Odoo and have created a few modules, but I'm having difficulty figuring out the structure for accounts, customers, and partners.
I'm trying to adapt one of our current applications in which it's Accounts>Customers> and Accounts>Billing accounts. I basically what to add a tab to the customer creation view called billing accounts. Problem is I can't figure out what is tied to what. It looks like it's Partners>Accounts>Customers or Sales>Accounts>Customers.
Thanks
If you are talking about a bank account (i.e. your customer or partner's bank account), I believe the relation is res_partner_bank (many2one relation).
If you are talking about another concept, please clarify what you mean by billing account (invoicing, pur accounting, etc...) in order to understand the context.
As a sidenote, every entity (person/company) is stored in res_partner. You then have a boolean flag specifying whether the entity is a customer and/or a partner
and/or a company (so in short partner_id is usually the relationship key).
New user so I can't post images. Image link provided below:
http://i.stack.imgur.com/EXf0G.jpg
This is for a walk-in booking system not an online reservation system.
Normal Booking scenario:
User/Member gives information to receptionist. Users can book up to a month in-advance.
Receptionist searches user/member info. Receptionist must be logged in to search user/member or make a booking.
if details are found the booking continues as normal, if not user details are added to the users file.
Booking time/date/type is then checked for availability. If available then a booking is made.
Extra:
There are two types of staff account 'normal-user' (Receptionist) and 'admin' (Manager).
Manager can reset staff account passwords and create new staff accounts.
Manager can edit session details on the timetable (time, date, type) etc. Do i need a timetable class here??
In order to answer that, we would need a much more developed specification.
I would suggest you develop with what you have, meeting only the minimum requirements for each iteration. Then, if you find your users need a timetable of some sort, then add it at that point.
In general, don't add more complexity than you need until you know you need it. The more moving parts a system has, the harder it is to maintain and use and to put together in the first place. Get the application up and functioning and in the users' hands. Until you get real feedback from them, you are just taking stabs in the dark. Let the users' tell you what they need and want.
I am trying to run a workflow on the creation of a 1:n relationship.
I have a Contact entity, and PortalRole entity. When I associate the PortalRole with the contact I would like to trigger a workflow which sends out welcome emails to the users.
The PortalRoles are assigned to the contacts from a ribbon button which launches a HTML web resource and uses JSON / JQuery and the REST services to create the associations.
How can I call the workflow? I need to grab the Contacts email address and send them 1 of 2 emails depending on how many associations they have (new portal user or portal user gaining extra roles)
You should build your workflow for the PortalRole entity and trigger it from Create. You'll still be able to access Contact fields in the workflow.
The trick is in your last requirement - send "Email A" for the first role association and then "Email B" for the each additional association.
You could add a Yes/No field to Contact called "First Role Assigned." Your workflow would look something like this:
If Contact:FirstRoleAssigned = Yes
Send "Email B"
Else
Send "Email A"
Set Contact:FirstRoleAssigned = Yes
This blog post provides a very good explanation of dealing with relationships.
(So Many) Many-to-Many Options: Which to Use?
So…of these three approaches, which is best? As always, it depends on
what you need to do, but here are some rules of thumb you can use as
guidance:
Native N:N
Probably the easiest to configure but the most limiting. Use when you
only need to know that two records are connected to each other but you
don’t need additional information about the connection itself.
Examples:
Custom entity Industry with an N:N to Account Add a custom N:N
relationship between the Competitor and Territory entities to track
which competitors are active in which territories Custom entity Color
with an N:N to Contact (you don’t track your contacts’ favorite
colors???)
Manual N:N
A little more work to configure, but generally worth the effort. Use
when in addition to knowing two records are connected, you also need
information about the connection, such as its status, when it was
created and so forth.
Examples:
Associations and Members Events and Registrations (1:N from Contact
to Registration, 1:N from Event to Registration) Subscribers and
Subscriptions (1:N from Contact to custom entity “Subscription”, 1:N
from custom entity “Subscription Product” to Subscription)
Connections and Connection Roles
As I mentioned above, these are actually a specific implementation of
the Manual approach. And if you delve into this a little, you’ll find
that the Connection entity is a bona-fide customizable entity. You can
even customize it, adding custom fields to the connection form and so
forth. But…be careful about overdoing it: there’s only one Connection
entity, and customizations made for one Connection Role generally will
not be applicable to another one.
One specific advantage of these is that a single connection role can
connect records of different types (e.g., contacts can refer other
contacts, accounts and opportunities)
This is a judgment call, but I’d say to use these when you need to
track some information about the actual connections (such as when
they’re created and how many there are…), but not that much. Examples:
Referrals (Contact to Contact, Contact to Account, Contact to
Opportunity) Former Employee (Contact to Account, Lead to Account)
Board of Directors (Contact to custom entity “Board”, Lead to Board)
http://community.dynamics.com/product/crm/crmtechnical/b/richardknudson/archive/2011/05/08/many-to-many-relationships-in-dynamics-crm-2011.aspx