Una de las opciones para realizar integraciones con MSDyn365FO es usar las data entities con servicios REST a través de OData. Para poder usar las entidades con servicios REST solo tenemos que comprobar que tengan la propiedad IsPublic a Yes:
Si no la tienen, y es una entity estándar, tocará duplicarla porque no es posible editar la propiedad en una extensión.
Si realizamos una integración con un sistema externo a través de OData para insertar datos en el ERP, nos podemos encontrar con el problema que al generar el registro sea obligatorio el ID de ese registro, como ocurre con los clientes. Si vemos la propiedad Mandatory del campo CustomerAccount está en Auto, con lo que hereda el valor de la propiedad en la tabla CustTable donde esta a Yes.
En este caso si intentamos crear un cliente sin número de cuenta el servicio va a fallar como podemos ver en esta captura de pantalla de Postman:
El error es claro, la cuenta de cliente no puede estar vacía.
Esto no sucede así con la entidad de proveedores. «Pero si la cuenta de proveedor también es obligatoria en la VendTable!» dirá alguno. Sí, lo es, pero en la entidad no lo es:
Para ver cómo lo soluciona el estándar vamos a ver el initValue de la entidad de proveedores:
Tiene truco!
El método skipNumberSequenceCheck es uno de los métodos de datos de la clase Common, y es de la familia de los skipDataMethods, skipDataSourceValidateWrite, skipAosValidation, etc… El método siempre nos devolverá un false a no ser que le digamos antes lo contrario, pasándole el parámetro true en las llamadas en el código.
El método enableNumberSequenceControlForField de la clase NumberSeqRecordFieldHandler lo que hace es inicializar el valor del campo que le pasamos por parámetro con el next de la secuencia numérica que le digamos. En este caso rellena la cuenta de proveedor con la secuencia que este configurada en los parámetros de proveedores para la cuenta de proveedor (lógico).
Reproduciendo el estándar, vamos a crear una clase de extensión para la data entity y extenderemos el método initValue:
Con esto podemos volver a probar a generar un nuevo cliente en Postman, borrando el parámetro de cuenta de cliente del cuerpo del mensaje, y…
Premio! Tenemos un nuevo cliente! Creado desde un sistema externo, usando la secuencia numérica del ERP.
Esto no tiene ningún misterio, sobretodo porque reproduce el comportamiento de las partes del estándar que ya lo hacen. Algo que deberíamos intentar hacer siempre, seguir el estándar. Siempre que podamos claro :), porque aunque se intente que los clientes se adapten al estándar lo máximo posible, todos sabemos que siempre, siempre, siempre habrá que hacer alguna customización (menos mal, que somos devs).
