SDK configuracin para CUITs delegados

RunLLM
RunLLM

Debes inicializar el SDK siempre con el CUIT de tu plataforma (el del certificado), no con el CUIT del cliente representado. El CUIT del cliente debe enviarse solo como parámetro en los métodos que lo requieran (por ejemplo, en el campo cuitRepresentada o similar en los datos de la request), pero nunca en el constructor del SDK. Así, el sistema cuenta solo el CUIT de tu plataforma para el límite del plan, aunque operes en nombre de otros CUITs delegados. Según la documentación y respuestas oficiales, si pones el CUIT del cliente en el constructor, el SDK lo toma como un CUIT adicional y suma al límite del plan, lo cual no es lo que buscas.

No existe un parámetro especial en el constructor para indicar el CUIT representado; siempre debe ir en los datos de cada request. Por ejemplo, para métodos como getSalesPoints, debes pasar el CUIT del cliente en el cuerpo de la solicitud, pero la instancia del SDK debe estar creada con el CUIT de tu plataforma. Así evitas el error de límite de CUITs y cumples con el modelo de "App de terceros" del plan PRO o superior. Más detalles en las respuestas de la comunidad y la documentación oficial del SDK sobre delegación y uso de certificados únicos para SaaS (fuente, fuente).

¿Te gustaría ver un ejemplo de código concreto para este escenario?

Sources:

Carla Palmieri
Carla Palmieri

<@&1333894833621827677> Entiendo, pero hay muchos métodos, diria que la mayoria en facturacion electronica que no tienen cuitRepresentada como getSalesPoints, createVoucher, etc. Como se supone que aclare a quien represento en dichas request si no existe un parametro que pueda pasar en cada metodo?

RunLLM
RunLLM

Mi entendimiento es que, en el SDK actual, no existe un parámetro explícito como cuitRepresentada en métodos como getSalesPoints o createVoucher. El CUIT que se utiliza para operar es el que se define al instanciar el SDK, por lo que si necesitas facturar en nombre de un cliente, debes inicializar el SDK con el CUIT de ese cliente, lo que lamentablemente suma al límite de CUITs del plan, según la lógica del SDK y la documentación disponible (fuente).

No hay forma documentada de indicar el CUIT representado en cada request para esos métodos; el SDK asume que el CUIT de la instancia es el operante. Por lo tanto, en el modelo actual, no es posible operar en nombre de múltiples clientes con un solo CUIT de plataforma sin que cuenten para el límite, salvo que el SDK implemente soporte específico para representación en el futuro (fuente).

¿Te gustaría que te muestre alternativas o posibles workarounds?

Sources:

Carla Palmieri
Carla Palmieri

@user esto es correcto?

RunLLM
RunLLM

Sí, es correcto. Si el método del SDK no permite especificar el CUIT representado como parámetro, el CUIT que uses al instanciar el SDK será el que cuenta para el límite del plan y el que opera ante AFIP. No hay forma de aclarar a quién representas en esos métodos si el SDK no lo soporta explícitamente (fuente).

¿Te gustaría que te explique cómo manejar este escenario o ver posibles alternativas?

Sources:

Ivan
Ivan

Hola Carla, por cada CUIT de cliente que uses en la plataforma se cuenta como uno, no es que porque tus clientes te deleguen el servicio solo cuenta como un CUIT (el tuyo)