Description des aménagements et améliorations apportés à l'application Numéro Unique.

Modification n°1

Permettre aux gestionnaires départementaux de procéder en toute sécurité aux archivages et aux apurements de leurs demandes radiées les années antérieures, c’est à dire en 2001 et en 2002 (pour ce qui est autorisé en 2004).

Cette fonction est exclusivement réservée aux gestionnaires départementaux et est accessible uniquement en mode transactionnel.

ARCHIVAGE : L’archivage consiste à changer l’état des demandeurs « inactifs » dont toutes les demandes ont été radiées avant le 1^er janvier de l’année N-1 (soit en 2004 des demandes radiées avant le 1.1.2003), en demandeurs « archivés ».
Vous pouvez archiver tous les demandeurs en une seule fois jusqu’au 31/12/2002, ou le faire par lot jusqu’à la date que vous choisirez (la limite maximale restant le 31/12/2002).

APUREMENT : L’apurement consiste à effacer physiquement de la base de données les demandes précédemment archivées.
L’apurement consiste à supprimer physiquement du serveur les données précédemment  archivées.
L’apurement est une fonction qui sollicite des ressources matérielles importantes. Afin de conserver des temps de réponses acceptables, nous avons limité ce traitement à 1000 demandeurs. A chaque apurement demandé, un fichier correspondant aux données supprimées sur le serveur vous sera automatiquement retourné sur votre messagerie afin que vous conserviez localement une sauvegarde.
Si besoin le traitement est à réitérer autant de fois que nécessaire (par tranche de 1000 demandeurs) jusqu’à ce que tous les demandeurs archivés soient radiés du serveur N°Unique.
 

Modification n°2

Permettre aux lieux d’enregistrement de saisir sous forme de tableaux les motifs d’attente sur leurs demandes en délai dépassé

Cette fonction est exclusivement réservée aux lieux d’enregistrement et est accessible uniquement en mode transactionnel. Les lieux d’enregistrement qui le souhaitent peuvent (comme cela est actuellement possible en version 1.4) procéder à ce type de mise à jour en mode BATCH.

En mode transactionnel, la saisie de ces motifs devait être réalisée demande par demande ce qui était fastidieux pour les services disposant de stocks conséquents de demandes hors délais.

Pour améliorer l’ergonomie de cet écran, nous avons modifié le principe de mise à jour qui peut désormais être faite sous forme de tableaux successifs.Chaque page comporte 50 demandes hors délais. L’utilisateur choisit dans la table départementale des motifs ceux qui s’appliquent à ses propres demandes et coche chaque demande pour lesquelles le motif correspond à celui préalablement choisi.

Les demandes pour lesquelles un motif a déjà été saisi sont affichées dans la liste présentée à l’écran et mentionnent le code motif antérieurement affecté. L’utilisateur peut choisir de modifier ce code motif si nécessaire.

Avant d’effectuer cette saisie, nous recommandons que les utilisateurs s’importent localement leurs fichiers de demandes en délai dépassé afin de préparer la saisie qui nécessite le plus souvent de se rapprocher des dossiers de demandes.
La mise en cohérence départementale de ces motifs et l’exploitation qui en est faite est du ressort de la cogestion dépar tementale.

Le nouveau tableau de bord fait maintenant apparaître le nombre de demandeurs ayant eu une attribution de logement (actuellement, seul figure le nombre total de demandes attribuées, un demandeur pouvant au titre d’un même N° unique avoir N demandes).

Il manquait sur un certain nombre de rubriques la distinction entre demandeurs et demandes. Les nombres et les pourcentages n’étaient pas suffisamment séparés quand le nombre de demandes était sur 6 caractères ou plus.
Ces inconvénients sont désormais corrigés en version 1.5

Rappels :

• Le nombre de demandeurs est le nombre de N°unique différents en base.

• Le nombre de demandes est le nombre d’enregistrements en base. Un même demandeur (avec un même N°unique départemental) peut déposer n demandes auprès de n lieux d’enregistrement

Désormais le nouveau tableau de bord se présente ainsi :

La colonne « Modalités de calcul du % » explique la façon dont le pourcentage (colonne « % ») est calculé.

Exemple :
Pour les demandeurs en instance – ligne 3 – le pourcentage de 64,01% est le rapport entre le nombre de demandeurs de la ligne 3 ( 46436) et le nombre total de demandeurs enregistrés en base inscrit en ligne 1 (72 546). Ce pourcentage est donc le rapport du chiffre de la ligne 3 avec le chiffre de ligne 1. (3/1).

Modification n°4

Restituer dans les fichiers « CSV » la totalité des informations disponibles en base concernant les demandeurs et les demandes.
Les nouvelles informations intégrées dans les fichiers retournés seront cadrées à droite afin de ne pas perturber les traitements automatisés qui prennent en charge localement ces fichiers.

En transactionnel, pour les fonctions « Gestionnaires » et « Lieux d’enregistrement » choix « Consultation et édition de demandes »,  les informations suivantes sont ajoutées au fichier CSV :
DEMANDE.NUM_DEMANDE, DEMANDE.CODE_RESERVATAIRE, DEMANDE.DATE_SAISIE, DEMANDE.DATE_PREAVIS_SORTIE, DEMANDE.ETAT_DEMANDE, DEMANDE.NUMERO_INTERNE, DEMANDEUR.CODE_ASSOC, DEMANDEUR.GENRE, DEMANDEUR.ETAT_DEM, DEMANDEUR.DATE_CREATION, DEMANDEUR.DATE_ATTRIBUTION, DEMANDEUR.CLE_DEMANDEUR

En transactionnel, pour les fonctions « Gestionnaires » et « Lieux d’enregistrement » choix « Consultation et édition de demandes hors délai »,  les informations suivantes sont ajoutées au fichier CSV :
DEMANDEUR.CODE_ASSOC, DEMANDEUR.GENRE, DEMANDEUR.ETAT_DEM, DEMANDEUR.DATE_CREATION, DEMANDEUR.DATE_ATTRIBUTION, DEMANDEUR.CLE_DEMANDEUR, DEMANDE.NUM_DEMANDE, DEMANDE.CODE_RESERVATAIRE, DEMANDE.CODE_SERVICE_SORTIE, DEMANDE.DATE_SAISIE, DEMANDE.DATE_PREAVIS_SORTIE, DEMANDE.ETAT_DEMANDE, DEMANDE.AUTRE_COMM, DEMANDE.NUMERO_INTERNE

NB : Ces modifications sont répercutées de même façon dans les retours de fichiers sollicités en mode BATCH

Modification n°5

Ajout de filtres supplémentaires dans l'écran "Edition et consultations des demandes" permettant aux gestionnaires et aux lieux d’enregistrement d’affiner leurs extractions.

• « demandes actives » , « demandes inactives », « Préavis en cours » et « demandes archivées » (sous forme de cases à cocher).

• Fourchette de dates de sortie (pour les demandes définitivement radiées)

En transactionnel, pour la fonction « Gestionnaires » l’écran « Consultation et édition de demandes »,  a été modifié pour :

• Ajouter et gérer le filtre sur la date de sortie (date de début et date de fin),

• Ajouter et gérer le type de demande « Inconnu »,

• Ajouter et gérer le filtre sur l’état de la demande (boites à cocher « active », « inactive », « préavis en cours » et « archivée »).
  Les dates de sortie début et fin sont contrôlées pour vérifier leur validité.

En transactionnel, pour la fonction « Lieux d’enregistrement » l’écran « Consultation et édition de demandes »,  a été modifié pour :

• Ajouter et gérer le type de demande « Inconnu »,

• Ajouter et gérer le filtre sur l’état de la demande (boites à cocher « active », « inactive », « préavis en cours » et « archivée »).
  La date de sortie existait déjà dans les filtres proposés.

Désormais l’écran « Consultation et édition de demandes », proposera donc les filtres suivants :

En batch, cette modification influence le type de traitement « 5 ».
Le format d’envoi est modifié pour ajouter les nouveaux champs du filtre.
Le nouveau format d’envoi est le suivant (en gras les nouveaux champs):
C4;5;C23;C24;C26;C27;C34;C35;C36;C37;C38;C39;C40;C41;C42;C43;C44;C45;C46
Avec C42 = Date de sortie début.
Avec C43 = Date de sortie fin.
Avec C44 = Etat de la demande (A = active, I = inactive).
Avec C45 = Préavis en cours (O = oui).
Avec C46 = Archivée (O = oui).
Seuls les deux premiers champs sont obligatoires. Si les champs C23 à C46 ne sont pas renseignés, le batch retourne le fichier avec l’ensemble des demandes du service.
Le contenu du fichier retourné reste inchangé.
Concernant le type de demande « Inconnu », ce dernier est géré comme les autres types (Externe, Mutation). Il suffit de mettre « I » dans le champ C26.

Modification n°6

Fiche « Demandeur » : il s’agit de permettre aux gestionnaires de visualiser à l’écran le détail de toutes les demandes d'un demandeur avant de solliciter l’envoi éventuel du fichier  « csv » correspondant.

Le nouvel  écran « Fiche demandeur » pour la fonction « Gestionnaire » ressemble à celui de l’écran « Consultation et édition de demandes » avec en plus l’information concernant l’état de la demande. L’écran de visualisation d’une fiche demandeur est le suivant :

Modification n°7

Il s’agit de différencier les demandes pour lesquelles le type de demande [EXTERNE –MUTATION] n’est pas connu lors de l’enregistrement de la demande. En plus des deux modalités actuelles, nous avons ajouté une nouvelle modalité dont le code est « I » pour [INCONNU].

Plutôt que de renseigner arbitrairement ce champ de saisie obligatoire avec « E » ou « M », ce qui fausse toute appréciation globale sur l’origine logement des demandeurs, les lieux d’enregistrement pourront désormais clairement indiquer qu’ils ignorent cette information  pour certaines des demandes qu’ils sont amenés à enregistrer sur le serveur départemental.

En transactionnel, il a été ajouté une nouvelle case à cocher « INCONNU » sur l’écran de saisie « Création et modification d’une demande ».

Cette nouvelle variable est également retranscrite sur les écrans suivants :

• Attribution d’un logement,

• Préavis de sortie,

• Recherche des demandes et des demandes hors délai (Gestionnaire et lieux d’enregistrement),

• Liste des demandes hors délai trouvées et des demandes trouvées (Gestionnaire et lieux d’enregistrement).

En batch, le champ C26 accepte désormais la valeur « I ». Si ce champ est transmis vide lors de l’envoi d’une création de demande, celle-ci sera inscrite en base avec la mention « I ». 

Modification n°8

Ajout d’un nouveau motif de sortie N°5 « ERREUR DE SAISIE » pour permettre de radier immédiatement sans préavis toute demande créée par erreur.

Jusqu’à la version 1.4, en cas d'erreur de saisie d'une demande, l'utilisateur ne disposait pas de fonction spécifique pour supprimer une demande créée par erreur. Le plus souvent la radiation était réalisée avec un motif qui ne correspondait pas à la réalité.
Il est ajouté en version 1.5 un cinquième motif « Erreur de saisie » qui est intégrer dans la table de référence des motifs de radiation.
Rappel : les 4 autres motifs sont 1 = attribution, 2 = renonciation, 3 = non-renouvellement, 4 = rejet pour irrecevabilité.

Le tableau de bord est complété de 2 lignes supplémentaires « demandeurs sortis pour erreur de saisie » et « demandes sorties pour erreur de saisie »
Les fichiers « CSV » retournés aux utilisateurs intègrent ce nouveau critère dans la colonne « motif_sortie ».

Pour les utilisateurs « BATCH » le champ C23 pourra désormais être renseigné avec la valeur « 5 »

Modalités et contrôles
Le nouveau motif « Erreur de saisie » fonctionnera de façon strictement identique au motif « Renonciation », c’est-à-dire date de sortie = date de préavis.

En transactionnel, il est affiché un message de confirmation du choix de l’erreur de saisie (comme pour le motif de sortie « Renonciation ») et après confirmation le traitement correspondant est effectué (identique au traitement pour motif de sortie « Renonciation »).

En batch, la fonction de « modification de demande » a été aménagée pour prendre en compte ce nouveau motif de sortie.

Modification n°9

Il est désormais interdit de saisir le point-virgule dans les champs «libellés» du N°Unique afin de ne pas perturber le cadrage des fichiers « CSV » importés par les utilisateurs.
Le point-virgule est en effet le caractère retenu dans les fichiers de données pour séparer les différentes variables des demandes

Lors de la validation de la saisie, l’application vérifie s’il n’y a pas de point virgule dans les champs « Adresse », « Adresse suite », « Code postal » et « Commune ».
Si des points virgules sont saisies, le message d’erreur suivant est affiché « Le caractère ; n'est pas autorisé dans la saisie de l'adresse ».

Cette modification concerne les écrans de l’application transactionnelle:

• Création et modification des tables de références « Association » et « Service » (fonction « Gestionnaire »)

• « Création d’une demande », « Modification d’une demande » et « Modification des informations personnelles » (fonction « Lieux d’enregistrement »).

Cette modification ne concerne pas le Batch. Ce contrôle devrait exister dans les modules locaux de création des fichiers d’interface, en amont donc de tout traitement sur le serveur N°Unique.