Stop channel communication. Activating this field will stop channel processing with message ‘The Channel is not active - raising the error’ (idocs will not be transferred to SAP FSM).

When the ‘Bulk processing’ option is enabled, objects sent to FSM are removed from the SAP standard queue (processed from a system perspective) and placed into an internal, dedicated Connector’s queue. If the number of objects reaches the predefined limit or there are no more relevant objects in the standard queue to select, the Connector combines all the objects and sends them to the message broker in a single call. This optimization ensures that the related web service is invoked once instead of being called individually for each message. The maximum number of messages that can be sent together is controlled by the parameter ‘Transactions per LUW.’

Enabling this flag can improve message sending time in highly loaded systems, but it must be used cautiously. The solution relies heavily on data selection from the ARFCSDATA table, so it’s possible that obtaining data from this table may take longer than the system saves by limiting the number of web service calls.

The FSM Connector can place selected objects (based on Low priority queue setting in /PACG/ECM_CLSASSIG) into a so-called low-priority queue.

Since there is no inherent prioritization of queues, this is achieved by dynamically pausing and starting the low-priority queue based on the number of elements in the standard queue. Two parameters control this behaviour: ‘Activate low-prio queue’ and ‘Stop low-prio queue.’

Specifically, if the number of objects in the standard queue drops below the specified ‘Activate low-prio queue’ threshold, the low-priority queue is activated. Conversely, if the number of elements in the standard queue reaches the ‘Stop low-prio queue’ threshold, the low-priority queue is paused

‘Stop low-prio queue' parameter must be higher than ‘Activate low-prio queue’.

Upper threshold at which low-prio queue is paused.

Specify which queue will be used for processing of outbound confirmations. The options include:

• Standard queue - /PACG/ECM_STD_OUT_xxxx [where ‘xxxx’ is the company number]

• Confirmation queue - /PACG/ECM_CNF_OUT_xxxx [where ‘xxxx’ is the company number]

When enabled, the Connector can utilize a so-called express queue. This queue operates as follows: when an object is added to it, all other Connector-related queues are paused to make room for processing. Once the express queue is emptied, the FSM Connector resumes previously blocked queues. Objects can be added to the express queue using the BAdI /PACG/ECM_IDOC_EXP_QUEUE. The BAdI features only one method, SET_EXP_QUEUE, which determines whether a message should be added to the express queue based on received data.

If checked, inbound idocs will be created and processed using the inbound queue (SMQ2), instead of the outbound queue (SMQ1). Inbound confirmations will also be processed using the inbound queue.

Expand
title Examples
Example of an inbound message processed by the Inbound Queue (SMQ2): Image Added Example of an inbound confirmation processed by the Inbound Queue (SMQ2): Image Added

BAdI for parallelization of inbound processing

Implement BAdI /PACG/ECM_IN_QUEUE to create more than one queue for inbound idoc processing. The BAdI can change queue name based on company ID and idoc content.

Image Added

Image Added

Specify which queue will be used for processing of inbound messages. Inbound messages used to be processed by queue /PACG/ECM_STD_IN. The current options include:

• Standard queue - /PACG/ECM_STD_WS

• Standard queue for each company - /PACG/ECM_STD_WS_xxxx [where ‘xxxx’ is the company number]

• Status
  title (S4)PACG 200 SP10

  bgRFC processing - to improve performance of inbound documents processing, use bgRFC instead of tRFC mechanism. When selected, after clicking enter, an input option 'Select bgRFC destination' is displayed:

Image Added

This additional field is ‘bgRFC destination name’ as defined with SBGRFCCONF transaction. ‘bgRFC destination‘ is a mandatory parameter required for processing to start. 

Specify which queue will be used for processing of inbound confirmations.

Inbound confirmations used to be processed by queue /PACG/ECM_STD_IN. The current options include:

• Standard queue - /PACG/ECM_STD_WS

• Confirmation queue - /PACG/ECM_CNF_WS

• Confirmation queue for each company - /PACG/ECM_CNF_WS_xxxx [where ‘xxxx’ is the company number]

• Status
  title (S4)PACG 200 SP10

  bgRFC processing - to improve performance of inbound documents processing, use bgRFC instead of tRFC mechanism. When selected, after clicking enter, an input option 'Select bgRFC destination' is displayed:

Image Added

This additional field is ‘bgRFC destination name’ as defined with SBGRFCCONF transaction. ‘bgRFC destination‘ is a mandatory parameter required for processing to start. 

If either for ‘incoming confirmation’ or ‘incoming messages’ the ‘bgRFC processing’ is selected also bgRFC destination must be selected. The bgRFC can be defined using 'SBGRFCCONF' transaction.

During inbound processing, FM /PACG/ECM_S_INPUT responsible for initial FSM message handling, is called by default without destination specified. This means that tRFC with destination NONE is used, which can cause performance issues (destination NONE can be used by various other processes, it can cause delay of even 15 minutes and cause transporter to resend a message to SAP). To limit negative impact on inbound processing performance, enter in the hereby described field the name of an internal or logical RFC Connection (Destination) dedicated to FSM Cloud Connector processes. The RFC Connection should be created and adjusted performance-wise beforehand in transaction SM59.

During inbound processing, web service function module /PACG/ECM_S_INPUT is called by default in background task. This is because FSM Cloud Connector tries to minimize the synchronous part of the call. On certain landscapes synchronous processing of IDocs however may prove to be more efficient. Enable this field to activate synchronous processing of inbound messages.

This flag enables and disables the use of failover mechanism in the Connector.

Remember, in order to make proper use of failover it requires further configuration steps. Enabling only this flag may lead to unexpected side effects.

This parameter is used in the two scenarios.

• first one - it controls the number of processes of idocs generation in the single commit (for example, when sending equipment to the FSM this parameter says for how many of them idoc will be created and to the port in the single commit)

• second one - it controls number of messages read at once in the queue and eventually number of messages sent in a single call to the Message Broker reducing the overhead caused by executing web services separately for the single messages

When RESEND is started, Connector will look for all unconfirmed IDOCS not older than defined number of days. The default value is ‘30’ days.

When the price calculation is performed using the transaction VKPB (Run new price calculation), then the materials involved in this calculation will be sent to the Cloud as a side effect. Once the material data is sent to the Cloud, the price of the material is sent as well. So, if the execution of the VKPB changes the material price, the updated price will be sent to the Cloud as well.

Definition of HASH algorithm to be used for HASH-comparison.

Allow transfer of employees (personnel numbers) who are not supposed to be FSM users (i.e. are not added in https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/975601665). Such employees are sent only as employee records, visible in FSM master data. No account-level user is created for them (therefore licence is not consumed).

Automatic transfer of non-FSM-user employees when added as responsible person of service calls

This option triggers automatic transfer of the employee (personnel number) used as responsible of a service call - if it hasn’t been sent before.

Example use case: a service order has a responsible person assigned to it (a personnel number). This person has nothing to do with FSM and should not be able to log in/consume licence. However their name/surname must still be visible in FSM on service call level. They cannot be added to https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/975601665 because this would create an account-level user and consume another licence. If this checkbox is activated, personnel numbers used by service orders (and not added to the user maintainance transaction) will be automatically transferred to FSM and exist as employee master data (with no corresponding FSM user).

Manual transfer of non-FSM-user employee

If the hereby described option is enabled, transaction https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/37138800 displays an additional checkbox - ‘Send HR persons to FSM’. When activated, employees not added as FSM-relevant users will also be transferred to FSM. This double-check is necessary to avoid transfer of too many objects.

During processing of the service order event, a lock with the order number can be set in a subsidiary table. If the lock is set and the next event for the same order is triggered, then the second one waits until the first one is processed.

When this option is enabled the system lock is not set for the processed document.

By default, during processing of the service order event, a system lock is set so if there are following events related to the same document they must wait for the first one to get processed. This way Connector can ensure the right order of objects’ processing. However it can happen that multiple events are raised for some document and the order in which they are processed is not important and locking mechanism significantly increases the processing time. In such cases, enabling this flag can improve overall performance.

Due to various historical reasons, user IDs for FSM users based on SAP user names were initially always prefixed with ‘U/’ - similarly to how user IDs for FSM users based on HR personal numbers are prefixed with ‘X/’. However, during a certain period, the user’s ID was also used as the FSM login name, making the ‘U/’ prefix inconvenient. As a result, a feature flag was implemented to allow disabling the ‘U/’ prefix (while IDs for FSM users based on HR records still retain the ‘X/’ prefix).

However, since the user’s ID and ‘FSM login name’ became separate properties, this flag has become essentially irrelevant - the ‘FSM login name’ is now always sent without any prefix.

If switched on the SAP user of the cloud user is used to post changes in SAP whenever technical possible. Otherwise the technical user executing the IDOCs is used for postings and will appear in change documents.

Please note that in case where the users are created just with Personal number without ERPUSER marking this option will lead to an error in processing idocs such as "No user found".

When this feature is enabled, time breaks will not be included in the overall duration of time effort or work time during split calculation.

By default, breaks are included in work duration during split calculation. This may result in ‘extra' hours being reported not because a technician worked more but because they took a break in the meantime. This settings allows to reduce impact of breaks on calculated labour costs.

Expand
title Example
Time entry recorded for 9 hours (10:00-19:00) with 1 hour break. In the split customizing, activity type 101 is used for the first 8h of duration, 102 for 8-12h of duration.   The following time entries will be created, depending on the value of ExclBrkSplitDur setting: Image Added

A field in COBL Structure (an append field or a standard field) which can be used when the service order confirmation is created. It allows the costs analysis to be related to the operations of the service orders. It is used also by the Confirmation Cockpit – the link between the CO document and the operation of the service order.

Necessary for expenses to be properly posted to travels when using E4C activities (based on customizing in https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/31953879 ).

This property enable the use of Business Partners (BP Model) functionality by Connector. It is enabled by default in the S/4HANA systems.

This flag must be enabled always when partners in SAP system are maintained using the BP transaction.

Expand
title Example
If the field is not checked, then inbound Contact objects (e.g. generated during customer creation in the Self-service module) will be stored as ‘Contact Person’ of the related Customer. This setting (BP used = false) is recommended for SAP ECC systems. Image Added  If this field is checked, then inbound Contact objects will be stored in SAP as new Business Partners with partner role ‘Contact Person'. Image Added Please note that this setting (BP used = true) is recommended and automatically defaulted for SAP S4 systems

Enabling this feature will result in each change in the service order, triggering the sending of all activities linked with the given order (even those not relevant from the perspective of the activities).

Path to find the conversion tool for pictures

How to convert pictures when printing them as part of a Checklist. This is because SAP can only work with 256 colours in a Smartform.

• S – Server Conversion, requires a conversion tool in SAP

• G – GUI Conversion, requires a conversion tool on the client

• N – No Conversion, pictures remain unchanged when printed

The checklists, which are bound to the equipment via the GOS Link, will be also presented as the documents in the Serial Number History.