- Cómo habilitar la aplicación lógica para objetos comerciales personalizados
- Cómo implementar una base de datos de objetos comerciales cambiantes
- Cómo aplicar una verificación a un objeto comercial personalizado antes de guardarlo
- Cómo guardar o rechazar un objeto comercial personalizado
- Cómo implementar informar al usuario final sobre el ahorro
- Cómo facilitar el desarrollo y las pruebas ya en el proceso
Al final, su aplicación reparará automáticamente algunos datos y solo rechazará un mensaje de error debido a las inconsistencias que causa.
Nuestro Ejemplo
Un ejemplo diferente mostrará tutoriales que cubren la amplitud de las aplicaciones personalizadas de administración de bonificaciones.
En la primera parte, el gerente quiere definir las cosas comerciales Plan de bonificación para empleados. Hay un plan de bonificación para guardar las reglas específicas de los empleados sobre el derecho a bonificaciones.
Información extra
- Lanzamiento de SAP Cloud S / 4HANA (última actualización del tutorial): 1808
Paso 1: cree un campo clave de solo lectura
Porque no hubo una implementación de backend para corregir el campo principal obligatorio ID
Hasta ahora, hemos tenido que solucionarlo desde la interfaz de usuario para poder guardar casos. Ahora, a medida que aplicamos la lógica para configurar el ID en un fin de semana y en otros lugares, configuraremos ese campo principal en Solo lectura para la interfaz de usuario.
Abra el objeto comercial Plan de bonificación en la aplicación Objetivos comerciales personalizados
Inicie el modo de edición a través del Editar borrador acción.
Cambiar a Campos alt.
Controlar el cuadro Único legible para un campo clave
ID
.
Hecho
Inicie sesión para responder la pregunta
Paso 2: habilitar la aplicación lógica
Cambiar a Información general alt.
Controlar la caja para Determinación y validación
Publicación el objeto comercial.
Ahora está habilitado para aplicar Decisión llamado lógica después de cada modificación al ejemplo del plan de bonificación de la interfaz de usuario, así como Validación llamado lógica antes de cada salvamento por ejemplo.
Solo puede cambiar los detalles personalizados de los objetos comerciales en la lógica de la Decisión.
La lógica de validación implica verificar el objeto comercial, decidir si guardar y proporcionar información útil al usuario final, como un guardado exitoso o por qué se debe rechazar un guardado.
Hecho
Inicie sesión para responder la pregunta
Paso 3: comienza a aplicar la lógica
Para publicado Objetos comerciales personalizados sin borrador puedes aplicar la lógica.
- Cambiar a Lógica alt.
- Ingrese la lógica de eventos después de cambiar la lógica de decisión.
- Lógicamente, ve la versión publicada vacía que no se puede editar al principio.
Clickea en el Crear borrador acción.
Parece que se dejó a su izquierda una copia comestible de la versión publicada. Con el Versión preliminar y Versión publicada acciones puede determinar qué codificación es visible.
Hecho
Inicie sesión para responder la pregunta
Paso 4: Implementación después de la modificación: establecer valores
Aplicar después del evento de cambio con la siguiente funcionalidad de valor establecido:
Establecer el campo clave
ID
si todavía es inicial.Consejo: Cambiar parámetro
bonusplan
le permite leer y cambiar los datos del nodo actual.Consejo: Puede leer los detalles existentes sobre el Plan de bonificación a través de la Vista de CDS designada como Identificador de propósito comercial (aquí:
YY1_BONUSPLAN
).Consejo: Con la combinación de teclas CTRL + espacio Puedes acceder a la cumplimentación del código es muy útil.
* set ID IF bonusplan-id IS INITIAL. SELECT MAX( id ) FROM yy1_bonusplan INTO @DATA(current_max_id). bonusplan-id = current_max_id + 1. ENDIF.
Establezca la unidad de medida para los porcentajes de bonificación en
P1
que es el código para% (porcentaje)* set percentage unit bonusplan-lowbonuspercentage_u = bonusplan-highbonuspercentage_u = 'P1'.
Determinar y determinar el nombre del empleado a partir de la identidad del empleado
Consejo: Helper ofrece una clase expansiva
CL_ABAP_CONTEXT_INFO
por métodoGET_USER_FORMATTED_NAME
que requiere una identificación de usuario para restaurar su nombre formateado* set Employee Name IF bonusplan-employeeid IS NOT INITIAL. bonusplan-employeename = cl_abap_context_info=>get_user_formatted_name( bonusplan-employeeid ). ENDIF.
Hecho
Inicie sesión para responder la pregunta
Paso 5: implementación después de la modificación: verificación de coherencia
Dependiendo de las siguientes comprobaciones, configure el isconsistent
propiedad.
- Mira eso
ValidityStartDate
yValidityEndDate
set y esoValidityStartDate
antes en el tiempo queValidityEndDate
. - Verifique que los factores y porcentajes estén configurados correctamente (todos> 0, porcentajes <100,
LowBonusAssignmentFactor
<HighBonusAssignmentFactor
) - Verifique que la ID de empleado esté configurada
* consistency check START
IF bonusplan-validitystartdate IS INITIAL
OR bonusplan-validityenddate IS INITIAL
OR bonusplan-validitystartdate GE bonusplan-validityenddate
OR bonusplan-lowbonusassignmentfactor IS INITIAL
OR bonusplan-highbonusassignmentfactor IS INITIAL
OR bonusplan-lowbonuspercentage_v IS INITIAL
OR bonusplan-highbonuspercentage_v IS INITIAL
OR bonusplan-lowbonuspercentage_v GE 100
OR bonusplan-highbonuspercentage_v GE 100
OR bonusplan-lowbonusassignmentfactor GE bonusplan-highbonusassignmentfactor
OR bonusplan-employeeid IS INITIAL.
bonusplan-isconsistent = abap_false.
ELSE.
bonusplan-isconsistent = abap_true.
ENDIF.
* consistency check END
Hecho
Inicie sesión para responder la pregunta
Paso 6: prueba la lógica durante el desarrollo
Además de la codificación, puede mantener los datos de tiempo de ejecución para la estructura de nodo actual mostrando los datos antes de que se pase la funcionalidad de prueba. Estos datos se pueden guardar a cambio de usos posteriores.
Haga clic en la ayuda de valor para agregar datos de prueba
Ingrese los siguientes detalles
Nombre del campo Valor de campo validitystartdate
2017-01-01
validityenddate
2017-12-31
targetamount_v
1000
targetamount_c
EUR
lowbonusassignmentfactor
1
highbonusassignmentfactor
3
lowbonuspercentage_v
10
highbonuspercentage_v
20
employeeid
<any>
employeeid
<any>
será uno de los vendedores que ha creado pedidos de cliente con un Importe Neto de más de EUR 3000,00 en 2016 y se completará.Esto se verá de la siguiente manera.
Un Examen acción y puede ver los datos del nodo después de ejecutar su lógica.
Ves que tu lógica funciona como
id
,*percentage_u
campos yemployename
para llenar yisconsistent
es ‘X’.Publicación la lógica después de la modificación.
Hecho
Inicie sesión para responder la pregunta
Paso 7: Aplicar antes de ahorrar
Si está en la lógica de After Modification, puede acceder a Before Save Logic de esta manera:
- Regresar en la aplicación
- En la pestaña «Lógica», vaya a la sección «Decisión y validación»
Implementación Antes de guardar el evento con la siguiente funcionalidad
Si el plan de bonificación es consistente, los ahorros pueden continuar, si no se ahorran. Para guardar no se requiere ningún procesamiento adicional y la lógica puede omitirse.
Consejo: La configuración del parámetro de exportación válido debe ser verdadera para guardar y falsa solo para rechazo
* decide about save rejection IF bonusplan-isconsistent EQ abap_true. valid = abap_true. RETURN. ELSE. valid = abap_false. ENDIF.
Si el plan de bonificación no es consistente, escriba el primer error encontrado en el mensaje y detenga el procesamiento lógico.
Aquí están los posibles errores en detalle:ValidityStartDate
yValidityEndDate
Debe ser arregladoValidityStartDate
debe ser antes en el tiempo queValidityEndDate
- Los factores y porcentajes deben ser> 0
- Los porcentajes deben ser <100
- Debe ser LowBonusAssignFactor
- Se debe establecer la identificación del empleado
* consistency error message START IF bonusplan-validitystartdate IS INITIAL OR bonusplan-validityenddate IS INITIAL. message = 'Validity Period must not be empty.'. RETURN. ELSEIF bonusplan-validitystartdate GE bonusplan-validityenddate. CONCATENATE 'Validity End Date' bonusplan-validityenddate 'must be later than Validity Start Date' bonusplan-validitystartdate '!' INTO message SEPARATED BY space. RETURN. ENDIF. IF bonusplan-targetamount_v IS INITIAL. message = 'Target Amount must be over 0!'. RETURN. ENDIF. IF bonusplan-targetamount_c IS INITIAL. message = 'Target Amount Currency must be set!'. RETURN. ENDIF. IF bonusplan-lowbonusassignmentfactor IS INITIAL OR bonusplan-highbonusassignmentfactor IS INITIAL. message = 'Assignment Factors must be over 0!'. RETURN. ENDIF. IF bonusplan-lowbonuspercentage_v IS INITIAL OR bonusplan-highbonuspercentage_v IS INITIAL. message = 'Percentages must be over 0!'. RETURN. ENDIF. IF bonusplan-lowbonuspercentage_v GE 100 OR bonusplan-highbonuspercentage_v GE 100. message = 'Percentage must be below 100!'. RETURN. ENDIF. IF bonusplan-lowbonusassignmentfactor GE bonusplan-highbonusassignmentfactor. message = 'Low Bonus Factor must be smaller than High Bonus Factor!'. RETURN. ENDIF. IF bonusplan-employeeid IS INITIAL. message = 'Employee ID must be set!'. RETURN. ENDIF. * consistency error message END
Publicación la lógica antes de guardar
Hecho
Inicie sesión para responder la pregunta
Paso 8: prueba a través de la interfaz
Una vez que ambas implementaciones lógicas se hayan publicado correctamente, puede comenzar a probar la aplicación como un usuario final a través de la interfaz de usuario.
- Abierto la aplicación Bonus Plan
- Abierto el plan de bonificación con identificación
1
- Editar este plan de bonificación
- Ingresar valor
10
en el campo Porcentaje de bonificación bajo - Salvar el plan de bonificación. Verá que su lógica empresarial funciona cuando se llenan las Unidades de porcentaje y el Nombre del empleado, pero guarde los errores debido a los mensajes de error de validación del porcentaje que faltan.
- Ingresar valor
20
en el campo Bonificación de alto porcentaje - Salvar el plan de bonificación. Ahora no será rechazado.
Hecho
Inicie sesión para responder la pregunta