...
Category | Description | |||||
---|---|---|---|---|---|---|
Administration FSM Cockpit FSM Cockpit – IDocs report & Hotspots FSM Cockpit – IDocs report & custom IDocs New Checks for /PACG/ECM_QSTATUS
FSM Users’ Management Learn more: Mass User Upload Companies’ deletion Anchor | | 390de685-6523-4863-8384-c1f3036a5389 | 390de685-6523-4863-8384-c1f3036a5389 | Deleting objects in FSMBusiness Partners | Regions | Work centers as regions Learn more: https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/37136514/PACG+ECM_SC_GR+Group+region+for+service+calls+activities#Include-Hierarchy-(S4)PACG-200-SP15 Version check in /PACG/ECM_SEND_DELRQ Enhancement of /PACG/ECM_DEL_MIDMAP The selection screen of /PACG/ECM_DEL_MIDMAP was enhanced and deletion by company Id has become an available option FSM Cockpit - IDoc report To avoid further confusions the ‘REPEAT’ button was removed from the screen showing incoming IDocs since it is not possible to repeat processing anyways. Export and import transport - Connector tools These two transactions have now the authorization checks added and new authorization roles have been created specifically for these two reports. |
Equipment and functional locations | New selection class A new selection class for equipment and functional locations has been implemented and delivered in this release New event for triggering of functional locations With a new event type dedicated to functional locations, it is now easier to control when equipment and functional locations are sent to FSM - independently from each other. Send equipment and functional locations in batches Paging functionality was added to sending reports for equipment and functional locations. This new feature allows transmission of large amounts of data without causing program termination due to high data volumes. Send equipment or functional location with service order Performance improvements related to the sending of equipment (and functional locations) only if required by service order. Previously, these were sent every time sending of service orders were initiated, bypassing the hash verification functionality. From now on they will be sent only when truly needed. Check if parent is FSM relevant When sending equipment or functional location having the parent and the parent is not FSM relevant, the object itself will not be visible in FSM. To avoid such situations the additional check was implemented - Connector verifies relevancy of parent and removes it when irrelevant. | |||||
Attachments | Data transfer restrictions attachments' age. | |||||
Production Orders | New transactions | Productions Orders as Service Calls
| CS Service Orders | |||
FSM Activity | Fiori App Operation’s control key and FSM activity status | |||||
Reserved materials | Returns of materials in customer consignation process Arrival date determination Arrival date determination report Learn more: https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/1722679297 | |||||
Equipment | Characteristics sent as remarks Learn more: https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/31953680 | |||||
UI modification | In transactions /PACG/ECM_COMP and /PACG/ECM_CCUST entries’ deletion got suppressed. Since Connector delivers dedicated reports for deleting companies data deletion of companies deletion is not only no longer needed but can lead to data inconsistencies | |||||
Employees | Changes in the HR Infotype 0105 using transaction PA30 are now transferred to FSM automatically – relevant even is raised. Valid subtypes of infotype 0105 for which this will happen are | |||||
| ||||||
Service contracts |
| |||||
Worktime patterns | Dynamic worktime patterns | |||||
Time effort configuration | Order type dependant time efforts Time effort configuration gained another level of granularity. From now on it will possible to handle incoming time efforts depending on the type of order they refer to | |||||
FSM Activity | Activity maintenance transaction | |||||
Performance | Incoming XML handling There are several objects in the Connector which require sending of the ‘Generic IDoc’ as a confirmation. For this to work, an incoming XML must be stored in the system. Until now they were saved as the regular attachments. With the newest connector, this has changed and from now on these XMLs will be stored in the dedicated table. | |||||
New transactions |