New element for E08 PAYMENT for making a deposit

[c-yak]

Currently, the payment entity do not seem to have a way to indicate making a deposit of funds.

Would it be possible to add a new element, such as E08D12/Deposit with 'Y" indicating that the payment is to be created for making a deposit?

[franciscave]

I seem to recall that we discussed this idea before but dropped it. I drafted something on adding a Payment Purpose code to entity E08 that would have enabled the purpose of a payment to be specified, and making a deposit on account was certainly one of the options we considered. I cannot remember whether we rejected this for some reason, or decided to defer implementation. I hope one of my fellow editors can recall what we decided.

[franciscave]

I've checked back on old issues and found #57, as a result of which we decided that a payment "on account" can be made without reference to any existing charge. I seem to recall that not all LMS systems will allow patrons to build up credit on their account, but this is the current solution for those that do allow this. A payment without a charge reference, if accepted, is a deposit. @c-yak, do you see any reason why this would not meet your need?

[franciscave]

At the Technical Panel meeting on 25 August it was agreed that making a payment without a charge reference is indeed allowed and clearly a deposit, so no new element is required.

[c-yak]

I've checked back on old issues and found #57, as a result of which we decided that a payment "on account" can be made without reference to any existing charge. I seem to recall that not all LMS systems will allow patrons to build up credit on their account, but this is the current solution for those that do allow this. A payment without a charge reference, if accepted, is a deposit. @c-yak, do you see any reason why this would not meet your need?

For us, not sending a charge ref just means pay any available charges. So specifying that it's a deposit is important.

[franciscave]

We discussed this at the Technical Panel meeting on 23 September. We agreed that there should be a way of distinguishing between a payment intended to be a deposit against future charges of a specified type (e.g. printing or computer access) and a payment that the library would use to pay off existing charges on the patron's account.

It was suggested that a deposit fund could be viewed as a charge of a specified type, for which the charge amount is unspecified, and a payment that refers to such a charge would represent a payment into the deposit fund.

In order to implement this, we would need to make several changes to the Charge entity, to indicate that the charge represents a deposit fund (and is therefore a fictitious charge) and to allow the gross charge amount (E07D12) to be omitted (this is currently a mandatory element).

I think, on reflection, that it would be simpler to implement something closer to the submitter's original request, which would be to add a single new element to the Payment request indicating the deposit fund type, using the same code list as charge type (CHT).

Request

Id	Element	SIP2 ID	Card.	Format	Description
Q13D01	Request type		1	Code	LCF code list RQT
Q13D02	Patron reference	AA	1	String
Q13D03	Charge reference		0-n	String	Charge(s) against which to set this payment. Either one or more instances of this element or one instance of Q13D09 but not both may be included in the request. If both this element and Q13D09 are omitted, the LMS determines the charges against which to set the payment. Description modified in vx.x.0
Q13D09	Deposit type		0-1	Code	Deposit made against future charges of this type. LCF code list CHT Added in vx.x.0
Q13D04	Payment type		1	Code	LCF code list PYT
Q13D05	Payment type description		0-1	String	Further information on method of payment
Q13D06	Payment amount		1	Value	Currency value.
Q13D07	Payment currency		0-1	Code	ISO three-letter currency code, e.g. ‘GBP’
Q13D08	Transaction reference		0-1	String	The identifier of the successful payment transaction. Only included if the request type (Q13D01) is '02' (Confirmation request). Added in v1.0.1

The Payment entity (E07) would need to be similarly modified, to enable the LMS to record that the payment was being made as a deposit against future charges:

Description

An identified payment made by a patron to settle one or more charges, or to make a deposit against future charges of a specified type. (Modified in vx.x.0)

Properties

Id	Element	SIP2 ID	Card.	Format	Description
...	...	...	...	...	...
E08D05	Charge reference		0-n	String	One or more charges to which this payment relates. Either one or more instances of this element or one instance of E08D12 but not both may be included. If, when creating a Payment entity, both this element and E08D12 are omitted, the LMS determines the charge(s) or deposit fund against which to set the payment and modifies the record accordingly.. Description modified in vx.x.0
E08D15	Deposit type		0-1	Code	Payment made as a deposit against future charges of this type. LCF code list CHT Added in vx.x.0
...	...	...	...	...	...

[franciscave]

In preparing updated Data Framework documentation, I've come to the conclusion that my proposal needs to be modified in two small respects:

1. If Q13D09 Deposit type is included in the request, this should be interpreted as a request to make a deposit against both current and future charges of the given type, not solely future charges of that type. It doesn't make sense to me that a deposit be made against future charges of a given type when there are already charges of the same type on the patron's account.

2. If Q13D09 Deposit type is included in the request, it should be repeated in the response, as confirmation that the deposit has been accepted. This is already the case with the inclusion of Q13D03 Charge reference in the request, so I believe that the same rule should apply to Q13D09.

I've also noticed and fixed some element ID clashes resulting from several recent revisions of E08 Payment.

I've prepared updated documentation in pull request #275.