OLO2OLO Panservice: migrations and codes

Scope

OLO2OLO is the Panservice integration for operator and COW catalogs, migration-code checks, outgoing migrations, incoming migrations, and formal or management communications. FiberCop provisioning is separate and does not share credentials, order rules, or files.

Use OLO2OLO as the authoritative workflow only for the contracted processes and retain customer authorization and source-service evidence outside the migration code itself.

API configuration

Enter the provider HTTPS Base URL and a dedicated token. Saving validates the authenticated profile inside the same transaction; invalid credentials roll back the configuration instead of leaving an unusable value stored.

Keep the token out of screenshots, URLs, and support material. After saving, open Operators and verify that the catalog belongs to the intended Panservice environment and account.

Operators and COW catalog

Filter operators by current name, historical name, or native COW. Detail can include provider identifier, associated COW codes, technical endpoints, contacts, IP addresses, and certificates.

The COW catalog is remotely paginated and can be filtered by operator, native COW, and usable value. Reread current data instead of copying a historical code list into local notes.

Migration-code verification

Submit the complete customer-provided code to the provider check without silently correcting or completing it. Preserve the original value for traceability while showing normalized interpretation separately.

A syntactically valid code does not prove account-holder ownership, service portability, or absence of an already-running migration. Perform the commercial and identity checks required by the process.

Create a migration

Provide either the full migration code or its COW, COR, and COS parts. A complete code is uppercased and stripped of spaces; when parts are absent, the first three characters form COW, the last character COS, and the middle segment COR.

Enter the external supply-order code, optional recognizable name and note, and directory numbers separated by comma, semicolon, or line. Search existing migration codes and external orders first to prevent duplicates.

Created migrations and real state

Creation stores the provider order code and an immutable snapshot of submitted values with the local Created state. Choose Send file now only when immediate provider transmission is required; otherwise the OLO2OLO server schedule handles the file.

The module intentionally does not invent a local file-send status refresh. Formal and management progress is learned from provider communications, which must be read before changing operational state.

Notifications for sent migrations

Refresh communications for all local orders or one provider order code. ISP Billing deduplicates by order and communication type and preserves phase, recipient and donating operators, resource, request status, rejection code and reason, dates, session, directory numbers, and waiting window where supplied.

Interpret formal rejection separately from management progress. Do not mark the customer service migrated solely because a communication was downloaded.

Received migrations and management errors

Incoming notifications are fetched from provider order codes and deduplicated by order and communication type. Records retain resource, service, session, numbers, customer, dates, and phase-two formal or management errors.

When the provider workflow requires it, Send management error transmits the selected error code and note externally and records the communication. Verify target order, resource, phase, permitted cause, and wording before sending.

Scheduled synchronization

The protected multi-tenant process iterates configured ISPs and imports new received order/type pairs. Failure on one order or tenant is isolated so the remaining scope continues, with errors available for review.

Outgoing-migration notifications use their own manual refresh, globally or by order code. Monitor both paths and do not assume that one scheduler updates every OLO2OLO surface.

Permissions and security

Separate catalog and migration reading from creation, refresh, and externally transmitted management errors. Grant write operations only to staff responsible for number portability.

Protect token, operator contacts, certificates, customer identifiers, telephone numbers, and provider payloads. Export or copy only the fields required for an authorized case.

Checklist

• Use a dedicated provider token
• Verify the authenticated profile and environment
• Read current operator and COW catalogs
• Check the unmodified customer migration code
• Verify customer authority and service portability
• Search migration codes and external orders for duplicates
• Choose immediate or scheduled file handling deliberately
• Read formal and management communications separately
• Validate management errors before external sending
• Monitor manual outgoing refresh
• Monitor the received-notification scheduler and errors
• Restrict write permission and protect payloads