Introduction

Scope & Objectives

This document aims at describing the overall architecture of Vertex application in the SyWay context.

As per KDD093, SyWay will run Vertex Cloud solution (SaaS).

Key Decisions and Requirements

Terminology

VERTEX is an external software used by Syensqo to calculate taxes on customer and vendor invoices for US and Canadian legal entities. Tax Rules are customized by legal entities in VERTEX, based on Syensqo's Sales and Procurement processes.  The tax rules customized in VERTEX are based on directions from the Syensqo USA Tax Department.  Tax Jurisdiction Codes linked to the Country/State or Province/County/City/Postal Code are assigned to US and Canadian Customer and Vendor master data in SAP.  Tax jurisdiction codes also are assigned to company codes, shipping points, and storage locations for the US and CA.

When a sales order, customer invoice/credit memo, purchase order, or vendor invoice/credit memo are processed in SAP, there is a Remote Function Call (RFC) from SAP to VERTEX to determine taxability of the transaction based on the customization. If the transaction is determined to be taxable, the tax rate is determined by the tax jurisdiction code specified on the customer, vendor, or plant/delivery address master record.  

VERTEX issues monthly updates for tax rule changes, tax jurisdiction code changes, and tax rate changes.  These monthly updates are applied to the VERTEX development, quality, and production servers to ensure tax calculations are correct.

Vertex Cloud is connected to its respective S/4 system through a component named SIC (SAP Interface Component).

Application Architecture

Overview

Application Architecture Components

Vertex runs in S/4 systems through standard processes and transactions. . There are however dedicated objects to help on configuration, customization, monitoring and tax management. This list will depend on the additional tools and features purchased by Syensqo and are provided as external transports.

A specific RFC in S/4 calls the SIC processes, passing the required information onto them. The request is then sent against Vertex Cloud. Data is retrieved by SIC and sent back to the calling S/4. It uses SAP Jco and a J2EE engine.

Vertex Cloud operates the tax calculation and other activities. Syensqo IT team and tax department need accesses to Vertex Cloud to configure and manage their specific activities.

Network Architecture

System Landscape

Vertex Cloud has 3 different environments : 1 for DEV, 1 for QAS, 1 for PROD

Syensqo will have 3 servers for running the SIC : 1 server serving as interface for all non-prods S/4 systems towards Vertex Cloud Dev and Qas. 2 servers in 2 differents AZ for production with multiple SIC running in parallel. It will provide HA and good response times.

The part residing in S/4 is for all S/4 RoW systems

System Access

The main usage of Vertex is done in background from SAP. IT team and Tax department will connect to the web page to proceed with some specific activities related to configuration.

Access to Vertex Cloud DEV is https://................

Access to Vertex Cloud QAS is https://................

Access to Vertex Cloud PROD is https://................

Application Security

Authentication

Syensqo users will connect through SSO to Vertex Cloud

There is a dedicated technical account for the connection from SIC to S/4

Authorisation

Authorisations in S/4 will be provided depending on the user roles. This is not covered in this document.

Authorisations in Vertex Application will be managed manually by the different teams.

Communication Security

Communication between SICs and Vertex Cloud is encrypted (HTTPS)

Communication between SICs and S/4 must be set as RFC with SNC encryption

Data Security

Credentials and TrustedIDs must be encrypted in SIC configuration file.

We shall enable the use of Trusted IDs  and assign each partition to a Trusted ID. Trusted IDs do not allow anyone unathorized to log on to our system to change our tax data.

A Trusted ID is a partition-specific unique identifier that enables a secure connection where messages are exchanged between Vertex cloud products and an external system. 

A partition represents a logical separation of data that is isolated from other logical data sets.

• Each logical data set can be associated with a single entity or with multiple entities in a single system.

• Multiple taxpayers can use the same partition.

Operation Architecture

Change and Configuration Management

Changes on S/4 will follow S/4 change management (see Transport Management for Release 4 DD-TEC-170)

Changes on SIC must be tested against the different non-productions environments and validated before proceeding with the production implementation.

Changes on Vertex Cloud must be tested and validated in DEV then QAS. 

There is no tool to transport the changes between the different environments (SIC and Cloud), they have to be manually reproduced each time. 

Monitoring

Monitoring of Vertex Cloud is part of Vertex contract. Different levels of support (Gold/Silver/Bronze) and reactivity can be defined. SyWay selected the XXXX plan.

Vertex Cloud status can be checked here.

Monitoring of the SIC servers is done through XXXX as other VMs in Azure.

Sizing

Sizing of production is based on XXXX

Sizing of SIC servers depends on the number of SIC processes running. It is foreseen to use 3+3 SICs processes in parallel for production.

The hardware requirements are described below (see best recommendations)

High Availability & Disaster Recovery

SLA is 99.9% and obtained via Vertex Cloud running on 2 different regions in EU ( Primary is AWS Frankfurt  with secondary in AWS Dublin)

SIC servers are deployed on 2 availability zones in Azure in order to achieve HA

Backup/Restore

Backups and restore are managed by Vertex in order to meet (or exceed) the below RPO/RTO

On the SIC server part, backups are scheduled every XX 

Maintenance Plan

Vertex reserves a weekly recurring scheduled maintenance each sunday between 12AM and 6AM ET. Scheduled Maintenance windows will be published at least 72 hours in advance in the status page . Shorther publication period may however apply if a maintenance is required for security reasons.

SIC servers will follow standard Azure patching cycle. Update to SIC component itself will be done on demand.

Exceptions

See also

Change log