1.2 LU-GE 0102: Information Flows (Finance)

Finance User Manual ENG -> General Finance_en -> 1.2 LU-GE 0102: Information Flows(Finance)

LU-GE 0102 Information Flows

How to Explain UniField Information Flow?

Link between Finance and Supply

The following chart is the global business model, presenting an overview of the main functions and represents the different flows of the functional coverage of the project.

Not all of the variations of flows are represented here, in order for the standard flows to remain readable.

Not all of the functions displayed in this chart will be accessible to all users; this will be according to the user rights management.

Global functional project coverage

Relationship between Different Operational Levels

Some MSF field processes crosscut over several operational levels. The following charts will show the main functional links between Projects, Coordination, Regional supply centres, European Supply Centres and HQs.

The data flows accompanying these processes will be handled by the synchronization module of UniField. They will also rely on the successive statuses of the transactions, each status corresponding to a specific step in a process to be performed by the defined user at the appropriate operational level.

These flows are of an accounting and supply nature, and include master data. Validation workflows across sites, including HQ are also considered as part of these inter-site operations.

  1. Integration with External Systems

The UniField solution will provide a full integration with existing systems:

  • Vertical integration: The first version of the UniField tool will provide each HQ/European supply center (ESC) system with the same degree and format of integration as what is used in the former systems. Future versions of UniField will move towards an automated integration with all HQs/ ESCs, potentially through a unique common integration platform and web service.
  • Horizontal integration: The UniField tool will integrate with field applications (Homere, EasyMED…) in a similar format as they did with past MSF accounting and supply software. In cases where tools have not yet been standardized and are still based on spreadsheets (e.g. drug forecasting tools based on epidemiological data or medical protocol, activity monitoring tools) the information will not be synchronized with UniField

2. Inter-Instance Accounting Flows

As described in the following chart, accounting flows correspond to two distinct needs:

  • Accounting consolidation, aiming at having closed accounting records at HQ on a monthly basis within a reasonable timeframe.
  • Financial information flows, aiming to make financial data available at any operational level for budget follow-up and financial management purposes. This flow will include records made at HQ level for a mission (called HQ Entries).

Data exchanged includes both general accounting and analytical information.

In the Registers there are three distinct statuses to manage entries:

  • Draft: created locally and are not synchronized
  • Temp-posted: synchronized up to coordination – can be edited at creation instance (but not necessarily by all users)
  • Hard-posted: cannot be edited or deleted any more

In the Journals, entries can be:

  • Unposted: the corresponding entries are not final in the accounting; they can still be modified without generating an accounting correction. For entries created from registers this status is corresponding to {Temp-posted}.
  • Posted: the corresponding entries are final in the accounting; they cannot be modified anymore. If they need to be corrected, an accounting correction will be generated. For entries created from registers this status is corresponding to {Hard-posted}.

There are four period statuses to manage the closing process:

  • Open
  • Field-closed
  • Mission-closed
  • HQ-closed

In addition to the first synchronization of a created entry, any correction or posting of accounting entries is synchronized as well.


Inter-site accounting flows

3. Supply Order Flows

The documents in UniField are linked: whenever a document is confirmed, validated or closed, the following one, corresponding to the expected next step of the supply chain, is automatically generated in {Draft} (snowball effect).

These flows can be grouped in 3 major groups: Internal Flows; Inter-Instance Flows and External Flows.

  • Internal Flows

The Internal flow regroups all the flows that are specific to an instance (Coordination; Project) and that are occurring WITHIN the instance.

The starting point of the supply chain process is the requirement which is expressed in UniField by the creation of an Internal Request (IR). Consequently the IR is the starting point of UniField Internal Flows.

Once the IR is validated, the IR will need to be sourced either from “stock” if the goods are in the “Warehouse” or to a “Purchase Order (PO)”. The sourcing will confirm the IR.

Afterwards, the requirement will follow a step by step process where all the documents will be generated automatically in Draft in a logical stream until the delivery of the goods.

  • Inter-Instance Flows

As opposed to the Internal Flows, the Inter-Instance flows are between two MSF instances (Coordination and Project). That is to say that there will be a requiring instance which will require goods from another instance (“supplying” instance). The requiring instance will address a PO to a “supplying” instance which will act as an Internal Supplier.

The synchronization engine processing the Validated PO from the “requiring” instance will be sent automatically to the “supplying” instance. The details of this PO will be received in a Draft Field Order (FO) at the “supplying” instance.

The “Supplying” instance will then process the requirement via the sourcing of the FO. Once the FO is confirmed, a new synchronization will happen and the initial PO at the requiring instance will be automatically updated and confirmed.

  • External Flows

The External Flows are the ones that happen between an MSF instance and an external Supplier; That is to say when a PO is addressed to a supplier that is not an Internal Partner (not Coo, not Project, not ESC). Confirmed POs will be printed from UniField and sent to the external supplier.


Inter-instance standard order flows

1.1 UniField: an Enterprise Resource Planning (ERP) System.

Finance User Manual ENG -> General Finance_en -> 1.1 UniField: an Enterprise Resource Planning (ERP) System.

LU-GE 0101 UniField: an Enterprise Resource Planning (ERP) System

How to Explain the Architecture of UniField?

UniField is an Enterprise Resource Planning (ERP) tool that facilitates the integration of the work of the supply and finance departments into one system. It is a complex task to build a single software that meets the needs of each user, whether they are in finance, supply, or warehouse. UniField combines these into a single, integrated software. This program runs off a single instance (project database) and allows each department to share information and communicate with each other.

UniField has various business applications that link with a variety of submodules. It facilitates interaction between users in field offices and the mission and vice versa and offers benefits in time savings, paper work and efficiency. The application is managed via user access control, so each user has access to a specific part of the process e.g. a supply officer creates an order, this same order is validated by a supply team member, received by a supply logistician, and paid for by finance staff. All users interact with the order at different levels in the system.

UniField is a web-based application. Provided there is sufficient internet connectivity, users will exchange data via an Internet connection. When not exchanging data with another instance (project database) UniField works via an offline network.

  • One of the key needs for all MSF Operational Centers is to improve and accelerate the flow of information between the various operational and functional levels. One of UniField’s main benefits is providing a common international tool for Coordination and Projects across all sections. The management of MSF operations requires numerous interactions, especially between Projects and Coordination, and between Supply and Finance departments. Before UniField, the coordination between Supply and Finance was almost exclusively restricted to manual data checking and time-consuming meetings, which can lead to misunderstandings between finance and supply. The operational scope of the UniField project is to provide a common international tool for Coordination and Projects.

In addition, UniField provides automated links between supply and finance operations leading to improved efficiency, consistency, reliability, and precision in the management of MSF resources. Integrating Supply and Finance into one tool allows information to be shared and retrieved easily by all departments. UniField will reduce manual data checking and miscommunication between the Supply and Finance departments.

Business Application Model

An Enterprise Resource Planning (ERP) system offers a high number of available features. Most users of the system will only need selected features, depending on their role in the organization. In order to remain easy to use, the different features are split into business applications.

All users will usually work in a particular context (e.g. in a supply warehouse or recording accounting entries). Within this role, UniField will provide business applications in which they will be able to directly see all features related to their individual role. The business applications were developed according to user roles in the organization: coordinators, purchasers, accountants, etc.

These business applications define a context of work and all terminology used in an application are relative to this context e.g. a purchaser sees screens adapted to purchasing operations. An accountant may see the same data, but from an accounting perspective (adapted terminology, adapted menus, adapted default values in each screen).

Transversal Features, Used by All Applications

The user can perform most of their tasks using only one business application. They do not have to switch to another application to perform the tasks of the same role e.g. an accountant is not forced to go to one of the supply applications to see a supplier invoice. They can do it from the accounting application and can also pay the invoice from this application.

Some features are accessible by all users, irrespective of the application they usually work in. The direct menu can be found in the application that uses the feature most regularly. Shortcuts to this feature are found in other applications that need less regular access. For example, many users need access to {Partners} and {Products} modules. The menu is inserted into the applications that need these features most regularly e.g. the address book is in the {Order}, {Purchases}, and {Accounting} business applications. However, inside the Accounting Application, certain finance team members will have shortcut buttons in order to reach the {Partners} and {Products} modules.

Access Rights

The roles defined in each module are directly related to each business application. This means that for a given application, all roles within this application must be relevant to this process. For example, the {Accounting} application will be used by financial staff members: Financial Coordinators, Financial Managers, and Finance Assistants. For supply, the permissions/access rights given will correspond to the tasks of a Warehouse Officer, Logistic Coordinator, Supply Manager, etc. In some cases, users will have read-only access. For example, a Financial Manager or Supply Manager may be able to access all screens for information purposes but certain actions may only be completed by the Financial Coordinator or the Logistic Coordinator.

Instance Synchronization in UniField

An instance is the installation of UniField. It could be a Project, Coordination, or an HQ. In simplified terms, one instance reflects one MSF office. The instances exchange data through the synchronization server, which has been designed to work with bad or unreliable internet connections. However, an internet connection is necessary when sending data between two different instances. Synchronization is performed regularly, either on an automatic or manual basis.

When working within one instance then users can work offline, i.e. not connected to the internet or synchronization server. For example, when coordination supply department adds data, the coordination finance department will automatically see the data without need for synchronization. When the project instance adds data, they will need to connect online via the synchronization server in order for coordination to access the data.

In order to cut down on high internet usage, the synchronization server replicates only the necessary data for sending/pushing data and receiving/pulling data. The synchronization server does this by receiving/sending/routing messages from all other instances. For example, invoices and register lines created at project level are sent to the synchronization server and sync completely to the Coordination, but at the HQ level only the related accounting entries are replicated because this is all the information the HQ database requires. A synchronization rule is defined and applied for each type of data.

Finance User Manual ENG