Génération automatique du numéro de facture trop lent

Nous avons un problème étrange depuis le changement de serveur de notre BD Acomba. Il arrive parfois que, lors de la sauvegarde d'une facture (avec un objet de type "Transaction" et la méthode XModifyCard), l'inscription dans la BD ne se fait pas assez rapidement (du moins, c'est ce que nous croyons) et la valeur de la propriété InInvoiceNumber reste "nulle". Notre application s'attend de recevoir cette valeur en retour de fonction et ne peut pas continuer sans cela.

Un problème similaire nous était déjà arrivé lors de l'installation d'un anti-virus qui ralentissait trop les lectures et les écritures sur disque. Par contre, nous sommes certains que cela n'est pas la cause du problème actuel. Nous avons essayé d'ajouter des "sleep" afin de permettre à la BD de faire son écriture, mais cela n'a pas aidé.

Je suis encore dans mes apprentissages avec le SDK d'Acomba et je ne sais pas si il existe une meilleure façon de procéder. Voici une version légèrement simplifié de ma méthode :

Code:

public long saveInvoice(XmlDocument xmlDoc)
{
  Transaction transactionData = new Transaction();
  // remplir l'objet transactionData avec les informations contenues dans l'xml
  short FreeIt = 1;
  object ibc = Constant.IsBeingCreated;
  int err = transactionData.XModifyCard(ref ibc, FreeIt);
  if (err != 0)
    throw new Exception(err.ToString());
  return transactionData.InInvoiceNumber;
}

Merci beaucoup

bonjour

une fonction pour calculer un numéro de facture peut etre une solution plutot que d'attendre acomba !!!

genre (Dernière facture selon un type donné)+1

comme cela plus de probleme de delai !

bon succes,

hench

une fonction pour calculer un numéro de facture peut être une solution plutôt que d'attendre acomba !!!

Bien dangereux que cela. Car entre le moment où l'on fait le calcul et le moment où la facture qui nous intéresse sera enregistrée, un autre utilisateur sur un autre poste pourrait avoir créé une facture qui aura le numéro que l'on a calculé. Il ne faut pas essayer de battre l'engin de base de données.

Pour en revenir au code qui était présenté dans le premier message - sans être un expert du sdk - je ne comprends l'appel à XModifyCard, car ModifyCard a pour but de modifier une carte existante, pas de créer quelque chose de nouveau .

Je ne crois pas, car le numéro est Réservé, donc impossible à dupliquer le temps de la réservation !!!

Dans ce cas, à quoi sert cette option à l'onglet Client de Information société (extrait de l'aide):

Avertir d’un changement de numéro de facture : Cocher cette case affiche un message lorsque le numéro de la facture est modifié lors de son enregistrement. Cette situation peut survenir lorsque plus d’un usager effectue de la facturation en même temps.

Cela est parfait pour le Frontend !
Je viens de faire un test, 2 acomba ouverts sur la même compagnie avec 2 usagers différents

-Création d'une facture de chaque bord
Curieusement, le numéro de facture généré est le même, donc, le numéro n'est pas réservé !
-Je sauvegarde un bord
-Je sauvegarde l'autre bord, et m'indique que le numéro de facture a été changé. (La case a cocher que vous avez souligné.)



Au SDK, il faut réserver avant de pouvoir écrire quoi que ce soit (méthode ReserveCardNumber) ... donc je ne vois pas le soucis a avoir ... s'il y a un conflit a la sauvegarde d'une facturation au frontend, l'usager sera avertis.

Je viens de faire un test rapide pour tester le comportement du SDK.
1. Dans le frontend, je commence la création d'une facture,
2. En programmation, j'essaie de réserver le même numéro de facture, et il est impossible de réserver. Une certaine forme de protection est présente pour éviter le problème !!!

Well,... vive la fête du travail

Int ReserveCardNumber( )


Cette méthode réserve une valeur de clé primaire pour le type d'enregistrement correspondant à l'interface pour laquelle la méthode est appelée. Les propriétés, dont le nom débute par PKey_, composant la clé primaire de cette interface doivent préalablement être initialisées avec la valeur de clé primaire à réserver.

La réservation de la clé primaire d'une fiche, par exemple le numéro d'un client ou le numéro d'un compte, préalablement à sa création permet d'assurer le caractère unique de cette valeur de clé primaire.

Dans le cas de la création d'un client, on détermine sois-même la clef. Mais dans le cas d'une facture, faite par Facturation, c'est Acomba qui détermine le no. Alors il y a un truc que je ne saisis pas . Par contre, dans le cas d'une inscription de facture, par exemple des factures d'un ancien système comptable, c'est nous qui détermine le no de facture. Alors là ce serait normal de pouvoir réserver un numéro.

Supposons que l'on utilise Acomba, pas le SDK. Si l'on fait une facture par Facturation > Facturation, le no de facture ne se pointe que si lorsque l'on enregistre. Par contre, quand on fait une inscription, impossible de taper quelque chose tant que l'on n'a pas donné le no de facture (déterminé manuellement).