Note importante : à partir du mois de janvier, les grilles de catalogage paramétrables seront activées progressivement sur l’ensemble des clients Decalog SIGB. Le seul changement visible que cela provoquera est l’isolement des modules Périodiques et Récolement sur la page d’accueil de Decalog SIGB (aucun changement dans le fonctionnement néanmoins).

extjs6.png

L’activation des grilles de catalogage paramétrables permettra l’accès à un ensemble de fonctionnalités supplémentaires, activables à la demande et listées ici (cette liste ayant été enrichie depuis), et le fonctionnement des grilles en elles-mêmes est consultable dans la documentation téléchargeable ici.

Si vous souhaitez bénéficier de ce nouveau module plus rapidement, nous vous encourageons à soumettre par le biais d’un ticket Cérhème une demande d’activation afin que nous puissions l’activer immédiatement.

1. Gestion des bibliobus

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

V9.8-1.1-Gestion des bibliobus.png

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 :

V9.8-1.2-Gestion des bibliobus.png

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.

V9.8-1.3-Gestion des bibliobus.png

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 :

V9.8-1.4-Gestion des bibliobus.png

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 :

V9.8-1.5-Gestion des bibliobus.png

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) :

V9.8-1.6-Gestion des bibliobus.png

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).

V9.8-1.6.2-Gestion des bibliobus.png

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 :

V9.8-1.7-Gestion des bibliobus.png

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

V9.8-1.8-Gestion des bibliobus.png

Attention : il est important de noter que le choix d’un arrêt de retrait pour la réservation n’a pas encore été implémenté côté portail.

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 à l’avance 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}

A noter : si le réseau a défini des navettes de réservation, il est possible d’exclure le fonds du bibliobus des exemplaires pouvant faire l’objet d’une navette :

V9.8-1.9-Gestion des bibliobus.png

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) :

V9.8-2.1-Catalogage_amélioration du réservoir BnF via SRU.png

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 :

V9.8-2.2-Catalogage_amélioration du réservoir BnF via SRU.png

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.

A noter : le réservoir BnF via SRU (notices validées) est coché par défaut, contrairement au réservoir BnF via SRU (notices non validées).

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.

V9.8-2.3-Catalogage_amélioration du réservoir BnF via SRU.png

Pour ceux qui souhaitent aller plus loin au sujet du réservoir BnF via 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 :

V9.8-3.1-Assistants de prêts_amélioration de la gestion des transferts et des réservations.png

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.

V9.8-3.2-Assistants de prêts_amélioration de la gestion des transferts et des réservations.png

Exemples concrets : sur un réseau avec 2 sites (Sites A et B, qui ont mis en place des navettes de réservation et de retour entre eux) : 

1) Un abonné rend sur l’automate de Site A un document réservé par un autre abonné à Site B. On se retrouve donc dans le cas « Exemplaire nécessitant d’être transféré vers un autre site : la navette de réservation » :

  • Si on sélectionne « Effectuer le retour » = Non : alors le retour est refusé et le message paramétré est affiché à l’abonné. Il doit donc s’agir d’un message du type « Le retour n’a pas été effectué : le document nécessite un transfert, il doit être remis à un agent de la bibliothèque ».
  • Si on sélectionne « Effectuer le retour » = Oui : le retour est effectué depuis l’assistant de prêt et est automatiquement prêté à l’abonné fonctionnel spécifié, ce qui permettra d’effectuer le transfert lors du retour depuis cet abonné fonctionnel. Un message est affiché à l’intention de l’abonné pour lui demander de confier le document au bibliothécaire ou de le mettre dans une caisse réservée aux documents à transférer.

2) Un abonné rend sur l'automate de Site A un document appartenant à Site B. On se retrouve donc dans le cas « Exemplaire nécessitant d’être transféré vers un autre site : la navette de retour » :

  • Si on sélectionne « Effectuer le retour » = Non : alors le retour est refusé et le message paramétré est affiché à l’abonné. Il doit donc s’agir d’un message du type « Le retour n’a pas été effectué : le document nécessite un transfert, il doit être remis à un agent de la bibliothèque ».
  • Si on sélectionne « Effectuer le retour » = Oui, et que l’on renseigne un abonné fonctionnel : le retour est effectué depuis l’assistant de prêt et est automatiquement prêté à l'abonné fonctionnel spécifié, ce qui permettra d’effectuer le transfert lors du retour depuis cet abonné fonctionnel. Un message est affiché à l’intention de l’abonné pour lui demander de confier le document au bibliothécaire ou de le mettre dans une caisse réservée aux documents à transférer.
  • Si on sélectionne « Effectuer le retour » = Oui, et que l’on ne renseigne pas d’abonné fonctionnel : le retour est effectué depuis l’assistant de prêt et est automatiquement prêté à l’abonné fonctionnel de navette de retour vers Site B. Un message du même type que le précédent est affiché.

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 :

V9.8-4.1-RFID_gestion des documents multi-parties pour Nedap.png

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.

V9.8-4.2-RFID_gestion des documents multi-parties pour Nedap.png

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.

V9.8-5.1-Budgets_mise en place des traitements automatiques liés au changement d’année.png

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 1er 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.

V9.8-5.2-Budgets_mise en place des traitements automatiques liés au changement d’année.png

  • 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).

Rappel : les notions de montants « Engagés », « Programmés » et « Souhaités » sont liés à la gestion des suggestions et commandes (qui est un module facultatif de Decalog SIGB et non indispensable pour la gestion des budgets).

  • Le montant « Souhaité » correspond au cumul des montants associés aux suggestions « Proposées », « Accordées » ou « Validées financièrement ».
  • Le montant « Programmé » correspond au cumul des montants associés aux suggestions « En préparation de commande ».
  • Le montant « Engagé » correspond au cumul des montants associés aux suggestions « En commande », « En réception », « Livrée » et « Livraison différée ».
  • Le montant « Réalisé » correspond au cumul des montants des exemplaires mis à l’inventaire.

 

Tags:
    

Need help?

If you need help with XWiki you can contact: