Árbol del API · Facturas y cobranza › createCollection
Registrar un cobro
createCollection
Tipo
Mutation
Devuelve
Permiso de la llave
Crear Cobros
Reintentos
Seguros con idempotencyKey
Registra un pago recibido de un cliente y, si lo indicas, lo aplica a sus facturas en la misma operación. No emite ni timbra el complemento de pago.
El cobro se registra a nombre del usuario de input.userId, en la moneda de
la cuenta bancaria (bankAccountId). Sin aplicaciones queda REGISTERED;
con ellas queda APPLIED si se aplicó todo su importe o
PARTIALLY_APPLIED si no, y cada factura baja su saldo (balance) en ese
momento. Lo que no apliques se puede aplicar después en AdvantaCloud; con
Llave API un cobro no se modifica ni se cancela.
Revisa siempre createCollection.errors y también errors de la
respuesta: un error puede llegar en cualquiera de los dos y, con errores,
collection llega null. Es todo o nada: si una aplicación falla, no se
guardan el cobro, sus aplicaciones ni la clave.
Aplicaciones a facturas
Cada aplicación lleva el id de la factura y el importe en la moneda del
cobro. Para que se acepte:
- la factura es del cliente del cobro y está timbrada (
INVOICED), con sus datos fiscales completos; - es de la misma unidad de negocio del cobro (la del almacén o
xcumId), salvo que la empresa permita repartir cobros entre unidades de negocio; - el importe, convertido a la moneda de la factura, no pasa de su saldo (en una factura de venta mostrador, tampoco del saldo de su orden), y las aplicaciones juntas no pasan del importe del cobro;
- cada factura aparece una sola vez.
Las facturas con saldo de un cliente están en
invoicesConnection
con customerId y onlyPending: true.
Moneda y tipo de cambio
La moneda del cobro es la de la cuenta bancaria. El tipo de cambio va en
pesos por unidad de la moneda extranjera; si no envías exchangeRate, se
usa el vigente en AdvantaCloud para esa moneda, y si no hay uno vigente la
petición responde HTTP 422.
- Misma moneda que la factura: se aplica el mismo importe.
- Cobro en otra moneda a una factura en la moneda base de la empresa
(p. ej.
USDaMXN): AdvantaCloud convierte el importe con el tipo de cambio del cobro. - Cobro en pesos a una factura en dólares: sólo si envías
exchangeRate, distinto de 1. - Cualquier otra combinación responde
CONFLICT.
Cobros con tarjeta
Si la forma de cobro tiene card: true, envía en terminalId una terminal
activa de
bankTerminals(warehouseId:, bankAccountId:),
con el almacén y la cuenta del cobro; esa consulta pide además «Ventas» en
la llave. Si la terminal tiene cuenta bancaria o empresa, deben ser las del
cobro (la empresa del cobro es la de su unidad de negocio: la del almacén o
la de xcumId). Su error llega con field: "xvtb". Con otra forma de cobro,
terminalId se ignora.
Catálogos
Los identificadores del input salen de estas consultas:
- formas de cobro, con su marca
card:paymentMethodOptions; - almacenes:
warehouseOptions; - unidades de negocio, cobradores y tipos de cobro:
businessUnitOptions,collectorOptionsycollectionTypeOptions; - terminales de un cobro con tarjeta:
bankTerminals. Una terminal con cuenta trae también su cuenta bancaria y su banco (bankAccount.idybank.id).
Los bancos y las cuentas bancarias de la empresa no tienen una consulta publicada. Pide al administrador de AdvantaCloud los identificadores de la cuenta donde la empresa recibe los pagos y de su banco, y guárdalos en la configuración de tu integración.
Complemento de pago
Registrar el cobro no emite ni timbra el complemento de pago (REP): la
empresa lo genera y lo timbra en AdvantaCloud. Consulta si el cobro ya está
en uno, su estado y sus descargas con
paymentComplement(collectionId:).
Reintentos seguros
Si la conexión se corta y no sabes si el cobro se registró, repite la
petición con la misma idempotencyKey y los mismos datos: recibes el
cobro que ya se registró, sin duplicarlo. La respuesta muestra el cobro como
está en ese momento, no una copia de la primera respuesta. La clave se
recuerda alrededor de 30 días. Una clave repetida con datos distintos, o
desde otra llave, responde CONFLICT.
Si el registro falla, no se guardan el cobro ni la clave: corrige el dato y
reenvía con la misma. Un error al leer la respuesta, como un first
negativo en applications, llega cuando el cobro ya se guardó; ante
cualquier duda, reintenta con la misma clave y los mismos datos.
createCollection( input: CollectionInput! idempotencyKey: String! ): CreateCollectionPayload
Argumentos
2
| Argumento | Tipo | Descripción |
|---|---|---|
| Cobro | ||
inputCollectionInput! |
CollectionInput! | Los datos del cobro y sus aplicaciones a facturas (hasta 100). Ver |
| Reintentos | ||
idempotencyKeyString! |
String! | Clave única que generas por cada cobro, de hasta 200 caracteres, por ejemplo un UUID o la referencia del pago en tu sistema. Si repites la petición con la misma clave y los mismos datos, recibes el cobro que ya se registró en lugar de uno nuevo. Obligatorio. |
Lo que devuelve
CreateCollectionPayload
Campos principales de CreateCollectionPayload:
| Campo | Tipo | Descripción |
|---|---|---|
collectionCollection |
Collection | El cobro registrado, con sus aplicaciones; null si hubo errores. |
errors[FieldError!]! |
[FieldError!]! | Errores que impidieron registrar el cobro; vacía si se registró. |
Permisos
Llave API Integraciones
La llave ve los registros de toda la empresa del subdominio.
Sin el permiso HTTP 422
La respuesta es HTTP 422 con el cuerpo {"error": "invalid_graphql_request"}, sin data.
Errores
| Código | Cuándo ocurre | Qué hacer |
|---|---|---|
| HTTP 401 | Falta el header Authorization o la llave no existe en la empresa del subdominio. La respuesta no trae cuerpo. | Revisa la llave y el subdominio. No reintentes. |
| HTTP 422 | La llave no tiene «Crear Cobros». La respuesta es HTTP 422 con el cuerpo {"error": "invalid_graphql_request"}, sin data. | La llave necesita ese permiso; reintentar no ayuda. |
NOT_FOUND | Un identificador del input no existe. Llega en createCollection.errors con el dato en field: customerId, warehouseId, bankId, bankAccountId (también si la cuenta es de otro banco), paymentMethodId, xcumId, cobdorId, o applications.0.invoiceId para una factura que no existe, es de otro cliente o no tiene cuenta por cobrar (las aplicaciones se cuentan desde 0). | Corrige el identificador y vuelve a enviar; puedes usar la misma clave. |
VALIDATION | Un dato no es válido. En errors de la respuesta: falta userId o el usuario no está activo, amount no es mayor que cero, hay más de 100 aplicaciones, una aplicación tiene importe cero o negativo o repite factura, exchangeRate no es mayor que cero o tpcbro no es Cobro ni Anticipo. En createCollection.errors: la terminal de un cobro con tarjeta falta, está inactiva o no es de la cuenta (field: "xvtb"), una aplicación pasa del saldo de su factura o las aplicaciones suman más que el cobro (field: "base"), o la idempotencyKey está vacía o pasa de 200 caracteres. | Corrige el dato y vuelve a enviar; puedes usar la misma clave. |
CONFLICT | En createCollection.errors, con field: "base": una factura no está timbrada (INVOICED) o le faltan datos fiscales, es de otra unidad de negocio, su moneda no se puede combinar con la del cobro, o estaba bloqueada por otra operación. En errors de la respuesta: la idempotencyKey ya se usó con otros datos o con otra llave. | Si es un bloqueo, reintenta con espera y la misma clave. Si no, corrige la aplicación, o usa otra clave para otros datos. |
| HTTP 422 | Falla interna o dato rechazado al guardar. El cuerpo es {"error": …}, sin data. | Si no cambiaste nada, reintenta con la misma idempotencyKey. |
Los errores de la consulta llegan con HTTP 200 en errors, con su código en extensions.code. Revisa siempre errors, no sólo el estatus HTTP. Errores y reintentos.