> ## Documentation Index > Fetch the complete documentation index at: https://docs.arcuserp.com/llms.txt > Use this file to discover all available pages before exploring further. # Retroactively remap Versa-migration 8xxx leaves to Arcus native GL accounts > Retroactive cleanup helper for entities loaded with the under-covered Phase 5A fold-rule set. For each item, transactionally swaps every `journal_entry_lines.gl_account_id` reference from FROM to TO, then optionally soft-deletes the FROM account. **Safety invariants (HARD BAR).** - Both accounts must belong to the API key's entity. - FROM must be a Versa-migration leaf: description must contain `versa_real_id=` or "Migrated from Versa". Native Arcus accounts never carry this tag, so this gate prevents the handler from ever touching a native account. - TO must have `system_account_key NOT NULL` (must be a native Arcus account; remapping one 8xxx leaf to another is rejected). - Per-pair transaction with `SELECT ... FOR UPDATE` locks on both accounts. - Pre/post snapshot of `journal_entry_lines.count + SUM(debit) + SUM(credit)` for FROM is compared against TO's delta; mismatch aborts the transaction so TB never drifts. **soft_delete_source.** Optional. When true AND zero JE lines remain pointing at FROM after the UPDATE (verified in-transaction), the source account is soft-deleted with `deleted_at = NOW()` and `is_active = false`. When a concurrent writer adds a JE line to FROM between the UPDATE and the orphan check, the soft-delete is skipped (the swap still committed). **Max 50 items per call** (smaller cap than relink because each item locks the gl_account row + UPDATEs every JE line on it; large batches risk lock contention with concurrent posters). **Scope:** `migration:write`. ## OpenAPI ````yaml /openapi.yaml post /entities/{entity_id}/migration/gl-accounts/remap openapi: 3.1.0 info: title: Arcus ERP Public API version: 1.0.0 description: > Arcus ERP public REST API. Designed for external integrations and data migration. **Authentication.** Bearer token (API key) via the `Authorization` header. Format: `Authorization: Bearer ark_live_ent__` (or `ark_test_*` for sandbox). API keys are issued per-entity in **Settings > Developers > API Keys**. **Entity scoping.** The entity is encoded in the API key prefix; routes are flat (e.g. `/v1/accounts`, `/v1/orders`, `/v1/products`). A small set of platform endpoints (migration, reconciliation, events, webhook endpoints, API keys) use the `/v1/entities/{entity_id}/...` form -- those are noted in their tags. **Key capabilities.** - Related-resource hydration via `?expand[]=` (see `x-arcus-expand` on each resource). - Cursor-based pagination (`starting_after` / `ending_before` / `limit`). - Idempotency via the `Idempotency-Key` header. - Webhook events for asynchronous notification. - Conditional requests / ETag for cache validation. servers: - url: https://api.arcuserp.com/v1 description: Arcus ERP API (accepts both live `ark_live_*` and test `ark_test_*` keys) - url: https://dev-api.arcuserp.com/v1 description: >- Dev sandbox API (test-only data, accepts `ark_test_*` keys against dev RDS) security: [] paths: /entities/{entity_id}/migration/gl-accounts/remap: post: tags: - Migration summary: >- Retroactively remap Versa-migration 8xxx leaves to Arcus native GL accounts description: | Retroactive cleanup helper for entities loaded with the under-covered Phase 5A fold-rule set. For each item, transactionally swaps every `journal_entry_lines.gl_account_id` reference from FROM to TO, then optionally soft-deletes the FROM account. **Safety invariants (HARD BAR).** - Both accounts must belong to the API key's entity. - FROM must be a Versa-migration leaf: description must contain `versa_real_id=` or "Migrated from Versa". Native Arcus accounts never carry this tag, so this gate prevents the handler from ever touching a native account. - TO must have `system_account_key NOT NULL` (must be a native Arcus account; remapping one 8xxx leaf to another is rejected). - Per-pair transaction with `SELECT ... FOR UPDATE` locks on both accounts. - Pre/post snapshot of `journal_entry_lines.count + SUM(debit) + SUM(credit)` for FROM is compared against TO's delta; mismatch aborts the transaction so TB never drifts. **soft_delete_source.** Optional. When true AND zero JE lines remain pointing at FROM after the UPDATE (verified in-transaction), the source account is soft-deleted with `deleted_at = NOW()` and `is_active = false`. When a concurrent writer adds a JE line to FROM between the UPDATE and the orphan check, the soft-delete is skipped (the swap still committed). **Max 50 items per call** (smaller cap than relink because each item locks the gl_account row + UPDATEs every JE line on it; large batches risk lock contention with concurrent posters). **Scope:** `migration:write`. operationId: postMigrationGlAccountRemap parameters: - name: entity_id in: path required: true schema: type: string format: uuid - name: Idempotency-Key in: header required: false schema: type: string requestBody: required: true content: application/json: schema: type: object required: - items properties: items: type: array minItems: 1 maxItems: 50 items: type: object required: - from - to properties: from: type: string format: uuid description: The 8xxx Versa-migration leaf to drain. to: type: string format: uuid description: >- The native Arcus GL account (system_account_key NOT NULL) to receive the JE lines. soft_delete_source: type: boolean default: false description: >- When true AND zero JE lines remain on FROM after the swap, soft-delete FROM in the same transaction. responses: '200': description: GL-account remap batch result content: application/json: schema: type: object properties: object: type: string enum: - migration_gl_account_remap_batch total: type: integer succeeded: type: integer failed: type: integer total_je_lines_moved: type: integer total_sources_soft_deleted: type: integer results: type: array items: type: object properties: from: type: string format: uuid to: type: string format: uuid status_code: type: integer moved: type: integer source_soft_deleted: type: boolean error: type: string code: type: string hint: type: string '400': $ref: '#/components/responses/Error' '401': $ref: '#/components/responses/Error' '403': $ref: '#/components/responses/Error' '404': $ref: '#/components/responses/Error' security: - ApiKeyAuth: [] components: responses: Error: description: Error response (400/401/403/404/409/422/429/500) content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' schemas: ErrorEnvelope: type: object description: | Canonical error response envelope. All API errors use this shape. required: - error - code properties: error: type: string description: Machine-readable error key example: not_found code: type: string description: Machine-readable error code (often same as error) example: not_found type: type: string enum: - validation_error - permission_error - not_found - conflict - rate_limit - internal - expand_error - not_implemented example: not_found hint: type: string description: Human-readable one-sentence explanation (English) example: >- The requested order does not exist or does not belong to this entity. param: type: string description: The parameter that caused the error, if applicable example: expand[0] required: type: string description: The scope required (only on insufficient_scope errors) example: accounts:read request_id: type: string description: >- Unique request ID for support tracing (maps to CloudWatch log stream) example: req_abc123 securitySchemes: ApiKeyAuth: type: http scheme: bearer description: | API key issued per entity via Settings > Developers > API Keys. Each key carries scopes (e.g. orders:read, products:write). Bearer token format: Authorization: Bearer ark_live_ent__ Test keys use ark_test_ent__. Both are issued per entity via Settings > Developers > API Keys. ````