SAP S/4HANA date de saisie, date du document et diagnostic du refus de période de saisie
Un refus de saisie est généralement un problème de contrôle des périodes, et non une erreur de date de document. La date d'écriture comptable est la date d'émission du document, tandis que la date de saisie détermine la période de saisie vérifiée par le système. La variante de période de saisie, et non la variante de l'exercice fiscal, ouvre et ferme les périodes pour l'en-tête et chaque type de compte.
Dans ce guide
La réponse courte
Un refus de saisie est généralement un problème de contrôle des périodes, et non une erreur de saisie de date. La date d'écriture comptable est la date d'émission du document, tandis que la date de saisie détermine la période de saisie que le système vérifie. La variante de période de saisie, et non la variante de l'exercice fiscal, décide si cette période est ouverte pour l'en-tête du document et pour chaque type de compte des lignes. Une saisie peut échouer même si la date de saisie tombe dans le bon mois calendaire, si la période concernée est fermée, si un type de compte spécifique est fermé, ou si l'utilisateur n'a pas l'autorisation pour un intervalle de régularisation. Les variantes de l'exercice fiscal définissent uniquement le nombre de périodes et leurs débuts et fins ; elles n'ouvrent ni ne ferment les périodes. Lors du diagnostic sans modifier la configuration, lisez le message de refus, identifiez si l'en-tête ou un type de compte de la ligne a échoué, et décidez si la date de saisie, la date du document ou l'affectation de compte est le vrai problème. Ne supposez pas qu'une période fermée doit être rouverte ; confirmez plutôt la période prévue, l'affectation de la variante et l'autorisation de l'utilisateur, puis choisissez une action légitime telle que corriger la date, utiliser un autre type de compte, ou escalader vers la personne qui gère les périodes.
Distinguer les deux dates
L'en-tête du document porte à la fois une date d'écriture comptable et une date de saisie, et elles ne sont pas interchangeables. La date d'écriture comptable est la date d'émission du document original. La date de saisie est généralement la date utilisée lors de la saisie du document en Comptabilité Financière, et c'est le champ qui déclenche la vérification de la période de saisie. La période de saisie elle-même est dérivée de la date de saisie, et c'est cette période que le reporting utilise pour placer les valeurs du document dans la période de reporting correcte. En d'autres termes, la date du document indique quand le document métier a été créé, tandis que la date de saisie indique au système où classer la saisie pour le contrôle des périodes et le reporting.
Cette distinction est importante car un utilisateur peut saisir une date de document qui semble raisonnable et obtenir un refus si la date de saisie tombe dans une période fermée. La vérification de période du système est liée à la date de saisie, et non uniquement à la date du document. Si les deux dates diffèrent, ne supposez pas que la date du document est la valeur de contrôle. Traitez la date de saisie comme la valeur principale pour l'acceptation de la période, et traitez la date d'écriture comptable comme la référence d'émission du document.
Pour une illustration concrète, imaginez une facture datée du 28 septembre avec une date de saisie du 30 septembre. Dans une variante d'exercice fiscal calendaires, les deux dates tombent en septembre, donc la date du document et la date de saisie pointent vers le même mois. Même ainsi, cet alignement ne garantit pas l'acceptation, car l'acceptation dépend de savoir si la période de saisie de septembre est ouverte pour les types de compte concernés. L'exemple est hypothétique et est utilisé uniquement pour séparer le sens des deux dates de la question distincte de savoir si la période est ouverte.
Relier la date de saisie au calendrier fiscal
La date de saisie est mappée à une période fiscale via la variante de l'exercice fiscal affectée au code société. Cette variante définit combien de périodes existent et où chaque période commence et finit. Elle ne décide pas, en soi, si une période est ouverte ou fermée. Cette séparation est importante : la logique calendaire indique au système à quelle période fiscale une date appartient, mais la décision ouvert/fermé est prise ailleurs.
Dans un exercice fiscal calendaires simple, une date de saisie du 30 septembre est mappée à septembre. Dans un exercice fiscal non calendaires, la même date calendaire peut tomber dans une période fiscale différente, ou une période fiscale peut couvrir des parties de deux mois calendaires. C'est pourquoi une règle naïve comme 'septembre égale période 9' peut être fausse dans un système spécifique. La variante de l'exercice fiscal est la raison pour laquelle le mappage existe, mais ce n'est pas le contrôle qui accepte ou refuse la saisie.
Parce que la variante de l'exercice fiscal définit uniquement la structure des périodes, vous devez l'utiliser pour interpréter le mappage date-à-période, et non pour conclure qu'une période doit être ouverte. Si le mappage lui-même est flou, le problème peut être les limites de période de la variante plutôt que la saisie de la date de saisie. Dans l'exemple septembre, le mappage calendaires est simple uniquement parce que la variante supposée est explicitement calendaires ; cette hypothèse ne doit pas être transposée à tous les systèmes.
Vérifier la variante de période de saisie
La variante de période de saisie est l'objet qui contrôle quelles périodes fiscales sont ouvertes ou fermées. Elle a un identifiant et une description et est affectée à un ou plusieurs codes sociétés, donc les codes sociétés partageant la même variante peuvent gérer leurs périodes ensemble. Après la création de la variante, elle est affectée dans les paramètres globaux du code société et est utilisée pour le grand livre principal, les autres grands livres étant par défaut issus de cet affectation sauf si une variante différente est définie pour un grand livre non principal.
La variante est vérifiée par rapport à la date de saisie. La première vérification est la ligne globale ou en-tête, qui couvre le total du document et est vérifiée en premier pour chaque saisie. Cette ligne en-tête doit être ouverte pour au moins les mêmes périodes que tout type de compte, car si l'en-tête est fermé la saisie ne peut pas passer du tout. Si tous les types de compte sont traités de la même manière, la ligne en-tête peut être la seule ligne nécessaire. Si les types de compte nécessitent un traitement différent, la variante peut définir des intervalles séparés pour chaque type de compte.
Le détail des types de compte est important car la clôture de fin de période peut être échelonnée. Par exemple, les saisies clients ou fournisseurs peuvent être fermées avant les saisies sur les comptes du grand livre. Les types de compte incluent client, fournisseur, actifs, comptes du grand livre, matériel et comptes de contrats. Une saisie peut donc passer la vérification de l'en-tête et échouer sur une ligne si le type de compte de cette ligne est fermé pour la période fiscale. Dans l'exemple septembre, la date de saisie pourrait être valide pour l'en-tête tandis qu'un compte fournisseur est fermé, et le système signalerait que le grand livre n'est pas ouvert pour ce compte fournisseur dans cette période fiscale.
Tracer un exemple de date concret
En utilisant la facture hypothétique datée du 28 septembre et saisie le 30 septembre, la première étape est de laisser le système mapper la date de saisie à une période fiscale sous la variante de l'exercice fiscal affectée. Sous une variante d'exercice fiscal calendaires explicitement supposée, ce mappage pointe vers septembre. C'est seulement l'étape de mappage ; elle ne dit pas encore si septembre est ouvert.
L'étape suivante est la vérification de la variante de période de saisie. Le système vérifie la ligne en-tête par rapport à la date de saisie en premier. Si la période de septembre est ouverte dans l'intervalle d'en-tête, la vérification de l'en-tête passe. Si l'en-tête est fermé, la saisie est refusée à ce point, indépendamment des lignes. Si l'en-tête passe, le système vérifie ensuite le type de compte de chaque ligne contre la variante. Une date de saisie de septembre peut encore échouer si le type de compte concerné est fermé pour septembre.
C'est ainsi qu'une saisie peut être refusée même lorsque la date du document et la date de saisie semblent appartenir au même mois. L'exemple n'est pas un test système observé ; c'est un moyen de séparer trois questions : quelle période la date de saisie mappe, si cette période est ouverte dans l'en-tête, et si le type de compte spécifique sur la ligne est ouvert. Ces trois questions peuvent produire des réponses différentes dans le même document.
Lire le refus avant de changer quoi que ce soit
Lorsqu'une saisie est refusée, la première étape de diagnostic est de lire attentivement le message de refus au lieu de modifier immédiatement la configuration. La vérification de période du système renvoie des échecs différents selon l'endroit où le problème se produit. Si la date de saisie tombe dans une période fiscale fermée, le système répond que la saisie dans la période n'est pas possible. Si la date de saisie est valide mais qu'un type de compte de ligne est fermé, le système peut renvoyer un message indiquant que le grand livre n'est pas ouvert pour cette période fiscale et ce compte.
Cette différence est l'indice diagnostique clé. Un refus au niveau de l'en-tête pointe vers la date de saisie et le paramètre global de la variante de période de saisie. Un refus de ligne pointe vers le type de compte, le compte spécifique ou l'intervalle qui régit ce type de compte. Ne traitez pas les deux échecs comme le même problème. Le texte du refus indique si le système s'est arrêté à la vérification de l'en-tête ou plus tard à une vérification de ligne.
Dans l'exemple septembre, un refus d'en-tête signifierait que la période de saisie de septembre n'est pas ouverte dans l'intervalle d'en-tête pour la date de saisie. Un refus de ligne pourrait signifier que la date de saisie est acceptable mais que l'intervalle fournisseur, client, actifs, grand livre, matériel ou comptes de contrats est fermé pour cette période. Lire le message avec précision vous empêche de modifier la mauvaise chose, comme ajuster la date du document alors que le vrai problème est une période de saisie fermée ou un intervalle de type de compte fermé.
Vérifier la portée et les autorisations
La variante de période de saisie contient des intervalles séparés, et l'intervalle concerné change la portée de la vérification. L'Intervalle 1, parfois appelé intervalle de régularisation, est utilisé pour ouvrir des périodes en dehors du traitement métier normal et peut comporter un groupe d'autorisation. Ce groupe d'autorisation restreint qui peut saisir dans cette période via l'objet de permission pertinent dans le profil de sécurité de l'utilisateur. L'Intervalle 2, parfois appelé intervalle normal, ouvre la période courante pour les transactions métier et s'applique à tous les utilisateurs ; il ne peut pas être restreint de la même manière. L'Intervalle 3 est utilisé pour les saisies de la Comptabilité de Gestion vers la Comptabilité Financière, et s'il n'est pas rempli, les paramètres des intervalles 1 et 2 s'appliquent aussi à ces saisies.
Cela signifie qu'un refus peut venir de plus d'une source. Un utilisateur peut essayer de saisir dans un intervalle de régularisation sans l'autorisation requise, même si la période est techniquement ouverte. Ou l'intervalle normal peut simplement ne pas couvrir la date de saisie. Ou la saisie liée à la CG peut nécessiter une période de saisie FI ouverte et un verrou de période CG séparé. La question diagnostique n'est pas seulement 'La période est-elle ouverte ?' mais aussi 'Quel intervalle s'applique, et l'utilisateur a-t-il accès à cet intervalle ?'
Pour l'exemple septembre, si la date de saisie est dans une période qui n'est ouverte que dans l'Intervalle 1 et que l'utilisateur n'a pas le groupe d'autorisation requis, la saisie peut être refusée même si la période est ouverte pour d'autres. C'est une situation différente d'une période fermée pour tous. Distinguer ces cas est important car l'étape suivante légitime dépend de savoir si le problème est une autorisation, une couverture d'intervalle ou une période fermée.
Choisir une action suivante légitime
Une fois le refus compris, l'action suivante doit correspondre à la cause diagnostiquée et ne doit pas supposer que rouvrir une période est la bonne correction. Si la date de saisie est simplement dans une période fermée et que l'intention métier est de saisir dans une autre période, l'action appropriée peut être de corriger la date de saisie vers une période ouverte pour les types de compte prévus. Si la date du document et la date de saisie sont confondues, clarifiez quelle date le processus métier exige réellement et saisissez la date de saisie en conséquence.
Si l'en-tête passe mais qu'un type de compte de ligne échoue, le problème peut être l'affectation de compte ou le statut de période pour ce type de compte. Dans ce cas, l'action légitime est de vérifier si le type de compte devrait être ouvert pour la période prévue ou si la saisie doit être routée différemment. Si l'échec est lié à un intervalle de régularisation et que l'utilisateur n'a pas l'autorisation, l'action est d'utiliser un utilisateur disposant de l'autorisation requise ou de router la saisie via le processus approprié, et non d'élargir l'accès informellement.
Si la saisie est pertinente pour la CG, rappelez-vous que les contrôles de période FI et CG peuvent différer. Une saisie de la Comptabilité de Gestion vers la Comptabilité Financière peut nécessiter une période de saisie FI ouverte et peut aussi être affectée par le verrou de période CG. L'étape suivante légitime peut être de confirmer les deux contrôles plutôt que de modifier un seul côté. Dans tous les cas, le but est de résoudre l'échec de contrôle spécifique identifié par le refus, et non de modifier la configuration comme réponse par défaut.
Garder les limites d'édition et de configuration
Les concepts des extraits sont généraux, mais les champs concrets, les noms d'applications, les objets d'autorisation et les contrôles disponibles peuvent varier selon la configuration du produit et l'édition. Les extraits indiquent que les variantes de l'exercice fiscal définissent le nombre de périodes et leurs dates de début et de fin, et que les variantes de période de saisie contrôlent l'ouverture et la fermeture. Ils indiquent aussi que la ligne en-tête est vérifiée en premier et que les types de compte peuvent être traités différemment. Ce sont les limites dans lesquelles vous devez travailler : utilisez la variante de l'exercice fiscal pour comprendre la structure des périodes, et utilisez la variante de période de saisie pour comprendre le contrôle ouvert/fermé.
Ne généralisez pas à partir d'un seul système. Un exercice fiscal calendaires peut faire paraître l'exemple septembre simple, mais une variante non calendaires ou des périodes spéciales peuvent changer le mappage et la logique d'acceptation. Les grands livres non principaux peuvent utiliser des variantes de période de saisie différentes, donc le défaut du grand livre principal n'est pas toujours toute l'histoire. Les extraits notent aussi que l'Intervalle 3 peut être laissé vide, auquel cas les intervalles 1 et 2 s'appliquent aussi aux saisies pertinentes pour la CG, ce qui est un autre détail dépendant de la configuration.
Gardez la logique de diagnostic liée à ce que le système vérifie réellement : la date de saisie par rapport à la variante de période de saisie, d'abord au niveau de l'en-tête puis au niveau du type de compte, avec les effets d'intervalle et d'autorisation là où ils s'appliquent. Utilisez l'exemple septembre uniquement comme moyen de séparer le sens des dates, le mappage fiscal et le contrôle des périodes. Ne le traitez pas comme la preuve de comment un système spécifique se comportera, et ne le présentez pas comme un résultat de test observé.
Points à vérifier
- Vérifiez si le refus concerne la période de l'en-tête du document ou un type de compte spécifique sur les lignes.
- Vérifiez la date de saisie, et pas seulement la date du document, car la date de saisie déclenche la vérification de la période.
- Identifiez la variante de l'exercice fiscal uniquement pour comprendre le nombre de périodes ; ne la traitez pas comme le contrôle ouvert/fermé.
- Identifiez la variante de période de saisie affectée au code société et au grand livre principal avant de supposer qu'une période est ouverte.
- Vérifiez si la période en échec se trouve dans l'Intervalle 1, l'Intervalle 2 ou l'Intervalle 3, car l'autorisation et la portée diffèrent.
- Confirmez si l'utilisateur dispose du groupe d'autorisation requis pour une saisie dans un intervalle de régularisation, si cet intervalle est concerné.
- Distinguez un problème de période fermée d'un type d'écriture comptable incorrect ou d'une affectation de compte incorrecte, qui peuvent aussi fausser la reporting.
- Évitez de modifier la configuration en premier lieu ; utilisez le texte du refus et les champs du document pour réduire la cause d'abord.
Champ d’application
Ces indications sont basées sur les extraits d'apprentissage SAP fournis et sont descriptives, non une procédure de configuration. Les noms de champs de document, les noms d'applications, les objets d'autorisation et les contrôles disponibles peuvent varier selon la version du produit, l'édition et la configuration du code société. Les extraits expliquent que la variante de l'exercice fiscal définit le nombre de périodes et leurs dates de début et de fin, tandis que la variante de période de saisie contrôle l'ouverture et la fermeture ; ils ne fournissent pas de liste universelle de champs ni un texte de message garanti pour chaque système. Les périodes spéciales, les exercices fiscaux non calendaires et les grands livres non principaux avec des variantes de période de saisie différentes peuvent briser une hypothèse simple de mois-à-période. L'exemple septembre est hypothétique et n'est ni un test système exécuté ni un résultat de récupération observé. N'utilisez pas ceci comme substitut au message système réel, à la configuration spécifique de la variante ou au design d'autorisation de votre environnement.