Professional Documents
Culture Documents
Trademarks
Intergraph, and Intergraph logo, PDS, INtools and MARIAN are registered trademarks of Intergraph Corporation.
Microsoft and Windows are registered trademarks of Microsoft Corporation. Other brands and product names are
trademarks of their respective owners.
General
Table of Contents
General..............................................................................................................................33
MARIAN™ Service Packs (Release Management Change) ....................................................33
API Changes ............................................................................................................................33
1271 ID: New Entity Activities................................................................................................34
1280 ID: Multiple Selections for Documents ..........................................................................35
1457 ID: Report Parameters Saved by User.............................................................................35
Site Control.......................................................................................................................58
1196 ID: Material Transfers Between Warehouses .................................................................58
1471 ID: WinZIP Site Export Files..........................................................................................60
1541 ID: C2001/C2004 Report Button ....................................................................................60
Interfaces ..........................................................................................................................61
1323 ID: INtools: View for TAG Import Free Format with 6th Level ....................................61
1414 ID: PDS Procedures for Project Wide List .....................................................................62
1446 ID: BOM Import of Special Material with Tag No.........................................................62
1474 ID: Project Specific Spec Type Procedures ....................................................................63
Index..................................................................................................................................64
General
MARIAN Service Packs (Release Management Change)
Beginning with MARIAN® 5.5.3, Service Packs will replace individual patches.
Service Packs (SPs) ensure that all customers receive quick and easily-applied
updates. Service Packs replace the bi-annual maintenance releases. Customers should
contact Intergraph® Support or the MARIAN Service Center (MSC) to receive a
Service Pack.
Each Service Pack (SP) will include a list of the fixes and change requests it contains.
SPs will be cumulative for each full version of MARIAN. For example, a customer
working with SP 1 who installs SP 4 will also receive (in SP 4) all the necessary
modifications of included in SP 2 and SP 3. This way, customers can choose to not
install a SP that has fixes or changes that they do not need. Installing SPs will save
customers valuable time previously spent troubleshooting specific patches.
API Changes
For all procedures in the following APIs, an additional parameter p_commit_ind has
been added:
• m_api_ish
• m_api_poh
• m_api_poli
• m_api_uoc
This parameter allows you to control when changes are committed to the database. If
you omit this parameter or pass a Y to the procedure, data will be committed
immediately by the API procedure. If you pass an N, the data will not be committed
by the API procedure.
A new field for activities has been added on Requisition, Requisition Line Item, and
PO to facilitate the communication with PRISM.
Since all scheduling and planning systems like PRISM, PRIMAVERA, and SAP PS
are working with activities, this field makes it easier to link MARIAN with these
systems. The activities are loaded into the project with the appropriate ROS (required
on Site) date. Each Requisition line item will have an ROS date determined by the
activity stored at the requisition header level.
A new entity was created for activities. To each activity, you can enter a schedule that
can be considered as a ROS = Required on Site Date.
Requisition Line Item can be linked to a particular activity, causing the ROS Date for
the Requisition Line to be set to the date of the activity. If the ROS date is changed
after the activity was linked, the ROS Date is removed.
When loading the same activities again, MARIAN remembers the original Activity
date. A new screen is available to see which Requisitions are affected by a potential
change of the activity.
The problem in previous version was that a Valve, which is a standard valve with an
existing Ident, was given a Tagnumber and the Item Type SWT in B.20.01. After
running them MTO, this ItemType was lost and turned into SOT that is the one from
the Commodity Code.
With Part Access Control, it is now possible to completely control access to the
equipment by specific users. As a result of this, it is possible to allow users to
insert/update attribute values for only specific types of equipment, making the saving
of work between different operating centres or departments possible.
• POS-No
• QTY
• QTY Unit
• ListStatus
• IssueStatus
If the value for ZB_TAG_UPD is Y, only users having appropriate rights according
to PAC are allowed to perform an update. The Project Default must be set to Y, and
PAC must be granted to a user before they can perform an update.
CIP procedures are available to return a report name. They can be entered in the
e-mail template.
You can now send test e-mails from R.30.01 to one recipient.
ZP_DLV_DSG is set to the project default setting when you insert a new record, but
you can overwrite the default value, if necessary.
Unit Weight
The weight for this requisition position. This value is calculated by the MTO
(together with the weight unit) if the related check box was checked before the MTO
was started.
Remarks:
The procedure used to calculate the ident unit weight is a CIP. The name of the CIP is
M_PCK_REQ_CUSTOM.WEIGHT.
Attribute Change Control also applies to attached attributes for Purchase Orders.
Change
This drop-down list shows whether an attribute or its value has changed compared
with the previous supplement.
The following list shows the available options and a description of each one.
As there is no supplement handling for inquiries, quote summaries and quote detail
attributes for these objects are always displayed as New.
In the case of requisitions and requisition line items, the previous supplement is
clearly defined. It is the requisition with the same name and the supplement decreased
by 1.
In the case of orders, order line items, and item shipments, the type of the order is
taken into account for the determination of the previous supplement. Details for each
type of order are provided in the following sections.
If the order is not the first of an order chain, in other words, if it is not the one with
the lowest supplement, the system searches for the latest change order of the previous
Purchase Order supplement. If no change order exists, the attributes are compared
with those attached to the previous PO supplement.
The attributes of the immediately previous Change Order are compared with those
attached to the current CO. If the current CO is the only one or the first one of an
order, the parent PO order is the previous supplement for the comparison.
If the value of an attribute has changed in the course of the supplements, this field
shows the number of the latest supplement with a value not equal to the current value.
If the value of an attribute has changed in the course of the supplements, this field
shows the value of the latest supplement that is not equal to the current value.
For Receivable Items, New Idents with descriptions can be created on the fly directly
on PO Line Items.
The TechnicalEvaluation is linked to the quote, meaning that if there is no quote, the
Technical Evaluation should be linked elsewhere, such as the PO. The solution is that
now Procurement can create a PO from a Requisition directly, even if
TechnicalEvaluation is required; however, they cannot approve it until the Technical
Evaluation is complete.
The following changes have been made concerning the Technical Evaluation.
The following new fields have been added to Global Update, which can be accessed
by clicking the Update button in PX.20.24:
This new OPI pre-processor functionality makes the import of purchase order
information much easier and faster. The pre-processor imports free format type files
into MARIAN by creating a translation CIP between the 3rd party procurement
system (which may be a client partner or contractor) and MARIAN.
UNITS-Codes are first compared directly and then in uppercase. For example, for the
units mm and MM, MARIAN first compares mm=MM and if it isn’t true, then
compares MM=MM.
Global Update
The Global Purchase Order Line (POLI) update can now also be used to make a
global update on Incoterm and Delivery Place.
• P3033
• P3071
• P3073
• P5016
• P5014
An order can be closed only if all material has been received, and no open OS&Ds or
incomplete outstanding work lists exist.
For orders that have already been closed, the Closed check box is enabled. The
Reverse button is available for only for these orders.
Closing an order effects the data available in screen PX.20.01 Expediter Workload. In
the workload, only orders that have not been closed can be selected.
Since the data that has to be queried to perform the checks is constantly increasing in
the course of a project, you should restrict the query, particularly in the Order
Number field to reduce response time.
Orders
All purchase orders and notices of commitment that have been approved are available
in this module.
Notices of commitment are available only if they have not been converted into a
purchase order.
Order Number
Type
NC = Notice of Commitment
PO = Purchase Order
Supplier
Origin
The name (code) for the origin (branch) of the order appears in this field
Buyer
This field contains the name of the MARIAN user who is the buyer for this order.
Received
This check box is enabled only if all material of the order has been received, meaning
that the quantity (or even more) of all item shipments has been received on site and
has been posted to the inventory.
If you used the split tag functionality, you can receive only the master tag or its detail
tags. Regardless, material is regarded as received if either the master or its details
were received completely.
OSD
If any open OS&D exists for the order (including all approved supplements of the
order) this check box is disabled.
All OS&Ds created by traffic and by site, either for a release note, a package, or a
package item, are taken into account.
OWL
This field indicates whether all outstanding work lists have been completed.
This checkbox is checked if no outstanding work list exists and is incomplete for any
item shipment of the order (including all approved supplements of the order.
An order cannot be closed if any outstanding work list has not been completed.
Closed
An order is regarded as closed if the closed date has been set for all approved
supplements of the order.
Close
This button is enabled if the order (including all approved supplements and approved
change orders) has not been closed, so long as the following conditions have been
met:
• All material has been received, and the Received check box is checked.
• No open OS&Ds exist, and the OSD check box is marked.
• No incomplete outstanding work lists exist, and the OWL check box is
checked.
When you click this button, the PO Close Date field is set to the current date for the
order, including all approved supplements and change orders.
If the order is based on an inquiry, this order is the last (or only) one that is based on
this inquiry, and it is to be closed, the PO Closed Date field in P.30.11 Create
Inquiries is also set to the current date.
Reverse
This button is active for all orders that have already been closed.
When you click this button, all changes that were applied when clicking the Close
button in this module are turned back. In other words, the date fields are reset to
NULL.
This screen provides an overview of the development of costs and ordered quantities.
The order level displays the amount of that material ordered along with this order,
including all previous supplements and the change in costs compared to the previous
supplement.
The line item shows the same information, this time related to the individual line
items.
Additionally, you can see what quantities have been ordered so far, up to and
including the supplement you are viewing, and what this means compared to the
previous supplement.
Costs always include not only the line item costs but also all attached other costs.
Other costs attached to the order header are also taken into account on the order level.
You determine how often you want to take these snapshots. For example, you can
create snapshots daily, weekly, or monthly.
Your job definition in A.60.45 (field 'Executed PU') should look like this:
BEGIN
mpck_login.select_login(#US_ID#);
m_pck_req_progress.calc_req_progress;
END;
The number of requisitions of different statuses and the number of inquiries, quote
summaries, and orders are calculated.
For the budget, compare the original and total budgets of engineering requisitions,
and their associated orders are totalled. The totals that are calculated are grouped by
discipline and determined over all disciplines.
For all totals that are calculated, the discipline of the engineering requisition or the
associated engineering requisition(s) is decisive. Thus, requisitions are often created
in different disciplines, but the work in procurement is done in one overall discipline.
Only approved objects (requisitions, inquiries, and such) are taken into account.
This screen consists of two overview windows and several detail windows.
The first overview window shows the requisition progress. Double-clicking on any
"counter" field opens detail windows where you can see all requisitions, inquiries,
and so forth for the selected discipline.
Double-clicking on the discipline in the first window opens the detail window of the
budget compare.
The second overview window contains the budget compare and is opened by clicking
the Budget Compare button. Again, double-clicking on any record opens the detail
windows.
From each detail window, corresponding screens for the object are available by
double-clicking. For example, screen R.30.11 Requisition Cross Reference is opened
when you double-click on a requisition number, or screen P.30.32 Quote Summaries
opens if you double-click on a quote summary.
Please note that only the accumulated values are snapshots. When looking at the
details, you will always see the data that are actually in the database.
Site Control
1196 ID: Material Transfers Between Warehouses
2. Receive this material by Direct Receive. Material is booked into the inventory
again.
The Propagate function causes the system to display all idents belonging to the
selected MTR/Voucher No. After posting the received quantities, you must update
the inventory in both warehouses (source and destination). Quantity discrepancies
between positions on the voucher and received quantities will generate an OS&D
report.
Interfaces
1323 ID: INtools: View for TAG Import Free Format with 6th Level
A view for importing instruments from INtools is now a Free Format view and
supports up to six levels.
For further details, refer to the MARIAN INtools Documentation in the Online
Reference Library.
Due to this new functionality, the PDS interface procedures can now be implemented
for different projects accordingly, enabling the companies to better serve from one
MARIAN instance several PDS instances with different settings in different projects.
This functionality is available using the following three types of procedures:
• SpecProcedures – the known procedures that are run after the generation.
• Standalone Procedures – executed at any time by clicking a button in
PDS.10.03.
• Project Wide Lists Procedures – executed after the generation of the
Project Wide Lists.
A new BOM Config Item (PDS.30.01) for Item-Rule was created that makes it
possible to determine the Item Type.
The link between PDS Procedure and SpecType can differ between projects even if
Spec.Type is in the ProductGroup.
Index
activities, 6 planned date, 20
API, 5 position numbers, 17
ASCII files, 23 PRIMAVERA, 6
Attribute Change Control, 13 PRISM, 6
Attribute Origin, 17 project progress, 28
attributes, 23 project-wide lists, 34
BOM, 34 receiviable items, 18
CIP, 10 report settings, 7
closing purchase orders, 24 requisitions templates, 12
comments, 22 reverse, 24
DeliveryDesignation, 11 ROS date, 7
Direct Receive, 30 SAP PS, 6
e-mail, 11 schedule, 6
expediting dates, 19 service pack, 5
Global Update, 21 site export files, 32
grouping, 23 SOT, 10
ident values, 13 statuses, 28
INtools, 33 sub-position numbers, 17
ItemShipments, 16 supplement, 14
line items, 18 SWT, 10
material transfer, 30 TechEvalCompDate, 20
milestones, 19, 22 technical evaluation, 19
MLCL, 8 TechPass, 20
MTO, 10 TechPassed, 20
MTR/Voucher No, 31 TecReqd, 20
multi-selection, 7 reports, 32
non-receiveable items, 18 user-defined report, 32
OPI, 23 USY_ID, 8
order progress, 27 Weight, 11
OS&D, 25 WeightUnit, 11
p_commit_ind, 5 ZB_QTY_UPD, 11
Part Access Control, 11 ZB_TAG_UPD, 11
PDS, 34, 35 ZC_REPORT, 32
Pertinent Area, 20 ZP_DLV_DSG, 12
PipeClass Details, 8 ZP_EXPDATE, 22
PipeClass Overview, 8
piping specification, 8