Liste des transactions WF :

LE WORKFLOW

21.SWI2_freq :

42.SWI6 :

63.SWI14 :

74.SWIA :

95.SWDD (WF builder) :

106.SWID :

117.SWB_COND :

128.SWE2 :

149.CL6BN

1810.Description of REMEDY Ticket HD0000000632411 : PR Release workflow error for ECS project

2011.Purchase Requisition 10111283

21a) With the old price 203,175 EUR = 1,934,533.83 SEK

21b) With the new price 305,075 EUR = 2,905,348.20 SEK (after modifications)

2212.Purchase Requisition 10111366

2313.CL6BN

2414.Problem description

2415.Investigations

24Swi1

28Work item deletion

Liste des transactions WF :

1. SWI2_freq :

Cette transaction permet de lister tous les WF générés pour une période et de connaître les détails d’un WF. Ainsi avec cette transaction nous sommes capable de connaître le statut d’un WF, ces intervenants et les détails techniques !

La transaction édite une première liste de tous les WF créés pour la période par type de WF:

En cliquant sur une tache une deuxième liste est éditée avec tous les WF créés pour ce type.

Pour avoir le détail de chaque WF, il suffit de double-cliquer sur une ligne de la liste.

2 types de détails peuvent être affichés : protocole ou graphique

Le protocole :

Le protocole donne le statut du WF ainsi que les intervenants et les détails techniques (workitem, etc…).

Le graphisme :

Donne une vue graphique du WF

2. SWI6 :

Cette transaction comme la transaction swi2_freq permet de lister tous les WF générés pour une période et de connaître les détails d’un WF. Ainsi avec cette transaction nous sommes capable de connaître le statut d’un WF, ces intervenants et les détails techniques !

Mais la sélection s’effectue pour un objet précis comme une demande d’achat, une commande.

cliquer sur l’icône

cliquer sur l’icône

3. SWI14 :

Cette transaction comme la transaction swi6 permet de lister tous les WF générés pour une période et de connaître les détails d’un WF. Ainsi avec cette transaction nous sommes capable de connaître le statut d’un WF, ces intervenants et les détails techniques !

Mais la sélection s’effectue sur un type d’objet comme une demande d’achat, une commande.

Ex : poste de demande d’achat : type BUS2009

Demande d’achat : type BUS2012

Commande d’achat : type BUS2012

Etc…

4. SWIA :

Cette transaction permet d’administrer les workitems liés aux Wf. Un workitem est une étape d’un WF.

Par exemple si un workitem doit être validé par une personne qui est en vacances ; il est possible de transférer ce workitem à une autre personne présente qui pourra valider l’étape du wf en cours et celui-ci pourra continuer son chemin.

Le numéro du workitem se trouve dans le protocole du wf :

Pour trouver le numéro du workitem d’une étape cliquer sur le bouton détail .

sélectionner la ligne workitem : Ensuite cliquer sur le bouton droit !

Choisir Détails :

le numéro du workitem se trouve à la ligne « Code d’identification » (dans l’exemple 4499017).

Avec ce numéro de workitem nous pouvons utiliser la transaction SWIA :

Ensuite :

Nous pouvons avec cette transaction :

valider l’étape ( passer d’un statut en attente à valider) poursuite du wf.

afficher le détail comme pour la transaction SWI2_FREQ

le protocole

détail du container ( infos techniques)

afficher la tache ( infos technique)

détail du workitem

transfert du workitem d’une personne vers une autre

5. SWDD (WF builder) :

Cette transaction permet de maintenir un wf ou d’afficher les détails techniques d’un WF.

Transaction utile pour les consultants techniques.

Avec cette transaction nous pouvons connaître tous les détails techniques d’un Wf et les modifier.

6. SWID :

Cette transaction permet de débloquer un WF quand celui-ci est bloqué.

liste des workitem en erreur :

Avec cette les workitem en erreur nous pouvons :

détails de l’erreur

le redémarrer

voir son protocole

modifier les détails techniques du workitem

7. SWB_COND :

Cette transaction permettre de connaître les conditions de démarrage d’un Wf.

Un wf est créer après un événement et si et seulement s’il respecte les conditions de démarrage !

dans l’exemple ci-dessus le wf WS7000007 ne démarrera que si la date de création est supérieur au 19.01.1998.

la condition de démarrage n’est pas obligatoire pour qu’un wf démarre !

8. SWE2 :

Cette transaction affiche les événements et les wf correspondant.

Dans un transaction : exemple ME51 ( création de demande achat) lorsque notre DA est créer et que nous cliquons sur le bouton « save » pour sauvegarder la DA, alors un événement « SAVE » est créée et de ce fait un ou plusieurs wf.

Le liens entre événement et wf se trouve avec cette transaction.

9. CL6BN

Permet de consulter les stratégies paramétrées

La commande a été envoyée sur le workflow de Christian Cuche.

Après discussion avec l'utilisateur final, ceci est une anomalie, car la détermination du valideur doit se baser sur les éléments du poste 10 uniquement et toujours d'après lui, le valideur aurait du être Léon Moggio.

Suite investigation technique : A la sauvegarde de la commande d'achat, le module fonction Z_WF_Valideur_CA détermine le valideur de la commande de la façon suivante :

lecture de la table EKKN avec tri décroissant sur la valeur NETWR

sur la valeur la plus grande trouvée en NETWR, on récupère :

1) le centre,

2) l'OTP,

3) l'ordre,

4) l'Immo,

5) ou le réseau.

Ensuite avec la table ZMX01 on détermine avec les éléments trouvés ci dessus le valideur

dans le cas de la commande 4500007660, le tri sur NETWR remonte le poste 170 qui donne un réseau = BQN01G1AUX1

pour BQN01G1AUX1, et V3 : le valideur est bien Christian Cuche.

Nous avons tenté de contacter ce jour Jean-Luc Parisot pour lui demander confirmation que le module fonction est correct (selon les informations contradictoires du end user) - pas de réponse, nous devons le rappeler demain.

Nous avons tenté de contacter ce jour Mr Christian Cuche, mais il est absent : nous devons le rappeler demain - afin de lui demander son code utilisteur et son mot de passe. Il semble qu'il récupère bien la commande dans son workflow mais a un message 'vous n'êtes pas le valideur attitré pour cette commande' - à investiguer

18/04/2007 16:52:15 e_cpg_paberl

This Case has been assigned to ABERLENC Philippe.

18/04/2007 16:52:54 e_cpg_paberl

.

19/04/2007 11:56:04 e_cpg_alagra

Utilisateur final contacté : la commande d'achat a été validée du fait de l'urgence signalée par la ME28.

KU non au courant du fonctionnement du programme - le consultant du N2 doit nous rappeler

20/04/2007 16:25:25 e_cpg_paberl

This Case has been assigned to ABERLENC Philippe.

20/04/2007 16:34:39 e_cpg_paberl

Ticket has been resolved with solution:

Bonjour,

Jusqu'à maintenant, le workflow fonctionnait normalement car les commandes étaient mono-imputation.

Depuis qq temps, les commandes sont devenues multi-imputation et le workflow ne fonctionne pas correctement.

Une évolution est cours de validation par Levallois (OK), Belfort (en cours) et Grenoble (non commencée) pour choisir comme valideur celui correspondant au poste ayant le montant le plus élevé.

( POUR INFORMATION EVOLUTION PASSEE EN PROD LE 12 / 6

En cas de problème, merci d'utiliser la transaction ME28.

Cordialement.

Philippe ABERLENC (Capgemini).

30/04/2007 19:03:41 AR_ESCALATOR

Case HD0000000657831 was automatically closed on 4/30/2007 7:00:00 PM.

Regarding Ticket HD0000000639117

Analysis of the ticket:

Workflow: WS90500004

Execute transaction SWI2_DIAG for error diagnosis of work item

We have received the following error messages for work item 1798761 as mentioned in the ticket -

We have also analyzed other work items with same profile which contains same errors messages.

We have also analyzed its work log and found that after exceeding the first deadline date it sends a mail to responsible person and delete this work item and move to the next activity which is same as the deleted one with different latest end date (Second Dead line date).

These errors were occurred during deletion of the obsolete work item (Step no- 000003) and creation of new work item for next activity (Step no- 000102).

After exceeding the first deadline date, process controller obsolete step 003 and move to next step 102.During this process first two errors are occurred that are happened in the standard function modules ‘SWP_CALLBACK_WI_DONE’ and ‘SWP_CONTINUE_WITH_NEXT_NODES’.

And because of these two errors, third error is occurred.

10. Description of REMEDY Ticket HD0000000632411 : PR Release workflow error for ECS project

PR 10111283 and 10111366 should have been directed to the "Project Dept Manager" for ECS projects. They have release codes for level 3, code SH.

What happend was that WF went to he Responsible Person (Project Manager) instead. (Today the PM made a manually foward to Göran Nyman)

I have reported this type of error 2-3 times before as I suspect the the setup for ECS ( ECS have one level less than the other Plants) don't work correctly.

Maybee this have something to do with the "Deadline exceeded" algorithm for ECS.

Regards

Jan

11. Purchase Requisition 10111283

The price is in EUR.

In the PR, we have item changes :

a) With the old price 203,175 EUR = 1,934,533.83 SEK

the release strategy selected was SG (ECS Level2-Proj)

b) With the new price 305,075 EUR = 2,905,348.20 SEK (after modifications)

the release strategy selected is now SH (ECS Level3-Proj)

12. Purchase Requisition 10111366

All is OK

Release Strategy :

13. CL6BN

14. Problem description

"Problems with Workflow in SAP MAX (PRD400) ... I have 2 error messages in my workflow but I cannot do anything with them.

Error on the first item in the workflow:

EDI: File '\\SARUG41074\SAPMNT\TRANS\SHARE\INT\SE\TIME\IN\PS\' will not be processed again

Description

An error which cannot be assigned to a specific IDoc has occurred during IDoc processing.

The error description can be viewed by executing the work item.

Objects and attachments

Message for IDoc Error Handling: E0 370

Error on the second item in the workflow:

Error at DELETE '\\SARUG41074\SAPMNT\TRANS\SHARE\INT\SE\TIME\IN\PS\' (please check file)

Description

An error which cannot be assigned to a specific IDoc has occurred during IDoc processing.

The error description can be viewed by executing the work item.

Objects and attachments

Message for IDoc Error Handling: E0 086

I don't know what todo with them? I cannot access any invoices or purchase requisition. My username in SAP MAX: lindstenp

Since I cannot do anything with them they are still in my workflow."

15. Investigations

Swi1

"Execute function" gives no result :

1. Read access only

2.

We do not have the possibility to select the function in the menu (it is certainly reserved to the agent assigned)

Work item deletion

Il arrive parfois que des commandes d’achats soient complètement validé , mais qu’au niveau du workflow elles restent en statut ‘started’.

Dans ce cas nous recevons un ticket nous demandant de supprimer le work item .

(exemple ticket N° HD694831).

Dans ce cas il ne faut pas faire une suppression d’item, mais terminer manuellement le process work flow. Pour cela suivre la procédure ci-dessous.

1°) rechercher le numéro d’identification de l’élément à compléter.

Transaction SWUE

Catégorie d’objet : type d’objet BOR.

Type d’objet : BUS2012 pour la commande d’achat (voir liste déroulante)

Evènement : l’évènement dépend de ce que l’on veut faire. Dans le cas décris on choisi RELEASED.

Cliquer sur le bouton la boite message suivante apparaît.

Saisir le n° de commande d’achats puis valider en cliquant sur le bouton

Le résultat suivant apparaît. Récupérer l’ID récepteur (code récepteur)

2°) Traiter le work item pour le passer en ‘COMPLETED’

Transaction SWIA

Renseigner le code récepteur et la date. Puis valider en cliquant sur le bouton

L’écran suivant apparaît. Noter que la ligne de commande est en statut ‘STARTED’. Le but est de la passer en statut ‘COMPLETED’.

Sélectionner la ligne et cliquer sur le bouton . Le résultat suivant apparaît.

Sélectionner l’élément ‘commande d’achat lancé’ puis cliquer sur le bouton

L’écran suivant apparaît.

Rafraîchir l’écran en cliquant sur le bouton . Vous devez obtenir le résultat suivant.

SWI6 délégation de signature et circuit de validation de commandes d’achats.

Pour effectuer l’analyse du flux de validation saisir les éléments relatifs à la commande d’achats comme suit.

L’écran suivant apparaît. Chaque tâches correspond à un point de validation.

Remarque : Le nom de l’agent est le nom d e la personne signataire.

Si l’on souhaite trouver l’ID d’une tâche sélectionner la ligne puis cliquer sur l’icône . La boîte message suivante apparaît.

Pour accéder au protocole sélectionner la tâche et cliquer sur le bouton . L’écran suivant apparaît.

Si l’on sélectionne l’onglet On obtient les informations suivantes :

Remarques : Sur cette tâche on note qu’il y a deux noms, cela signifie qu’il y a eut délégation de signature. Le problème est que cette information est tracée à cet endroit une fois que la délégation de signature a été accepté par le signataire.

ATTENTION : A ce jour je n’ai pas trouvé où est tracé la demande de délégation de signature.

Pour obtenir la liste des détails techniques cliquer sur l’icône . L’écran suivant apparaît. Pour avoir le détail développer les points.

Sur l’écran ci-dessus on note que l’acceptation de délégation est tracée Mais pas l’émission ce qui pose un problème lorsque l’on est en mode intermédiaire. A savoir que l’émetteur à effectuer une délégation de signature, dans ce cas il ne peut plus signer, et que cette délégation n’a pas encore été acceptée.

On peut se trouver sur une commande d’achat avec l’erreur suivante :

Si l’on fait une SE91 sur ce message d’erreur on obtient l’information suivante :

Alors que le valideur de la transaction ZM02 est le bon.

Si l’on regarde via les cas d’emploi, on voit que ce message est utilisé dans l’objet suivant :

Include ZXM06U43 du programme ZXM06U43.

Table des valideurs :

Pour accéder à la table des valideurs utiliser la transaction ZM02.

Les valideurs sont associés à une imputation. Cette information se trouve sur le poste de la commande d’achats dont le montant est le plus élevé. Prendre l’onglet imputation. Sil y a un réseau prendre le code réseau comme dans l’exemple ci-dessus.

Pour la commande 4500009421 code réseau GUR11T1DI51.

Attention, dans le cas d’une délégation de signature, la personne attitrée figurant dans la table ne pourra plus signer.

A ce jour je n’ai pas l’information quant à la table de référence dans le cas d’une délégation de signature.ni dans la table ZMX01 ni dans ZMX02

ZREQ_MAX for PR

ZPO_SHAPE for PO

6/36