Importante: Estamos utilizando a versão do Koha 25.05.05.
A primeira coisa que vamos fazer é acessar a interface do Koha de Equipe com o login de super bibliotecário (superlibrarian, acesso total ao sistema administrativo). (Na gringa e em vários outros tutoriais você vai encontrar essa interface sendo chamada como staff – que é a palavra em inglês para ‘equipe’). E então você vai clicar no menu “Administração do Koha”. (imagem abaixo).
Esse é o menu da administração.
Vou tentar trabalhar por pequenos módulos de administração. O primeiro módulo é o de “Parâmetros básicos”. Ele vai nos tomar muito tempo porque vamos exaurir suas opções. A primeira opção dele é “Bibliotecas”. Neste grupo você cria as bibliotecas dentro do sistema. Você trabalha numa única unidade? Sua unidade é a sede principal de diversas sucursais? Cada sucursal tem horários diferentes de trabalho? É aqui que você configura tudo isso. Sempre que possível vou oferecer boas práticas dentro de um campo ou configuração que pode facilitar sua vida e a justificativa para ela.
Clique em + Nova Biblioteca
Ele vai te dar um formulário de configuração da sua nova unidade de informação. Vamos analisar cada um dos itens deste formulário.
Código da biblioteca é o branchcode. Ou seja, é o identificador interno (que você vai criar sem espaços e com no máximo 10 caracteres em maiúsculas).
Exemplo: BIBINF (Biblioteca de Informática) ou BPMM (Biblioteca Pública Municipal de Mossoró).
Boas práticas aqui: Use um padrão curto e estável (não mude ao trocar de gestão); Evite acentos, hífens ou números confusos (O/0, I/1); Planeje uma convenção para futuras filiais (ex. BPMRURAL).
Nome é name, o que aparece tanto na parte de Equipe quanto na OPAC, em listas de retiradas, filtros, etc.
Exemplo: “Biblioteca Pública Municipal de São Paulo”, “Biblioteca Setorial Infantil”.
Boas práticas aqui: Use o nome oficial que o público reconhece. Evite siglas internas como único nome (se quiser, deixe em parênteses).
Endereço e Contato . (address, contact) Esses campos alimentam avisos, comprovantes, cartas de atraso (se você ainda usar algum tipo de carta física) e páginas de informação no OPAC.
Linhas de endereço 1/2/3, Cidadade, Estado, CEP, País. Use o padrão de correspondência real, porque é o que vai aparecer em malas diretas e avisos impressos.
Exemplo: Linha 1: “Rua das Amêndoas, 123”
Cidade: “Rio de Janeiro”, Estado: “RJ”; CEP: “12345-123”; País: “Brasil”.
Boas práticas: Preencha completo ao menos para a(s) unidade(s) que emitem cartas/avisos físicos. Mantenha consistência de abreviações (sempre “PR”, não “Paraná” em umas e “PR” em outras).
Telefone / Fax / E-mail
Telefone: Será usado em recibos, notas e páginas da biblioteca no OPAC. Diferencie contato geral da biblioteca central de contatos específicos de serviço (“agendamento de grupos escolares”, “oficinas culturais”).
Fax: hoje quase sempre fica em branco, a menos que a instituição ainda use.
E-mail: endereço de contato da unidade; pode ser usado em avisos e comunicações dirigidas àquela biblioteca.
Boas práticas: Tenha um e-mail genérico institucional por unidade (ex. biblioteca@riodejaneiro.gov.br). Evite colocar e-mails pessoais de servidores/funcionários (por motivos de fim de turno, férias, etc).
Responder para / Caminho de retorno
Esses campos definem o comportamento dos e-mails enviados em nome dessa biblioteca.
Responder para: Define o endereço que aparecerá como “Reply-to” nas mensagens disparadas pela unidade (ex. avisos de atraso configurados para aquele branch/unidade). Se você deixar em “Padrão: ReplyToDefault”, o sistema usará o valor da preferência global ReplyToDefault.
Exemplo: Para uma biblioteca escolar, seria ideal que você usassse biblioteca.escola@riodejaneiro.gov.br se você quiser que as respostas caiam direto lá naquele e-mail daquela unidade.
Boas práticas: Use este campo apenas quando uma unidade realmente precisa receber as respostas diretamente. Caso contrário, centralize na biblioteca matriz ou e-mail geral (via ReplyToDefault).
Caminho de retorno
Define o “Return-Path” dos e-mails (para onde vão mensagens que falham, ou seja, bounces).
Se ficar em “Padrão: ReturnpathDefault”, usa a preferência global ReturnpathDefault.
Boas práticas: Aponte para um e-mail monitorado pela TI ou por quem acompanha falhas de entrega (ex.: nãorespondeer-ti@…). E evite o mesmo e-mail usado para atendimento diário para não misturar falhas com mensagens de usuários.
Servidor SMTP:
Permite, em versões recentes, escolher um perfil de SMTP diferente para aquela biblioteca (se você tiver vários perfis configurados, por exemplo, por ter servidores de e-mail ou configurações diversas).
Boas práticas: Em instalações simples, deixe “Padrão”. Use perfis separados só se, por política da sua instituição, cada unidade precisar enviar com servidor diferente (ex. domínios separados).
URL: Se você preencher, o nome da biblioteca nos holdings do OPAC vira link para esse endereço. Esse campo pode carregar muito significado se bem utilizado. Ex. aponte para uma página dedicada da unidade no seu site (fotos, mapa, agenda de atividades).
Ex. https://biblioteca.uepg.pr.gov.br/unidade-central
Boas práticas: Use a página pública da unidade (Koha, site institucional ou página no seu site). É útil pra você integrar com opac-library.tt, mostrando descrição, fotos, mapa, etc.
Informação do OPAC (Adicionar conteúdo HTML)
Abre o editor da ferramenta “Conteúdos adicionais” para cadastrar um bloco de HTML com informações dessa biblioteca (horário, serviços, acessibilidade). Esse texto aparece quando o usuário passa o mouse sobre o nome da biblioteca ou na página específica da unidade no OPAC.
Aqui você pode construir um mini-site por unidade dentro do Koha. Dá pra incluir, por exemplo: Apresentação da unidade, missão e público atendido. Lista de serviços (empréstimo domiciliar, internet, jogos, clubes de leitura, biblioterapia…). Regras específicas e prazos específicos, políticas de uso diferenciadas e etc.
Exemplos:
Sala de estudos, Wi-fi livre, acervo infanto-juvenil, acesso para cadeirantes, audiobooks e fones, jogos de tabuleiro.
Boas práticas: Escreva um mini “cartão de visita” padrão (serviços, público-alvo, contatos). Evite textos enormes; para conteúdo longo linke para uma página externa (exemplo: seu site institucional).
Organizar em blocos com <h3>, listas e, se quiser, ícones/font‑awesome para ficar mais “sitezinho”.
Usar datas de publicação/expiração na própria ferramenta de HTML customizations para avisos temporários (reforma, horário reduzido, campanhas).
IP: Permite restringir o acesso ao perfil de equipe dessa biblioteca a um IP ou sub-rede (ex.: 192.168.1.*). Se ficar vazio, a equipe pode acessar de qualquer IP autorizado pelo servidor.
Boas práticas: Para redes públicas (Wi-fi aberto), geralmente deixe em branco e faça controle de firewall/VPN. Para unidades remotas, pode ser útil colocar a faixa interna da escola/posto de leitura para reforçar segurança.
Código de organização MARC
É o código da instituição (pode ser específico da unidade; se em branco, usa o definido na preferência MARCOrgCode).
Você pode pedir um código para a sua instituição diretamente à Library of Congress. Isso gera um impacto: preenche o campo de agência em novos registros MARC, importante para intercâmbio e identificação de registros da sua instituição.
Boas práticas: Defina o código institucional em MARCOrgCode e deixe o campo da biblioteca em branco, a menos que algum branch precise de código distinto. Documente isso na política de catalogação para manter consistência.
Notas: É um campo interno, visível só na página de equipe, para observações administrativas sobre a unidade. Exemplo: Unidade atende apenas alunos da escola X; Fechada para reforma até XX/XX. Pode virar seu dossiê técnico da unidade.
Ideias do que você pode documentar aqui: Histórico de mudanças relevantes (ex. “Desde 2024 usa apenas empréstimo por agendamento”; “Acervo juvenil transferido para filial x em 2025”
Boas práticas: Use para registrar particularidades que impactam circulação interna (horário sazonais, convênios, limitações de acervo).
Local de Retirada:
Define se a biblioteca aparece como opção de coleta de reservas (pickup location).
A opção padrão é “sim”, mas você também pode colocar como “não” se um leitor não puder retirar livros nessa unidade. Exemplo de “não”: Um depósito técnico, um setor interno, aí os usuários não poderão usar esse local como retirada no OPAC. Combinando com grupos de bibliotecas e regras de circulação, você consegue modelar redes de empréstimo interbibliotecário, depósitos técnicos invisíveis ao usuário e pontos de retirada específicos.
Boas práticas: Somente unidades (branches) que atendem presencialmente o público devem ser locais de retirada. Use “não” para depósitos, setores administrativos, bibliotecas exclusivamente digitais.
Público: Controla se essa biblioteca aparece como opção de filtro/pesquisa e em listas de bibliotecas no OPAC. Ou seja, se escolher “sim” vai aparecer visível ao público no OPAC, se escolher “não”, só aparece na página da Equipe.
Boas práticas: Marque “não” para unidades que você quer manter invisíveis ao usuário final. (Ex. Laboratório de Processamento Técnico). Para qualquer espaço onde o usuário pode ir fisicamente ou usar serviços, mantenha “sim”.
Horário da Biblioteca: Dia / Tempo aberto / Hora de fechamento
Permite registrar o horário de funcionamento por dia da semana; essas informações podem aparecer em páginas da biblioteca e ser usadas por alguns fluxos de reserva / aviso.
Exemplo: Segunda: Aberto das 08:00-12:00 ; das 13:00-20:00; Mas na terça: das 08:00-12:00 e das 13:00-17:00. Na quarta se a sua unidade não abrir, deixe em branco.
Boas práticas: Preencha horários reais e mantenha atualizado sempre que houver mudança de turno ou férias coletivas. Combine com a equipe: em mudanças maiores (novo horário de verão, reformas), revise aqui e nas páginas públicas / avisos.
Campos de customização do OPAC:
Opac JS específico: Caixa para inserir JavaScript que será carregado APENAS no OPAC quando o usuário estiver “naquela” biblioteca” (dependendo da versão, isso vale para contextos como página da unidade, ou quando selecionada como “biblioteca atual”).
Exemplo: Um script que mostra um aviso para usuários da filial rural sobre atraso na entrega de reservas; Ajustes de interface específicos (mostrar um bannoer só para aquela unidade).
Boas práticas: Centralize scripts gerais na preferência OPACUserJS; use este campo só para exceções locais. Documente bem o que cada biblitoeca tem de JS específico para evitar conflitos e facilitar migração/atualização.
CSS OPAC específico: Campo para CSS que se aplica só ao OPAC daquela biblioteca.
Exemplo: Mudar a cor de fundo da página da filial infantil, usar ícones diferentes, destacar avisos de horário reduzido.
Boas práticas: Use seletores específicos (por classe/id) para não quebrar o layout global. E para estilos comuns, use o OPACUserCSS.
Checklist de criação de bibliotecas para facilitar:
- Defina um padrão de branchcode e registre em documentação interna.
- Preencha endereço completo e contatos oficiais.
- Confira se será “Local de retirada” e se deve ser “público” no OPAC.
- Ajuste horários e revise páginas opac-library para manter a informação coerente.
- Centralize o que é global (SMTP, JS, CSS) nas preferências de sistema; use campos específicos da biblioteca só para exceções.
