Page blanche sur le grand livre

rol · Novembre 26, 2018, 8:03

Bonjour,

Depuis que j’ai inscrit les opérations du journal de vente et des journaux de banque dans le grand livre, J’ai une page blanche en lui et place du grand livre. Toutes les autre fonctions de Dolibarr fonctionnent, mais lorsque je clique sur le grand livre, j’ai un carré blanc.

J’ai effacer l a cache de mon navigateur, tester avec un autre navigateur. Même résultat.
Quelqu’un a-t-il déjà rencontre ce type de problème? Quel solution pour revenir à l a normale?
J’utilise Dolibarr en version 7.0.4

rol · Novembre 26, 2018, 8:04

Arre · Novembre 27, 2018, 7:50

bizarre bizarre,

tu n’aurais pas changé des noms de banque ou de journaux entre temps ?

rol · Novembre 27, 2018, 1:15

Non pas a ma connaissance. C’est la première fois qu’on utilise l’inscription au grand livre.
La fonction marchait très bien lors de l’inscription du journal des ventes et puis ne fonctionnais plus après l’inscription des journaux de banques.

rol · Novembre 27, 2018, 1:22

Je pense qu’avec un changement de nom, je pourrais ne pas avoir de résultat, mais au moins j’aurais un interface pour le grand livre. Je n’ai qu’un espace vide.

yves57 · Novembre 27, 2018, 3:05

Pour sortir du brouillard, il faut identifier l’erreur. Une page blanche est typique d’une erreur du serveur ( Apache ?) Il faut chercher dans les logs.
Voir le dernier paragraphe: https://wiki.dolibarr.org/index.php/Gestion_d’erreur

freegate · Décembre 8, 2018, 5:55

Bonjour,

J’ai la même erreur. Page blanche lors de l’affichage du grand livre, j’ai activé le syslog. Ci-après les lignes générées suite à la tentative d’ouverture du grand livre :

2018-12-08 01:41:50 DEBUG   x.x.x.x   - This is an already logged session. _SESSION['dol_login']=admin _SESSION['dol_entity']=1
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT u.rowid, u.lastname, u.firstname, u.employee, u.gender, u.birth, u.email, u.job, u.skype, u.signature, u.office_phone, u.office_fax, u.user_mobile, u.address, u.zip, u.town, u.fk_state as state_id, u.fk_country as country_id, u.admin, u.login, u.note, u.pass, u.pass_crypted, u.pass_temp, u.api_key, u.fk_soc, u.fk_socpeople, u.fk_member, u.fk_user, u.ldap_sid, u.statut, u.lang, u.entity, u.datec as datec, u.tms as datem, u.datelastlogin as datel, u.datepreviouslogin as datep, u.photo as photo, u.openid as openid, u.accountancy_code, u.thm, u.tjm, u.salary, u.salaryextra, u.weeklyhours, u.color, u.dateemployment, u.ref_int, u.ref_ext, u.default_range, u.default_c_exp_tax_cat, c.code as country_code, c.label as country, d.code_departement as state_code, d.nom as state FROM llx_user as u LEFT JOIN llx_c_country as c ON u.fk_country = c.rowid LEFT JOIN llx_c_departements as d ON u.fk_state = d.rowid WHERE u.entity IN (0, 1) AND u.login = 'admin' ORDER BY u.entity ASC
2018-12-08 01:41:50 INFO   x.x.x.x   fetch_name_optionals_label elementtype=user
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT rowid,name,label,type,size,elementtype,fieldunique,fieldrequired,param,pos,alwayseditable,perms,langs,list,fielddefault,fieldcomputed,entity,enabled FROM llx_extrafields WHERE entity IN (0,1) AND elementtype = 'user' ORDER BY pos
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT param, value FROM llx_user_param WHERE fk_user = 1 AND entity = 1
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT rowid, entity, type, page, param, value FROM llx_default_values WHERE entity IN (0,1) AND user_id IN (0, 1)
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT r.module, r.perms, r.subperms FROM llx_user_rights as ur, llx_rights_def as r WHERE r.id = ur.fk_id AND ur.entity = 1 AND ur.fk_user= 1 AND r.perms IS NOT NULL
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT r.module, r.perms, r.subperms FROM llx_usergroup_rights as gr, llx_usergroup_user as gu, llx_rights_def as r WHERE r.id = gr.fk_id AND gr.entity = 1 AND r.entity = 1 AND gr.fk_usergroup = gu.fk_usergroup AND gu.fk_user = 1 AND r.perms IS NOT NULL
2018-12-08 01:41:50 INFO    x.x.x.x  --- Access to /htdocs/accountancy/bookkeeping/list.php - action=, massaction=
2018-12-08 01:41:50 DEBUG  x.x.x.x   Menubase::menuLoad mymainmenu=accountancy myleftmenu=accountancy_generalledger type_user=0 menu_handler=eldy tabMenu size=0
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT m.rowid, m.type, m.module, m.fk_menu, m.fk_mainmenu, m.fk_leftmenu, m.url, m.titre, m.langs, m.perms, m.enabled, m.target, m.mainmenu, m.leftmenu, m.position FROM llx_menu as m WHERE m.entity IN (0,1) AND m.menu_handler IN ('eldy','all') AND m.usertype IN (0,2) ORDER BY m.position, m.rowid
2018-12-08 01:41:50 DEBUG   x.x.x.x  sql=SELECT date_start, date_end from llx_accounting_fiscalyear  where date_start < '2018-12-08 01:41:50' and date_end > '2018-12-08 01:41:50' limit 1
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT rowid, code, label, nature FROM llx_accounting_journal WHERE entity = 1 AND active = 1 ORDER BY label DESC
2018-12-08 01:41:50 DEBUG   x.x.x.x   BookKeeping::fetchAll
2018-12-08 01:41:50 DEBUG   x.x.x.x   sql=SELECT t.rowid, t.doc_date, t.doc_type, t.doc_ref, t.fk_doc, t.fk_docdet, t.thirdparty_code, t.subledger_account, t.subledger_label, t.numero_compte, t.label_compte, t.label_operation, t.debit, t.credit, t.montant, t.sens, t.fk_user_author, t.import_key, t.code_journal, t.journal_label, t.piece_num, t.date_creation, t.tms as date_modification FROM llx_accounting_bookkeeping as t WHERE entity IN (1) AND t.doc_date>='2018-01-01 00:00:00' AND t.doc_date<='2018-12-31 23:59:59' ORDER BY t.piece_num ASC, t.rowid
2018-12-08 01:41:53 INFO    x.x.x.x   --- End access to /htdocs/accountancy/bookkeeping/list.php

On a affaire à des requetes sql. Mais il y aucun message d’erreur (je suis au niveau 7 LOG DEBUG ). Une idée sur l’origine du bug ?

laboul · Janvier 2, 2019, 11:33

[Résolu]
Bonjour et bonne année à toutes et à tous

J’ai la même erreur de page blanche sur le grand livre, et j’ai un état annuel à sortir pour l’AG dans quelques jours.

Par ailleurs le résultat des ventilations des journaux pour les opérations déjà ventilées sont vides aussi.

Je viens de saisir une partie du deuxième semestre pour une association et le rapport d’exercice ne prend pas en compte les écritures saisies.

Les parties facturation, tiers et banques ont bien fonctionné;

Pour le module Comptabilité, les lignes fournisseurs sont bien liées.

Je suis en version 8.0.4. Je viens d’activer le syslog, mais cela ne me parle pas.
je suis super admin avec toutes les autorisations.

Si quelqu’un à une idée, cela m’arrangerait grandement.

par avance merci.

Edit : merci @aspangaro ; j’avais oublié une étape dans la ventilation des journaux

aspangaro-Easya · Janvier 3, 2019, 4:27

Bonjour et meilleurs voeux 2019 !

@rol & @ freegate & @laboul

Pouvez-vous me transmettre un accès admin à vos dolibarr respectifs pour vérifier ce qui ne vas pas et trouver une solution car effectivement le log ne donne rien…

Il suffit de m’envoyer un email à l’adresse suivante aspangaro AT open-dsi DOT fr

Merci de me préciser aussi si vos versions sont des installations propres ou mise à jour depuis longtemps.

Bonne journée,

Arre · Janvier 3, 2019, 8:04

@aspangaro

Regarde au niveau du plan comptable: j’ai vu plusieurs cas de bizarrerie dans des migrations 7 -> 8
Vider la table (sauf les comptes créés manuellement) et regenerer le Plan à partir du modèle a corrigé le problème à chaque fois.

Par contre… je n’ai pas trouvé la cause.

yves57 · Janvier 3, 2019, 1:10

Bonjour,
Pour une page blanche, ce sont les logs du serveur web (apache) qu’il faut. C’est là qu’une erreur PHP, cause de la page blanche, peut être enregistrée, pas dans le syslog de Dolibarr.