[14.0][IMP] connector_sage: detect employee code reassignment on import - #950
Open
deeniiz wants to merge 1 commit into
Open
[14.0][IMP] connector_sage: detect employee code reassignment on import#950deeniiz wants to merge 1 commit into
deeniiz wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 14.0 #950 +/- ##
==========================================
+ Coverage 51.50% 52.10% +0.59%
==========================================
Files 1182 1184 +2
Lines 20438 20504 +66
Branches 4299 4302 +3
==========================================
+ Hits 10526 10683 +157
+ Misses 9657 9542 -115
- Partials 255 279 +24 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Sage reuses employee codes: a code can be given to a different person. The importer resolves the binding by (CodigoEmpresa, CodigoEmpleado) alone, so after a reassignment the sync relabeled the employee while the partner kept the old person, misattributing payroll payments. Add a _validate_update() hook to the generic importer, called on an existing binding after the mapping and right before the write. The partner importer overrides it to compare the incoming Sage identity (SiglaNacion+Dni) against the partner VAT, which holds the identity the code belonged to at first import (the euvat mapping is @only_create, so no later sync rewrites it). On mismatch the import stops with ValidationError and the queue job fails without retries; the error message documents both unlock procedures (same person with a new identity document -> fix the partner VAT and retry the job; real reassignment -> delete the Sage bindings of the code and retry). The employee import always imports the partner dependency first, so a reassigned code stops before the employee is touched. Partners without VAT (e.g. excluded by employees_exclude_nif_pattern) cannot be checked and are skipped. The identity normalization is a single mapper method, sage_identity(), shared by the euvat mapping and the guard.
deeniiz
force-pushed
the
14.0-imp-connector_sage-detect_employee_code_reassignment
branch
from
July 17, 2026 10:16
7066dee to
fccc866
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sage reuses employee codes: a code can be given to a different person. The importer resolves the binding by (CodigoEmpresa, CodigoEmpleado) alone, so a reassigned code relabeled the existing employee while the partner kept the old person (partner fields are
@only_create), silently mixing two people and misattributing payroll payments.Add a
_validate_update()hook to the generic importer, called on an existing binding right before the write. The partner importer overrides it to compare the incoming identity (SiglaNacion+Dni) against the partner VAT, frozen at first import by the@only_createeuvat mapping: on mismatch the import raises ValidationError and the queue job fails visibly, with both unlock procedures in the message (same person with a new document → fix the partner VAT and retry; real reassignment → delete the Sage bindings and retry). The employee import brings the partner as a dependency, so the single guard covers both flows. Partners without VAT (employees_exclude_nif_pattern) are skipped.