Transaction Document Management: Case Study of International

Passenger Carrier

Vladimirs Salajevs

, Gatis Vitols

, Nikolajs Bumanis

and Irina Arhipova

LLC Mobilly, Dzirnavu street 91 k-3, Riga, Latvia

Faculty of Information Technologies, Latvia University of Agriculture, Liela street 2, Jelgava, Latvia

Keywords: Mobile Payments, Electronic Tickets, M-commerce.

Abstract: As m-commerce services availability is rapidly increasing, more solutions are required to support business

processes. One field is a management of transaction documents that appear during payment transaction,

such as transportation tickets, receipts, etc. This position paper address transaction document management

issue with application of previously developed improvements of payment procedures using micropayment

company payment processing procedures for case study of international passenger carrier. Introduced

improvements include the document structure and versioning, the improved interaction setup for the

involved parties and the definition of smartlet content management engine. Improvements were included in

prototype that was successfully developed following the OSGI standard approach for modular development

using the Apache ServiceMix software stack. The proposed transaction document management approach

can be implemented in other logistics companies after testing with larger amount of transactions and

considered for possible application for other business fields.

1 INTRODUCTION

Transaction document management is crucial

component in m-commerce solutions and transaction

document management is increasing (Oliveira T et

al. 2016). Transaction document examples are bills,

warranty cards, bank statements and insurance

policies.

Transportation industry for multiple years are

trying to substitute printed ticketing with e-tickets

using different technologies typically including

separate smartcards (Payeras-Capellà et al. 2015)

and RFID technology (Sankarananrayanan and

Hamilton 2014). Recently m-ticket technologies are

developing, for example using m-ticket purchase

using location services (Khan et al. 2016).

NFC and other m-commerce enhancing

technologies support typically transaction document

purchase (Ceipidor et al. 2013), but also can be used

for further management during purchase transactions

and possible unification of transportation flow for

other parties (Vitols et al. 2017).

Transaction document management after purchase

is fragmented and raises multiple issues, especially

with documents that should be stored for longer

periods, such as warranty cards and purchase receipts.

Previous research introduce concept of smartlet

and role interaction for smartlet management (Vitols

et al. 2015) that can be applied for transaction

document management.

Aim of this research is to propose technological

solution and application scenario for previously

introduced solution for generation and transportation

of transaction documents using payment

infrastructure.

2 PROPOSED IMPROVED

COMPONENTS FOR

TRANSACTION DOCUMENT

MANAGEMENT

Proposal of unified document structure and

management components can be introduced to

support scalable solution for transaction document

management.

Introduced improvements are:

• Introduced document structure and

versioning (Fig. 1, Fig. 2);

• Interaction setup for the involved parties

(Fig. 3);

Salajevs, V., Vitols, G., Bumanis, N. and Arhipova, I.

Transaction Document Management: Case Study of International Passenger Carrier.

DOI: 10.5220/0006755706070611

In Proceedings of the 20th International Conference on Enterprise Information Systems (ICEIS 2018), pages 607-611

ISBN: 978-989-758-298-1

607

• Role of Smartlet content management

engine (SCME) (Fig. 4).

The document includes type and class. Class has

a version and version corresponds to the type. At the

same time document has an original version and a

snapshots. Original version is stored in the profile

system while snapshots are transported between

involved parties of the transaction.

Figure 1: Proposed document class and type association.

Document is abstract distributed document

object, which circulates between different integrated

profiles systems. Document is built around five main

components: Abstract, Class components, content,

Mandates component and Access History

component. Abstract contains unified data for the

document package's identification. Class component

defines presentation that is formed using CSS and

HTML5 or any required interpretation of XSLT with

functioning elements, XML scheme for content

validation and methods. Methods can either be

realized on front-end or back-end, depending on

class author's needs, and be implemented into

mobile application and/or web page as end points.

Documents content is stored in XML format that can

be filtered according to class component's

presentation specification. Mandates component is

used to authorize initiation of Methods. Access

History includes all the changes performed to the

document, including usage of such method as view.

Figure 2: Proposed document architecture.

To develop solution and describe interaction for

transaction document management, we introduced 4

concept interactions (Fig.3):

• Point of interaction (POI) (example, mobile

device);

• Smartlet (example, mobile application,

smartcard application);

• Payment interaction object (PIO) (example,

payment application, payment method);

• Service interactions object (SIO) (example,

service or service order module in

application).

To describe introduced role of Smartlet content

management engine, parking payment and

transaction document management can be explained.

When service interaction object (SIO) initiate order

(parking payment), check is performed if there is a

class (instructions how to process) that can process

this order. If the class (i.e. order execution template)

exists, the order is executed using template

description.

Otherwise if SIO does not have the class

description for particular order, SIO interact with

service provider's SCME to get the class for

execution of initiated order. Service provider's

SCME can get the class from another role's SCME

which is the class author (Fig.4).

Figure 3: Interaction setup for the involved parties.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

608

Figure 4: Role of Smartlet content management engine.

Figure 5: Role of Smartlet content management engine.

3 APPLICATION OF PROPOSED

PROTOTYPE FOR

INTERNATIONAL PASSENGER

CARRIER

For concepts approbation prototype was developed

and applied in the information system of

international passenger carrier that operates in

Latvia. Prototype is introduced in ticket sales

business process.

Involved parties for application of developed

prototype include:

• Service provider provides PIO which

provides e-ticket purchase function.

Executed by LLC Mobilly (micropayment

company);

• Profile system provided by national level

ICT company that holds large profile

database from all municipalities of Latvia;

• Transaction messaging and payment

processing using profile system is

performed by LLC Mobilly (Payment

method and Processing Method role);

• E-ticket writing (POI interaction) to the

smartcard is performed by international

passenger carrier (Smartlet manager role).

Proposed prototype execution is described in

Figure 5.

Described scenario includes ticket purchase and

profile modification procedures. Blue arrows

describe purchase execution, green arrows -

response, red arrows describe profile modification,

and yellow arrows response from these modification.

General Ledger is an accounting system, which

contains all client's data - account numbers,

balances, limits, etc. General Ledger is also

responsible for deal's processing, where each deal is

processed according to particular accounting scheme

that is defined with business rules, such as when to

execute transaction, which profiles are used, how

commissions are deducted, how to deduct and

process subsidies (discounts, special conditions), if

there are defined subsidies from government or other

organizations. Transaction processing schema (i.e.

template) can be stopped any time and calls for

external system procedures can be performed such

as profile update, adding funds, requesting for

calculations of subsidies or other checks. System

also allows to dynamically processing various types

of reservation (one time reservation, reoccurring

reservation).

Profile System stores user information - personal

data and client's profile numbers, payment

configuration such as payment sources (e.g. payment

Transaction Document Management: Case Study of International Passenger Carrier

609

cards, virtual wallets, digital currency, etc.), service

access rights and other information.

Mobilly SIO is virtual cash register. It is entrance

point for prototype. Transaction initiation starts with

request for Payment Order object. After request,

access to profile system is performed to retrieve

needed configuration for payment order. Based on

this configuration further transaction processing step

is determined. Usually next step includes interaction

with Charge Router entity.

Charge router is virtual POS that based on

Payment Order configuration calls Gator to perform

payment using bank payment card or external

profile. Charge router also creates Transaction

Message object and transports this object to

Transaction Router entity.

Gator works as transaction processor (interface

with bank). Gator receives request for cash

transaction and connects to correct bank, after that it

performs transaction and sends processing result

back to requester.

Transaction (TRX) Router based on Message

object content determine format in which forward

message for further processing. Developed prototype

sends Financial Message data object to Processing

Router.

Processing Router based on Transaction

Message content determines which accounting

system, if there is multiple, has to execute

transaction. This prototype is developed with one

profile system, therefore Processing Router forwards

Transaction Message to this system.

Accounting system is developed following OSGI

standard approach for modular development.

Modules use Apache ServiceMix software stack

(Karaf module containers, Jetty web server, etc.)

(Fig

. 6).

Accounting system is divided into multiple OSGI

modules (Fig. 7) responsible for main functionality.

Figure 6: Overall architecture for profile system of

proposed prototype.

Module that is responsible with ActiveMQ

profile calls is also included. Module allows

establishing communication between ActiveMQ

supporting systems. HTTP REST interface is used to

call profile systems from other systems.

Accounts charting module perform profile

schema management and choose transaction

processing template according to accounting systems

calls. Modules also include and store schemas for

accounting for various financial organisations.

Prototype introduction was successful as the

proposed improvements (Fig. 1.–4.) were

successfully implemented which allows to expand

involved parties list and apply proposal for other

business processes that involve generation and

manipulation of transaction documents.

4 CONCLUSIONS

Unified document concept allows systematical

creation of dependent and traceable documents that

allows furthering connecting processing points of

integrated systems.

Proposed improvements of mobile payment

infrastructure support creation and management of

transaction documents using unified document

concepts.

Figure 7: Developed prototype system modules.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

610

Proposed improvements of mobile payment

infrastructure support creation and management of

transaction documents using unified document

concepts.

Profile system can be successfully developed

following OSGI standard approach for modular

development using Apache ServiceMix software

stack.

Proposed transaction document management

prototype is scalable and can support collaboration

with multiple companies and organizations for

unified transaction document management.

Further research involves in full integration of

proposal into transportation transaction document

management in Baltics and development and testing

with increased flow of transactions and parties

interactions.

ACKNOWLEDGEMENTS

The research leading to these results has received

funding from the research project "Competence

Centre of Information and Communication

Technologies" of EU Structural funds, contract

No. 1.2.1.1/16/A/007 signed between IT

Competence Centre and Central Finance and

Contracting Agency, Research No. 1.4

“Development of personified transaction document

management model". More information at

http://www.itkc.lv/?lang=en.

REFERENCES

Ceipidor, U.B. et al., 2013. Mobile ticketing with NFC

management for transport companies. Problems and

solutions. In 5th International Workshop on Near

Field Communication. Zurich: IEEE.

Khan, M.B.R., Mourya, S. and Kaulgud, S., 2016. SMS

ticketing system for local trains. In International

Conference and Workshop on Electronics and

Telecommunication Engineering, ICWET 2016.

Mumbai: IET Conference Publications.

Oliveira T., Thomas M., Baptista G., C.F., 2016. Mobile

payment: Understanding the determinants of customer

adoption and intention to recommend the technology.

Computers in Human Behavior, 61, pp.404–414.

Payeras-Capellà, M.M. et al., 2015. Electronic Ticketing:

Requirements and Proposals Related to Transport. In

G. Navarro-Arribas and V. Torra, eds. Springer, pp.

285–301.

Sankarananrayanan, S. and Hamilton, P., 2014. Mobile

enabled bus tracking and ticketing system. In 2nd

International Conference on Information and

Communication Technology. Bandung: Institute of

Electrical and Electronics Engineers Inc., pp. 475–480.

Vitols, G. et al., 2015. Multi-payment solution for smartlet

applications. In H. Slimane, M. Leszek, and E.

Teniente, eds. ICEIS 2015 - Proceedings of the 17th

International Conference on Enterprise Information

Systems. Barcelona: SciTePress, pp. 668–673.

Vitols, G., Bumanis, N. and Arhipova, I., 2017.

Generation and transportation of transaction

documents using payment infrastructure. In ICEIS

2017 - Proceedings of the 19th International

Conference on Enterprise Information Systems. Porto:

SciTePress, pp. 739–744.

Transaction Document Management: Case Study of International Passenger Carrier

611