search

NeTEx-CEN / NeTEx

NeTEx is a CEN Technical Standard for exchanging Public Transport schedules and related data.
http://netex-cen.eu
GNU General Public License v3.0
78 stars 40 forks source link

Add support for CUSTOMER ACCOUNT LOG ENTRIES on a CUSTOMER ACCOUNT #217

Open skinkie opened 2 years ago

skinkie commented 2 years ago

137

Needs documentation

nick-knowles commented 6 months ago

Currently, in Transmodel and NeTEx, CUSTOMER ACCOUNT LOG ENTRIES are linked to a CUSTOMER ACCOUNT via a FARE CONTRACT, that is a FARE CONTRACT must be created to hold the account log entries; thus a dummy FARE CONTRACT must be created for the account itself to record and log entries before any sales transactions have taken place for the account. This is not unreasonable - the account itself entails a "contract" between the customer and operator to hold and account and manage the customers details according to certain terms and conditions. . The CUSTOMER ACCOUNT LOG ENTRIES do however have a reference to the relevant account so can readily be associated with it.

If people think it really necessary, for convenience in NETEx for the purposes of data exchange, one could add a list of LOG ENTRY references also to the CUSTOMER ACCOUNT but this would be redundant from a modelling point of view

This is the current model image

nick-knowles commented 6 months ago

Added to NeTEX UML as convenience feature. (not needed in Transmodel)

image

ue71603 commented 1 month ago

@trurlurl if input from @Aurige is necessary just ask him.

trurlurl commented 1 month ago

Replicating the update to the UML model would mean adding an element entries to CustomerAccount. The entries of type fareContractEntryRefs_RelStructure would collect references to each of the log entries that are hold in a "dummy" / dedicated FareContract. Is that correct?

When transferring CustomerAccount data, the sender would have to collect the log entries from the dedicated FareContract and pack the references in CustomerAccount.entries. The FareContract in question has also made sure to be included somewhere. That's quite complicated. Easier would be to transfer CustomerAccount.entries as a duplicate of the FareContract.entries, i.e., of type fareContractEntries_RelStructure. But then, why not having just that element (CustomerAccount.entries), there is no more need for the additional "dummy"/dedicated FareContract?

@nick-knowles Could you help with my unterstanding - do these questions make sense or am I ignorant about some more basic things?

trurlurl commented 4 weeks ago

Added a note in the documentation, part 3. Changing milestone to 3.0 as it should be treated as part of PR #137.