Guion para la creación de recibos y aplicación de recibos utilizando

API en APLICACIONES

Ar_recibo_api_pub.Crear_efectivo
Esta rutina se llama para crear recibos de caja por el pago recibido en forma de cheque o efectivo.
Esta rutina no llama a Oracle Payments directamente.
Esta rutina de API tiene 4 parámetros de salida y un total de 44 parámetros de entrada.

TIPO atributo_rec_type ES REGISTRO

TIPO global_attribute_rec_type ES REGISTRO

código_moneda_p ………fnd_currencies
tipo_de_tasa_de_cambio ……………gl_diarios_tipos_de_conversión
p_id_cliente ……………….El cliente existe y tiene el código de prospecto ='CUSTOMER'
…….El cliente tiene un perfil definido a nivel de cliente
p_ubicación ………………..La ubicación de Facturación para el cliente
p_id_de_cuenta_bancaria_de_remesas……….cuenta bancaria del usuario para depositar el recibo
p_método_de_recibo_id …………………Identifica el método de recepción del recibo
p_valor_secuencia_doc ………………Valor asignado al recibo del documento.

Validando el ID del método de recibo

Debe ser un ID de método de recibo válido en la tabla AR_RECEIPT_METHOD.
La fecha de recepción debe estar entre la fecha de inicio del método de recepción y la fecha de finalización (si no es nula).

• El código del método de creación para la clase de recibo de este ID de método de recibo particular debería
ser 'AUTOMÁTICO,' la bandera de mandato ='Y,' y la bandera de confirmación = 'N' o 'MANUAL.'
• Al menos una cuenta bancaria de remesas asociada con este ID de método de recibo debe tener ya sea el múltiple-
la bandera de la moneda establecida en 'Y' o la misma moneda que la moneda del recibo. Además, esto debería tener un banco
tipo de cuenta = 'INTERNO' y su fecha de inactividad (si se especifica) mayor que la fecha de recibo.

Validando el ID de cuenta bancaria de remesas

• Ser una identificación válida de cuenta bancaria de remesas para el método de recibo actual.

• Tener la bandera de multi-moneda configurada en 'Y' o la misma moneda que la moneda del recibo. Además, esto
debería tener un tipo de cuenta bancaria = 'INTERNA' y su fecha de inactividad (si se especifica) mayor que el
fecha_de_recibo

Validando para recibo duplicado

Si la combinación de la fecha de recepción, el número de recepción y el monto en este recibo coincide con cualquier existente
recibos que no han sido revertidos, entonces el mensaje de error AR_RW_CASH_DUPLICATE_RECEIPT es
aumentado.
Ar_recibo_api_pub.Crear_efectivo(
1.0
FND_API.G_TRUE
aj_test_api_1
p_amount => 1000,
p_receipt_method_id => 1001,
Servicio y Alquiler de Computadoras
l_cr_id
l_return_status
l_msg_count
l_msg_data
Ar_recibo_api_pub.Aplica
Llama a esta rutina para aplicar los recibos de efectivo de un cliente (recibo de efectivo identificado) a un ítem de débito.
Esta rutina de API tiene 3 parámetros de salida y 34 parámetros de entrada

p_cr_id ……….El cash_receipt_id del recibo que necesita aplicarse a un ítem de débito dado
p_customer_trx_id ………..
número_de_transacción …. El trx_number del ítem de débito al que se aplicará el recibo

Validación p_cr_id
El tipo debe ser 'EFECTIVO'
El estado no debe ser Revertido o Aprobado
El recibo no debe ser desconocido

ID de Transacción del Cliente

• Si la bandera Mostrar Facturas Cerradas está establecida en 'Y', entonces la transacción actual + el pago a plazos pueden tener un
el estado del cronograma de pagos debe ser Cerrado ('CL'). De lo contrario, el estado del cronograma de pagos debe ser Abierto ('OP').
• Si la opción del sistema Permitir Pago de Transacciones No Relacionadas = 'Y', entonces la transacción actual puede ser
para un cliente que no esté relacionado con el cliente en el recibo. De lo contrario, la transacción debe ser para
el mismo cliente o uno relacionado en el recibo.
La transacción debe ser una Factura, Memo de Crédito, Memo de Débito, Depósito o Devolución de Cargos.
Nota:Esta transacción puede ser en una moneda que sea diferente de la moneda del recibo.

Monto Solicitado
• La cantidad solicitada no puede ser nula
• La cantidad aplicada no debe ser mayor que la cantidad de línea para la ID de customer_trx_line dada (si
especificado).
• Dependiendo del signo de creación, la bandera de aplicación natural, la bandera de sobreejecución y la cantidad
el saldo restante de la cuota de transacción especificada, se valida el monto aplicado para verificar
sobreaplicación y aplicación natural.
• Para una aplicación de moneda cruzada, la siguiente ecuación siempre debe ser válida:
monto aplicado * tasa de transferencia a recibo = monto aplicado de

Cantidad aplicada de
• Durante una aplicación de recepción de moneda cruzada, el monto aplicado desde no puede ser nulo.
La cantidad aplicada no puede ser mayor que la cantidad no aplicada disponible en el recibo.
• Si la moneda de la transacción y la moneda del recibo son la misma, entonces el monto aplicado debe
siempre ser nulo.
• Como se mencionó anteriormente para una aplicación de divisas cruzadas, la siguiente ecuación debe ser siempre válida:
monto aplicado * tasa de transferencia a recibo = monto aplicado de

Tasa de Recepción de Trans

• Para una aplicación de divisas cruzadas, la tasa de transacción a recepción debe tener un valor positivo.
• Si la moneda de la transacción y la moneda del recibo son las mismas, entonces la tasa no debería tener ninguna
valor especificado.
• Para una aplicación de moneda cruzada, la siguiente ecuación siempre debe ser válida:
monto aplicado * tasa de transacción a recibo = monto aplicado desde

Descuento
• Si el monto original adeudado en la transacción (elemento de débito) es negativo, entonces el descuento = 0 o nulo.
• Si el monto aplicado > 0, entonces el descuento no puede ser negativo.
• Si la bandera de descuento parcial = 'N' y la transacción no ha sido completamente pagada con el recibo
aplicación, entonces el descuento = 0 o nulo.
El descuento no debe ser mayor que el descuento máximo permitido en la transacción, que es
calculado internamente en la API por la rutina de descuentos.

Número de referencia de la aplicación

Si p_application_ref_type es 'CLAIM', entonces el número de referencia de la aplicación puede ser poblado con un
número de deducción válido de la Gestión Comercial. Esta deducción/sobrepago debe estar en el mismo
moneda como el ítem de débito al que se está aplicando.

ID de referencia de la solicitud secundaria

Si p_application_ref_type es 'CLAIM', entonces el ID de referencia de la aplicación secundaria puede ser poblado con
un ID de reclamación válido de Gestión de Comercio. Esta deducción/sobrepago debe estar en la misma moneda que
el ítem de débito al que se está aplicando. Si tanto el número de referencia de la aplicación como la aplicación secundaria
si el ID de referencia se deja nulo y p_application_ref_type es 'RECLAMO', entonces se creará un nuevo reclamo en
Gestión de Comercio.

Ejemplo:
1.0

Programa para crear y aplicar un recibo de caja utilizando API

CREAR O REEMPLAZAR PROCEDIMIENTO APPS.XX_CREATE_CASH_RECEIPT_APPLY(errbuf out

NOCOPY varchar2,
retcode out NOCOPY
varchar2)
ES
VARCHAR2(240);
L_CANT_MENSAJES NÚMERO;
L_MSG_DATA VARCHAR2(240);
ID_DE_RECIBO_DE_EFECTIVO NÚMERO
VARCHAR2(240);
nombre_cliente VARCHAR(240);
v_cantidad NÚMERO
v_recibo_numero NÚMERO;

CURSOR C1
ES
SELECCIONAR * DE XX_AR_RECIBOS_GMC;

COMENZAR

INICIAR
MO_GLOBAL.SET_POLICY_CONTEXT('S',150);
FIN;

PARA I EN C1 BUCLE

INICIO
 I.nombre_cliente; --
substr(I.NOMBRE_DEL_CLIENTE,1,length(I.NOMBRE_DEL_CLIENTE)-1);

SELECCIONAR DISTINTO ARC.NUMERO_DE_CLIENTE

DENTRO número_de_cliente
DE CLIENTES_AR ARC
HZ_CUST_ACCOUNTS_ALL HCA
HZ_CUST_ACCT_SITES_ALL HCAS
DONDE HCA.CUST_ACCOUNT_ID = HCAS.CUST_ACCOUNT_ID
Y HCA.CUST_ACCOUNT_ID = ARC.CUSTOMER_ID
Y HCAS.ORG_ID = 150
Y LTRIM(RTRIM(UPPER(ARC.NOMBRE_DEL_CLIENTE))) =
LTRIM(RTRIM(UPPER(v_cust_name)));

DBMS_OUTPUT.PUT_LINE ('Id de cliente -

||v_customer_number);

EXCEPCIÓN
CUANDO NO_SE_ENCONTRÓ_DATO ENTONCES
DBMS_OUTPUT.PUT_LINE(I.CUSTOMER_NAME||' Cliente
Error: '||SUBSTR(SQLERRM,1,150));
FIN;

v_amount:= to_number(substr([Link],1,length([Link])-
1));
--v_amount := to_number([Link]);
v_receipt_number := to_number(I.RECEIPT_NUMBER);

AR_RECIBO_API_PUB.crear_efectivo
( p_api_version 1.0
p_init_msg_list => FND_API.G_TRUE,
p_commit => FND_API.G_TRUE,
p_validation_level
FND_API.G_NIVEL_VALIDO_COMPLETO
x_estado_de_devuelto=> l_return_status,
x_cantidad_mensajes => l_msg_count,
datos_msg_x => l_msg_data,
código_moneda_p AED
monto_p v_cantidad
número_de_recibo número_de_recibo
fecha_de_recibo => sysdate,
p_gl_fecha => to_date('31-dic-2008'),
v_customer_number
p_org_id => 150,
2007
p_cr_id => l_cash_receipt_id);

/*
AR_RECEIPT_API_PUB.crear_y_aplicar
(p_api_version => 1.0,
p_init_mensaje_lista => FND_API.G_TRUE,
p_comprometer => FND_API.G_TRUE,
p_validation_level
FND_API.G_NIVEL_VALIDO_COMPLETO
l_return_status
 conteo_mensajes_x => l_msg_count,
x_msg_data => l_msg_data,
p_cantidad v_amount
número_de_recibo número_de_recibo
p_fecha_de_recibo => fecha del sistema,
p_gl_fecha => to_date('31-dic-
2008'),
número_de_cliente v_número_de_cliente
p_ubicación Abu Dabi
2007
número_de_trx 500001
p_cr_id l_id_recibo_efectivo
);
*/

FIN DEL BUCLE;

DBMS_OUTPUT.PUT_LINE('Recibo de Efectivo Creado y Aplicado'||'-

'||l_cash_receipt_id||'- Comentarios : '||l_msg_data||l_return_status);

COMPROMETER;

EXCEPCIÓN
CUANDO OTROS ENTONCES

DBMS_OUTPUT.PUT_LINE(SUBSTR(SQLERRM,1,150)||'-'||l_msg_data);

FIN;