PJC501-Project and Job Costing - Student Booklet

TRAINING PJC501 – Project and Job Costing – Student’s booklet -1-

TRAINING PJC501 – Project and Job Costing – Student’s booklet - 10 -
Services, the term is rather unclear and can cover a large range of activities.
With its wide functional coverage the module can be used in many contexts as soon as
services activities are concerned.
The main targets are all the companies that manage projects, as software integrators,
consulting and engineering societies. But also in other activities as construction site
management (public works, finishing works, …), and special machines manufacturing,
for example.
We said that the module was able to cover a wide range of activities, widely adaptable it
can also be used in other activities rental & maintenance societies.
Yellow : Shared function

Grey : X3 standard function
White : PJC function
Services, purchasing and invoicing flows are linked to the project and follow up using the
situation.
R&D Project Project type
Detail type Engineering Design
SR type Purchase
Analyse SR Training SR Analyse SR Training SR
or purchase flow Request
Customer
Project type Project
Software
Detail type Engineering
Installation
SR type Analyse SR Training SR

Purchase
Invoice Analyse SR Training SR
Installation
Invoice
Purchase
or purchase flow Order SR Order
Recurrent contract is an option

Recurrent contract allows us to generate periodically Service Request or invoicing or

both.
Contract type Rent
Doc managed Invoicing
Contract type Maintenance
Preventive Reparation
Doc managed Invoicing SR SR (manually
(generated) linked)
SR type Analyse
At the
Response type On site
office
Operation Code Time Travel Time
SR type Preventive
Non
Response type Billable
Billable
Operation Code Time Travel Spare Time Travel Spare

Concept
The Requests of Services (= job to do, assignment) and the service response (=
tracking of what have been done) are the tracking function of the PJC module.
It is used on Project, Contract or on direct entry mode (not link to an other
function)
It allows us to track time, stocks movements, travel expenses, … (depends on
the setup)
The Service Response process is defined by service request which we could call
"mission orders". On theses SR we can input several responses. The responses allows
to record the effective job done.
With this part you have a full X3 integrated activities process.

A Service request can be generated by a project detail using a situation or by a contract

or a contract line or directly entered.
The requirement defines what we expected to track on the SR using operation code and
quantity.
Three ways are available to track on a SR :

- Enter a Service response
- Enter a periodic activity report without approval
- Enter a periodic activity report with approval
When you have a periodic activity report and before to validate it, you don’t see it as a
response.
To use SR and Response you need to setup all the combination you want to manage
using SR types, Response type and Operation code.
You can setup several process and control that you use the right combination on each
flow.
The intervention process ease the management of traceability of the realized operation.
Allows to be as close to the customer's operational flow.
It does not only manage time but also articles, for purchase, inventory or sales orders.
An automatic generations of documents can be linked to the response.
We can manage several type of SR or interventions type, allowing several input

processes
The details of an response are entered in the form of operational codes. These ones
allow the identification of the achieved and according to the settings, the type of data to
be entered.
In this example it’s a setup to manage a maintenance process and to generate all X3
document needs link to the responses.
In this second example you will see a possibility to manage consulting activity and to
generate X3 document corresponding.
The setup you will do will define the process to manage.
This flow gives the right order to setup the Service Request part.
It’s a normal miscellaneous table you need to setup a code, a description and a short
description.
For example :
- SR type for project using :
Analyse
Installation
Training
- SR type for recurrent contract using :
Corrective or Reparation
Preventive
Tab General
- Report : A report code to print if you want to use a specific report code for this SR
type
- Mandatory printing : block the SR closure if not printed
- Access code : Normal access code to control access per SR type
- Operation code restriction : Used in a project mode  If check allows to track only on
operation code planed in the project detail link to the SR
- Credit control : Use the normal customer credit control when you create a SR
- SR update : Which event update the SR when you enter a response? The last
response entered or the response with the latest date…
- Foot : you use the last calculated end date of the response to update the SR
- Last : you use the last response entered to update the SR
- Date : you use the last date entered in the response header to update the SR
- SR installed base control : Do you want to control the installed base entered in this
SR type?
- Preload response tab : The response tab in the SR shows the responses already
entered. For performance you can decide not to preload it automatically.
Tab Contract Revision / Message

We can control which type of contract can be imputed to the SR.
We are also able to define some workflow trigger associated with a workflow button…
- Revision types autorized : if control is ticked you can link this SR type only with the
contract type you’ve populated in the bottom list.
- Mail button : you can use a message button in the SR screen to send some Workflow.
You need to list the workflow code there and in the workflow header condition to
control that GBIDC3 is equal to your workflow code.
Tab Service Response

Routing, Response type in direct input or in report activities, can be controled per SR
type.
- Routing autorized : if control is ticked you can use on this SR type only the
« requirement template » entered in the bottom list
- Response type autorized : if control is ticked you can use on this SR type only the
«response type » entered in the bottom list, when you create a direct service
response
- Response type default value WS: which response type is created when you track time
on this SR type using the Web TimeSheet
- Resp type autorized in Rep Act : if control is ticked you can use on this SR type only
the «response type » entered in the bottom list, when you create a service response
using a periodic report activity
Tab Stages
For a SR type we can choose which stages, we will be able to input to it.
We can define which are initial stages, default stage or closing stages.
- Autorized stage : if control is ticked you can only use the stages in the bottom list.
- Initial : if there is no response on the SR allows to use stage if YES
- Close : allows to close the SR at this stage if YES
- Def interv. Type : define the default response type at this stage for this SR type.
Tab Other
It’s the same for questionnaires and queues
Autorized queue: if control is ticked you can only use the queue/line/skill group in the
bottom list.
Autorized questionnaire: if control is ticked you can only use the questionnaire in the
bottom list.
Tab Tracking
The last tab on SR type is to choose what kind of event we want to track in the SR
tracking. The tracking is done with the operator and the previous value tracked.
This tracking is on the SR screen. Menu Option/tracking
Tab Commitment
Used to setup the commitment generation per SR type. The commitment is generated
from the SR requirement.
- Controls : if check you will generate commitment from this SR type when you will
create the SR
- Item by default : if in the requirementthere is no product code, the process will use this
one to find the account code
- Accounting code ind : define the line to use in the accouting code to find the account
number.
Tab Reordering
Used to setup the generation of needs from a SR to be considered by the MRP process
or reodering, The need come from the SR requirement.
- Controls : if check you will generate commitment from this SR type when you will
create the SR
For example :
- Response type used on all SR type :
On site
At the office
IP, CR, FI, CL : SR stages

INT (internal task), FUP (follow up): S. Response Types
Tab General
- Report : A report code to print if you want to use a specific report code for this
Response type
- Mandatory printing : block the response validation if not printed
- Access code : Normal access code to control access per Response type
Tab stages
The stage tab give availability to control stage before and stage after the response.
It’s to manage response type depending on SR progress
- Autorized preliminary stage : if control is ticked you can only use the Response type
when the SR stages is in the bottom list.
- Autorized following stages : if control is ticked you can only update the SR stages
from the response using a stage in the bottom list.
Tab operations
Operation screen, it’s to control operation code you’re able to use depending on those
already captured.
- Control code : define a group of operation code

- Operation code : define the operation code allowed for a control code
Tab sequences
Sequence tab, allows us to have an automatic data capture with a sequence of operation
code. The operation code of the second line is automatically entered depending on the
first entered.
- Triggers : operation code of the actual response line

- Released : default operation code of the next line
Tab others
You can also make control on operators or questionnaires you can input on the response
type.
- Autorized operator : if control is ticked you can only use the users in the bottom list.
TRAINING PJC501 – Project and Job Costing – Student’s booklet - ‹#› -
- Autorized questionnaire: if control is ticked you can only use the questionnaire in the
bottom list.
For example :
- Operation code for project using :
Travel (just allowed for “On site” response
Time
Spare (for product maintenance management)
It needs to be enable to be used
Tab General
- Type of operation : 3 types are available (product, service, resource) depending on

what you want to track (quantity fro product, time for person, time for non human
resource)
- Category : Statistical data
- Nature : Define which value you want to manage on response line using this
operation code (sales, purchase, both)
- Options : Contextual option depending on the operation type (ie : “SR supervisor” to
allow just user that are SR supervisor to use it)
- Family : Statistical data
- Commitments : Enable commitment management for this operation code if the SR
type also enable it.
- Reordering : Enable needs generation for this operation code if the SR type also
enable it.
- Method : Define how to input time (date + duration / date + start hour + end hour…)
- Inter type : List the response type for which setup is done (to use an operation code
you need to define how it work with Response type in an other setup function)
Using the setup of operation per response type you can manage the valuation, the fields
to populate or the documents to generate.
Exemple : 1st response. generate a quote, once accepted the duplication of the 1st
response generates a purchase flow , once terminated will call an response of on-site
installation which one will update the inventory and invoicing.  a Whole flow for a same
mission order
BILL = Billable NON-BILL = non billable EXPENS = Expenses
In an other example we can just manage time on SR. Generic time or Time for project
management or development.
It can generate automatically journal entry, invoice for response (if you don’t invoice from
a project).
This depend on the setup of operation per response type.

Tab initialization
The first screen define default values It also let us define if in an activity report the report
will need approvals or not
Default value : product code mandatory if ope code type = service. For example the
document generation will need a product code
- Negative quantity : Allows to track negative quantity if ticked

- Positive quantity : Allows to track positive quantity if ticked
- Qty = 0 : Allows to track nil quantity if ticked
- Mandatory code : To create a response of this type you need to enter this operation
code
- Approvals / implicit project : If the response is entered on an activity report, if ticked
you don’t need approval from project manager
- Approvals / implicit hierarchic :If the response is entered on an activity report, if ticked
you don’t need approval from hierarchic manager
- Default value : Define default values, if the default value is on a category that will
control that values entered correspond to this category.
Tab input
The input tab allows us to choose which fields are needed in the response for this
operation.
Be careful to be coherent with the entry transaction.
- Modification : tick the fields you want to be able to enter. In the same response you
can want to enter different fields depending on what you are tracking (time, product…)
Tab Transaction
Next tab defines what documents will be generate by this response. We can have
generation of several documents. The activation is by the response validation or the SR
closing. You can setup one line per document to generate.
- Event : Do you want to generate document when you validate the response or when
you close the request.
- Movement : Which document you want to generate from the validation code list
- Active : If no, there is no document generation
- Origin site : Which site will be used in the document generation
- Param 1 : Depend on validation code and type of document generated
- Param 2 : Depend on validation code and type of document generated
- Origin grouping : Where the grouping method of document generated come from
- Changeable : can we update data in the pre-validation table before to generated
definitive document
- Postponed generation : if ticked you need to use the “document generation” function
to generate your document, if not it’s automatic.
- Released expression : You can use a formula to control when you want or not
generate this document
Tab valuation
The valuation tab let us fix rules on how sale price, purchase price and cost price are
calculate
The cost price can use product mode, operator, category or price search.
The price search will be done in the input order.
- Cost price / Price origin : Define how to valorize the cost of the response line (from
user, user category, purchase price, sales price or using the valuation method of the
facility product)
- Qty origin : qty to use with the cost price (day, hour, qty of the line or default qty of the
operation code)
- Sales price origin & Purchase price origin : define where to look for the price, the
process will search on the first item, if there is no value it will search on the second….
You can use the standard prices (it will do the standard search using the normal setup)
or specific price list link to a contract or a project, or specific price from a cover (allows
to define price/discount per operation code and can be used on a contract or a SR to
define operation included or not in the contract)
Tab miscellaneous
Can be used in specific development to create interface between time tracked and salary
system.
The Rate used to valorize a response is defined in the linked “operation code per response type”
USERS CATEGORY
Normal miscellaneous table to manage all the categories of user you want to use in the folder.
USERS
Tab Calendar
- Manage the user working days and a number of hour per day, they can be used to convert
days in hour depending on the setup (GESOTI)
It Can be used to control the time tracking
Tab Services Activities
- Category : User category used to manage cost for time tracking
- Technical site : default site for user in services
- Hierarchic sup : user who approve time tracked the actual user if setup don’t give implicit
hierarchic approval (GESOTI)
- Authorization : What this user can do in the services module
- Salary interface : Informative link to your salary system
USERS CATEGORY COST
Define a daily/hourly rate per user category and per site
- Site : if blank means for all sites
- Start / End : Range date where the rate will be applied
- Cost : rate per unit
- Unit : Time unit for the rate
OPERATORS COST
Define a daily/ hourly rate per user using the same fields than cost per category
The Rate used to valorize a response is defined in the linked “operation code per response
type”
RESOURCE CATEGORY
Normal miscellaneous table to manage all the categories of user you want to use in the
folder.
RESOURCE
Tab Calendar
- Manage the user working days and a number of hour per day, they can be used to convert
days in hour depending on the setup (GESOTI)
It Can be used to control the time tracking
Tab Resource
- Category : User category used to manage cost for time tracking
Tab Services Activities
Default values
RESOURCE CATEGORY COST
Define a daily/hourly rate per user category and per site
- Site : if blank means for all sites
- Start / End : Range date where the rate will be applied
- Cost : rate per unit
- Unit : Time unit for the rate
RESOURCE COST
Define a daily/ hourly rate per user using the same fields than cost per category
REQUIREMENT TEMPLATE
- Operation : Operation code planned to be tracked
- Default product : Product planned to be tracked
- Automatic interv : If ticked can generate automatically a response if SR requirement is
generated from a contract and a requirement template
- Interv type : if response generation, define the type of the automatic response
The Service Request is like a Service Order. It allows to plan what to do.
You will create on the Service Request several Services Response to track what is really
done.
You can track in one Response several line to declare different things. Each line is
categorize by an operation code.
The setup of operation code per intervention type can be done to generate X3 document
from the response (invoice, stock movement…)
The Service Request :

- can be created directly,
- can be generated link to a project detail (Project – Detail  Situation  SR
generation),
- generated link to a recurrent contact header or line. (Contract/Contract line  SR
generation)
The requirement manage the tracking planned, using operation code quantity…
It can be blank.
You can track on a Service Request using 3 ways :

- Service Response
- Periodic activity report + validation = Service Response
- Periodic activity report + approvals + validation = Service Response
- Not in this course but a web timesheet using web services is also available….
General Tab :
The General tab defines the third-party concerned, the contract/project/equipment. It allows to
specify the type of SR carrying the management rules, as well as a responsible operator and/or
a team.
- Ref : Free fields, can refer to customer asking number.
- Contract/Line : Contract header number/Contract line number. Link the SR to the contract or
the line. Automatically populated if the SR is generated from the contract.
- Product/Serial : Used to link the SR to an installed base defined by a product code and a
serial.
- Project/Lot : Used to link the SR to a project/Lot is an informative field. Automatically
populated if the SR is generated from a situation on project.
- Date : By default date of the SR creation, can be used to enter the planned service
beginning.
- Supervisor : User, allowed to be SR supervisor, who will manage the SR. He’s not the user
that can track on this SR.
- Skill group : Link the SR to a group of users. This can allows to determine the SR
responsible in a second time. It means that the SR is assigned to a group of people, the skill
group responsible will view all the SR of his group and assigned each to a responsible.
- Priority : Informative field
- Penalty : Informative field
- Coverage : A coverage define what is cover or not by a contract. It’s allows to manage
discount per operation code (ie if the service is under contract for example), or delay to
response.
- Calendar : Can link a specific calendar to the SR

- Max D/Hr : Can be populated by the coverage or manually, it’s an informative field.
- Breakdown/Fail : The breakdown code allows to type the SR. It can be completed with
the summary which gives the mission order.
- Stage :The stage permits to identify/follow the progress of the SR.
Control :
The tab Management allows a follow-up of the realized of the SR, of its traceability, of its
statistical categories,
- Routing : The routing allows us to preload a need to the SR.

- Range : The range can come from the contract. It’s just an information
- Questionnaire : The questionnaire lets us recall a set of question and to stock the
answers for that SR. It’s a SR level questionnaire.
- Next SR Response date : Informative fields
- SR Statistics : Statistical data
- Source : link to the origin document
Invoicing :
The invoicing tab allows us to define the invoicing rules. It is used in the frame of
responses generating lines of invoice.
- Adjustment: The regularization generates the inverse quantities of those entered. It

allows us, for example to cancel an SR and Response after they have been
validated. A response on a SR ticked regularization will generate the negative
document of the response entered. (ie if you track 2 billable days on a SR ticked
regularization, it will generate a customer credit of 2 days)
- Grouping : how to group the document generated from the responses. It can be
populated from the customer, the contract, the project or manually.
Responses :
Tab allowing the consultation of the interventions input on the SR. It can be automatically
pre-loaded or not depending of the settings of the SR type (to manage performance).
General Tab :
Type : To enter the Response type using one of the type setup in the folder
Interv date : Main date of the response
Comments : Free text to describe the response
Line Tab :
In the same screen we are able to enter everything on the response (time, stock
issues…).
- Ope : Operation code (using the response type it will define the fields to
populate on the line)
- Tec/Prd/Res : If the operation code is a service operation type, enter the user
who spend the time, if it’s a product operation type, enter the product code
managed, if it’s a resource operation type, enter the resource code which
spend time.
- Qty/Duration/Day : Are calculated depending on the calendar set up to be used
with this operation code on this response type.
Line Tab :
- Next stage : define the SR stage after the response (In progress, terminated,
…)
- Resp after : Supervisor of the SR after the response
- Skill group : SR skill group or queue after the response
- Breakdown : SR breakdown or fail after the response
- Rest to do : Remaining time to spend on the SR to finish the service. It can be
used on the project situation screen.
Adjustment = negative value
Service response + adjustment is like a credit note to correct a first response

which should see like an invoice in this example…
Report Activities is quite equivalent that a mass tracking tools for manufacturing.
The main difference is that Activities report are saved
Header :
- Type : Activities report type
- Site : Site of the SR on which you want to track
- Person : Default user which will track time
- Contract Revision : Used to filter the SR on the tab behind
- Project : Used to filter the SR on the tab behind
- From : Start date used to control the date of the response entered in the tab
- To : End date used to control the date of the response entered in the tab
Line :
- Date : Date of the tracking
- BP : Used to filter the SR
- Contract Revision : Used to filter the SR
- Project :Used to filter the SR
- SR : SR number where you want to track
- Interv type : Response type
- Ope code : Operation code
- Next stage : SR stage after the tracking
- Project approval : Has the tracking been approved by the project manager
(more example next slide)

- Hierarchic approval : Has the tracking been approved by the user manager
(more example next slide)
If Project Implicit or hierarchic ticked no approval process. Approval is done in the

function CONSVGS.
Header :
- Processing type : define which type of action is done (approving or
disapproving)
- Selection bloc : to select the line to manage
- Signature : allows to define if the selection is on the hierarchic point of view or
project
Page :
- To be realized : when you save, if yes do the process define in processing type
in the header
This mechanism allows the generation of documents in accordance with the

controls and the constraints of the standard, but also to update the objects.
The setting allows to determine what will be generated, from which event and
under what conditions.
Whatever its origin this generation follows the same mechanism.
Some events can generate data in the pre-validation table

This data can be manage in the Pre-validation Data function
The document generation scan the pre-validation table, generate X3 document
and close Pre-validation data records.
The pre-validation table is used to manage :

- The way to group document (ie : do you want to generate one invoice per
customer, one per project, one per project line…)
- The management of errors : you can update a records with bad values to
generate the final document
- The temporization : you validate your service responses every week and you
want to invoice every month the time between both the record for invoicing will
wait in the pre-validation table
Three steps :
- Define the grouping methods
- Define the validation code to define the documents you want to generate
- Define where you want to generate document and which of the event you want
to use
Grouping code :
The grouping code is entered on the origin

document to the generation. It define with which
other pre-validation the record that we will
create, will be grouped.
The standard grouping define normal rules to warrant the standard fonctionalities
Parameters > Services Activities > General parameters > Std documents
grouping (non modifiable)
It applies in addition with a standard grouping code linked to each of document
and allows the generation of a rupture/breaking code in the VALGAS database.
- Validation grouping code : Use as a criteria in the document generation, this

value is added in the calculated key that define the rupture
- Grouping expression : Using a formula, defines the key of the rupture. If you
want to generate one invoice per project and per product, the formula have to
add the project number and the product code

- Date expression : Using a formula, defines the date of the document generated.
It can be a grouping criteria
- Sort expression : Using a formula, defines the sorting of the lines in the
document generated.
If these fields are blank the default values will be used.

Two possible types, generation of new documents or updating of existing

ones
Param 1 & Param 2 : Contextual parameters linked to the type of

generated doc
Determining formula of the generation

Document generation if zero valuation
Inverse code to be applied if negative quantity

Default grouping code
Can the recording in temporary table be editable
Automatic statuses in the table VALGAS

General Tab :
- Object update : if ticked use the second tab to define how to update an
existing object, if not use this tab to define how to generate a new
object
- Document type : Choose in a limited list the type of document you
want to create. It’s an hardcoded list you can’t change, it determine all
the document you can generate from this module.
- Reverse code : Inverse code to be applied if negative quantity
- Company site : Default accounting site if not find in the flow
- Site : Default controls site if not find in the flow
- Param 1 : Contextual parameters linked to the type of generated doc,
can be blank depending on the document
- Param 2 : Contextual parameters linked to the type of generated doc,
can be blank depending on the document
- Grouping : Default grouping value for the document generation if not
find in the flow
- Triggering : Formula, if the evaluation isn’t true the record in the pre-
validation table is not created
- Generation condition : Determining formula of the generation, if the

evaluation is not true the record in the pre-validation table is not
considering by the generation document process
- Changeable : Can the recording in temporary table be editable
- Validation if null : Document generation if zero valuation, can stop the
document generation if the value is null
- Status before generation / after generation / after cancellation : Define
the status of the pre-validation record before the generation, after the
generation and after the cancellation of the generated document. To
remind : the generation documents process considers the record in a
status “validated”.
Parameters tab :
,
- Object : Which object do you want to update? In a limited list.
- Update : Do you want to update this field?
- Questionnaire : If the field is update using a questionnaire answer you need to
populate here the origin questionnaire
- Question : If the field is update using a questionnaire answer you need to
populate here the origin question
- Value : If the field is not update using a questionnaire use a formula to define
the new value of the field
Over each object of the X3S module, an option allows, in an only one action, to
launch the dump into the temporary table and the generation of documents.
To do so the tag Postponed generation must be set to NO. But in this case the
grouping will be effective only for the elements generated by the same time.
The document generation is a mass process which scan the pre-validation record
to generate documents.
It can be substitutes using a picking left list in some X3 object. You can select
pre-validation records from the PO or sales invoices screen to generated these
documents more manually from the pre-validation data.
The recurrent contract allows to generate periodically SR or Sales invoice or

both.
It can be link to an installed base.
The main interest : management of the lines of the contract with a direct
invoicing in the header (i.e. directly managed from the contract itself) of the
contract or in the line itself and management of the interventions in header of the
contract (i.e. directly managed from the contract itself) and / or in the line.
For example let's consider an installation and maintenance contract : It allows

first to generate SR for the installation, then a periodical generation of new SR
for the maintenance of the installed base and obviously the invoicing of the
interventions accordingly. In this example the SR generation has been defined in
the lines while the invoicing rules are triggered by the contract.
It also possible to add intervention not covered and which will be invoiced.
Of course it's possible to get different types of contracts in the same X3 folder
and thus several possible ways of management
what do the Recurring contracts y manage ?

Contract Revisions and/or Amendments
Status of the contract (validated / closed / beginning & end date…)
Type of periodical invoicing (yearly, monthly, fortnightly, weekly, …)
Management of revision indexes
Associated Price-list
For example a contract type RENT which will just generate invoice and not
allowed for services management
An other one for maintenance which will manage invoicing and services request.
We can have dedicated services request type Reparation and Preventive

General Tab :
- Report : Specify a report per contract type

- Access code : Control the use of this type
- Sequence number definition : According to the contract type you can
have specific sequence number
- Preload tab line : Let us choose to preload or not the lines tab. This
can help us to manage big data quantity, and to have a quickly
browsing
Control Tab :
- Invoice validation code : Define which validation code will be use to generate
invoices
- Credit note validation code : Like for invoicing but if amount is negative
- Sales site origin : Defines which site need to be used the contract site or the
default site in validation code
- Shipping site origin : Defines which site need to be used the contract site or the
default site in validation code
- Postponed generation : Used to invoice the contract in two times the first one
to create records in VALGAS, the second time to generate the invoice. It allows
us to group several origin in a single invoice. (for example with some line
coming from project invoicing)
- SR validation code : Like for invoice but in service request generation
- Contract installed base control : Does the installed base, linked to the
contract, have to be control or not?
- Expression unique line control : Use a formula to define a unique id for contract
lines
Status Tab :
Define on the right side of the tab different rules depending on the status selected
on the left side
- Modification authorized : Are you allowed to update the contract status /

contract fields or contract line at this status? If ticked means yes.
- Contract invoicing : Do you want to invoice at this status? If yes you also need
to setup the validation code for invoicing in the previous tab.
This function is used to define the different frequency of SR generation used in

recurrent contract. Do you want to create a new SR every month, week, year…
and do you have wishes days, forbidden days…
A test button is available to check the setup.
General Tab :
- Active : The setup can’t be used if is not active

- Periodicity N° : Number of period*
- Period : Period (Day, Week, Month, Year)*
- Visit Frequency : Number of visit per number of period (*ie Periodicity N° =3,
Period = Month, Visit Frequency =1 means 1 visit every 3 months)
- Calendar : Specific calendar to use for this frequency
- Way to search : If the date of the generation is on a restricted day, defines how
to plan the SR.
- Day of the month : Allows us to manage one to four dates in the month to
define the days when the SR will be planned
- Unavailability code use : If ticked use the unavailability code as restricted days.
- Restricted days : If ticked means that theses days are forbidden
- Wished days : If ticked means that days are wished
Forbidden period tab :
- Forbidden weeks : allows to define forbidden period using start and end week
number
- Forbidden days/month : allows to define forbidden period using start and end
dates without year
- Forbidden dates : allows to define forbidden period using start and end dates
including year
General Tab :
- Project : Informative link with a project

- Customer ref : Free reference
- Validated : Means that the contract has been posted (Need to be authorized in
the milestone tab.). Mandatory to generated document from the contract.
- Closed : Means that the contract has been closed (Need to be authorized in
the milestone tab.). Stop the contract use.
- Status : Allows us to manage intermediate status
- Signature date : Not mandatory
- Start / End validity : Beginning and ending of the contract
(To generate anything a contract needs to be validated)
Control Tab :
- Supervisor : User who supervise the recurrent contract

- Group : Define how to group the documents generated from the
contract. It’s a default value that can be used to define invoicing
grouping or SR grouping.
- Coverage : A coverage define what is cover or not by a contract.
It’s allows to manage discount per operation code (i.e. if the
service is under contract for example), or delay to response. It can
initialize the SR coverage.
- Calendar : Can link a specific calendar to the contract
- Questionnaire : Can be used as a default value for the SR link to the
contract or to manage a question on the contract as a check list
- Users : User who manage the recurrent contract.
Milestone tab :
- Authorized validation : If ticked you can post the contract. Allows to

manage access right to this field.
- Authorized closing : If ticked you can close the contract. Allows to
manage access right to this field.
- Cancellation date : Date of contract cancellation, the cancellation stop
all document generation.
- Cancellation reason : Justify the cancellation to do statistics
- On hold : Stop the SR generation if the value is different of not
suspended.
Periodical Invoicing Tab :
- To be invoiced : The contract header or lines has to be invoiced

- Effective date : Start of invoicing
- Frequency : Frequency of invoicing
- Grouping : Group code for invoice generated from the contract.
- Payterm : Invoice an expired period or a period to be expired
- Calculation : Informative, can be used if specific adaptation are needed
- Prorata temporis : The invoice is done from the beginning date + the period
every time or use a smaller period for the first one to be on a calendar period
after (tick prorata). (each time from the 13 to the 12 of the month, or from the
13 to the 30 and from the 1st to the 30)
- Credit resign : Do you automatically create a credit note if the contract is resign
Price update
- Formula : Select a formula revision already setup
- Factor : If you don’t use a formula you can just use a factor to modify your
sales price
- Ref dat : Date of the formula index reference
- Beg rev : Beginning of revision
- Frequency : Frequency of gross price revision
Contract
- To be invoiced : Means that you want to invoice the contract header
- Product : Which product is invoiced
- Unit price : Which price is invoiced
- Frequency : Defines the period for the price entered (Is this price for a month, a
week, a year…)
Last invoiced period

- Start / end : Automatically populated by the invoicing process to know which is
the next period to invoice
- Unit Amount : Automatically populated by the invoicing process
Request Generation Tab :
- To generate : Is mandatory ticked to generate SR on the header or on the line

- Generation if SR in progress : If ticked you generate the next SR even the
previous is not closed
- Multiple generation : If ticked you generate SR for one year with a
monthly periodicity you will have 12 Sr not just the next one
- On contract generation : If ticked you will generate SR on the header, and you
have to populated the next fields to define how.
- Frequency : Select one SR frequency for generation
- Calendar : Define a specific calendar
- Reference date : Beginning of the SR generation (the SR generation is only for
future date)
- Progress date : Date of the last SR generated (automatically populated)
- Last SR : Number of the last SR generated (automatically populated)
- SR Type : Which SR type will be generated

- Skill group : You can indicate a skill group for the SR
- Grouping : Define how to group SR record during the generation

- Supervisor : To define the future SR supervisor
- Coverage : Allow to manage coverage on the SR. A coverage define what is
cover or not by a contract. It’s allows to manage discount per operation code
(i.e. if the service is under contract for example), or delay to response. It can
initialize the SR coverage.
- Requirement Generation : If ticked the requirement can be automatically
populated using the template
- Requirement Template : Allows to define a default requirement. For example in
maintenance it can be the list of the task to do.
- Penalty : Informative field to manage the penalty of the SR
General Tab :
- Active : The line can be managed

- Line Type : Informative field to classify the lines
- Machine code : If link to an installed base record it is the installed base number
- Product code : Product involved in the line management
- Serial number : Serial number of the product manage
- Quantity : One line can manage several product
- Coverage : A coverage define what is cover or not by a contract. It’s allows to
manage discount per operation code (i.e. if the service is under contract for
example), or delay to response. It can initialize the SR coverage.
Invoicing Tab :
- To be invoiced : If ticked the line can be invoiced. You also need to tick “to be
invoiced” at a contract level.
SR Tab :
- To generate : If ticked the line can generate SR. You also need to tick “to
generate” at a contract level.
Postponed is defined in the contract type
So you have the validation table where each recording line was store. And a
second process which scans this table, groups records and generates invoices.
If you do a postponed generation you need after to use the generation process
Postponed is defined in the contract type

So you have the validation table where each recording line was store. And a
second process which scans this table, groups records and generates invoices.
If you do a postponed generation you need after to use the generation process
The project management allows us to manage the company business by project.

Each project allows you to calculate the margin by managing a separate Profit
and Loss.
It allows you to measure profitability of the project. The planned profit, the actual
and the end profit. You can compare the budget, the actual cost and what you’ve
invoiced.
Operationnal :
- Follow business by projects
- Manage time spent on projects
- Achieve a case tracking
- Invoice in time without forgetting without error (gerer son temps)
Financial and accounting plan :

- Measure profitability on your projects
- Follow your costs and sales progress
- Compare all what you’ve Budgeted , Realized and Invoiced on your
projects
- Evaluate Expenses and products on each project
- Calculate operating account project ( or project Income ?) at each step of

life project
In the project & detail screen you define your planned sales, and for each sales
you will have some planned cost (internal or external) this give you a planned
profit.
During the project life you will spend time on the project, purchase for the project
and invoice it to the client, this will give at each time an actual profit.
The way to manage it easily give you the opportunity to take some action plan in
case of drift. The right side of this slide give an example of drift on cost which can
decrease the profit at the end of the project.
The project is the heart of the whole process. It gives to the users a 3 hundred
and sixty degrees view of the their activity.
With this tool they'll get a better vision of the project's profitability and ending
profits. They will manage costs/ quality and delay with an integrated package. So
they will be able to better anticipate budgetary drifts.
The project can generate X3 processes document or manage progress for each
process.
It allows the follow-up of the before sales and after sales stages.
It's a complete tool of project tracking in terms of purchases, services,
manufacturing and sales processes.
It allows to follow the realized and to compare it to budget with an operational or
accounting vision.
A project can be defined and structured in lots, eventual sub-lots and lines which
contain all the costs (purchasing, services, production) and the definition of the
sold "product" (global service, end product, …) corresponding
The hierarchical structure of the project allow to manage profits at every level.
Each line can be independently invoiced according to specific conditions : on

stages, on progress or to determinate dates.
At each level of the project you can see the profit.

The profit is defined at the line/detail level.
One project line is built with one product sold and some purchases and/or
services corresponding to the sold.
In fact you plan what you have to do to answer the sales of the line.
Each item of the line can start a process :

- An invoicing one for the sales part
- Some purchasing for purchase part
- Some Services for services part
It will depend on the setup.
These allows us to manage the plan profit and to compare with the actual for
each project line. And to sum theses data until the project level to manage the
project profit
To follow the project life and to start or adjust some processes, we use a tools called the situation.
The Project situation is like an operating account project or a project review.
It will compile all the actual link to your project detail and for each item of your project it will give you the view
of the planned and the actual. You can for each line manage the process to strat or to adjust.
The Project flow is piloted by a tool called the situation. It allows us to check what
have been planned, to decide what we want to generate from this plan to X3
document and to track what have been done. This is done for each project
element, that is to say at the product code level.
An X3 document can be generated from a situation or manually from X3 normal
function and linked to a project detail/line
Document generated from the project plan and constitue project life
In this example you plan in the project detail 8 days.

The first situation will launch the project and generate the SR.
You will use Response to track time on the SR. (6 Days)
The next situation will compare and give you a remaining of 2 days.
The situation validation will update the SR requirement with this 2 days.
You also can change these days to adjust the remaining to the real remaining at
this time of the project.
For the purchase point of view it’s quite the same.
In this example you plan in the project detail 2 Days to purchase.

The first situation will launch the project and generate the PO.
You will track the work done using receipt, that will help you to compare the
supplier invoice.
The next situation will compare and give you a remaining of 0 day to purchase.
But you choose to force the purchase for one day more because the mission is
not completed.
The validation of situation will create a complementary PO of 1 Day.
For the sales point of view different method can be used, this example shows the
advancement method. It will suggest to invoice the percentage of sales
corresponding to your cost spent.
At the situation 1, the advancement calculated was 8 k$. The validation generate
the invoice.
Before the situation 2 some cost were spent on the project detail, so the
advancement at situation 2 was 20 k$.
The validation generate an invoice of 12 k$ : 12 = Advancement of 20 – alreaday
invoiced 8
Prerequisites not covered in this course

Hierachy codes are used to define the project structure. It can be use at the first
level, the second one or both, depend on the setup.
- Code : It’s the code you will use in the project screen
- Description : It’s the code’s description
- Level 1 : If ticked, means that you can use this value as level 1 in a project
- Level 2 : If ticked, means that you can use this value as level 2 in a project.
Note that you can choose to tick both to use it at both level.
- Dependence : If the code can be used in level 2 you can create a dependency
between the level 2 and the code used in level 1
- External structure : If ticked, means that you can use this hierarchic code in the
external structure screen
- Internal Structure : If ticked, means that you can use this hierarchic code in the
internal structure screen
- Active : If ticked means that you can use the code using the rest of the setup, if
not you can’t use it even if you’ve done the setup
For example types :

Engineering which will generate SR and Purchase request
Design which will manage SR
Software Implementation which will manage SR and PO
Invoicing will be manage at the project type level

Detail type define the different rules you will have for one project line of this type.
In one project you can have several line and each line can have its own type.
General :
- Access : you can manage an access code to control the use of this code
- Commentary : Help you to remember the main objective of this setup, type per
type.
- Default : If ticked this type will be initialize on the line you will create in a
project as a default value.
Status :
Second screen is more important. The line status is local menu 1732. For a line
type each status can have some different rules
- What is available for update at this stage
- Does the line can be imputed by a process done
- Can we calculate situation for this line at this stage
- What kind of documents can be generates by a situation validation (if
they aren’t manage a the project type level)
- Status : Select the status for which one you will setup the rules in the right part
of the screen (all the other fields of this screen value is for the status selected
here)
- Modif Autorized
• Detail Status : If ticked you can change the status of the detail. Be aware
if you choose to forbid to change the status it means even if it was a
mistake…
• Detail : If ticked you are allowed to update all other fields of the detail
when it is at this status.
- Forms line selection

• Purchasing : If ticked, you are allowed to link a purchase document (PO
or request) to your line or to generate one. It means that you are allowed
to track actuals on this line.
• SR : If ticked, you are allowed to link a SR to your line or to generate
one.
• Sales (delivery header) : If ticked, you are allowed to link a shipment to
your line. It means that you are allowed to track actuals on this line.
• Manufacturing : If ticked, you are allowed to link a work order to your line
or to generate one.
- Situation generation : If ticked and if the project type allows it, you can
generate/calculate a situation for this detail when it is at this status
- Budget RTZ : If ticked, it means that if you manage an automatic budget
generation, and if you calculate a situation at this status, the budget will
automatically Remains To Zero when you will validate the situation
- Auto preload form line : If ticked, it means that you will automatically preload
your project line in the quote objet when you use the « Quote creation » button
on project.
- Service response creation : If ticked, it means that you can create Services
Responses link to your project line. If it’s not ticked you can’t track time on the
SR linked to your detail.
- Validation of situations (used if on the project type, you have define that
validation code are manage by detail type and not by project type)
• Purchasing : Identify the document you want to generate at the situation
validation for the detail purchase tab
• Services : Identify the document you want to generate at the situation
validation for the detail services tab
• Sales : Identify the document you want to generate at the situation
validation for the detail sales tab

• Budget : Identify the document you want to generate at the situation
validation for the purchase generation for all tabs
Situation :
Next tab is to setup how project progress will be calculate, and how turnover
progress/advancement will be calculate
- Does quantities of the rest to be done are calculated or manually entered
- What is the progress release in purchasing process
- What is the progress amount used for calculation
- Proposal amount to generate : for each tab define how the calculation
of the situation will suggest quantities
• Manual :
• Recalculated :
• Negative authorized :
- Advancement amount : define which amount is used to

calculate the cost advancement
• Planned cost : the calculation will multiply the quantity to
calculate the cost advancement and the cost use will be the plan
cost
• Sales : the calculation will use the calculated sales cost to
calculate the cost advancement. It allows to have an

advancement base on quantity if the sales price is the same for
the all line and each cost is different.
• Real cost price : the calculation se real cost divide by planned
cost to calculate advancement
- Advancement quantity : just used for the purchase part to

define when the calculation have to consider the purchasing flow as
completed
• Reception and purchase invoice : purchase flow is considered as
completed when the purchase is received in the project site.
(When the purchase is received for non stocks managed)
• Shipment : purchase flow is considered as completed when the
purchase is delivered to the project customer.
This first example illustrate the use of the two last parameters.
On the first example : you calculate the turnover advancement using the
planned cost even if the purchase is at a different price, and you choose to
consider the purchase flow as complete when you receive the purchase.
- The order have no impact on the turnover advancement
- The receipt gives you an turnover advancement. Even if you purchase
more expensive than you plan it has no impact : (5 * 1000 / 10*1000)*
15 000
- The shipment has no impact on the turnover advancement
On the second example : you calculate turnover advancement using the

planned cost but you choose to consider the revenue when you ship the
item to the customer.
- The order has no impact on the turnover advancement
- The receipt has no impact on the turnover advancement
- The shipment gives you an turnover advancement. Even if you
purchase more expensive than you plan it has no impact : (2 * 1000 /
10*1000)* 15 000
On this example we illustrate the difference between a real cost calculation

and a planned cost calculation
planned cost even if the purchase is at a different price, and you choose to
consider the purchase flow as complete when you receive the purchase.
- The order have no impact on the turnover advancement
- The receipt gives you an turnover advancement. Even if you purchase
more expensive than you plan it has no impact : (5 * 1000 / 10*1000)*
15 000
On the second example : you calculate turnover advancement using the

real cost and you choose to consider the revenue when you receive the
product.
- The order has no impact on the turnover advancement
- The receipt gives you an turnover advancement. The fact you’ve
purchased more expensive than you’ve planned change the turnover
calculation : (5 * 1100 / 10*1000)* 15 000
On this example we illustrate the difference between a sales cost

calculation and a planned cost calculation on a services example. You’ve
planned two services with different costing price but the same sales price.
planned cost.
- If you complete the second service planned the calculation will
calculate an advancement bigger than half of the plan because you’ve
done the more expensive part of the mission… : ([0*500]+[10*1000]/
[10*500]+[10*1000])* 20 000
On the second example : you calculate the turnover advancement using

the calculated sales cost.
- If you complete the second service planned the calculation will
calculate an advancement of half of the plan because you’ve don’t
consider the real cost of the tracking… : ([0*1000]+[10*1000]/
[10*1000]+[10*1000])* 20 000
For example two project type :

- R&D which allows to use Engineering and Design detail type
- Customer which allows to use Engineering and Software implementation detail type and which can be
invoiced
General :
- Access code : Access code to control use of this project type and
project access
- Commentary : To comment the setup
Services :
- Control : If ticked means you want to control the SR type used in these
project
- SR Type : If you have ticked control you need to populate the table
with the SR type you want to allow
Project Detail:
Next screen is more important. It allows us to control what type of line we can use
on this project type. And if it will be possible to calculate situation on these lines.
But it also allow to determine what documents we will generate on situation.
- Validation code determine what kind of document.

- Validation code can be configure on project type or on line type
- We can choose if the generation is in one time or postponed
We generate project line and control at which project stage it’s possible or
not.
- Controls : Do you want to manage detail on your project?

- Control : If ticked means that you want to control which type of detail
you want to use
- Revision management : Do you want to manage revision on project, if
ticked all project update after the detail validation will be historized
- Type : if control is ticked list the detail type allowed for this project type
- Sit Gen : choose if you want or not generate situation for this detail type
when is used on this project type
- Default type : defines the detail default type on this project type
Purchasing
- Validation code / form type : for the data on the purchase tab of the
detail do you want to manage the generation of document per detail
type or per project type? If ticked means per detail type so you don’t
have to populate the validation code on the project type
- Validation code : Defines the document to generate per project type for
purchases
- Postponed generation : If ticked means that you want to launch the
documents generation function, if not means that it will do automatically
when the pre-validation data will be created
Services
- Validation code / form type : for the data on the services tab of the
detail do you want to manage the generation of document per detail
type or per project type? If ticked means per detail type so you don’t
have to populate the validation code on the project type
services
Sales
- Validation code / form type : for the data on the sales tab of the detail
do you want to manage the generation of document per detail type or
per project type? If ticked means per detail type so you don’t have to
populate the validation code on the project type
sales
Budget
- Validation code / form type : for the data for budget do you want to
manage the generation of document per detail type or per project type?
If ticked means per detail type so you don’t have to populate the
validation code on the project type
budget
Creation of detail
- Creation of detail / step : Defines if you want to control the project step
to generate the detail
- Step : If yes at the previous field you need to define the step where the
detail creation is allowed
External or Internal Structure:

You can control which level/hierarchy code you can use in the project structure.
You’ve got the same screen for secondary structure
Use free level name or control with a level table

Allows us to control what code you can use in this project type
You are able to generate a project structure for this type of project
Hierarchy codes need to be define in a common data table
The last screen allows us to determine where we can calculate a situation on a

project. For example you can have one situation for all of the project. But in some
case you could want to calculate one situation by level of the project. In this
screen you determine the situation calculating level.
- Level 1/ input : Free or Normal. Define how to enter the project

structure for level1 for the external structure or the internal depending
on the tab you setup. If free it means that you can use a free
description of 20 characters. If normal, means that you have to use a
value defined in the hierarchy code function.
- Hierarchy code control : If ticked, it means that you want to control the
hierarchy codes use for this project type, in external structure for level
1. And if it ticked, you have to populate the table which defines the
values allowed.
- Level1/Level2/Product… : Define the default project stuture which be
preload when you will create a project of this type.
Situation :
The last screen allows us to determine where we can calculate a situation on a

project. For example you can have one situation for all of the project. But in some
case you could want to calculate one situation by level of the project. In this
screen you determine the situation calculating level.
- 1 Situation / Project : Defines if you want to create one situation per

project at each calculation or more?
- Structure : If you don’t want to calculate one situation per project
defines the structure (external or internal) used to define the level of
each situation header
- Level : If you don’t want to calculate one situation per project defines
the level used to define the level of each situation header. For example
one situation per internal structure / level 1,
- Log reading desact : Active or not the log file view when you validate a
situation
- Index : Index code you will use in the formulas

- Reference date : Date of the reference value for this index for the X3 folder.
You can define reference date for a document in the process.
- Reference value : Value of the index for the reference date
In the table you will manage the index evolution

- Knowledge date : defines the date when you know the index value
- Level date : defines the date when the index value is applicable/valid/legitimate
- Level value : Defines the value of the index
- Review code : Formula code

- Active : If ticked means that you can use the formula in X3 documents
- Reference date : Defines how to calculate the index value. If you ticked
“knowledge date”, it means that you use the index “knowledge date” to
determine the value.
i.e. : Knowledge Level Date Value
date
01/03/12 01/02/12 100
01/04/12 01/03/12 110
In this example, if you choose “knowledge date” the 1st of March,

the index value will be 100. If you use the level date, the index
value will be 110,
- Formula : Defines how to use indexes to calculate a coefficient to apply to the
sales price.
The revision can be used in recurrent contract, project or specific price list. It will
be used when the process will calculate a price for example to invoice.
The project view allow to define a project structure using a sales point of view.
Each product code used or each amount entered correspond to a turnover.
To define the cost corresponding to these sales you will generate a detail
corresponding. This is done using a function on the project top menu or a batch
function that allows to handle several projects.
For each sales you can manage several costs item corresponding.
i.e. : you can sale a “server installation” and to realize this task you will purchase
a server, purchase some software licenses and to spend time. So you will
manage several cost for a single item sold and invoice to your customer.
If you use the “detail creation” without any other information, you will have to
populate all the purchases, services corresponding to your sale. If you have
some repeated sales, you can manage model lines. They will define how to
preload the detail fields when you will generate the detail record using the “detail
creation” function.
In fact the “model line” screens are the same than the detail screen. You will have
the same fields to define all the preload you need.
The detail of theses screen will be described in the same times than the detail of
the project,
Invoicing mode : a complementary value is available  Project default, that

means that you won’t define in the model the invoicing mode but you will use the
invoicing mode defined in the project tab “default value”.
Prerequisites not covered in this course

The Project flow is piloted by a tool called the situation (snapshot of the project /
project review). It allows us to :
- check what have been planned,
- decide what we want to generate from this plan to X3 document
- track what have been done.
This is done for each project element, that is to say at the product code level. You
need to launch a situation calculation to have a refresh view of your project. Each
situation is historized.

Document are generated from the project plan and constitute project life
External Structure :
We can define the project structure with a maximum of two levels.

We can put in the structure in a table form or directly in a graphical mode.
At this point each line corresponds to what you sold

A template can create detail of the line. (It is defined by project type)
Level can be controlled by a table
Show and allow to modify project structure
At each level you can see the planned profit
Each line is a product sold as in a project quote.
The project structure gives a sales view of the project.

When the structure is ready, generate “project detail”. In the detail populate
the cost corresponding to the sale.
Structure :
- Level 1 : First Hierarchy code use by this project line. Can be updated every
time,
- Level 2 : Second Hierarchy code use by this project line. Can be updated every
time
- Product : Sales product code which will be copy in the detail sales tab. It will be
the invoiced product.
- Qty : Sales quantity. It will be the invoiced quantity.
- UP : Unit Price. Sales unit price corresponding to the quantity. The planned
invoice amount.
- Template : Model Line which will be used to preload the detail data when the
“detail creation” will be launched
- Type : Detail type for each line
- Detail : Detail number, automatically populated when the detail is created. If the
detail is created the data have to be update at the detail level not in the project
level.
Margin :
The margin table show a sum of amount corresponding at the graphic selection.
- Sales : Sum of the sales amount
- Purchasing : Sum of the purchase amount
- Services : Sum of the services cost
- Gross Margin : Sales - Purchasing
- Net Margin : Gross margin - Services
Icons meaning :
- Green Tick : It’s the active selection/position for margin calculation
- Yellow Folder : It’s a hierarchy code level, a group of detail
- White & Blue square : It’s a detail level which detail is created & validated
- Red cross : It’s a detail level which detail is created not validated
- Red/Blue/Yellow Sheet : It’s a detail level which detail is not created
The structure tabs name can be setup with the local menu 1829
For one project you can have two structure with the same lines. That lets you to
manage the same data in two views. For example a customer view and your
personal view. You manage the same details and change the group using
different hierarchy code/level organization.
When you've created your first structure you can copy it in the second tab using a
right click on the structure graphic.
On the hierarchical structure you have some contextual functions.

Add a new line
Change line status
Do a tunnel to the line object
Copy to the second structure
Controls :
In the controls tab, you can manage invoicing customer’s information, statistical
groups, analytical dimensions..
Who is the responsible of the technical part of the project

Project manager, this is the user put in here who can easily use projects
processes
- Address: Project customer main address

- Technical resp : Technical responsible. X3 user which is allowed to be technical
responsible for a project.
- Questionnaire : Questionnaire that can be pop up at the project creation as a
check list. Or which can be used as default value for SR on project.
- User : Project Manager. Can be used as criteria for example for situation
calculation…
Calendar:
Allows to define the project calendar. Hour working for each days of a week. It
can be used for service response to convert the time tracking from days to hours
for example. To use it you need to set it up in the operation / response type
parameters.
The tab can be hide using the transaction entry
Associated project :
X3S allow us to manage projects “BOMs”. That’s to say we can have a principal
project and some secondary project.
We can follow advancement of the complete structure in the project monitoring
If value is father, you are in a hierarchical association of projects, else it’s

the standard association
- Subproject type : Father means that the project enter on the line is father
project of the actual one.
- Code : Code it’s for the project associated. The project associated is father, the
actual is son project.
Default values :
When you end to define the project structure you need to generate the line
object. That allows you to define in detail every project part and especially
forecast cost.
The last project tab in X3S define “default values”. These values will be used in
project lines.
If you have a template line in the structure tab, the template values will be used
except if you flag “forced” in this case the project values are put in in priority.
- Forced : If ticked the Project default values have priority on the model line.
All the next fields of this screen are default values for details. The real effect of
the value inside is in the detail screen.
Invoicing
- Billing mode : Defines the detail invoicing mode (Situation/Fixed Date/Steps…)
- Grouping code : Defines how to group the invoices generated from the details
- Payment term : Each detail can have its own payment term. To initialize all with
the same value you can use this field.
Price revision
- Formula : To initialize the formula use for price revision in the details
- Ref date : To manage the Reference date for indexes used in the formula, for
this project
- Factor : To manage a coefficient instead of a formula to change the sales price
- Beg rev : To manage the beginning of the price revision calculation
- Frequency : To manage the frequency of price revision calculation. i.e. you can
have one year with a fixe rate, update the sales price every quarter and invoice
every month.
Invoicing step :
- Steps : For detail with invoicing mode = steps. Defines a step name using a
local menu
- Planned : Planned date of the step invoicing
- Earliest date : defines the start of a planned period for the step invoicing
- Maximum date : defines the end of a planned period for the step invoicing
- % invoiced : defines the percent of the detail amount invoice at this step
- Payment terms : allows to manage a payment term per step.
Fixed date invoicing

- Date : For detail with invoicing mode = fixed date. Defines the date of the
invoicing.
- Payment terms : allows to manage a payment term per date.
Prepayment deduct :
- Method : Define per detail how to deduct the project prepayment
(Percentage/Amount…
- Amount : If amount is selected allow to enter a fixe amount to deduct per line
- % : If percentage is selected allow to enter a percent of the invoice to deduct
Budget :
- Budget : Budget code where the budget will be generated
- Start date : Begining of the budget period for budget distribution
- End date : Ending of the budget period for budget distribution
- Distribution : Distribution coefficient to allocate budget amount per period
Planned S. Response
- Start date : Informative field to define the planned beginning of responses
- End date : Informative field to define the planned ending of responses
The real project information are in the detail. It is completed after the project
structure and the detail generation.
There is one tab per process :

- The first one for purchasing
- The second one for services
- The third one to complete the project data one invoicing
- The last one for all other information
The most important is to understand that with this construction you can manage
the real thing you have to do (purchase/services) and the invoicing corresponding
independently.
That means that you have a profit per detail, but not per item in the detail. You
won’t invoice the service you track. you will invoice the detail line and maybe the
advancement of the line calculated using you’re tracking. But not directly you’re
tracking.
It’s not like a shipment, where you invoice what you’ve shipped. You can combine
several data in you’re advancement calculation or invoice a step even if you
haven’t really do what you’ve planned…
Each item of the detail can generate / or be linked to a process. It depend on the
setup you’ve done of you’re project type and detail type.
To generate something on a project you have to use a situation.

Purchase Tab:
For purchasing you manage product, supplier if it is known, site, unit, quantity,
price…
This forecast can make a purchase order in the project process. Or a purchase
order can be imputed to this part of the project. That let us compare what you
forecast and what you’ve done.
It depends on project type and detail type setup
- Product : Planned purchase product reference. One detail can have several
purchase product
- Supplier : Supplier of the product if known
- Site : Purchase site
- Unit : Unit of the quantity
- Exp quantity : Quantity of product planned to purchase
- Wished receipt : Wished date of receipt for this product
- Currency : Currency of the amount
- Gross price : Gross price entered manually. No automatic price calculation.
- Sales coeff : Define the profit you expect to do on this item to help you to build
a sleds price for the all costs.
- Calc unit SP : Gross price multiply per Sales coeff. In the last tab you have an
automatic sum of these calculated unit sales price.
- Budget distribution : Code of the budget distribution used to calculate and
amount per period.
Services Tab :
It’s the same principle for services. You can define several missions you need to
do for the service you sold. Each mission is define by a SR type, an operation
code, a time unit, a quantity and an amount (automatically comes from operator
category)
This forecast can make a Service request in the project process. Or a service
request can be imputed to this part of the project. That let us compare what you
forecast and what you’ve done.
The cost come from the category of user

The SR Generation will be define by the three values Group/SR Type and Ope, if
you have the same group and SR Type you will have the same SR with several
requirment lines, if you haven’t you will have as many SR as SR Type/Group. In
this slide you will 4 SR (one for the two first line and one for each other line)
- Work center : Defines how to group the operation code with the same SR type
when you generate the SR
- SR Type : Defines the SR type planned
- Operation : Defines the operation code planned
- Category : Defines the category of user planned. It will be used to initialize the
unit cost.
- Oper / Res : Depending on the operation code type allow to define a default
operator or resource in the requirement
- Product : Define the product which will be used for example to manage the
accounting code
- Site : Services site
- Unit : Unit of the quantity
- Exp quantity : Quantity of services planned
- Currency : Currency of the amount
- Unit cost : Price of the services. Initialize by the category of user cost.
- Sales coeff : Define the profit you expect to do on this item to help you to build
a sales price for the all costs.
- Calc unit SP : Cost price multiply per Sales coeff. In the last tab you have an
automatic sum of these calculated unit sales price.
- Budget distribution : Code of the budget distribution used to calculate and
amount per period.
- Start end : Defines the planned beginning and ending of this particular service
- SR Responsible : Define the responsible of the SR.
- Summary : Define the SR summary
Sales Tab :
You enter, product, quantity, price, discount, analytical, invoicing mode…
(Product/Qty/Price can come from project level)
The Calculated price come from your cost, it helps you to
determine/review your sale price
(𝑃𝑢𝑟𝑐ℎ𝑎𝑠𝑒 𝐶𝑜𝑠𝑡 ×𝑆𝑎𝑙𝑒 𝐶𝑜𝑒𝑓𝑓)+(𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑠 𝑐𝑜𝑠𝑡 ×𝑆𝑎𝑙𝑒 𝐶𝑜𝑒𝑓𝑓)
= 𝑆𝑎𝑙𝑒𝑠 𝑄𝑢𝑎𝑛𝑡𝑖𝑡𝑦
Grouping code : Determine the key to group your invoices (per project, per
customer, per project detail….)
Define how to group each invoice record. For example an invoice by

project, or an invoice by customer…
- Site : Sales site. Initialized with the project sales site

- Product : Sales product, which will be invoiced. Initialized with the project
structure product code
- Invoice : Defines the detail invoicing mode (Situation/Fixed Date/Steps…) Can
be initialize with the project billing mode.
- Group : Defines how to group the invoices generated from the details
- Qty : Sales ordered quantity
- Calculated price : Sum of the sales calculated prices of each item. Sales
calculated price using the profit expected on each cost. It’s just information.
- UP : Unit sales price manually entered. Can come from the project structure
screen.
- Distribution : Budget distribution code to define the accounting period amount
split
Invoicing
- Billing mode : Defines the detail invoicing mode (Situation/Fixed Date/Steps…)
- Grouping code : Defines how to group the invoices generated from
Invoicing step :
- Steps : For detail with invoicing mode = steps or fixed date. Defines a step
name using a local menu
- Planned : Planned date of the step invoicing. Date for the fixed dat invoicing
mode.
- Earliest date : defines the start of a planned period for the step invoicing
- Maximum date : defines the end of a planned period for the step invoicing
- Payment terms : allows to manage a payment term per step.
- Gross price : Automatically amount calculated based on percentage. Can be
entered the percentage will be recalculated.
Step & Fix Date : Have to populate the bottom table to define the step/date for
each invoice
(500/1000)*1200=600
Miscellaneous Tab :
- User : Detail manager. Allows to manage a “sub-project manager” per detail

- Address / Inv customer… : Allows to manage customer information per detail.
So to invoice several customer in one project for example. Or to manage
several address per project.
Price revision
- Formula : To initialize the formula use for price revision in the details
- Ref date : To manage the Reference date for indexes used in the formula, for
this project
- Factor : To manage a coefficient instead of a formula to change the sales price
- Beg rev : To manage the beginning of the price revision calculation
- Frequency : To manage the frequency of price revision calculation. i.e. you can
have one year with a fixe rate, update the sales price every quarter and invoice
every month.
Prepayment deduct :
- Method : Define per detail how to deduct the project prepayment
(Percentage/Amount…
- Amount : If amount is selected allow to enter a fixe amount to deduct per line
- % : If percentage is selected allow to enter a percent of the invoice to deduct
Budget :
- Budget : Budget code where the budget will be generated
- Start date : Begining of the budget period for budget distribution
- End date : Ending of the budget period for budget distribution
- Distribution : Distribution coefficient to allocate budget amount per period
Planned S. Response
- Start date : Informative field to define the planned beginning of responses
- End date : Informative field to define the planned ending of responses
Document are generated from the project plan and constitute project life
The situation allows to do a project review item per item.

The situation has to be calculated to be managed.
You can calculate a situation from the situation screen or using a mass process.
The situation can be calculated to make a project review without document

generation. In this case you have to phantom it.
If you validate the situation you can begin a generation of documents depending
on the data you’ve entered in the situation screen.
XREGULSTEP : in case you have invoiced your project at a step during a

situation and you adjust the amount to invoice in a detail line of the project for the
same step, it will generate an invoicing adjustment during the following situation
(complementary invoice or credit note)
Header :
- Site : Criteria for project selection. If blank you can select project on all site. If
populated you can manage project of the site chosen.
- User : Criteria for project selection. If populated you can only see situation on
project where project manager = user.
- Sales rep : Criteria for project selection. If populated you can only see situation
on project where project rep= sales rep.
- Project : Project number of situations shown in tab “situations”

- Situation : Situation shown in tab “expenses” and “turnover”
- Calculated date : Date of the situation in progress
You can have only one ongoing situation each time.
Right click :
Recalculating = Refresh situation data
Phantom = transform situation in phantom
Budget situation = want to generate budget from this situation
…
The situation validation is irreversible.

Expenses :
The corrected value come from an other situation and change the planned
purchase from 100 UN to 100+10=110 UN. That explain the rest to order of 20
UN
You can enter the yellow fields
The bloc “To Order” define the documents to generate….
- Planned : come from the detail

- Receipt at last situation : come from all the receipt link to this detail item, that
have been done at the previous situation
- Delivery at last situation : come from all the shipment link to this detail item,
that have been done at the previous situation
- Receipt since last situation : come from all the receipt link to this detail item,
that have been done since the previous situation
- Delivery since last situation : come from all the shipment link to this detail item,
that have been done since the previous situation
- Corrected : Sum of change the plan of this item that have been entered in
previous situation.
- To correct : Change the plan of this item. New planned value = Planned +
Corrected + To correct
- Ordered : Purchase order generated or link to this item
- Remains to be ordered : Difference between the new planned value and what
have been ordered.
- Supplier : Come from the detail and used to generate PO* (*or Purchase
request)
- Receipt date : Come from the detail “Whished date” and use to generate the
PO*
- Qty : Used to generate the PO*
- Gross price : Come from the detail and used to generate the PO*
Expenses :
It’s the same for service process. You manage the rest to be done. You have on
the right of the screen the rest to be done entered in the SR, and you can update
it from the situation. Or generate new mission order.
If the rest to do is different to zero you will generate (depend on your setup) a
new service request or update the requirement of an existing SR
- Planned : come from the detail

- Real at last situation : come from all the responses on SR link to this detail
item, that have been done at the previous situation
- Real since last situation : come from all the responses on SR link to this detail
item, that have been done since the previous situation
- Corrected : Sum of change the plan of this item that have been entered in
previous situation.
- To correct : Change the plan of this item. New planned value = Planned +
Corrected + To correct
- Remains to be done : Difference between the new planned value and what
have been ordered.
Turnover :
The last tab allows us to manage invoicing. How to input depends on how you
decide to invoice (step, situation…). You see theoretical turnover progress.
You can also manage how to deduct prepayment for this situation and this
invoice
Planned
- Qty : Qty sold, come from the detail
- UP : Unit price, come from the detail
Invoicing
- Billable previous : Turnover advancement* at the previous situation
- Billable for this situation : Turnover advancement* from the previous situation
- Theoretical advancement : Turnover advancement* for this situation
- To invoice from prev situation : Difference between the theoretical
advancement and the actually charged at the previous situation
- Actually charged : Sum of the invoices link to this detail
- To invoice for this situation : Difference between the Theoretical Advancement
and the actually charged.
Steps
- Planned stage : Description of the stage
- Expected amount : Calculated amount from the detail
- Realized : To manage the invoicing of each step. No possibility to change the
amount
Prepayment
- Method : How to deduct prepayment on this line
- Amount entry : you have to enter an amount
- Percentage of invoice : you have to enter a percentage of the invoicing
amount
- Normal : an automatic maximum deduction will be done
- Amount : Enter the amount to deduct
- Percent : Enter the percentage of invoice amount to deduct
You can choose by setup what you want to track on project and to see on
situation.
You have to setup the event you have tracked and that you want to see in the
situation. If you don’t manage this setup you will have no actual in the situation.
It’s done using a dedicated validation code that will populate a dedicated table. It
will optimize the calculation, allows to manage the data created from and since
the previous situation and allows to exclude some tracking to the situation. (i.e.
internal time spend, auto training time…)
The specific table (VALGASSIT) allows us to manage what is imputed to a

situation and what is imputed to an other. We can also manage how to increase
the value of the work done in services module.
As I said before, each detail of a sold item includes :
•A "Purchasing" tab,
•A "Services" tab,
•A "Manufacturing" tab.
All of them can have one or more lines.
The launch of a project in production will generate documents in X3 : purchase

orders, RS, down payment invoices, sales invoices, or work orders
Every event realized on the project will be realized in connection with one of the
posts of the line
It allows the tracking of the commitment and of the realized and the rest to be
done of each item, and if need to be, to straighten certain items.
We will see 4 parts todays :

- Budget generation on project (which will be done using the document
generation that does an import)
- Commitment generation from SR requirement (which is harcdoded generation)
- Journal entry for actuals (which is done using the document generation and an
automatic journal)
- Journal entry for accruals (which is done using the document generation and
an automatic journal)
The Services Request process allows to manage services (time spent or product
track on Services Request)
The Services request can be generated manually, from a project, from a recurrent
contract…
The SR requirement defines the operation code you’ve planned to track on the
SR. The SR requirement is like a Services Order so it can generate
Commitments.
The tracking allows to declare what has been done. It can generate journal entry
to manage accounting cost management for example
The journal entry or budget creation use the document generation function. It will
follow the same process.
Commitments don’t use this process to be more actual.

Project situation = operating account project
The project and detail define the budget of the project

The Services Request and purchase order on project define commitment
Actual are managed using PO, Receipt, Shipment and Services Responses.
The revenue come from the project invoices
In fact each project step or flow document can have its corresponding in
accounting.
Project financial situation = Closing operations (accrual, wip, Received Not

Invoiced, Not Yet Invoiced)
Person : link to a user to identify his dimensions

Ope / response type : link to a setup of operation per response type, where you
can define default dimensions
Resource : link to a resource record to identify its dimensions
Project : link to a project header to identify its dimensions
Contract general : link to the header contract dimensions
Contract invoicing : link to the invoicing tab dimensions of contract header
Contract SR : link to the SR tab dimensions of contract header
Service Request : link to SR dimensions
Contract line : link to contract line dimensions
This function generate dimension copying an existing dimension and changing

the code and the description of this template.
The objects allowed to manage dimension generation are :

- Customer
- Supplier
- Contract line
- Installed base
- Project
- Services Request
- Recurrent Contracts
BMO = Budget Miscellaneous Operation
The budget entry is generated from the project detail data using a situation. This
situation have to be ticked as budget situation.
The validation code for budget generation must be setup in detail type or project
type.
This generation will use the generation of documents.
You can manage the period distribution of each item

In the detail you will manage start date and end date for the budget
corresponding to the detail. So the distribution will be done on the period defined
in the detail. In this case, the first period of the distribution, correspond to the
start date of your detail.
In the detail of your project you manage product code. To generate budget you
need to manage account number.
This table help us to know how to transform a product code into an account code.
We define the line we have to use in the accounting code depending on where
the product is entered in the detail.
The budget code is entered per detail

Your product have an accounting code in the product file.
This code gives one account number per line.
If you’ve setup per budget code the line you want to use we can determine which
account number to send in budget.
For example the same product using in two tabs can generate two different
account number if it’s used for cost management or sales management. That is
to say one time for credit and one time for debit.
As Budget generation use the same process as other documents generation you
need to setup validation code to generate budget.
Keep in mind, the validation code defines what you have to generate and some
default values.
For budget generation, as it come from data in detail you have to enter the
validation code in the project type or in the detail type (if you’ve specified in the
project type that you want to manage it at detail level.)
Over each object of the X3S module, an option allows, in an only one action, to
launch the dump into the temporary table and the generation of documents.
To do so the tag Postponed generation must be set to NO. But in this case the
grouping will be effective only for the elements generated by the same time.
Keep in mind : the document generation is in two parts the first one create
records in a pre-validation table. The second one scan this table, manage the
grouping method and generate the documents.
Until now we’ve seen in project detail how to manage product code, quantity,
amount… and how to generate purchase flow, services flow or invoices from
these planned data.
To generate budget we miss few information :

- How to distribute the amount per accounting period. To do that you have to use
a periodic distribution for each product code of the detail
- To manage the date of this distribution, we need start and end date : for
services we have these information, for other you need to populate two
dedicated fields in the last tab
- Last but not least data missing is the budget code on which we will generate
the amount. So in the last tab you also have to enter this field.
Budget Miscellaneous Operation
Remind with theses setup we will use a situation ticked as budget one. When you
will validate the situation it will generate the BOM.
The BOM will be generated in two times, creation of record in pre-validation data
and after generate the document.
It will be in one time or not depending on the setup of project type (you can define
postponed or not for budget)
In the detail screen you can look at the distribution for each item but you can’t
modify the distribution calculated.
You can modify manually the distribution calculated in the situation screen.
If you correct the plan (using the field “to correct” in situation) or if you change
manually the distribution, the situation validation will generate an adjustment
entry. Just the difference between the actual budget and the new one defined in
the situation.
Using this process you transform a project operational plan view into an
accounting budget point of view.
CFO and Project manager share the same information.
The project side define the plan so in accounting term the budget.
From a Project you can generate PO or SR. PO in accounting in a commitment.
So SR can also be viewed in accounting as a commitment.
In fact it’s the SR requirement which will be linked to a commitment.

Reminder : the SR requirement can be populated by the project detail data when
you create a SR from a situation.
In an other view to understand how services works on budget commitments and

journal entry in comparison to the purchase flow
You have corresponding between SR and PO, in fact a SR can be viewed as a

service order. And a response can create entry in the journal. It’s the next point of
this training.
Two setup are needed to activate this functionality of commitment generation.

We just have to identify the SR type which will be concerned and the operation
code which will be also concerned when they will be used in SR requirement.
Remember operation code defines the task to do (in SR requirement) and

the task done (in Services Response).
In SR type, you will define if you want to generate commitment.

Like for budget we need to transform an operational view in an accounting view.
To do that we need to convert a product code in account number. So we need to
define the line number of the accounting code to determine the link between
product and account.
If there is no product code in the SR requirement, we will use the default product
code define in the SR type.
*Forced manually in the situation
Use right click from SR requirement to look at the corresponding commitment
So this is an example of commitment evolution :

- You’ve created a R from a project where the plan is 10 Days.
- You first track 4 days
- When you validate the days you’re commitment is update (10-4=6)
- You calculate a new situation and change the remaining from 6 to 8 (you need
more time to complete the job). When you validate the situation it will update
the SR requirement and the Commitment to 8 Days
- You will next track 5 days
- The response validation will update the commitment (8-5=3)
Warning : No document generation in this case

To keep in mind : in the first day we have seen how to generate document from
the service response.
It allows to manage several possibilities.
Now we just focus on the journal entry generation.

It will work like other document generation on Services Reponses
To setup the document generation on Service Response you have to setup a new
movement to generate.
On operation per response type you define the validation code and the valuation
method it will create records in valgas.
The validation code define using param 1 and param 2 the automatic journal* to
use and the level of group (one entry per operation, per response, per SR)
*Automatic journal : accounting setup to define how to generate a journal entry. In

our case it has to use valgas data
To sum up :
- You will order for a service : it’s a SR it can generate commitment
- You will track time or product spent : it’s a response
- The response validation can generate documents : in the pre-validation data
- The document generation will generate the journal entry with the accounting
task to process the journal entry.
The process we have talk about until this point is link to an operational point of
view.
We managed product code quantity and operational documents.
To obtain a Global project review the operational situation as to be completed

with an accouting situation that allows to manage for example accruals.
The accounting situation is calculated for a period. It uses the data of the last
validated operational situation in this period.
It doesn’t manage data at a product level but per project detail it aggregates one
amount for internal cost, one for external cost, and one for revenue.
It allows to generate journal entry. A maximum of 5 journal entries can be setup
per accounting situation.
On line of the screen give you the calculation of the revenue advancement using
a prorate between your costs tracked and yours costs planned apply to the plan
cost.
WIP = could be used in case we don’t post each time tracking during the period
The setup of detail type give the availability to setup 5 item. Each can define how
to calculate the amount to use, and which validation code to use. The validation
code defines that we want to generate documents. It will use the generation
documents flow. It contains the automatic journal to use.
Standard automatic journals for accruals are not included today. (patches 17)
The formula defines the amount to calculate. The bottom of the screen gives
detail on the variables you can use. This formula and the setup of the validation
code and automatic journal allows to customize the revenue and accruals
recognition.
- Code : Non entered code just to identify the line corresponding to a journal
entry
- Formula : Use X3 formula with fields from the accounting situation or with the
variables to define the amount to use
- Conf code : Validation code that define what to generate
- Post gen : Postponed generation. If ticked tha validation of the accounting
situation will create the pre-validation data and generate the journal entry (if
the accounting task is on)

To sum up the flow :

- The project define the budget using detail.
- An accounting budget can be generated using an operational situation.
(generation is done when you validate)
- The validation of the operational situation can also generate document as
sales invoices, PO, SR…
- Theses processes generate cost and revenue on the project
- The Accounting Situation make a project review with a financial point of view. It
can generate closing journal entry when you validate it.
It’s a project dashboard
Header :
Site : Criteria for project selection. If blank you can select project on all site. If
populated you can manage project of the site chosen.
User : Criteria for project selection. If populated you can only see situation on
project where project manager = user.
Sales rep : Criteria for project selection. If populated you can only see situation
on project where project rep= sales rep.
Project : Project number of situations shown in tab “situations”

Status / Situation : Situation shown in tab “accounting”
Calculated date : Date of the situation in progress
You can have only one ongoing situation each time.

Right click :
Recalculating = Refresh situation data
Delete = cancel situation
The situation validation is irreversible.
Accounting :
Each line correspond to a type of amount, each column correspond to the value of
this amount in different time of the project life or some calculation.
Line
- Income / Revenue : define the turnover the revenue at different stage
- The realized internal charges / Actual internal costs : costs tracked on SR
(correspond to the services tab of the detail)
- The invested internal charges / Internal costs commitments : costs in SR
requirement
- Invoiced external charges / Invoiced external costs : Cost on purchase invoices
(correspond to the purchase tab)
- Gross profit : difference between revenue and actual internal cost and invoiced
external costs.
- Invested external charges / External costs commitments : PO cost
- Received external charges / receipt external costs : receipt of PO on your
project
- Delivered external charges / Costs shipped : sum of the cost shipped
- Charge progress / cost progress : Sum of the costs tracked on the SR and the
purchases received or shipped (depending on the setup of the quantity
advancement on the detail type)
- Weighted income progress charges / Cost prorata on revenue : Cost progress
divide per the sum of planned costs multiply per planned revenue
- Accruals / Invoice to be issued / Invoice receivable / Accruals / Work in
progress : are calculated per the formulas setup in the detail type
Column
- Planned : Come from the detail data
- Previous total : What was the previous actual
- Rea / Tracked since : New amount corresponding to the line done since the
previous accounting situation
- Tec prog / Actual: Sum of previous actual + tracked since
- Op correction : Sum of the corrected amount in operational situations
- Internal prog : Internal progression, Actual + Correction
- End correction : Correction you can enter in the accounting screen (only for
actual internal cost)
- End prog : End or Accounting progression = internal progression + end

correction
- RTD : Remains to do = planned - end prog except if your are on revenue in an
invoicing mode that doesn’t allow to invoice more
- Total at term : End prog + RTD

PJC501-Project and Job Costing - Student Booklet

Uploaded by

Document Information

Original Title

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

PJC501-Project and Job Costing - Student Booklet

Uploaded by

Copyright:

Available Formats

TRAINING PJC501 – Project and Job Costing – Student’s booklet -1-

TRAINING PJC501 – Project and Job Costing – Student’s booklet -2-

Yellow : Shared function

R&D Project Project type

Detail type Engineering Design

SR type Analyse SR Training SR

Recurrent contract is an option

Recurrent contract allows us to generate periodically Service Request or invoicing or

Contract type Rent

Doc managed Invoicing

Contract type Maintenance

Operation Code Time Travel Time

Operation Code Time Travel Spare Time Travel Spare

With this part you have a full X3 integrated activities process.

A Service request can be generated by a project detail using a situation or by a contract

Three ways are available to track on a SR :

We can manage several type of SR or interventions type, allowing several input

Tab Contract Revision / Message

Tab Service Response

IP, CR, FI, CL : SR stages

- Control code : define a group of operation code

- Triggers : operation code of the actual response line

It needs to be enable to be used

- Type of operation : 3 types are available (product, service, resource) depending on

BILL = Billable NON-BILL = non billable EXPENS = Expenses

This depend on the setup of operation per response type.

- Negative quantity : Allows to track negative quantity if ticked

The Service Request :

You can track on a Service Request using 3 ways :

- Calendar : Can link a specific calendar to the SR

- Routing : The routing allows us to preload a need to the SR.

- Adjustment: The regularization generates the inverse quantities of those entered. It

Adjustment = negative value

Service response + adjustment is like a credit note to correct a first response

(more example next slide)

If Project Implicit or hierarchic ticked no approval process. Approval is done in the

This mechanism allows the generation of documents in accordance with the

Some events can generate data in the pre-validation table

The pre-validation table is used to manage :

The grouping code is entered on the origin

- Validation grouping code : Use as a criteria in the document generation, this

add the project number and the product code

If these fields are blank the default values will be used.

Two possible types, generation of new documents or updating of existing

Param 1 & Param 2 : Contextual parameters linked to the type of

Determining formula of the generation

Inverse code to be applied if negative quantity

Can the recording in temporary table be editable

Automatic statuses in the table VALGAS

- Generation condition : Determining formula of the generation, if the

The recurrent contract allows to generate periodically SR or Sales invoice or

For example let's consider an installation and maintenance contract : It allows

what do the Recurring contracts y manage ?

We can have dedicated services request type Reparation and Preventive

- Report : Specify a report per contract type

- Modification authorized : Are you allowed to update the contract status /

This function is used to define the different frequency of SR generation used in

- Active : The setup can’t be used if is not active

Forbidden period tab :

- Project : Informative link with a project

(To generate anything a contract needs to be validated)

- Supervisor : User who supervise the recurrent contract

- Authorized validation : If ticked you can post the contract. Allows to