X3 WhatsNew U9 FinanceCompliancy NFR

Sage X3
Whats New in Update 9:

Finance, Compliancy, and FA
Improvements
Certified course curriculum
d
o
r
p
r
o
f
t
No
le
a
res
re
r
o
ctio
Important Notice
This is a publication of Sage Software, Inc.
2016 Sage Software, Inc. All rights reserved.
Sage, the Sage logos, and the Sage product and service names mentioned herein are registered
trademarks or trademarks of Sage Software, Inc. or its affiliated entities. All other trademarks are the
property of their respective owners.
This workbook provides general business information that should not be construed as professional
advice. Sage does not represent or guarantee that the information is accurate or applicable to your
business needs. Consult a tax, legal, financial, or other business professional to assess its suitability
before implementing the information in your business. This information does not alter, amend, or become
part of the license or purchase terms applicable to your use of any Sage product or service. Sage may
make changes to this information at any time and without notice.
Your use of this document and the Sage product(s) described herein is governed by the terms and
conditions of the Sage End User License Agreement ("EULA") or other agreement that is provided with
or included in the Sage product. Nothing in this document supplements, modifies, or amends those terms
and conditions. Except as expressly stated in those terms and conditions, the information in this
document is provided by Sage "AS IS" and Sage disclaims all express, implied, or statutory warranties of
any kind, including but not limited to the warranties of merchantability, fitness for a particular purpose, or
of noninfringement. No implied license is granted to you under any Sage intellectual property or trade
secret right. Sage reserves the right to revise, supplement, or remove information in this document at any
time without notice to you or others.
02/2016
Whats New in Update 9:

Finance, compliance, & FA
improvements
Table of contents
Course objectives
Lesson: Factoring management
4 55
Lesson: SEPA improvements - BIC optional
56 69
Lesson: XML bank file management
70 84
Lesson: Miscellaneous finance/compliance improvements

(Swiss addon and VAT function)
85 118
Lesson: Fixed assets improvements
119 146
Lesson: New physical assets app
147 171
Course conclusion
172
2/21/2016
Course Objectives
Objectives
Learn about new functionality in
Sage X3 Update 9 including:
Finance and compliancy:
Factoring management set up and

use factor types
BIC option
XML bank file management
Miscellaneous finance/compliancy
improvements SWISS addon and VAT
functions
Fixed Assets improvements and new
Sage X3 Physical assets app
2/21/2016
Finance and compliancy

Factoring management
Lesson Objectives
Understand Factoring management
improvements
Set up and use Factor types
2/21/2016

Overview
Why?: Improve the current functionality in Factoring Management
What for?: Ability to define the type of contract with the Factor
Features: According to the contract with the Factor, the Factoring Management
changes in the accounting way of events, control of the risk, accounting of costs
in a possible unpaid,...
Benefits: Improvement of standard functionality
2/21/2016

Overview
The Factoring management improvement allows you to define different
relationships with the factor. These relationships or contracts define different ways
of managing the factoring operations in terms of risk with the final customer,
costs, etc.
There are two types of contracts with the factors:
-
Recourse factoring: The client keeps the risk
No recourse factoring: The factor assumes the risk
The current management is maintained as a third type of factoring called

Standard.
2/21/2016

Overview and Prerequisites
The Factoring management improvement affects the following:
Factor definition
The factor of the invoices
Receipt generation and reports
Receipt posting depending on factoring type and costs
Payment notification depending on factoring type and possible unpaid
Prerequisites
The activity code FCT must be active
2/21/2016

Setup - Factors
Factoring type: Defines the type of relationship or contract with the Factor:
Standard: This type defines the current factoring management. If the factor has
this type, it will be managed as currently and all the improvements do not apply .
Recourse: The customer keeps the risk in the case of unpaid.
No recourse: The factor assumes the risk of unpaid, but in this case, the factor
withholds an amount proportional to the invoice in case of unpaid (Reserve).
2/21/2016

Setup - Factors
The Accounting data section on the File tab has been modified:
2/21/2016

Example:
Setup - Factors
Reserve %: This field can only be
edited if the factoring type is
No recourse. It is the percentage
of the invoice that the factor
withholds to anticipate a possible
unpaid.
The contract with the factor indicates a

reserve of 10%
If we send to the factor an invoice of
1000 , the factor pays us 900 and retains
100 :
a)
On the due date, the customer pays the

invoice, then the factor returns the
100 .
b)
On the due date, there is an unpaid

amount, then the factor does not return
anything and we have to consider the
100 as a loss.
2/21/2016
10
10

Setup - Factors
Payment bank: Can only be edited if the factoring type is not equal to
Standard. It is the bank account that will be used in all the management with this
factor. So, the factor will be linked to an account bank (it is mandatory).
The fields Company, Site, Currency, and Rate type are fed from the definition
of the payment bank.
Company and Site will be used to control the invoices assigned to the factor.
All the journal entries in the bank account will be in the right currency
(accounts currency or companys currency) and in the right site (Banks site
or companys main site).
In case of invoices with a different currency than the bank one, the rate type
will be used to define the exchange rate.
2/21/2016
11
11

Setup Accounting code
In the Factor types accounting codes, 8 new lines have been added. The first 3
lines remain used for a case of Standard factoring type.
2/21/2016
12
12

Setup Accounting codes
The use of these new lines is the following:
No recourse account: (No recourse factoring) used to post the amount by
customer when the invoice is sent to the factor.
Recourse account: (Recourse factoring) used to post the amount by
customer when the invoice is sent to the factor.
Doubtful customers: Used to post the unpaid amount of the customers
Interests by factoring operations: The amount that the factor charges us as
interests.
Financial amount by factoring operations: Used to post the amount that
the factor charges us as commissions (usually submitted to tax)
2/21/2016
13
13

Setup Accounting codes
The use of these new lines is the following (continued):
Loss of uncollectible commercial credits: (No recourse factoring). It is
the loss amount when there is an unpaid case.
Debts by factoring operations: (Recourse factoring) Risked amount by
factoring operations.
Reserves factoring: (No recourse factoring). Factor reserves to prevent the
unpaid case.
2/21/2016
14
14

Setup Bank accounts
A new section has been added, on the management Tab, to assign default
dimensions to the bank.
The setup could be used in the factoring management thanks to the setup of a
dedicated Default dimension.
2/21/2016
15
15

Setup Bank accounts
The Dimension types are defined in Default dimension type for the Bank
entity:
Note: The same
management has
been added to the
Cash. These
default dimensions
could also be used
in other standard
functions.
2/21/2016
16
16

Setup Default dimensions
The analytical dimensions that the accounting could need are defines
thanks to a new Default dimensions setup: The delivered code is FCT.
Identifiers can be taken

in CPTQUIT &
NOTRGLT screens
2/21/2016
17
17

Setup Automatic journal entries
New lines have been added to the existing automatic journals used for
factoring management:
FCTQ (receipt posting)
Five new lines (3 to 7)
FCTN (payment notification

Six new lines (3 to 8)
2/21/2016
18
18

Besides these already existing journals, there are 4 new automatic journals:
Two are executed in the receipt posting:
FCTQ2: To post the interests, commissions, VAT, of the operation
FCTOD: In case of No Recourse and the invoice currency is not equal to
the bank currency
2/21/2016
19
19

Two are executed in the payment notification:
FCTN2: To post the case of reserves and unpaid
FCNOD: In case of Recourse and the invoice currency is not equal to the
bank currency.
2/21/2016
20
20

Setup Group automatic journal entries
Two automatic journal groups have been defined:
FCTQ, grouping FCTQ, FCTQ2 and FCTOD auto journals, for posting receipt.
FCTN, grouping FCTN, FCTN2 and FCNOD auto journals, for payment notification.
2/21/2016
21
21

Setup Group parameters
The general parameters GAUFCTQ and GAUFCTN are now defined at the
level of the company. They have to indicate, respectively, the automatic journal
groups describes before:
2/21/2016
22
22

Example of process
To explain the process we are going to follow two examples: The process in a
case of Recourse factoring and the case of a No Recourse factoring. The
standard case is not object of this new feature because that still work as
previously.
The data for the example are the following (according to the SEED folder
definition):
Company:
ES20 / Site: ES021
Factors:
SPFACTREC: Recourse type

SPFACTNREC: No recourse type / Reserve = 10%
Both Bank: ES2EU / Currency EUR
Customer:
ES001
In both cases, use an invoice in EUR and an invoice in USD

2/21/2016
23
23

Invoice creation and Factor assignment
When creating a new customer invoice and the invoice is assigned to a factor,
there is a control on the compatibility between the company/site of the factor
and the company/site of the invoice:
This control is done for the Sales and A/P A/R accounting modules
2/21/2016
24
24

Invoice creation and Factor assignment
In the factor assignment management, there is a similar control when
assigning a new factor to an invoice:
2/21/2016
25
25

Receipt generation
The receipt generation process has been modified in the following points:
Control of compatibility between company/site. If we enter a factor as a
range, the process advises that the company of this factor is not compatible
with the factor of the process:
2/21/2016
26
26

Receipt generation
The process will only take into account the factors that are compatible with
the company/site of the process.
The log file indicates if there is any invoice assigned to a factor not
compatible with the company/site.
2/21/2016
27
27

Receipt generation - Report
The report LISFAC has been modified. Now the total amount of the receipt
is in the bank currency.
1 $ =0.833
A new report has been created in Spanish: S-LISFAC.
2/21/2016
28
28

Recourse factoring Receipt posting:
The screen of Receipt posting has been modified.
2/21/2016
29
29

Recourse factoring Receipt posting:
Currency: It is taken from the factor setup (not editable). All the amounts in the
screen are in this currency.
Factoring type: Standard, Recourse, or No recourse in function of the factor type.
Payment bank: It is taken from the factor setup (not editable).
Amount + tax: Total amount of the receipt in the currency of the factor. The change
rate will be calculated in the function of the entry date of the screen.
Reserve amount: Not editable in this case (Recourse factoring).
Financial cost & Interest: Enter the amounts indicated by the factor.
Tax: Editable if the account associated with the financial cost is subject to tax (see
accounting code). The default value is defined in the account.
Tax amount & Deductible tax amount: These amounts are calculated thanks to the
tax setup (Tax amount is editable).
2/21/2016
30
30

Recourse factoring Receipt posting (journal entries):
The result of the validation on the previous screen is the following:
For the invoices in :
The change rate has been calculated with the entry date of the posting
receipt
1 Line: It is the account where the invoice was posted
2 Line: Recourse account 5 line of the accounting code
2/21/2016
31
31

A journal entry by the total of the receipt in the bank currency :
2/21/2016
32
32

1.
2.
3.
4.
5.
Line: Bank account. It is the deposited amount by the factor in our bank
account
Line: Debts by factoring operation. Line 10 from the accounting code.
Line: Financial cost. Line 8 from the accounting code.
Line: VAT account. From the accounting code associated with the tax.
Line: Interest. Line 7 from the accounting code.
In this example, the dimension ACCT-001, has been fed thanks to the setup
from the definition of the bank:
2/21/2016
33
33

Recourse factoring Receipt posting (matching):
In this step, a matching in the invoice account is done:
If the general parameter DCLVATPAY is set as 2 for the company, then the
matching is not done in this step, but in the payment notification.
2/21/2016
34
34

Recourse factoring Payment notification:
The payment notification has changed:
If the general parameter DCLVATPAY is set as 2 for the company, then the
matching is not done in this step, but in the payment notification.
2/21/2016
35
35

Recourse factoring Payment notification:
Factoring type: It is fed from the factor and cannot be edited.
Currency: Payment currency. It could be the invoice currency or the bank
currency.
Paid amount: it could be a partial payment of the invoice and it can not be
upper than the invoice amount.
Unpaid: Unpaid amount of the invoice. It could be a partial amount and the
Paid amount + Unpaid can not be upper than the invoice amount.
Bank currency: Not editable.
Reserve amount: It is not editable in this case (Recourse factoring).
Note: If the currency is changed, the Paid amount is calculated using the
change rate on the date of the receipt posting.
2/21/2016
36
36

Recourse factoring Payment notification (Journal entries):
With the previous example, the result of the validation will be the following:
For the invoice in and with a partial unpaid:
Line: Recourse account 5 line of the accounting code

2 Line: Doubtful customers 6 line of the accounting code (*)
3 Line: Debts by factoring operations 10 line of the account code
(*) If the general parameter DCLVATPAY is set as 2 for the company, then
account used in this line is the invoice account.
2/21/2016
37
37

For the same invoice in and with a partial unpaid there is a second journal
entry:
1 Line: Bank account: It is the amount taken from our bank account by the
unpaid
2/21/2016
38
38

For the invoice in $
1 Line: Recourse account 5 line of the accounting code

2/21/2016
39
39

In this step, there is a matching between the Recourse accounts :
If the general parameter DCLVATPAY is set as 2 for the company, besides

this matching, in this step there is the matching between the invoice
accounts.
2/21/2016
40
40

Recourse factoring Summary
2/21/2016
41
41

No recourse factoring Receipt posting
For this example we are using the same invoices, but assigned to a No
recourse factor. The receipt posting is as follows :
2/21/2016
42
42

No recourse factoring Receipt posting
The only difference with the recourse case is the Reserve amount field. Now it
can be edited and the suggested value is the result of applying the reserve
percentage to the Amount + tax value. In this example is 10%:
2/21/2016
43
43

No recourse factoring Receipt posting (Journal entries)
The result of the validation on the previous screen is the following:

For the invoices in :
2/21/2016
44
44

For the invoices in $: There are two journal entries: 1 in for the deposit in
the bank (the bank account is in ) and 1 in $:
2/21/2016
45
45

1 Line: Bank account

2 Line: No recourse account 4 line of the accounting code
2/21/2016
46
46

A journal entry by the other concepts of the receipt in the bank currency
2/21/2016
47
47

1 Line: Bank account. It is the deposited amount by the factor in our bank
account
2 Line: Reserve. Line 11 from the accounting code
3 Line: Financial cost. Line 8 from the accounting code
4 Line: VAT account. From the accounting code associated with the tax
5 Line: Interest. Line 7 from the accounting code
In this example, the dimension ACCT-001, has been fed thanks to the setup
from the definition of the bank:
2/21/2016
48
48

No recourse factoring Payment notification
The management of this screen is similar to the case of Recourse factoring.
The only difference is that now, for each invoice, we can indicate the
reserve amount that the factor reserved in case of unpaid.
The reserve amount is suggested in function to the Paid amount + Unpaid
amount:
2/21/2016
49
49

No recourse factoring Payment notification (Journal entries)
For the invoice in :
A journal for cancelling the doubt:
A journal for bringing to loss the reserve for this invoice
2/21/2016
50
50

No recourse factoring Payment notification (Journal entries)
For the invoice in $ and with a partial unpaid:
A journal for cancelling the doubt in $:
A journal for bringing to loss the reserve for this invoice
2/21/2016
51
51

No recourse factoring Payment notification (Matching)
In this step, there are two different kinds of matching:
1 between invoice accounts:
2/21/2016
52
52

No recourse factoring Payment notification (Matching)
2 between no recourse accounts
2/21/2016
53
53

No recourse factoring Summary
2/21/2016
54
54

To go further:
A factor with a bank that is valid for several sites of a company, then it is
possible to create a receipt with invoices from different sites.
The journal entries in the bank account will be always in the main site of the
company and the journal entry with the customer will be always in the Site
of the invoice.
So, it is mandatory to define all the needed reciprocal accounts in each
chart of accounts:
2/21/2016
55
55

BIC Optional
Prerequisites
Sage X3 SEPA Credit Transfer and Direct
Debit knowledge.
Lesson Objectives
Make BIC optional so that this information is
not anymore required for SEPA in 2016.
Ability to setup when BIC becomes optional

(Company level)
Discard BIC controls depending of this

setup
Update of the bank file definition
Redefine SDD amendment management

(bank change are not any more triggered
only by the BIC change)
2/21/2016
56
56
Financial Improvements BIC optional

Implementation dates and rules
The following rules are required
The obligation to provide the BIC ends on 1st February 2014 for national transactions
in euro within the same euro-country (SEPA SCT & SDD/national)
Member states may choose to extend the requirement to provide the BIC for national
transactions in EUR until 1st February 2016 (SEPA SCT & SDD/national)
The BIC is mandatory for SEPA cross-border transactions until 1st February 2016
(SEPA SCT & SDD/cross-border)
The BIC will continue to be mandatory for non SEPA cross-border transactions (out of
scope) .
Mandatory BIC
National SEPA
Transactions
Cross-Border SEPA
Transactions
NO
Possible member state
derogation
NO
Until the 1st February 2016
Non SEPA Transactions
YES
2/21/2016
57
57

Set up
New parameter : OPTBICSTR Optional BIC code start date
TC Common Data > SDD SDD management
Value at folder level : 02/01/2016. (February the 1st, 2016)
Definition level : Company
Linked with SDD activity code (only bank file changes for SCT payments)
2/21/2016
58
58

Set up
SEPA mandate import template improvement

New field NDAIMPFLG SMNDA or IBAN added to MDT template
This field is used for mandates update, and has to be populated with values below in case
of IBAN modification.
SMNDA (same mandate new debtor agent)
If the IBAN change corresponds to a bank change
IBAN
If the IBAN change doesnt correspond to a bank change
2/21/2016
59
59

Set up
Bank file definition (GESTFB)
Bank file SCT03
Header, line 46, <BIC> separator (in
<DbtAgt> separator)
<BIC> is optional
If the BIC is empty, <Othr><Id> is forced
to NOTPROVIDED and XML Tag
<BIC> is not returned
2/21/2016
60
60

Set up
Bank file SCT03
Detail, line 11, <BIC> separator (in
<CdtrAgt> separator)
<BIC> is optional
If the BIC is empty, the bloc <CdtrAgt>
and its content is not returned
2/21/2016
61
61

Set up
Bank file SDD02
Header, line 50, <BIC> separator (in <
CdtrAgt > separator)
<BIC> is optional
If the BIC is empty, <Othr><Id> is forced
to NOTPROVIDED, and XML Tag
<BIC> is not returned
2/21/2016
62
62

Set up
Bank file SDD02
Detail, line 44, <BIC> separator (in <
DbtrAgt > separator)
<BIC> is optional
If the BIC is empty, the bloc <CdtrAgt>
and its content is not returned
2/21/2016
63
63

New enhancements on Mandates
Starting date management

When the mandate creation date is superior or equal to OPTBICSTR, it is possible to
validate a mandate even if it has no BIC code.
This management is possible manually/individually (Validation button in GESMDT) or in
mass (VALMDT function)
Amendment management : IBAN only or SMNDA
For validated Mandate, when the mandate creation date is superior or equal to
OPTBICSTR , a new questions pops up : Does this IBAN change corresponds to a
bank change after a IBAN modification or a BIC change:
If the answer is No, it implies updating HISTOAMD as if it was an IBAN only
amendment
If the answer is Yes, it implies updating HISTOAMD as if it was an SMNDA
amendment.
2/21/2016
64
64

New controls
According to the users answer to the question Does this IBAN change corresponds
to a bank change , the following controls are done, when the mandate is saved.
Control 1 : Inconsistent BIC with a bank change
This message is returned if the user answers yes after an IBAN modification, whereas
the BIC hasnt changed.
As the BIC code is the same on IBAN1 & IBAN2, there is no BIC change when the IBAN
modification is done from IBAN1 to IBAN2. So the answer yes corresponding to
SMNDA is not possible.
Customer IBAN / BIC setup
IBAN1 : FR7620041000019876543219693 / BIC : SOGECAPP

IBAN3 : FR7620041000019876543219887 / BIC : SOGECAPR
Steps
Mandate validation
IBAN on mandate
BIC on Mandate
FR7620041000019876543219693
SOGECAPP
IBAN modification IBAN1 IBAN3

The user answer No to the question
Blocking message : BIC code changed : IBAN-only rule choice inconsistent
2/21/2016
65
65

New controls
Control 2.1 : BIC code changed : IBAN-only rule choice inconsistent
Case Triggered by an IBAN modification
This message is returned if the user answers No after an IBAN modification, whereas the
BIC has changed.
As the BIC code is different from IBAN1 to IBAN3, the BIC changes when the IBAN
modification is done from IBAN1 to IBAN3. So the answer No corresponding to IBAN only
rule is not possible.

IBAN3 : FR7620041000019876543219887 / BIC : SOGECAPR
Steps
Mandate validation
IBAN on mandate
BIC on Mandate
FR7620041000019876543219693
SOGECAPP

2/21/2016
66
66

New controls
Control 2.2 : BIC code changed : IBAN-only rule choice inconsistent
Case Triggered by a BIC update
This message is returned if the user answered No after an BIC update, whereas the BIC
has changed.
As the BIC code updated at customer level is different from the mandate ones, when the
mandate is updated it is not possible to answer No that corresponds to an IBAN only
rule.
Steps
Mandate validation
BIC Update at Customer level
IBAN1 : FR7620041000019876543219693 / BIC : SOGECAP

IBAN on mandate
BIC on Mandate
FR7620041000019876543219693
SOGECAPP
The user changes the BIC at customer level SOGECAPP SOGECAPR
Mandate update (BIC update on the mandate)

2/21/2016
67
67

New controls
Control 3 : An IBAN only amendment from IBAN XXX to IBAN YYY already exists
This message is returned if the user answers Yes after an IBAN modification, whereas an
IBAN only rule between those IBAN already exists in the amendment table.
As a consequence, since the only authorized possibility is an IBAN only amendment,
according to PAYNUM value,
either the FLDCOD=IBACOD record will be deleted (when PAYNUM= or PAYNUM<> &
[PYH]STA<8)
or a new FLDCOD=IBACOD record will be created (when PAYNUM<> & [PYH]STA>=8)
Steps
Mandate validation
BIC Update at Customer level
IBAN1 : FR7620041000019876543219693 / BIC : SOGECAP

IBAN on mandate
BIC on Mandate
FR7620041000019876543219693
SOGECAPP
The user changes the BIC at customer level SOGECAPP SOGECAPR
Mandate update (BIC update on the mandate)

2/21/2016
68
68

New controls
Control 4 : SMNDA amendment from IBAN XXX to IBAN YYY already exists
This message is returned if the user answers No after an IBAN modification, whereas an
SMNDA rule between those IBAN already exists in the amendment table.
As a consequence, since the only authorized possibility is an SMNDA amendment, according
to PAYNUM value,
either the FLDCOD=IBACOD & FLDCOD=BICCOD records will be deleted whatever is the
new value of BICCOD (when PAYNUM= or PAYNUM<> & [PYH]STA<8)
or FLDCOD=IBACOD & FLDCOD=BICCOD new records will be created with the new value
of BICCOD (when PAYNUM<> & [PYH]STA>=8)
Steps
Mandate validation

IBAN4 : FR7620041000019876543219111 / BIC : N/A (no BIC defined)
IBAN on mandate
FR7620041000019876543219693
The user answer Yes to the question
BIC on Mandate
SOGECAPP
An SMNDA rule is created in the amendment table (HISTOAMD)

FLDCOD=IBACOD (OLDVAL=IBAN1 & NEWVAL= IBAN4)
FLDCOD= BICCOD (OLDVAL = SOGECAPP & NEWVAL = )

Blocking message : SMNDA amendment from IBAN IBAN1 to IBAN IBAN4 already exists
2/21/2016
69
69

XML bank file management
Prerequisites
Knowledge of Sage X3 payments and
bank file
Lesson Objectives
Be able to generate international transfers
using XML format.
Use X3 delivered bank file, which respects the
standards below:
Standard ISO 20022, message Customer

Credit Transfer Initiation
XML format : pain.001.001.03
2/21/2016
70
70
Financial Improvements XML bank file management

Introduction
Why? Regulation and banks adopt XML language (ISO 20022 norm) for electronic
exchange between banks and companies/consumers. The first massive adoption was
the European SEPA regulation for -payment that uses this norm while including specific
rules.
What for? XML bank format was linked to SEPA regulation and included related controls
so that it was not possible to describe variable (XML) bank files without onboarding all
SEP rules, in particular currency only
Features Ability to describe non-SEPA XML bank files (direct debit/credit transfer)
Benefit Enable Sage, partners and customers to describe XML bank files (Credit
transfer, direct debit) using XML language
2/21/2016
71
71
Financial Improvements
XML bank file management - Set up
Set up Bank file format (GESTFB)
Bank file format : VIRINT03 - XML International Transfer
Variable format type
2/21/2016
72
72
Set up Payment transaction (GESTPY)
Payment transaction : FVIRV
New payment transaction setup with variable bank file format in FILREF6 field :
VIRINT03
2/21/2016
73
73
Set up Sequence number
definition (GESANM)
Sequence number definition : VARFB Message variable reference
Use in VIRINT03 bank format, XML
tag <MsgId>
2/21/2016
74
74
Set up Sequence number
assignment (GESTCA)
Sequence number assignment
Assignment of VARFB sequence
number in for AP/AR module
2/21/2016
75
75
XML bank file management Process description
Payment process
Payment flow: No modification of standard flows
2/21/2016
76
76
Magnetic file creation
Variable management within the generated file
Existing variables used for SEPA XML file, extended to non SEPA XML file:
[L]MSGID defined in XML Tag <MsgId>
o [L]MSGID returns the sequence number defined in (GESTCA) ,
Module AP/AR line 19 Variable file message reference

[L]NBPYH defined in XML Tag <NbOfTxs>
o [L]NBPYH returns the number of payments within the payment slip
/generated file.
[L]TOTCUR defined in XML Tag <CtrlSum>
o [L]TOTCUR returns the total amounts of payment within the payment
slip/ generated file, whatever the payment currency.

o Example : for a payment slip with 3 payments of 100 , 20GBP, 120
USD [L]TOTCUR will return 120 +20 +120 = 240
o The amount is up to 18 characters and it includes up to 5 characters
for the decimal
2/21/2016
77
77

Tables opened to generate the magnetic file:
2/21/2016
78
78
XML bank file management - Process description
Address management
Case 1: Payment with BP
The address information transmitted in the magnetic file, comes from the
address code defined on the payment but not from the default address of
the business partner.
Example:
Supplier SUP1, setup with 2 addresses
AD1 is defined as default address at supplier level
AD2 is defined on the payment.
The address information transmitted in the magnetic file comes
from the address AD2, defined at payment level. (those information

are read in BPADDRESS table, using BPATYP Entity type =1
Business Partner)
2/21/2016
79
79
Address management
Case 2: Payment without BP
The address information transmitted in the magnetic file, comes from the
address code defined on the payment but not from the default address of
the account.
Example:
Account 437100, setup with 2 addresses
AD1 is defined by default at account level
AD2 is defined on the payment.
The address information transmitted in the magnetic file comes
from the address AD2, defined at payment level. (those information

are read in BPADDRESS table, using BPATYP Entity type = 5
Accounts)
2/21/2016
80
80
Contact management
It only concerns payment with BP, as there is no contact information at
accounts level.
The contact information transmitted in the magnetic file comes from the
default contact of the supplier (or customer)

On the supplier / customer , the default contact is defined in the
default contact field : CNTNAM

Contact information are read in the table CONTACT
2/21/2016
81
81

Variable information management
The <InstdAmnt> XML tag is required to contain the payment currency
AS the payment slip is multi currency, the currency has to be defined
dynamically.
Example in the magnetic file :
2/21/2016
82
82
Bank file format setup:
Within the start separator, when the specified character string $1$ is entered, it is
replaced by the information indicated & valuated in the formula field right after
[F:PYH]CUR. This $1$ character string is hardcoded and it is always considered as
to be replaced by the formula valuated information.
2/21/2016
83
83
Unauthorized characters management
Some particular characters are not authorized
(e.g. with !"#$%&*;<>=@[]\_^`{}|~).

As a result, when Sage X3 creates a variable file, if such a character exists within
a field, it is automatically removed.

As a result, the address email provided from the contact information are returned
in the magnetic file without @
2/21/2016
84
84

Miscellaneous finance/compliancy improvements
Lesson Objectives:
Understand the miscellaneous
finance/compliancy improvements
SWISS addon is now
incorporated
VAT function
2/21/2016
85
85

Miscellaneous finance/compliancy Swiss addon
Why?: Re-structuring of Swiss payment life cycle and bank ID
management in Sage X3 core in order to replace local add-on function
and modules.
What for?: Reduce implementation time and improved maintainability of
the Swiss legislation.
Features: Master data settings and improved payment life cycle
Benefits:
Meet market requirements
Improved handling
Removal of local add-on solutions
2/21/2016
86
86

Overview
Essential payment functions of the
Swiss legislation have been
available only in a so-called Swiss
legal add-on in the past.
To reduce implementation time and
maintenance cost, these functions
will be transferred into the core
application.
Important note:
The objective of this lesson is primarily a
description of the essential settings and
parameters related to Swiss ISR
payments.
It will not describe the payment process
itself.
The transfer of the functions of the

Swiss add-on is phased into steps.
This session describes step 1 done
for Sage X3 Update 9.
2/21/2016
87
87

Glossary
ISR - Inpayment Slip with Reference number
Swiss domestic or internal business payment processes are usually
based on (OCR) codes named ISR. ISR are processed by either the
Swiss Postal Bank (Postfinance) or Swiss commercial banks.
An ISR code line is a payment reference consisting of several digits
that provide information about the supplier, invoice amount, invoice
number, etc.
2/21/2016
88
88

Glossary
DTA DatenTrgerAustausch
DTA (Data carrier exchange) is an electronic payment method
adopted by Swiss banks to settle payments electronically using a
standardized payment format.
DTA is coordinated by the Swiss Interbank Clearing (SIC).
EZAG - Elektronischer Zahlungsauftrag
EZAG (Electronic payment order) is the electronic payment method of
the Swiss Postal bank (PostFinance). EZAG requires a bank
account the Swiss Postal bank.
2/21/2016
89
89

Prerequisites and parameters
Activity codes
KSW Swiss localization
Activity KSW Swiss localization has to be set to Active in order to
work with functions dedicated to the Swiss legislation).
Parameters
SWIPAYBVR
Swiss checks in payments
A new parameter in chapter Localization (LOC) / group Switzerland

(SWI) controls at company level if a payment, that is present in the
payment process, is a Swiss payment or not.
By default this parameter is set to No no checks will be performed.
2/21/2016
90
90

Parameters (continued)
BVRBPCFROM
Swiss ISR customer start
A parameter in chapter Localization (LOC) / group Switzerland (SWI)

that defines the starting position of customer number in the ISR
reference number.
By default this parameter is set to 11.
BVRBPCTO
Swiss ISR customer end

that defines the end position of customer number in the ISR reference
number.
.
2/21/2016
91
91

BVRDATFROM
Swiss ISR date start

that defines the starting position of date information in the ISR
reference number.
BVRDATTO
Swiss ISR date end

that defines the end position of date information in the ISR reference
number.
.
2/21/2016
92
92

BVRIDFROM
Swiss ISR identifier start

that defines the starting position of the ISR identifier within the ISR
reference number. By default this parameter is set to 1.
BVRIDTO
Swiss ISR identifier end

that defines the end position of the ISR identifier within the ISR
reference number.
.
2/21/2016
93
93

BVRINVFROM
Swiss ISR invoice start

that defines the starting position of the invoice number within the ISR
BVRINVTO
Swiss ISR invoice end

that defines the end position of the invoice number within the ISR
.
2/21/2016
94
94

BVRNUMERIC
Swiss DTA/EZAG numeric

that defines, whether the DTA/EZAG sequence number is numeric
(Yes) or alphanumeric (No)? By default this parameter is set to Yes.
SWIPAYBAN
Swiss bank for charges

that defines a default bank.
Note: Parameter SWIPAYBAN has to be populated with a valid Swiss
bank code in order to process payments in the Swiss payment life
cycle. Naturally this parameter is empty by default and a valid bank
code has to be entered by the user when implementing the Swiss
legislation
.
2/21/2016
95
95

Parameters of the ISR import
BVRDEP
Early discount on customer
A parameter in chapter Localization (LOC) / group Switzerland (SWI).

This parameter defines if the total amount includes discount (Yes) or
excludes discount (No) on the customer account. If the parameter is
set to No, it implies that the discount will be on bank account side. By
default this parameter is set to No.
DEVAMT
Max. amt. deviation ISR import

It defines a threshold deviation amount in company currency in case
of a deviation between the amount of payment and the invoice
amount. By default this parameter is set to 0.
.
2/21/2016
96
96

Parameters of the ISR import
DEVPRC
Max. % deviation ISR import

It defines a threshold deviation in percentage in case of a deviation
between the payment amount and the invoice amount. Default value
of the parameter is 1.
TOLDEP
Discount tolerance

It defines a number of additional days to take into account the
discounts granted to customers by extending the duration of the
discount period. Default value of the parameter is 0.
2/21/2016
97
97

Related payment methods
Swiss bank payment methods
DT826, DT827, DT830, DT836,
DT837
Swiss postal bank payments
OPA22, OPA24, OPA27,
OPA28, OPA34, OPA37
The payments methods are
predefined by their type (e.g.
826) and the general Swiss
payment type they belong to.
EZAG is used by the Swiss
Postal Bank (Postfinance), DTA.
2/21/2016
98
98

Related payment methods
For payment methods flagged as DTA or EZAG the type field is used to
control the payment transaction type within the corresponding file format.
This value is evaluated when writing the transactions to the bank file:
2/21/2016
99
99

Related payment entry types
Swiss bank payment entry types
SWDTA - DTA for Suppliers
Swiss postal bank payments
SWOPA OPAE for Suppliers
Payment methods are assigned to

payment entry types according to
their Swiss payment type. There
is a cross check implemented that
indicates inconsistencies between
payment types and payment
method of a payment entry type.
:
2/21/2016
100
100

Related payment entry types
New fields for Swiss EZAG and
DTA payment entry types have
been added in the Extra fields
section of the payment entry type
definition function. See slide
Payment entry screen for details.
These extra fields are optional
fields, they are not mandatory for
the payment process.
2/21/2016
101
101

Bank accounts
A new field for the ISR
participant number (ISR
customer no.) has been added
to the bank screen.
The screen comprises of
additional fields for issuer
identification.
2/21/2016
102
102

Business partner bank ID (BID)
A new field for the ISR participant number (ISR customer no.) has been
added to the business partner Bank ID tab. This number is used for
transactions concerning the Swiss Postal Bank (Postfinance).
The bank ID number consists of the clearing number (the numeric Swiss
national BIC code) and the bank account number.
2/21/2016
103
103

Swiss local bank ID screen
Update 9 provides a local bank ID
screen for Swiss bank IDs.
The screen is adapted to the
requirements of our Swiss
customers. It allows to enter IBAN
codes, ISR customer numbers and
it reduces the potential conflicts in
multi legislation environments.
The IBAN code is the preferred
issuer identification in payment
files.
2/21/2016
104
104

Related sequence numbers
A new sequence numbers related
to Swiss payments have been
introduced.
2/21/2016
105
105

Payment entry screen
New fields for additional payment
information have been added to the
payment entry screen.
The fields are available only for
supplier payments based on DTA
and EZAG payment methods /
payment entry types.
2/21/2016
106
106

Manual remittance entry
The creation of Swiss DTA / EZAG files is started in the GESFRM function. The
selected remittance must be of a Swiss payment type. The payment file is
stored in directory BQE on the server. After starting the file creation, it is
possible to enter an execution date.
Important note: Swiss payment files are defined in the respective code.
Therefore, it is not possible to modify the payment file structure in GESFTB
function.
2/21/2016
107
107

ISR import functions
Sage X3 enables Swiss users to
import Swiss ISR payment files and
match these payments with the
corresponding invoices.
Two types of files exist.
The ISR file import functions

SWIIMPBVR and GESIMPBVR are
located under:
AP/AR accounting > Reconciliation >
Swiss legislation
2/21/2016
108
108

ISR import functions
Function GESIMPBVR supports the Swiss Sage X3 user in matching ISR

payments with the corresponding invoices. Imported ISR payments can have
different states.
2/21/2016
109
109

Swiss bank sort code import
The new import template ABNSWI
supports our Swiss customers in the
update of Swiss bank sort code (clearing
numbers).
The clearing number file (BC Bank Master)
is available for download from the Six
Interbank Clearing website.
Note: The data structure of Swiss clearing
numbers in Sage X3 has been changed for
Update 9. Existing clearing numbers will
not be migrated from older versions.
Please reimport the latest clearing
numbers directory from the Six Interbank
website.
2/21/2016
110
110

Swiss postal code import

The new import template POSCODSWI
supports our Swiss customers in the
regular update of Swiss postal codes.
2/21/2016
111
111

Miscellaneous finance/compliancy VAT function
Why?: When installing a country, it should require you to activate the
relevant legislation only, with the associated tax process if this process
exists. If this specific process doesnt exist, it should be possible to
activate a generic one, not liked to a legislation.
What for?: Ability to activate relevant tax declaration process depending
on legislation.
Features: Generic declaration process that is independent from a
legislation so that it may be activated for countries that need it (Australia,
South Africa) without requiring additional legislation.
Benefits: Ease installation.
2/21/2016
112
112

Overview
This development is linked to SAM requirement #105609
The aim of this requirement is to provide a generic VAT declaration for
whatever legislation that needs it (New Zealand, South Africa, ).
This new VAT declaration works the very same way as the French
declaration function without needing to activate the KFR activity code.
However, since such a function is not always required (standard
legislations already have their own VAT declaration), this new
functionality is linked to a new activity code, DCLOT VAT for other
legislations.
2/21/2016
113
113

Prerequisites
DCL activity code needs to be set to Yes since it drives all the master
switching actions/processes on which VAT declarations are based.
DCLOT activity code needs to be set to Yes.
2/21/2016
114
114

Setup
New activity code, DCLOT,VAT for other legislations
Financials module
Functional type
Dependency = None
Note: New control in GESADS so that if DCL activity code is set to

No, then DCLOT is also forced to No.
2/21/2016
115
115

Setup
New parameter, OTHVAT VAT decl. other legislations
In chapter CPT, VAT group
Linked to DCLOT activity code
Company level definition
Set to No for all legislations but AUS and ZAF in update 9 reference
folder
New function, DCLVATOTH VAT declaration

Linked to DCLOT activity code
Available in Declarations/Tax management/Others
2/21/2016
116
116

Setup
New batch task, DCLVATOTH,VAT declaration
Based upon DCLVATBAT function
Associated to OTH legislation
New activity code, OTHDC,Decl. other legislations

Financials module
Functional type
Dependency = Formula (and Formula=ESD or DCLOT)
Note: activity code created for technical purpose; associated to MOTH

function that is menu function type)
2/21/2016
117
117

Process description
DCLVATOTH function can only be run on a company for which OTHVAT
parameter is set to Yes.
When running it, if OTHVAT is set to No for the current company, the standard
message Function not implemented for this company is displayed.
For reports, the existing ones (DCLVATDEB1/DCLVATDEB2/
DCLVATENC1/DCLVATENC2) are also used in this function.
Other VAT standard parameters (FILVATDEF and VATRPTBAT and VATRPTDIR)
are also used when the DCLVATOTH declaration is run in batch mode and when a
report needs to be printed.
2/21/2016
118
118

Miscellaneous finance/compliancy improvements
Lesson Objectives:
Learn about new functionality in
Sage X3 Update 9 including:
Fixed Assets improvements:
Fixed Assets module is transformed

into the new Sage X3 web objects,
including setup buildings and
locations and Physical management,
etc.
Fixed Assets inventory process is

now a new mobile app called
Sage X3 Physical Assets
2/21/2016
119
119
Fixed Assets
Physical assets management
The sub-module for Physical assets management in Fixed Assets has been
transformed using the latest Sage X3 technology.
You will learn about the new features and modifications linked to these
improvements.
Note: This training does not present a complete description of the module
already available in the previous versions of Sage X3.
The inventory process previously available in Fixed assets has been removed
and replaced by a new mobile app.
120
2/21/2016
120
Fixed Assets
The highlighted menus and associated functionalities are no longer available in
Update 9.0.0
121
2/21/2016
121
Fixed Assets
In Common data, the Locations function has been renamed and reviewed:
New menu:
122
2/21/2016
122
Fixed Assets
Misc. table 604 Building has been removed and replaced by the Builidngs
function in Common data
Misc. table 605 Floor is no longer used for controls
123
2/21/2016
123
Fixed Assets
Set up Buildings
Buildings are now full Sage X3 web objects:
A query displays the list of buildings
CRUD actions are available
Secondary queries can be displayed using Actions
124
2/21/2016
124
Fixed Assets
Set up Buildings
In creation mode:
Mandatory fields are building code + description
Geolocation can be entered as address or coordinates
125
2/21/2016
125
Fixed Assets
Set up Buildings
In display mode:
A Google map is displayed
A picture is also available (if uploaded at creation/update)
126
2/21/2016
126
Fixed Assets
Set up Locations
Locations are now full Sage X3 web objects:
A query displays the list of locations
Secondary queries can be displayed
127
2/21/2016
127
Fixed Assets
Set up Locations
Geolocation data for the Location is defaulted from the building but can be
modified
128
2/21/2016
128
Fixed Assets
Set up Locations
Locaton sub-queries
From the buttons available in the
Locations right panel, it is possible to list :
The physical elements / assets linked to
the location
The physical elements / assets not yet
counted (FA inventory)
129
2/21/2016
129
Fixed Assets
Set up Locations
Filters are applied to the Physical element query
130
2/21/2016
130
Fixed Assets
Process description CRUD
Physical elements are now full Sage X3 web objects:
A query displays the list of physical elements
Predefined filters are available
131
2/21/2016
131
Fixed Assets
In creation mode:
Description and location are mandatory
Site is inherited from the location
A geolocation tab has been added
(defaulted with location)
The other fields were already available
in the previous versions
132
2/21/2016
132
Fixed Assets
From the display mode, links and actions are available from the Right panel.
It is possible to:
Acces the event log
Manage the disposal of an item
Transfer an item
Cancel the transfer
133
2/21/2016
133
Fixed Assets
Process description Banks
Events log:
A query displays all the events associated to a physical element
134
2/21/2016
134
Fixed Assets
Process description Disposal
Dispose an item by entering:
Issue date
Disposal reason
A picture can be added to clarify the
disposal reason
135
2/21/2016
135
Fixed Assets
A disposal can be cancelled. The movement will be set pending if linked to a
fixed asset.
136
2/21/2016
136
Fixed Assets
The disposal is validated from the fixed asset by the Dispose action:
137
2/21/2016
137
Fixed Assets
The disposal cancellation can be stopped (removed from pending movements)
prior to the actual disposal from the asset.
138
2/21/2016
138
Fixed Assets
Process description Transfer
Action - Transfer : The fields required are the transfer date, a reason code, and
a new location (destination).
139
2/21/2016
139
Fixed Assets
If the financial site associated to the new location is different from the original
site, the movement will be put on hold / pending as it was in the previous
version of Sage X3.
140
2/21/2016
140
Fixed Assets
A message is displayed on item with pending movements.
141
2/21/2016
141
Fixed Assets
The transfer is validated from the Fixed asset by the Transfer action:
142
2/21/2016
142
Fixed Assets
To cancel a transfer, use the button
A screen displays the items ID:
Save to validate the transfer cancellation
143
2/21/2016
143
Fixed Assets
Process description Mass transfer & issue
The transfer and disposal / issue can be executed for a group of physical
elements.
The rules and controls will be the same as the ones applying to the unit actions.
144
2/21/2016
144
Fixed Assets
The selection is made by using the criteria block + the Extended selection tab
(optional)
145
2/21/2016
145
Fixed Assets
The target location site is entered on the Main tab. The financial site is inherited
from the location.
146
2/21/2016
146
Fixed Assets
New Physical assets app
Lesson Objectives
Understand the new Physical assets app
Overview and prerequisites
Set up
Process description:
Main screen
Locations
Physical elements
Transfer
Disposal
2/21/2016
147
147
Fixed Assets
Overview and prerequisites
The Fixed assets inventory process
previously available in Sage X3 has
been removed and replaced by a new
mobile app: Sage X3 Physical Assets
The barcode scanner Symbol
PDT3100 and Windows mobile
devices running Sage Inventory Tools
(SIT) are no longer supported in
Update 9.0.0
2/21/2016
148
148
Fixed Assets
Setup
Install and set up the mobile app Sage X3
Physical Assets.
It requires the installation of an APK file on a
compatible mobile device (phone or tablet).
The installation can also be made for demo
purposes on an Android virtual device (using
AVD manager).
A connection to a Sage X3 server has to be
defined:
For the initial connection setup Full
documentation availabe from the Sage X3
Online help center > Technical help >
Implementation > V7 development platform >
8-UI Definition > 8-UI Mobile pages
2/21/2016
149
149
Fixed Assets
Set up
Enter:
A connection name (desciption)
A Sage X3 web server URL (by
giving the IP address)
The corresponding Syracuse server
port
A valid user and password
2/21/2016
150
150
Fixed Assets
Set up
After the connection has been defined,
it appears on the home page.
More than one connection can be
defined to different servers.
2/21/2016
151
151
Fixed Assets
Set up
Use the Add application icon to install
the app
2/21/2016
152
152
Fixed Assets
Set up
Select the endpoint(s) for which the
app will be available
2/21/2016
153
153
Fixed Assets
Set up
After the endpoints have been added,
the application icon is available:
Use
To add other apps
2/21/2016
154
154
Fixed Assets
Set up
Options can be defined from the app
home page
Use barcode reader: You can either

use a bluetooth scanner or a camera
scanner (see hereafter)
Use network location: To enter the
geoloc coordinates on an asset or a
location (enable GPS button)
2/21/2016
155
155
Fixed Assets
Set up
Show location at scan: Automatically brings the user to the location detail
screen when a scan is performed.
Picture size: choose depending on upload capabilities and speed (original /
large / medium / small - by default).
Camera scanner: You can use the camera of your device and a compatible
app (Zxing or QR droid) to read barcodes
2/21/2016
156
156
Fixed Assets
Process description
From the main screen, it is possible to:
Create directly a location or a physical asset
View the list of locations or physical asset
through a query
2/21/2016
157
157
Fixed Assets
Process description Main screen
To return to the main screen ,use the Physical
assets button in the Left panel
2/21/2016
158
158
Fixed Assets
Process description Locations
Create locations screen
The user must enter:
A description
A location code
A building (incorporating this location)
A set of optional fields (necessary for the
Inventory process) can also be defined.
2/21/2016
159
159
Fixed Assets
View locations screen
A query is displayed with the main fields to
identify the location
Filter & sort can be added
2/21/2016
160
160
Fixed Assets
View location
Displays all the characteristics of the
location
Displays the number of assets associated to
this location and the number of assets
already counted
Buttons allow to create a new physical
asset for the location or list the assets of the
location
2/21/2016
161
161
Fixed Assets
The location selected is identified at the top of
the screen as the current location
A picture can be associated to the location
2/21/2016
162
162
Fixed Assets
Actions and links are also available in the
Right panel
From the top menu access to create, update

and delete
2/21/2016
163
163
Fixed Assets
Process description Physical elements
Create physical elements screen
The user must enter:
A description and a location code
The reference can be attributed by an
automatic sequence number
A set of optional fields (necessary for the
Inventory process) can also be defined.
2/21/2016
164
164
Fixed Assets
View physical elements
A query is displayed with the main fields to
identify the asset
2/21/2016
165
165
Fixed Assets
Display physical elements
Displays all the characteristics of the asset
A Register button allows you to update the
fields
Note the date and time in the Count block
2/21/2016
166
166
Fixed Assets
If a physical element is scanned (or selected)
and if the value of the field location is not
equal to the current location then the
header will be displayed with an orange
background to alert on the discrepancy.
It will be possible to use the Actions menu to
record a transfer or a disposal.
2/21/2016
167
167
Fixed Assets
From the Physical elements screen, the
following actions are available:
Register (mark the asset as counted)
Cancel the register
Dispose
Transfer (the current location will be
defaulted to the destination location)
2/21/2016
168
168
Fixed Assets
The transfer will result in the direct transfer if
the physical element is not linked to an asset
or if linked + the financial site is unchanged.
For the other transfers, the movement will be
set pending and will be validated by the actual
transfer of the Fixed Asset.
2/21/2016
169
169
Fixed Assets
The disposal will result in the direct disposal if
the physical element is not linked to a Fixed
asset.
If linked to a Fixed asset, the movement will
be set pending and will be validated by the
actual disposal of the Fixed Asset.
170
2/21/2016
170
Fixed Assets
When disposing of a physical element ,a picture can be added to justify the
reason
171
2/21/2016
171
Course Conclusion
In this course, you have learned:
About Factoring management, including set up and using factor types
About SEPA improvements and BIC option
About XML bank file management
About Miscellaneous finance/compliancy improvements, including Swill addon and VAT
About Fixed assets improvements and new Sage X3 Physical assets app
2/21/2016
172
172
Visit Sage University for your training needs.

www.SageU.com
2016 Sage Software, Inc. All rights reserved. Sage, the Sage logos, and the Sage product and
service names mentioned herein are registered trademarks or trademarks of Sage Software, Inc., or its
affiliated entities. All other trademarks are the property of their respective owners.

X3 WhatsNew U9 FinanceCompliancy NFR

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

X3 WhatsNew U9 FinanceCompliancy NFR

Uploaded by

Copyright:

Available Formats

Sage X3

Whats New in Update 9:

Certified course curriculum

Whats New in Update 9:

Lesson: Factoring management

Lesson: SEPA improvements - BIC optional

Lesson: XML bank file management

Lesson: Miscellaneous finance/compliance improvements

Lesson: Fixed assets improvements

Lesson: New physical assets app

2015 Sage Software, Inc. All rights reserved.

Factoring management set up and

XML bank file management

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

Recourse factoring: The client keeps the risk

No recourse factoring: The factor assumes the risk

The current management is maintained as a third type of factoring called

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

The contract with the factor indicates a

On the due date, the customer pays the

On the due date, there is an unpaid

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

Identifiers can be taken

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

FCTN (payment notification

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

2015 Sage Software, Inc. All rights reserved.

Finance and compliancy

ES20 / Site: ES021

SPFACTREC: Recourse type

In both cases, use an invoice in EUR and an invoice in USD