# Partners Partners represent the trading partners you exchange EDI documents with. Each partner brings together the envelopes, connection, webhooks, and transaction settings needed to process EDI -- and from that configuration, Tediware builds the processing flows that handle your documents automatically. ## Creating a Partner 1. Navigate to **Partners** and click **Add Partner** 2. Fill in the required fields: - **Name** -- a display label for your reference. Not visible to trading partners. - **Key** -- a unique identifier for this partner, used in API endpoints and internal references. Must be 3-50 characters, uppercase letters, numbers, and underscores only. The key cannot be changed after creation. - **Starting Interchange Control Number** -- the first interchange control number to use. Defaults to 1000. - **Starting Group Control Number** -- the first group control number to use. Defaults to 1000. - **Tags** -- optional labels for organizing your partners. 3. Click **Create** ## Configuring a Partner After creating a partner, open it from the partner list to access the detail page. The **Configuration** card contains the settings that define how this partner communicates: - **Internal Envelope** -- your organization's EDI identity (sender for outbound, receiver for inbound) - **External Envelope** -- the trading partner's EDI identity - **Connection** -- the SFTP, AS2, or API connection used to exchange files with this partner - **Inbound Webhook** -- notified when EDI documents are received and processed from this partner - **Outbound Webhook** -- notified when EDI documents are successfully delivered to this partner (optional) - **Error Webhook** -- notified when processing errors occur (optional) After making changes, click **Save** to persist the configuration. ## Control Numbers EDI transmissions include control numbers in their ISA and GS headers to uniquely identify each interchange and group. Tediware automatically increments these numbers with each transmission sent to the partner. The partner detail page displays the current control number values. To adjust the starting point, click **Settings** and update the starting interchange or group control number. The next transmission will use whichever value is higher -- the starting number you set or the next number in the existing sequence. ## Transaction Settings Transaction settings define which X12 document types you exchange with a partner. Each setting specifies a transaction set (e.g., 810 Invoice, 850 Purchase Order) and its direction. ### Inbound Inbound transaction settings identify the document types you receive from the partner. They do not require an implementation or mapping -- Tediware parses inbound EDI using the standard X12 specification. To add one, click **Add** in the Inbound Transaction Settings section and select the transaction set. ### Outbound Outbound transaction settings identify the document types you send to the partner. Each outbound setting requires either: - An **implementation** -- the partner-specific EDI specification that governs how the document is structured - A **mapping** with an associated implementation -- a JSONata transformation that converts your JSON data into the format defined by the implementation Using a mapping is highly recommended. Without one, the JSON data you submit must precisely comply with the implementation's schema, which can be complex and error-prone. A mapping lets you transform your data from whatever structure is convenient for you into the required format automatically. The detail page shows the API endpoint for each outbound transaction set (e.g., `/partners/ACME/ts/810`), which you use to submit data for processing. To add one, click **Add** in the Outbound Transaction Settings section, select the transaction set, and assign an implementation and optionally a mapping. ### Remote Directory When a partner uses an SFTP connection, each transaction setting has an optional **Remote Directory** field. By default, Tediware fetches inbound files from, and uploads outbound files to, the directories set on the connection. A Remote Directory on a transaction setting overrides that default for just that document type. Leave it blank to use the connection's default directory. Inbound fetches still poll the connection's default directory as well, so a transaction setting without an override is always covered. The field does not apply to non-SFTP connections, or to VAN-routed connections where all files use the connection's default directory. ## Flows Flows are the processing pipelines that Tediware builds from your partner configuration. There are two flows per partner -- one for inbound documents and one for outbound. ### Building a Flow Once the partner's configuration is complete (envelopes, connection, webhooks, and at least one transaction setting), the **Flows** card on the partner detail page enables the **Build** button. Click it to generate the flow. If the button is disabled, hover over it to see which configuration is missing. ### Flow Status After building, each flow shows its status: - **Active** -- the flow is live and processing documents - **Pending** -- the flow has been built but is not yet active Click the flow name to navigate to its detail page. ### Rebuilding After Changes When you change a partner's configuration after a flow has been built, a **Changed (rebuild)** indicator appears on the affected flow. Click **Rebuild** to update the flow with the new configuration. Until you rebuild, the flow continues operating with its previous configuration. ## Automatic 997 Acknowledgments A 997 Functional Acknowledgment is the EDI message that tells a trading partner "we received your file." Tediware can generate and send a 997 automatically for every inbound EDI document it successfully parses from a partner. Enable it on the **Configuration** card of the partner detail page via **Automatically send 997 acknowledgments**. ### What auto-ack validates The 997 is an **envelope-layer acknowledgment**. It confirms that an inbound interchange arrived, was structurally well-formed, and parsed cleanly against the X12 standard. It does **not** confirm that the data inside the document makes business sense, that your downstream systems accepted it, or that any order, shipment, or claim will be fulfilled. Concretely, when auto-ack is on: - Every transaction set (ST) that parses cleanly is marked accepted (`AK5*A`) and the group-level `AK9` also reports accepted. - Tediware does not currently emit partial-accept codes (`AK5*R` for syntax-valid but malformed data) or segment- and element-level error detail (`AK3`/`AK4`). - If Tediware cannot parse an inbound file at all, no 997 is sent today. Partners expecting an ack on every inbound may notice this as silence. More granular reject behavior is on the roadmap. ### Who should turn this on Turn it on when your trading partner expects a 997 for every inbound file and you don't already generate one yourself. This is the common case for partners who treat EDI as plumbing and rely on their counterparty to provide envelope-layer acknowledgment. Leave it off when: - You (or a system upstream of Tediware) already send 997s based on your own business processing -- enabling auto-ack would result in duplicate 997s. - Your trading partner's contract requires 997s that reflect business validation outcomes (the automatic 997 always reports "accepted" on a parsed file, regardless of what happens downstream). - You exchange HIPAA traffic and your partner expects a 999 Implementation Acknowledgment -- 999 support is not yet available. ### What to monitor - **Ack volume per partner.** A partner that suddenly stops receiving 997s after inbounds is usually a sign something has broken upstream. Tediware's logs and traces for the inbound flow will show whether the ack node ran. - **Unexpected 100% accept rate.** This is normal for the current implementation -- every parsed file is accepted. If your trading partners or internal teams expect a mix of accepts and rejects, let us know; we can discuss stricter ack semantics for your account. ### Control numbers for 997s Outbound 997s consume interchange and group control numbers from the same pool as any other outbound document for that partner. Tediware increments them automatically. No separate configuration is required. ### Roadmap More granular ack behavior -- rejecting syntactically valid but malformed data, emitting segment- and element-level error codes (`AK3`/`AK4`), and supporting the HIPAA 999 -- is on the backlog. If your trading partner has specific ack requirements beyond envelope-layer accept, get in touch via **Get Support** and we can prioritize accordingly. ## Tracking 997 Acknowledgments for Outbound This is the reverse of automatic 997s above: instead of sending a 997 for documents you receive, Tediware watches for the partner's 997 replies to documents you send. When it is on, every outbound document to this partner starts out **Awaiting 997** on the [EDI Transactions](edi-transactions.md) page, then flips to **Accepted** or **Rejected** when the partner's 997 arrives, so you can search and filter by which of your sent documents the partner has acknowledged. Turn it on or off with **Track 997 acknowledgments for outbound** on the **Configuration** card. It is on by default. Leave it off for a partner that does not send you 997s, so their sent documents don't sit in an Awaiting state that will never clear. The setting only affects documents sent after you change it, and takes effect without rebuilding any flow. Matching is by group control number (GS06). A 997 reports acceptance at the envelope layer: **Rejected** means the partner's 997 reported a problem with the group, which you can inspect by opening the transaction and its trace. ## Partners with Multiple ISA Identifiers Some trading partners use different ISA identifiers for different transaction types. A carrier might use one ID for operational transactions (204, 990, 214) and a separate billing ID for financial transactions (210). Model each distinct ISA identifier as its own partner. Each identity then has its own transaction settings, mappings, and control number sequences, which matches how the partner actually addresses you. To set this up: 1. Create a partner for each distinct ISA identifier. 2. Point each partner at the same connection. 3. Give each partner its own envelope configuration with the appropriate ISA ID. 4. Name the partners clearly to show the relationship, for example "Acme Trucking" and "Acme Trucking (Billing)". Inbound files are routed to the correct partner by matching the ISA sender and receiver IDs against each partner's envelope, the same matching used for VAN routing (see the Connections documentation). Give each partner a distinct envelope identity. If two partners on the same connection share the same ISA sender and receiver identity and both have an active inbound flow, Tediware cannot decide which one an inbound file belongs to, so neither partner receives it. When you activate an inbound flow that would create this conflict, Tediware names the conflicting partner and asks you to confirm before continuing. ## Partner Settings Click the **Settings** button on the partner detail page to open a modal where you can edit: - **Name** - **Starting Interchange Control Number** - **Starting Group Control Number** - **Tags** Changes made in the settings modal are staged locally. Click **Save** on the main page to persist them along with any other configuration changes. ### Duplicating a Partner To copy an existing partner, open it and click **Duplicate** (also available from the actions menu in the **Partners** list). This is useful when a new partner shares most of its configuration with one you already have, or when you need a second identity for the same partner. The duplicate copies the source partner's configuration (envelopes, connection, webhooks, settings, and all of its transaction settings, including any Remote Directory overrides) and its tags. A form pre-fills a new name, key, and starting control numbers so the copy does not collide with the source. Adjust them before clicking **Duplicate**. Flows are not copied. Open the new partner and rebuild its flows when you are ready. The sandbox partner cannot be duplicated. ### Deleting a Partner To delete a partner, go to the **Partners** list, find the partner, and click **Delete** in the actions column. You will be asked to confirm. Deleting a partner removes its associated flows and transaction settings.