Paso 4: Enmiendas y ficheros bancarios

Concepto

El objetivo consiste en generar un fichero bancario SDD con las enmiendas.

En cada cobro, el acreedor debe enviar todos los datos relevantes del mandato en los elementos del mensaje XML "pain.008".

Remesas electrónicas (FICMAG)

Abrir: Contabilidad terceros > Remesas > Remesas electrónicas

Remesas electrónicas

Utiliza esta función para emitir los ficheros electrónicos de remesa para documentos ya creados.

Estructura del fichero bancario XML SDD

Estructura del mensaje

El mensaje "Customer Direct Debit Initiation" presenta información estructurada y agrupada en bloques. Los principales bloques de este mensaje se definen según el esquema "pain.008.001.02", que se utiliza tanto para CORE/COR1 como para B2B.

	Elemento de mensaje	Significado
A	GroupHeader
	MessageIdentification	Identificador del mensaje
	CreationDateTime	Fecha y hora reales de la creación
	NumberOfTransactions	Número de transacciones para DirectDebitTransactionInformation
	ControlSum	Suma de todos los elementos de InstructedAmount
	InitiatingParty	Parte que inicia el pago
B	PaymentInformation	Información del beneficiario
	PaymentInformationIdentification	Identificador del documento de remesa
	PaymentMethod	"DD"
	BatchBooking	True/False
	CodeScheme	"SEPA"
	CodeInstrument	"CORE" o "COR1" o "B2B"
	SequenceType	"FRST" o "RCUR" o "FNAL" o "OOFF"
	RequestedCollectionDate	Vencimiento de la remesa
	Creditor	Nombre del titular de la cuenta del acreedor
	CreditorAccount	Número de la cuenta del acreedor (IBAN)
	Currency	Divisa de la cuenta del acreedor
	CreditorAgent	Banco del acreedor (BIC)
	UltimateCreditor	Nombre del acreedor final
	ChargeBearer	"SLEV"
	CreditorSchemeIdentification	Identificador del acreedor SEPA (CI)
C	DirectDebitTransactionInf.	Detalles del pago
	PaymentIdentification	Identificador del pago
	EndtoEndIdentification	Referencia del pago
	Amount	Importe del pago
	MandatIdentification	Referencia única del mandato (RUM)
	DateOfSignature	Fecha de la firma del mandato
	AmendmentIndicator	True/False
	OriginalMandateID	Utilizado si AmendmentIndicator = True
	OriginalCreditorName	Utilizado si AmendmentIndicator = True
	OriginalCreditorID	Utilizado si AmendmentIndicator = True
	OriginalDebtorAccount	Utilizado si AmendmentIndicator = True
	OriginalDebtorAgent	Utilizado si AmendmentIndicator = True
	DebtorAgent	Banco del deudor (BIC)
	Debtor	Nombre del titular de la cuenta del deudor
	DebtorAccount	Número de la cuenta del deudor (IBAN)
	UltimateDebtor	Nombre del deudor final
	Objective	Objetivo del cobro
	RemittanceInformation	Información de la remesa del acreedor

Procesamiento

Los datos del mandato de origen también se deben incluir en el mensaje y deben corresponder a los detalles del cobro anterior.

Si estos datos faltan, las operaciones del acreedor podrían ser rechazadas.

Si se realiza alguna enmienda, el sistema debe presentar la orden de domiciliación SEPA de la siguiente manera:

Si se modifica, al menos, un campo editable:

• El campo AmendmentIndicator (<AmdmntInd>) muestra el valor True.

• Los datos de origen y los modificados se proporcionan con la orden:

  • OriginalMandateIdentification <OrgnlMndtId>

  • OriginalCreditorSchemeIdentification <OrgnlCdtrSchmeId>

  • OriginalDebtorAccount <OrgnlDbtrAcct>

  • OriginalDebtorAgent <OrgnlDbtrAgt>

Si se modifica el banco del deudor (si el IBAN y el BIC son diferentes):

• El campo OriginalDebtorAgent muestra el código SMNDA (mismo mandato, nuevo banco del deudor).

• El campo Tipo secuencia muestra el valor FRST.

• El IBAN de origen del deudor no se debe proporcionar.

Los datos de origen y los modificados se cargan a partir de los campos OLDVAL y NEWVAL del histórico de enmiendas (HISTOAMD).

Si no hay ninguna enmienda vinculada al pago, no se proporcionan los datos de origen. Los demás datos se recuperan de la tabla de la sociedad y de la del pago.

Excepción

Si, después de crear el pago, se cambia el nombre de la sociedad o del identificador del acreedor, el fichero bancario presenta la información identificativa de la sociedad o del acreedor a partir del historial de enmiendas (campo OLDVAL) para garantizar la coherencia de los datos.

Limitaciones

Las enmiendas se deben gestionar con precaución.

Antes de comenzar con el proceso de cobro, hay que definir las reglas.

Mandatos validados o suspendidos

• Si una enmienda SMNDA se suprime, la secuencia de la entrada de pago correspondiente se mantiene en FRST. No se vuelve a la secuencia inicial.

  • En ese caso, la entrada de pago se debe suprimir y, posteriormente, volver a crear para obtener la secuencia correcta.

• Si ya hay una enmienda al IBAN y está vinculada a una entrada de pago, la modificación de los campos IBAN y BIC no implica que se muestre el código SMNDA ni que la secuencia se fuerce en el valor FRST.

  • En este caso, la entrada de pago se debe suprimir y volver a crear tras modificar los campos IBAN y BIC del mandato.

Mandatos caducados o revocados

Si el nombre de la sociedad (CPYNAM) o el identificador del acreedor (SCINUM) se modifica, y si no hay ninguna enmienda vinculada al mandato, el sistema no crea una enmienda nueva.

No obstante, el nombre del acreedor (<Nm>) y el identificador del acreedor (<Id>) muestran los últimos valores introducidos en la tabla de la sociedad.

En ese caso, el fichero bancario se debe generar antes de la modificación.