NeTEx
NeTEx copied to clipboard
NeTEx-CEN
Add support for CUSTOMER ACCOUNT LOG ENTRIES on a CUSTOMER ACCOUNT
Currently there is a LogEntry extension hierarchy like
LogEntry -> FareContractEntry -> SalesTransaction/TravelSpecification etc. This pertains to things that happen on a FARE CONTRACT.
In TM6 part 5 CUSTOMER ACCOUNT USE EVENTS (chapter 5.10.6.2) are described. These events and entries log activity on the CUSTOMER ACCOUNT itself such as registration, deregistration, profile modification etc.
This PR adds another "branch" CustomerAccountEntry extending LogEntry and the first 2 events mentioned under chapter 5.10.6.2.2.
LogEntry -> CustomerAccountEntry -> CustomerRegistration/CustomerDeregistration
More LogEntries will be added as separate PRs later if this PR is merged.
Excerpt from TM6 part 5 page 134:
CUSTOMER ACCOUNT ENTRies record actions by the TRANSPORT CUSTOMER (that is, CUSTOMER ACCOUNT EVENTs) to set up or modify the account of a customer. Note that an account may pre-exist and be used for other transactions than the purchase of travel.
- A CUSTOMER REGISTRATION ENTRY records the registering of a customer and the creating of an account.
- A CUSTOMER DEREGISTRATION ENTRY records the clearing of all personal details of a customer and the closing of an account.
Will create CR if required; per response to https://github.com/NeTEx-CEN/NeTEx/pull/136#issuecomment-741688535
looks ok, however you are mentioning TM5 as reference, is it a type ? TM6 has largely reviewed LogEntries (and we will go much deeper with them in NeTEx when OpRa work will start next year)
My mistake, in it is TM6, but part 5.
Location 978 on page 134.
Doc CEN/TC 278 1 Date: 2018-07 2 TC WI00278497 3 EN 12896-5:YYYY 4 Secretariat: NEN 5 6 Public transport - Reference data model - Part 5: Fare management
Ok no pb... that's something on which I would like to have @nick-knowles and Kasia's input... that definitely makes sense, it is just not yet in NeTEx... Also we are clearly entering in OpRa scope (NeTEx is expected to be about planed information)
looks ok, however you are mentioning TM5 as reference, is it a type ? TM6 has largely reviewed LogEntries (and we will go much deeper with them in NeTEx when OpRa work will start next year)
What is the status of the OpRA work @Aurige ?
@seime you mean this PR or OpRA ? For OpRA we hope to launch the Work Item for the exchange format this year (Data4PT is going to have a direct discussion with the Commission to make sure it is not going to be postponed again at CEN level). For the PR, I will mail Nick (as said before, I really would feel more comfortable having his review on this ... for me it look Ok).
In general it is true that we could usefully populate in NeTEx more of the hierachy of specific subtypes of LOG ENTRY from TM6, in particular where we need capture additional attributes that are specific to a specific type of log entry (Otherwise one could just use the generic FARE CONTRACT ENTRY with a TYPE OF LOG ENTRY to classify it. ) , To date we have assumed that because of the large volumes of transaction data people would some different, highly optimised forma to exchange such data, but that may be an out of date assumption. ALso we need input as to the specific attributes
The abstract CUSTOMER ACCOUNT ENTRY, and specific CUSTOMER REGISTRATION LOG ENTRY / DEREGISTRATION LOG ENTRY are ENtur's initial requirements/ examples (Both subtypes of the hierarchy LOG ENTRY/ FARE CONTRACT ENTRY/ CUSTOMER ACCOUNT ENTRY) , but it would probably be sensible to implement the whole gamut so as to get an uniform implementation. A CR with the [propose attributes would be a good idea.
As I understand it from their example , the ENtur example also proposes two additional CUSTOMER ACCOUNT LOG ENTRies log entries that are not in TRansmodel (?)
i) InsufficientAccessRightsOnAccount (i.e. an attempt to travel with some, but insufficient rights?
ii) NoAccessRightsOnAccount - ie an illegal attempt to travel without rights
However, I note that the TM Control and Validation model (which is concerned with monitoring access rights during travel) already defines a different subtype type of FARE CONTRACT ENTRY , a VALIDATION ENTRY, to explicitly record the validation of rights Y. Each individual parameter that has been checked can be recorded as a more detailed VALIDATION ELEMENT. Both succesful and failed validations can be recorded. AN OFFENCE can be used to record further details about an attempt to travel with insufficient rights
In general the CUSTOMER ACCOUNT ENTRY is intended for events relating to the creation and maintenance of the account itself, whereas VALIDATION ENTRies are intended to record travel events and the consumption of rights.
But.... Having said that, the control and validation model has not been implemented yet in NeTEX ,either . It would probably be better to implement it and use a VALIDATION ENTRY instead of addidng the overlapping entur InsufficientAccessRightsOnAccount / NoAccessRightsOnAccount as this allows the control parameters, CONTROL ENTRY , etc to be captured too , and upholds the TM model. A concrete implementation could have an attribute for summary status insufficient/norights.
However, the entur proposal does highlights a gap in the current mode,; it is also necessary to add an association between a VALIDATION ENTRY and a specific CUSTOMER ACCOUNT, so that the entries relating to the specifc CUSTOMER ACCOUNT can be found (to handle thecase where the FARE CONTRACT has more than one account associated with it)
PS There is probably a further housekeeping CUSTOMER ACCOUNT ENTRY missing - INVALID VERIFICATION ATTEMPT , so that repeated Hacking attempts to use an account can be detected.
@Aurige Pls discuss and the next meeting, so that @trurlurl may work on it.
@Aurige Pls discuss and the next meeting, so that @trurlurl may work on it.
It was discussed in meeting 3 and it was mentioned that we already have a FareContractEntry that may be used for this. Also ENTUR said that they will rework the PR and finally dropped it (when Arne left). So I think that we can close it, unless you have a use for it
Have to be little careful here as to what is or isnt in Netex. Validation and control isnt. There are some thimngs we could do eg alowing a direct reference between CUSTOMER PURCHASE PACKAGE and FARE ENTRies for convenience (can derive this from other relations but a pain in NETEx as that means of the stuff has to be exchanged