Vos souhaits

[Conceptify]

Bonjour,

Tout d'abord, un grand merci pour cet excellent logiciel très complet que j'utilise depuis maintenant plus de 3 ans !

L’amélioration que je souhaite le plus est pour moi aussi, une gestion du dépôt des espèces en banque.
Je trouve dommage de devoir faire ça en saisie d'écriture comptable.

[rdcongo]

Bonjour Guillaume,
Pour ma part(je vis en république Démocratique du Congo), j'aimerais que OC soit un peu plus souple pour s'adapter a l'international. par exemple les identifiants professionnels utilises en France(URSSAF, SIRET , SIREIN, RCS, NII, APE) ne sont pas applicables.
N' y' aurait il pas moyens de permettre l’édition de ces champs ou la sélection automatique des noms de ces identifiants en fonction du pays de la societé/client,etc.
Merci

[JeromeL]

Bonjour,
De mon coté ce serait:

- le fait de pouvoir décocher POUR TOUJOURS la case ligne de contrepartie automatique dans "Créer une saisie au kilomètre"

- Avoir accès aux paramètres de la ligne de commande "Envoyer le document par mail":
Je suis sur Debian/Linux et je n'ai ni thunderbird, ni outlook, j'ai droit à une grosse erreur java

The MAIL action is not supported on the current platform!

si je règle sur client mail par défaut. Je suis sur Kmail.

- une jolie interface toute belle , c'est un peut resté sur windows 98 là
- Du graphique, d'évolution sur 12 mois

[doc]

Une petite chose qui serait pas mal également, en lieu et place des tâches à l'ouverture d'OC, un dashboard configurable.

[NDE-BB]

Bonjour,

Afin de répondre à la législation* (et ne pas avoir d'amende en cas de contrôle) : sur les factures pouvoir mettre le/les n°de BL avec leurs dates d'expédition

source : https://www.economie.gouv.fr/entreprise ... ligatoires

j'ai essayé avec diverses config ci-dessous mais...

<element location="B16" type="fill">
<field base="Client" table="BON_DE_LIVRAISON">
<field name="DATE_LIVRAISON" type="Date" />
</field>
</element>


<element location="B16" type="fill">
<field table="BON_DE_LIVRAISON">
<field name="CREATION_DATE" /> OU DATE TT SEUL
</field>
</element>


=============> OC indique erreur  : The table of the row SAISIE_VENTE_FACTURE[1900] doesn't contain the field 'null'.



<element location="B16" type="fill">
<field name="BON_DE_LIVRAISON">
<field name=DATE" />
</field>
</element>
=============> OC indique erreur  : et me dit que la table facture contient les champs xxx (dont ID_ADRESSE_LIVRAISON) et donc à priori pas celui de la date du BL

NB : perso, je ne suis pas capable de prévoir la date de livraison (différent transporteur entre 24 et 72h voir plus ou le client qui passera prendre... un jour....) donc si je peux au moins mettre la date d'émission du BL

Nath

[Lmlmd31]

A Nath,
A la lecture de ton lien, tu te trompes.
Il ne faut pas rappeler le n° de livraison, il faut rappeler le n° du bon de commande si c'est l'acheteur ( ton client) qui la éditer, ou rappeler la date de la prestation effectuée. En tout cas, c'est ce que je comprends.
De plus, cela me paraît bizarre que, quand tu transfert ton bl en facture, il n'y est pas toutes les références obligatoire( je n'edite pas de bl, donc je n'en suis pas sur)
Cordialement.

[NDE-BB]

à Lmlmd31,

la loi demande de faire référence aux pièces commerciales précédant la facture : devis, n° commande client si existe, AR si existe, BL (et depuis peu sa date) sur la facture (sur que pour du service à la personne pas besoin de BL) <=> doit pouvoir faire le lien entre les pièces justificatives
Comme nous fabriquons et expédions, nous utilisons les Bons de Livraison

actuellement, les références reprennent, automatiquement les numéros de devis, AR/n° commande client, BL/facture (personnellement, j'ai cocher "transférer les n° de pièces.. en tant que référence" et pas dans le corps) mais la date du BL n'y est pas encore

le mieux étant, je pense, de prévoir cela à part des références ou de pouvoir l'incrémenter en auto dans le corps (ce que font bcp de nos fournisseurs)
actu je l'entre manuellement
cordialement

[JacquesF]

Bonjour,

Une réflexion suite à un post récent liée à la sauvegarde proposée en sortie du programme.
Le bouton affiché génère une extraction des données au format texte et les commandes SQL de création des tables au format des principaux SGBD utilisables.
Je pense qu'une info-bulle et un message (avec une case à cocher pour ne plus l'afficher une fois qu'il a été "compris") indiquant que c'est une sauvegarde de dernier recours serait nécessaire lors de l'utilisation de ce bouton.

Toutefois, on peut distinguer 3 cas pour implémenter un bouton permettant de lancer un script de sauvegarde personnalisé :
- Travail sur la base intégrée en local (pas de difficulté particulière en principe)
- Travail sur la base PostgreSQL du serveur mais en local sur celui-ci (pas de grosses difficultés pour accéder à pg_dump)
- Travail sur la base PostgreSQL du serveur mais à distance (accès à pg_dump possible via SSH)
Dans le cas PgSQL on a aussi les différents types d'OS à prendre en compte, le client pouvant être sur un OS différent.

A priori, il est possible de lancer pg_dump via java, mais je pense que dans ce cas le programme de dump doit être local à la machine.
Dans le cas où le client est distant, il est possible (y compris pour Windows) d'installer un serveur SSH sur le serveur SQL et de créer une authentification par clefs pour éviter la saisie des mots de passe. Ensuite, lancer le programme de dump via un script local sur la machine distante est possible et on peut même rapatrier les données en local pour les archiver en dehors du serveur.

Je pense que dans un premier temps permettre de personnaliser la boîte de dialogue de sortie du programme par un bouton pointant vers un script personnalisé (avec l'option de masquer ou non dans ce cas le bouton de sauvegarde de dernier recours) ne représente pas un très gros développement. Comme on est dans un principe de script, on peut supposer que la modification d'un fichier .config ne serait pas trop délicat pour un administrateur.
Pour un utilisateur lambda, ce serait pour la prochaine étape, quitte à s'appuyer sur des scripts "maisons" partagés via le forum..
De plus, il est très probable que ce type de commande trouverait sa place dans la version cloud.

A voir la faisabilité, je veux bien partager mon script de sauvegarde quotidien de ma BDD depuis mon serveur (Debian) vers mon PC (linux) et sur mon NAS. Ce script fait aussi la sauvegarde tous les 15 jours des fichiers de configuration des clients linux et Win7, ainsi que l'archivage des documents PDF et ODS tous les dimanches, le tout étant exporté par sécurité sur un dossier dans le cloud en plus.

Jacques

[guillaume]

Bonjour,

Effectivement, en momoposte, rien de plus simple, on a la copie du fichier H2.

En version multiposte, nous avons choisi de rester au niveau de fichiers textes pour être indépendant de la base de données.
En théorie, nous ne devrions même pas permettre de sauvegarde du serveur depuis le logiciel, la sauvegarde étant de la responsabilité de l'administrateur du serveur.
Un "cron" avec "pg_dump" suffit tant que ce fichier est sauvegardé sur un support externe fiable.

Pour le cloud, on s'occupe de tout

Les choses vont changer avec la version web, le service tournant sur le serveur pourrait se charger (dans le futur) des sauvegardes.

Cordialement,

[JacquesF]

Merci des éclaircissements.

Je suis d'accord pour la part de responsabilités, mais peut-être qu'un message indiquant le type exact de sauvegarde (non restaurable sans connaissances avancées ou un support ILM) à l'usage serait utile en ce cas.
Ça éviterait probablement des surprises désagréables.

En tout cas bravo à l'équipe pour le travail réalisé.
Jacques