2019 : version 9.8 (décembre)

• 1. Gestion des bibliobus
• 2. Catalogage : amélioration du réservoir BnF via SRU
• 3. Assistants de prêts : amélioration de la gestion des transferts et des réservations
• 4. RFID : gestion des documents multi-parties pour Nedap
• 5. Budgets : mise en place des traitements automatiques liés au changement d’année

1. Gestion des bibliobus

Decalog SIGB permet de gérer, via une option facultative, les tournées de bibliobus.

Cette option permet de gérer les bibliobus, qui sont assimilés à des sites physiques mobiles possédant des arrêts, à des fins de gestion d'une tournée.

Ainsi, si l’on souhaite déclarer un bus, cela prendre la forme d’un nouveau site au sein du réseau, de type Bibliobus :

Le fait de définir un site comme bibliobus engendre l’apparition d’un onglet supplémentaire au niveau du site, permettant de définir les arrêts du bibliobus.

Si le nombre d’arrêts ou de tournées à gérer est important, il est possible d’activer en plus au niveau du réseau (de manière facultative) :

• Les regroupements d’arrêts : il s’agit simplement de permettre de regrouper visuellement des arrêts en sous-groupes, pour plus de lisibilité (sur le modèle des bassins pour les sites)
• Les circuits : ils permettent de définir les parcours que suivra le bibliobus, sollicités pour identifier les documents demandés sur le trajet et pour passer facilement d'un arrêt au suivant.

Les circuits et regroupements d’arrêts peuvent être activés au niveau du réseau, dans l’onglet Paramètres :

Une fois les options activées, les regroupements d’arrêts et circuits peuvent être définis au niveau du site bibliobus, au même emplacement que les arrêts :

Une fois le paramétrage effectué, le site (ou les sites) de type Bibliobus sont utilisables comme des sites classiques : le bus peut être le site dépositaire de documents (renseigné au niveau de la grille exemplaires dans le champ « Site dépositaire »), le site depuis lequel s’effectuent des prêts, ou encore le site de retrait demandé de réservation.

Lorsqu’un utilisateur se connecte sur le site de type Bibliobus, il peut se localiser sur un arrêt en particulier (par un simple clic sur cet arrêt) :

L’icône à droite de l’arrêt de prêt permet de se localiser en un clic sur l’arrêt suivant (dans l’ordre dans lequel les arrêts ont été définis, au sein d’un circuit ou non).

Une fois localisé sur un arrêt spécifique, les opérations effectuées (prêts, retours, inscriptions, paiement, etc.) seront enregistrées sur cet arrêt :

Lors d’une demande de réservation, il est possible de spécifier l’arrêt de retrait :

L’information de l’arrêt (que ce soit pour le prêt ou la réservation) est ensuite repris et indiqué dans tous les modules de Decalog SIGB :

• Dans les listes Prêts et Réservations du module Circulation : les critères de recherche accessibles permettent notamment de préparer les tournées en ayant la liste des documents réservés sur chaque arrêt dans la liste des réservations
• Dans les statistiques
• Dans les tickets de prêt
• En éléments de l’exportation vers un tableur (module Circulation, Catalogage, etc.)
• En vue détaillée d’une notice (partie exemplaire)
• En prêts déconnectés (le site et l’arrêt depuis lesquels on intègre les fichiers sont respectivement considérés comme site et arrêt de prêt)
• Dans les dettes et règlements (comme site de règlement d’une dette)
• Dans les modèles de documents, sous réserve d’insérer les balises correspondantes*

* Liste des balises à intégrer dans les modèles pour obtenir les informations relatives aux bibliobus :  

• Relances par mail :
  • Site de prêt : ${reminder.loanLibrary}
  • Arrêt de prêt : $!{reminder.loanBusStop}
  • Circuit de prêt : $!{reminder.loanBusLine}
  • Regroupement de l'arrêt de prêt : $!{reminder.loanBusGroup}
• Relances par lettre :
  • Site de prêt : ${reminder.loanLibrary}
  • Arrêt de prêt : ${(reminder.loanBusStop)!}
  • Circuit de prêt : ${(reminder.loanBusLine)!}
  • Regroupement de l'arrêt de prêt : ${(reminder.loanBusGroup)!}
• Avis de réservation par mail :
  • Site de retrait : ${library}
  • Arrêt de retrait : ${withdrawalBusStop}
  • Regroupement de l'arrêt de retrait : ${withdrawalBusGroup}
• Avis de réservation par lettre :
  • Site de retrait : ${booking.library.name}
  • Arrêt de retrait : ${(booking.withdrawalBusStop)!}
  • Regroupement de l'arrêt de retrait : ${(booking.withdrawalBusGroup)!}
• Avis d’ajournement ou de suppression d’une réservation par mail :
  • Site de retrait : ${booking.library.name}
  • Arrêt de retrait : ${booking.withdrawalBusStop}
  • Regroupement de l'arrêt de retrait : ${booking.withdrawalBusGroup}

2. Catalogage : amélioration du réservoir BnF via SRU

La version 8.4 d’octobre 2018 avait ajouté un nouveau réservoir que l’on pouvait solliciter pour les dérivations de notices : le réservoir BnF via SRU (Search / Retrieval via URL).

Pour rappel, ce réservoir dispose de 14 millions de notices bibliographiques et de 5 millions de notices autorités, qui sont donc accessibles directement depuis Decalog SIGB lorsqu’on scanne un ISBN en catalogage (sous réserve que l’on ait coché le réservoir BnF via SRU depuis Paramètres > Listes > Profils de dérivation des réservoirs).

Des améliorations ont été effectuées autour de ce réservoir. Il est désormais possible de distinguer au sein de ce réservoir les notices validées par la BnF de celles encore non validées.

Les versions antérieures de Decalog SIGB proposaient un réservoir BnF via SRU unique, avec les notices validées et non validées, ce qui se présentait ainsi (dans Paramètres > Listes > Profils de dérivation des réservoirs) :

Dans cette version 9.8, les réservoirs BnF via SRU ont été distingués et réorganisés dans la hiérarchie des réservoirs accessibles via Decalog SIGB :

[MAJ 2021 : les réservoirs BnF Decalog étant obsolètes, ils ne sont plus proposés désormais.]

On remarque l’ajout de flèches vertes, permettant de modifier l’ordre de dérivation depuis les réservoirs : ainsi, si l’on souhaite d’abord parcourir le réservoir MusicBrainz avant le réservoir BnF via SRU (notices non validées), il est possible de réorganiser la liste.

Concernant les automates de mises à jour de notices (bibliographiques et autorités), ils utilisent désormais les réservoirs SRU de notices validées, qui possède la meilleure qualité en terme de notices mises à disposition.

Pour ceux qui souhaitent aller plus loin au sujet du réservoir BnF via SRU : 

• Consulter la documentation générale de la BnF sur son service SRU
• Rechercher directement des notices dans le réservoir BnF via SRU via le formulaire de requête SRU

3. Assistants de prêts : amélioration de la gestion des transferts et des réservations

Il y a plusieurs types de problèmes gérés par les assistants de prêt, que ce soit lors des opérations de prêt ou de retour. Parmi les cas particuliers à gérer au retour figuraient les deux cas suivants :

• Retour d’un document réservé
• Retour d’un document dont le site de retour n’est pas le site dépositaire

Dans le paramétrage des assistants de prêt (Administration du réseau > Assistants de prêt), ces deux cas étaient matérialisés comme suit dans les versions antérieures de Decalog SIGB :

Ces deux cas ne suffisaient pas à prendre en compte l’intégralité des configurations possibles pour un réseau, c’est pourquoi ils ont été divisés en plusieurs cas :

• Exemplaire ne pouvant être restitué dans ce site
  • Ce cas bloque forcément le retour, et le message paramétré est affiché.
• Exemplaire attribuable à une réservation sans navette (à retirer sur le site)
• Exemplaire nécessitant d’être transféré vers un autre site : la navette de réservation
  • Ces cas peuvent bloquer le retour ou non. Si on choisit d’autoriser le retour, le prêt à un abonné fonctionnel est obligatoire afin de pouvoir traiter unitairement tous les cas de figure (qui seront présentés lors du retour unitaire depuis l’abonné fonctionnel).
• Exemplaire nécessitant d’être transféré vers un autre site : la délocalisation au retour non autorisée
• Exemplaire nécessitant d’être transféré vers un autre site : la navette de retour
  • Ces cas peuvent bloquer le retour ou non. Si l’on choisit d’effectuer le retour, le document sera prêté, au choix, soit à un abonné fonctionnel à renseigner (auquel cas les différents transferts seront à faire au moment du retour unitaire depuis cet abonné fonctionnel), soit à l’abonné fonctionnel de transfert défini pour chaque site dans chacun des cas.

Comme on peut le voir dans la capture écran, l’interface a également été légèrement reprise pour clarifier le blocage éventuel du retour : un choix entre « Oui » et « Non » est désormais demandé, plutôt que de cocher une case.

4. RFID : gestion des documents multi-parties pour Nedap

Attention : cette évolution ne concerne que les bibliothèques équipées avec les platines RFID du prestataire Nedap. Pour 3M/Bibliotheca, il est important de noter que le contrôle des documents multi-parties était déjà assuré de leur côté (c’est 3M/Bibliotheca qui contrôle la complétude du document avant de l’envoyer à Decalog SIGB, ce que ne fait pas Nedap).

Un document appelé « multi-parties » dans le cadre d’une gestion avec platines RFID est un document possédant un seul code-barres dans le SIGB, mais plusieurs tags sur les différentes parties du document. Exemple : pour un DVD (enregistré sous un seul code-barres dans Decalog SIGB), un tag sur le boîtier, un tag sur le DVD. Ce dispositif permet de contrôler la complétude d’un document lors du prêt ou du retour.

Ce contrôle est effectué par l’agent platine Decalog, le petit utilitaire permettant à la platine de communiquer avec Decalog SIGB, visible dans la barre des tâches du poste :

Lorsque l’on présente un document incomplet en prêt ou en retour, l’agent platine le signale par le biais d’un message d’avertissement, visible en bas de l’écran.

Tant que ce message est affiché, l’agent Decalog n’envoie pas le code-barres à Decalog SIGB. Dès que le document est complet (toutes les parties possédant un tag sont bien sur la platine), alors le tag est envoyé à Decalog SIGB qui peut effectuer le prêt ou le retour du document.

5. Budgets : mise en place des traitements automatiques liés au changement d’année

Le module de gestion des budgets est disponible dans Decalog SIGB depuis la version 9.0 de février 2019. 

Pour rappel, un budget est défini pour une année civile (appelée « Exercice ») qui définit l’état du budget : par exemple, si l’année du budget que l’on est en train de créer est 2019, alors jusqu’au 31 décembre 2019, l’état du budget sera « En cours ». Une corrélation sera ainsi toujours assurée automatiquement entre l’exercice et l’état d’un budget :

• L’état « En préparation » concerne le budget de l’année à venir
• L’état « En cours » concerne le budget de l’année courante
• Les états « Pré-clôturé » et « Clôturé » concernent les budgets des années passées.

A noter : s’il y a plusieurs acquéreurs au sein du réseau (chaque bibliothèque achète son fonds propre et gère son budget par exemple), plusieurs budgets du même état et sur la même année vont cohabiter. 

Ainsi, il est nécessaire lors du passage à l’année suivante d’assurer la cohérence des budgets en effectuant le changement d’état, avec les modifications qui en découlent. Voici les modifications qui interviendront donc automatiquement chaque année entre le 31 décembre et le 1^er janvier :

• Pour les budgets en préparation (s’ils ont été définis) :
  • Ils deviennent les budgets en cours.
  • Les suggestions et commandes sur ce budget (souhaitées ou en préparation, mais pas engagées) restent sur le budget désormais en cours.
• Pour les budgets en cours :
  • Ils deviennent pré-clôturés si une extension d’utilisabilité est demandée ou s’il reste des commandes non soldées. Ils sont sinon clôturés.
  • Les suggestions et commandes engagées et réalisées restent sur ce budget.
  • Les suggestions et commandes souhaitées et programmées ne peuvent pas rester sur un budget pré-clôturé ou clôturé. Selon le paramétrage effectué (encart rouge dans la capture écran ci-dessous), les lignes budgétaires des suggestions et l’exercice des commande seront soit basculées vers le nouveau budget en cours (généré automatiquement s’il n’existe pas), soit supprimées.

• Pour les budgets pré-clôturés :
  • Ils deviennent clôturés lorsque l’extension d’utilisabilité est dépassée et qu’il ne reste pas de commandes non soldées (à noter que cette conversion-ci n’est pas spécifique au changement d’année : le contrôle des budgets potentiellement « clôturables » est effectué chaque nuit).