Please provide Yes or No (Y/N) response for each requirement listed below.

Add clarification if needed and/or where requested

Requir
ement
No.

Solution Feature/Functionality Requirement

Availability (Y/N)
Out of the box
as shown in
demo

Out of the box

not shown in
demo

SUPPLIER REGISTRATION AND SETUP

1.

2.

3.

4.

5.

6.

Suppliers should be able to generate selfregister request using Alshaya's website linked
to GTMS portal
System should take suppliers information and
maintain their profile online. This include
scanned documents as well as information in
electronic form.
System should have ability to detect and avoid
potential duplicate records of suppliers in
system.
Ability to evaluate new supplier requests based
on evaluation criteria defined by Shipping
Team.
Negotiation terms and style formats should be
set at the time of registration of new supplier
as per requirements given by Shipping Team
Post verification of documents, supplier shall
be registered by authorized user, in the system
as prospective supplier

Y
Y

Requires
custom
development

Planned in
future
release

No plan to
support
requirement

Details of
offering

Requir
ement
No.
7.

8.

9.

10.

Solution Feature/Functionality Requirement

Availability (Y/N)

System should also manage renewal requests

to registered suppliers as per feed from
performance review sub-system
System should maintain a contract repository
which shall house following information for all
registered vendors - SLA (performance matrix),
Legal contract, Service components, Terms &
Conditions, Payment Terms
Above information must be in electronic form
wherever possible
Suppliers' information should seamlessly be
available with finance interfaces. Any change
by supplier must be approved by Alshaya
before getting updated with Finance Interface.

Out of the box

as shown in
demo

Out of the box

not shown in
demo

Requires
custom
development

Planned in
future
release

No plan to
support
requirement

??

??

??

??

??

ELECTRONIC BIDDING
11.

12.

13.
14.

A portal for tenders will be required, which

shall be accessible to vendors via logins

System should identify registered vendors and

fetch information from contract repository

System should allow user to generate Loginpassword manually for a non-registered vendor
An RFQ would be an electronic document
containing terms and conditions of service
requirements. The document shall have an
interface to fill in rate from different service
providers & is captured and stored in a central

Y
Y

Details of
offering

Requir
ement
No.

Solution Feature/Functionality Requirement

Availability (Y/N)
Out of the box
as shown in
demo

Out of the box

not shown in
demo

Requires
custom
development

Planned in
future
release

No plan to
support
requirement

Details of
offering

database
15.

16.

17.

18.

19.
20.

21.

22.

23.

All RFIs/RFQs shall be fed by Alshaya personnel

as per requirement and forecasted volume for
each particular sector (ocean/air)
Information to be disclosed to bidders must be
customizable as per Alshaya Shipping team
requirements
Existing rate cards would provide baseline for
evaluating new bids for every route and mode
of shipment. The selected rates should be
updated in baseline rates database
Services providers are ranked in score card on
the basis of criteria provided by Alshaya
shipping team
There should be provision of bid-negotiations
between Alshaya and shortlisted suppliers
Final approval for bid winner shall be by
authorized user access. Information shall be
provided about bid results automatically
through the portal.
System should have capability of post-bidding
analysis. Areas to evaluate include: i) variance
between pre-auction estimate and auction
prices, ii) performance of successful bidders
Configure bid templates with required fields,
restricted fields, hidden fields, acceptable field
values, allowable surcharges, forecasted
volumes, carrier capacity and target prices
Receive configurable reports to analyze and
compare competing offers, across multiple

Y
Y
Y

Y
Y

Strategi
c Bid
Analysis

Requir
ement
No.

Solution Feature/Functionality Requirement

Availability (Y/N)
Out of the box
as shown in
demo

Out of the box

not shown in
demo

rounds

RATE CARD REPOSITORY

24.

25.

26.

27.

The e-rate card shall be a data warehouse of

freight charges for all FF in all contracted
routes.
Rate cards shall also include the origin and
destination charges as quoted by the clearance
agent. This shall be in standardized formats
across different markets
The e-rate card shall be enabled with version
control to update charges. Any update should
require authentication and authorization by
user role privilege.
It shall also have the capability to add or
eliminate suppliers and routes as and when
needed.

SHIPMENT PLANNING
28.

29.

30.

31.

32.

Provide central visibility into actual

consolidation activities to monitor Host
brands/3PL performance
Create consolidation approval process through
Shipping Orders => requires host brand/3pl to
Y
create Shipping orders on the platform, to
ensure optimized origin fill rate
Shipments clubbed together must be optimized
using criteria like cargo weight, dimensions,
clearance type and other attributes
SHIPPING REGISTER
All fields in the SR to be available in eSR,
categorized into information types merchandize, service providers, carrier details,
financials, tracking, etc.
eSR to be accessible to Alshaya Shipping
Department, WH Brand Teams and IT through

Y
Y

Requires
custom
development

Planned in
future
release

No plan to
support
requirement

Details of
offering

Requir
ement
No.

33.
34.

35.

36.

37.
38.

39.

40.

41.

42.

Solution Feature/Functionality Requirement

Availability (Y/N)
Out of the box
as shown in
demo

Out of the box

not shown in
demo

respective logins. eSR should have search

options to search shipments by relevant tags
(AWB/SRN/ASN/PO)
Standardization of all input fields in Shipping
Y
Register across all markets
Incoming Pre-Alerts from FF/Supplier should be
tagged with a shipping reference number after
acknowledgment/approval from Shipping Team
??
??
and automatically create an SRN (rather than
manually uploading pre-alert documents)
eSR should have tracker templates for tracking
shipments which could show consolidated
Y
summary and highlight exception cases
Pre-Alert documents received from
FF/Brand/Supplier to Shipping through FTP and
Y
should be sent to Documents Repository.
CLEARANCE PLANNING
On receipt of Pre-Alert, alert to Shipping team,
Y
Brand Team, IT and WH
Pre-Alert documents must be approved against
compliance requirements as defined by Brand
Y
Team/Shipping Team as per market
requirements (as per product HS codes)
Any deviation or missing compliance document
should trigger alert to Supplier, Brand Team
Y
and FF
Shipping Team should be able to directly
approve Pre-Alert documents and forward them
Y
to respective Clearing Agents
Shipping Team should be able to track
availability of hard-copies of Pre-Alert
Y
documents with the CAs
Caution to import clearance on missing
Y
documents and approvals

Requires
custom
development

Planned in
future
release

No plan to
support
requirement

??

??

??

Details of
offering

Requir
ement
No.
43.

44.

Solution Feature/Functionality Requirement

Availability (Y/N)
Out of the box
as shown in
demo

In case of ICT shipments: Electronic Document

Generation - CoC, AWB, Commercial Invoice,
Packing List (from Warehouse), MoH Approvals,
EPA Approvals, Letter of Reserve as per
formats required by respective markets
System should have capability to store
scanned documents (approvals, clearance
certificate, etc) if required

Out of the box

not shown in
demo

Requires
custom
development

Y
SHIPMENTS

45.

46.

47.

48.

49.
50.

51.

eSR (Electronic Shipping Register) trackers

should send alerts to WH, Brand Teams and
Alshaya Shipping Department as per set
predefined levels for criteria given by Alshaya
Shipping Team
Brand Team and Warehouse must be sent
alerts through generation of an Advance
Shipment Notice (ASN) against a particular
incoming shipment
A shipment transaction should be allotted SRN
(shipment reference number) automatically
and a PO order must be generated against this
transaction
Details and updated information about the
inbound shipment must be updated in WH's
inventory planning system on continual basis
Integration with FFs carrier tracking systems.
Alerts if ATA is different from ETA
Alert from FF/CA to Shipping and Warehouse on
delivery of order from FF to CA at the import
port
Status of shipment in custom clearance must
be updated at every stage. Tracking and
provision of reasoning by FF at every stage of
clearance. Templates for clearance tracking

Y
Y
Y
Y

Planned in
future
release

No plan to
support
requirement

Details of
offering

Requir
ement
No.
52.
53.
54.
55.
56.
57.

58.
59.
60.

Solution Feature/Functionality Requirement

Availability (Y/N)
Out of the box
as shown in
demo

Out of the box

not shown in
demo

must be available for all operational markets.

Alert on demurrage - Update Demurrage Log
Alert to FF, Brand Team and WH after
documents are cleared at port
Caution alert from WH to Shipping on delivery
delay
Alert to Shipping and Brand Team on Shipment
Arrival at WH
Alert to Shipping Brand and FF on shipment
receipt and return of container
For every alert, option to ignore OR one-push
to-do list of actions. These to-do actions should
be included from all stakeholders
Lead time charts for times taken at Port of
Entry, Transit Times and Port of Exit
All shipments should be traceable using one
unique ID (Shipping Reference Number).
Tracker should be a summary of Process Step
vs Completion. Information transferred by
various stakeholders at different stages must
be captured for the same.

Requires
custom
development

Y
Y
Y
Y
Y
Y
Y
Y
Y

LANDED COST
61.

62.

Brand level and item level information for each

shipping transaction should be captured for
Tentative Landing Cost calculation. Cost
splitting (in a clubbed shipment) algorithm
should as per Shipping Team's requirements
Brand/Item level landing costs must be visible
to concerned Brand Teams as early in the
invoice approval process as possible

SUPPLIER INVOICES
63.
64.

Shipping and Clearance invoices are to be

accepted through FTP feed from FF and CA
GTMS must act as an Electronic Data Interface

Y
Y

Planned in
future
release

No plan to
support
requirement

Details of
offering

Requir
ement
No.

65.
66.
67.

Solution Feature/Functionality Requirement

Availability (Y/N)
Out of the box
as shown in
demo

Out of the box

not shown in
demo

(EDI) which converts FTP feeds by FF/CA into

invoice fields against shipment's AWB number
or shipment reference number
An invoice tracker should have summary of
status of reception of invoices by vendors
Upon matching of rates, PO shall be updated
Supplier Invoices must be also captured
against supplier history which would get stored
in the relevant contract repository

Requires
custom
development

Planned in
future
release

No plan to
support
requirement

??

??

??

Y
Y
Y

INVOICE APPROVAL
68.
69.
70.

71.

Verification of Shipping and Clearance invoices

with rates fetched from eRate Card
Alerts to Shipping personnel and FF/CA for
clarification on deviations and exceptions
Invoice approval process must have a system
work flow as per hierarchy and authorization.
Details of hierarchy requirements as per
different shipment criteria must be taken from
Alshaya Shipping Team
Upon reception and level-approval of all
invoices against a shipment, the shipment shall
be closed by Shipping Team and would be
forwarded to Finance Department's interface

??

??
Y

??

??

??

??

??

??

??

??

??

??

EXCEPTIONS
72.

73.

74.

Demurrage logs for delayed shipments Supplier wise, CA wise, product wise, Mode
wise, other search criteria
There should be an interface for demurrage
clarifications from FF/CA. If need be,
automated alerts should be sent asking
vendors for clarifications. All clarifications must
be captured against vendor history for long
term analysis.
All spend variances shall be recorded in spend

Details of
offering

Requir
ement
No.

Solution Feature/Functionality Requirement

Availability (Y/N)
Out of the box
as shown in
demo

Out of the box

not shown in
demo

Requires
custom
development

Planned in
future
release

No plan to
support
requirement

??

??

??

??

??

??

variance log for further analysis

FREIGHT AUDIT
75.

76.

77.

EFAS (Electronic Freight Audit System) should

have access to updated Rate Card repository
and Customs Charges for all FF, CA for all
modes and all contracted routes.
One step verification for Merchandize invoices
with the Brand Team. Merchandize invoice shall
be captured from Pre-Alert documents or be
conveyed directly by the Brand Team
Alerts to be sent to Brand Team, HB and FF to
resolve issues, in case of mismatch. If values
match, zero value Purchase Order is triggered

??

??

SUPPLIER PERFORMANCE REVIEW

78.
79.
80.
81.

82.

83.

Lead time analysis for suppliers and check

variations against contracted time periods
Supplier wise spend variance profile and
ranking of suppliers as per spend variance
Suppliers must be evaluated on the basis of
their ability to consolidate shipments efficiently
Suppliers should also be evaluated against the
loss and damage claims processing. Hence the
system should have interface with the tracking
of loss and damage claims.
Suppliers should be evaluated against the
ability to promptly respond to Alshaya's
request for responses and actions regarding
clarifications and follow-up information. Hence
system should keep supplier response time as
one of the metric.
Condition of products after unpacking must be
updated in tracker as well, so as to use it as a
supplier KPI. This information can be fetched
from WH's JRN report.

Y
Y
Y
??

??

Details of
offering